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