GSI Forum
GSI Helmholtzzentrum für Schwerionenforschung

Home » R3BRoot » Data Analysis » Data levels in R3Broot - suggestion
Re: Data levels in R3Broot - suggestion [message #18966 is a reply to message #18907] Tue, 02 February 2016 19:34 Go to previous messageGo to previous message
Hector Alvarez Pol is currently offline  Hector Alvarez Pol
Messages: 21
Registered: July 2015
Location: Univ. Santiago de Compost...
occasional visitor
From: *usc.es
Hi,

if it's not too late for the definition of the levels, I would like to comment on this topic:

- I agree with the Mapped, Cal, Hit as expressed by Ralf, but this is not a complete list. There could be intermediate calibration levels and different complexity of Hit structures. So, we should give space for Mapped, PreCal1, PreCal2, ..., Cal, Hit, Cluster, Track, ... in principle for a detector, but maybe using information of two or more detectors for the more complex (or complete) levels. We could give a list preferred name levels (fixing some standards as Mapped, Cal and Hit) and adapt and guide the developers for intermediate levels.
- I would not use the word Item for data levels. Just the name composed of R3BDetectorLevel (as in R3BLandCal). For me it should clear enough and identify it .
- I would use instead a modifier for the classes converting data levels. The class to obtain a given level would be R3BDetectorLevelFinder. Another synonym for Finder could also make the job, if you find any better. The second proposal by Ralf (R3BDetectorLevelFrom2LevelTo) is also valid for me, and maybe could work better if there are alternative tasks with different possible origin or destination levels (I do not know if this could happen). But I would prefer the first method according to Dmytro comment ("I would stick to the naming of conversion classes according to the output it produces. Since this is what task supposed to do.")
- Regarding parameters, I would use R3BDetectorLevelPar to identify the parameters used to convert data to a given Level.
- For tasks calculating or collecting parameters (geometrical parameters, calibration parameters, tracking parameters, reconstruction parameters, matching windows, ...) I would use a clear R3BDetectorLevelParFinder.

Regards,

Héctor
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: flag for different data structures
Next Topic: Channel / Crystal / Bar / Detector numbers
Goto Forum:
  


Current Time: Mon Feb 26 06:23:07 CET 2024

Total time taken to generate the page: 0.01082 seconds