L’analyse des DST

1. L’analyse des DST • La base de tout: PHOOL Phenix Object Oriented Library • La méthode d’hier : • « camDataCheck  » • La méthode d’aujourd’hui : • pdst • Ce que demain nous réserve • lecture sélective • accès simplifié aux tables (seul type de données dans les DSTs pour l’instant) L. Aphecetche (aphecetc@in2p3.fr)

2. TOP PHCompositeNode EMC DST PHCompositeNode PHCompositeNode dEmcTempo dEmcCluster PHDataNode PHIODataNode dEmcCalibTower PHIODataNode Transient Persistent PHOOL = données+modules • Des données organisées (en mémoire) sous forme d’arbre = ensemble de nœuds nommés L. Aphecetche (aphecetc@in2p3.fr)

3. Les modules PHOOL • Un module agit sur tout ou partie d’un « node-tree », grâce à sa fonction event: event(PHCompositeNode*) • Les modules eux-mêmes peuvent être mis dans des nœuds… • La navigation dans les nœuds se fait grâce à des itérateurs : PHNodeIterator L. Aphecetche (aphecetc@in2p3.fr)

4. PHOOL et la persistance • Persistance est gérée par des PHxxxManager : • PHNodeIOManager • pour lire/écrire les données dans les DSTs • PHRawOManager • pour écrire les événements dans les PRDF (Phenix Raw Data Format) • Types pouvant être persistants : • PHTable (et dérivés) • Event • TObject (mais Reset pose pb) L. Aphecetche (aphecetc@in2p3.fr)

5. PHOOL • Un framework simple, facile à faire évoluer • 2 formats de persistance pour l’instant: • PRDF (raw data) • ROOT (dst) • Une syntaxe un peu complexe ? • En cours d’ évolution... L. Aphecetche (aphecetc@in2p3.fr)

6. Évolution PHOOL • Contribution SUBATECH: • lecture étiquetée des DSTs • lecture sélective des DSTs (qq tables seulement) • Revient à ajouter qq méthodes à 1 seule classe PHOOL: • PHNodeIOManager::readSpecific(int evt, char* objectName) • PHNodeIOManager::selectObjectToRead(char* objectName) • Déjà dans CVS et dans la release actuelle. L. Aphecetche (aphecetc@in2p3.fr)

7. Lecture DST : camDataCheck • Méthode actuelle pour lire les DSTs. • Utilisées lors des nightly rebuilds et reconstruction pour Q&A de base. • C’est (juste) une macro ROOT. L. Aphecetche (aphecetc@in2p3.fr)

8. camDataCheck • Un PHNodeIOManager recrée en mémoire un node-tree à partir de la DST (TTree Root) • Faire un boucle sur les événements: pour chaque evt : • accéder les différent nodes • accéder les tables/object contenus dans les nodes • remplir des histogrammes L. Aphecetche (aphecetc@in2p3.fr)

9. pdst/process_event à multiplier par le nombre de tables... camDataCheck : exemple PHCompositeNode* topNode =new PHCompositeNode("TOP"); PHCompositeNode* dstNode =new PHCompositeNode("DST"); topNode->addNode(dstNode); PHNodeIterator mainIter(topNode); PHNodeIOManager* dstIn = new PHNodeIOManager(« dstData.root »,PHReadOnly); // Recrée le node-tree en memoire à partir de la DST dstIn->read(dstNode); int i; for (i=0;i<nevent;i++) { if (i>0) dstIn->read(dstNode[,i]) ; // Trouver le nœud contenant la table PHIODataNode<PHTable>* OneNodeTable = (PHIODataNode<PHTable>*)mainIter.findFirst(« PHIODataNode », »dEmcCalibTower »); // Trouver la table dans le nœud dEmcCalibTowerWrapper* dOneTable = (dEmcCalibTowerWrapper*)OneNodeTable->getData() ; } L. Aphecetche (aphecetc@in2p3.fr)

10. De camDataCheck à pdst • Il faut gérer la boucle sur les événements «  à la main » • Solution : pdst(équivalent de pmonitor utilisé online) : • on se connecte à la DST • dfileopen(« dstData.root ») • on lance la boucle sur tous les événements (ou une partie) • drun(); ou drun(Nevents); • à chaque evt, la fonction utilisateur process_event(PHCompositeNode* topNode) est exécutée L. Aphecetche (aphecetc@in2p3.fr)

11. Évolution (possible) de pdst • Problème actuel de pdst : l’ écriture de process_event reste (syntaxiquement) complexe (accès aux nœuds, puis aux tables : beaucoup de casting…) • Proposition faite à phenix-off : nouvelle classe PHDstHelper • ++ Son code peut être généré automatiquement à partir d’une DST L. Aphecetche (aphecetc@in2p3.fr)

12. PHDstHelper process_event(PHCompositeNode* topNode) { PHDstHelper d(topNode) ; float zvertex = d.dEventHeader().get_zdcZVertex(0) ; } • Toute la machinerie des nœuds est maintenant cachée à l’utilisateur qui accède plus directement aux tables. • Principe accepté par M. Purschke (le responsable de pdst). Devrait apparaître bientôt dans CVS. L. Aphecetche (aphecetc@in2p3.fr)

13. D’autres idées ? • Les DSTs contiennent un dRunHeader par événement… • Contribution à la base de données des runs (PHRED) ? • Autre chose que des PHTable dans les DSTs ? • Et si on rêvait d’une base de données des événements ? • Et d’une reconstruction entièrement compilée ? L. Aphecetche (aphecetc@in2p3.fr)