Hi Carla, A possible solution to your problem: Create an Event class with TClonesArray *fPixels; //holding all the pixels of one event Int_t fClusterCount[130]; //number of pixels fired per cluster Int_t fRPCCount[4][130]; //number of pixels per RPC per cluster Int_t fOtherCounts[..][..] Rene Brun Carla Bleve wrote: > > Thank you for your answer, > > I work in the ARGO-YBJ collaboration (ground based detection of > extensive air showers). Our detector is a full-coverage carpet of RPC > (under construction). The central part of ARGO is a matrix of 120X130 > logical units or pixels. Ten pixel (2X5) is a RPC, 3 RPC (3X1) is a module > and 4 modules (2X2) is a 'supermodule' (actually we call it 'Cluster'). > This grouping is related to electronics, high voltage, etc. > At the moment we are analyzing about 10^6 events (few minutes of data > taking) to check the behaviour of electronics, RPCs , trigger logic,... > so that I need to retain all possible information (ex. plot of time distribution > of first pixel in a module, selection of RPCs with at least 1 pixel in the > trigger > peack, time delay versus distance for different pixels, average number of > fired RPC in a Cluster, etc.) The complicated event structure has been > thought to face all possible query and to avoid repetitions. > Of course I need some functions and macros > for looping on whatever I want but they need a very large run time. > On the other hand a simpler design implies a lot of repetition and > doesn't avoid loops (how to count for ex. the number of fired RPC in a module > for each event? At the moment I'm using the TClonesArray::GetEntries() > method) > Very likely there is no simple answer to the problem, however, since I'm > not an expert ROOT user, I wonder if you can suggest a more efficient > (completely different?) strategy for data storage. > Thank you again. > > Carla Bleve > > Rene Brun wrote: > > > Hi Carla, > > > > Making a TClonesArray of TClonesArray is going against the spirit of a > > TClonesArray. That is the reason why we do not split the TClonesArray > > at the second level. > > > > It is somehow difficult to come with a meaningful proposal without knowing > > more about your structure (number of supermodules, modules, etc) and the type > > of queries you want to make. > > > > I have, however, the feeling that a simple structure with one single > > TClonesArray will be the most efficient and simple solution to your problem. > > If you have a pixel class, add new members to store the supermodule and module > > numbers for each pixel. This will consume less space on the file and will > > also facilitates the queries. > > > > Rene Brun
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:43 MET