Home » R3BRoot » Data Analysis » Data levels in R3Broot - suggestion
| Data levels in R3Broot - suggestion [message #18907] |
Wed, 20 January 2016 13:07  |
Ralf Plag
Messages: 25
Registered: September 2015
|
continuous participant |
From: *gsi.de
|
|
To avoid further chaos we need to define some common data levels.
In land02 we have:
RAW-level: mapped data (e.g. plane, bar, pm), no calibration applied
TCAL-level: time-slope and energy-offset applied
SYNC-level: fully calibrated: time-sync and energy-slope applied as well
DHIT-level: Physical quantities in the detector internal coordinate system
HIT-level: Physical quantities in cm, ns, MeV
In ucesb we have:
UNPACK: module, channel
RAW: mapped, as above
Unfortunately, in R3BRoot, RAW-level corresponds to the ucesb UNPACK-level.
I'd like to suggest three base levels which every detector should use. Additional levels can be added if needed.
MAPPED-level: mapped data (e.g. plane, bar, pm), no calibration applied
CAL-level: Fully calibrated
HIT-level: Physical quantities in cm, ns, MeV
Note:
UNPACK level is not needed in R3BRoot since this is provided by ucesb in stand-alone mode.
Since the term "RAW-level" is ambiguous, I suggest not to use it at all. MAPPED is nicely descriptive and intuitive, so we better use that and it should always refer to the detector channel (e.g. bar, pm) and not to the electronics channel (module, channel).
Existing data structures called "RAW" (mostly holding UNPACK-data) should be deleted (or if needed for some strange reason renamed into UNPACK).
Cheers,
Ralf
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Data levels in R3Broot - suggestion [message #18966 is a reply to message #18907] |
Tue, 02 February 2016 19:34  |
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
|
|
|
|
| Re: Data levels in R3Broot - suggestion [message #18967 is a reply to message #18966] |
Wed, 03 February 2016 08:16 |
Dmytro Kresan
Messages: 166
Registered: June 2004
|
first-grade participant |
From: *gsi.de
|
|
Hector Alvarez Pol wrote on Tue, 02 February 2016 19:34
- 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
Ralf has mentioned about introducing intermediate levels on demand. This option is definitely not excluded.
Hector Alvarez Pol wrote on Tue, 02 February 2016 19:34
- 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 .
This will work better, since names of data classes are used more often in the analysis code than names of tasks.
Hector Alvarez Pol wrote on Tue, 02 February 2016 19:34
- 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.
To my opinion - "Finder" is in some cases misleading. It is suitable for clusters reconstruction, hit finding, etc, but not for calibration.
|
|
|
|
| Re: Data levels in R3Broot - suggestion [message #18968 is a reply to message #18907] |
Wed, 03 February 2016 10:29 |
Ralf Plag
Messages: 25
Registered: September 2015
|
continuous participant |
From: *gsi.de
|
|
Hi All,
I want to strongly encourage using descriptive names. This makes life easier, especially for beginners, and we need as many people (aka beginners) as possible to work on R3BRoot.
And that's why I like the suffix "Item": It describes that the class holds ONLY ONE Item, as opposed of all MAPPED or CAL level data.
...and why I like Hector's suggestion to add an suffix to the converter classes. What about "Builder"? E.g. R3BTofHitBuilder?
...and why I don't like the names of the suggested intermediate levels precal1 and precal2 (or have that been only generic examples?) What is the difference between those two and between Cal?
And as already mentioned: Of course we need also other levels than MAPPED, CAL, HIT. My idea was the these three levels should be available for ALL detectors. Other levels can be always introduced in addition, as needed, although it would be fine if we could define at least some common names for those additional levels as well.
However we decide, we should decide fast since a lot of development is already ongoing. I'd like to set end of next week as deadline for the naming decision.
Cheers,
Ralf
|
|
|
|
| Re: Data levels in R3Broot - suggestion [message #18969 is a reply to message #18968] |
Wed, 03 February 2016 11:14 |
Hector Alvarez Pol
Messages: 21
Registered: July 2015
Location: Univ. Santiago de Compost...
|
occasional visitor |
From: *usc.es
|
|
Hi,
yes, we should converge soon. And I agree that descriptive names are the best for everyone.
- I also agree with Builder as Ralf said. As pointed out by Dmytro, Finder is not suitable for all, but it could even be better to simply say that it could be Builder or any other similar word that suits perfectly to the task (as could be "Converter", "Filter", "Calibrator"???).
- Precal1, Precal2 were simply generics. I was trying to state that we can have several intermediate data levels. I agree with you that intermediate levels could be added for detectors provided the name is clear enough, and we should fix some basis (Mapped, Cal, Hit, ...). We could ask simply for agreement before selecting the name of additional intermediate states to ensure that the name is ok.
- The only point where we disagree (I think) is in the Item for data levels. In my opinion, a level like R3BNeuLandHit or R3BCalifaCrystalCal is clear enough, and I do not need the word Item to understand that is a data level. It is impossible to mistake them with "conversors" as they will have the Builder suffix, or parameters with the Par suffix. So, I do not understand Ralf's quote: "It describes that the class holds ONLY ONE Item, as opposed of all MAPPED or CAL level data", because all classes are abstraction of objects and are a single item in a sense. Then, one could instantiate many objects... Maybe I did not get the point properly.
Best regards,
Héctor
|
|
|
|
| Re: Data levels in R3Broot - suggestion [message #18970 is a reply to message #18907] |
Wed, 03 February 2016 13:21 |
Ralf Plag
Messages: 25
Registered: September 2015
|
continuous participant |
From: *gsi.de
|
|
Hi Hector and All,
I do understand what you mean. However, I'm trying to look at the project from an outsider's perspective. Meaning: I'm trying to "forget" everything I know about R3BRoot. And then I wouldn't have any idea what R3BCalifaCrystalCal is about. I probably would assume it is performing some calibration.
We just had a small internal discussion (Dima, Haik, me) and came to the following suggestions:
Converters should be called R3B[Detector][FromLevel][ToLevel], e.g. R3BCalifaCrystalMappedCal or maybe with a '2': R3BCalifaCrystalMapped2Cal
Data classes should be called R3B[Detector][Level]Data
Calibration parameters should be called R3B[Detector][Level]Par
I admit that the 'Data' is not strictly necessary but it nicely marks all classes of the same type, which makes reading code for newbies much easier.
We also decided to collect more ideas here up to Friday this week and then send around the final/best idea via email to the analysis mailing list to give everybody else the chance to raise their voice.
Cheers,
Ralf
[Updated on: Wed, 03 February 2016 13:22] Report message to a moderator |
|
|
|
|
|
|
|
| Re: Data levels in R3Broot - suggestion [message #18979 is a reply to message #18975] |
Thu, 04 February 2016 10:48 |
Dmytro Kresan
Messages: 166
Registered: June 2004
|
first-grade participant |
From: *gsi.de
|
|
I propose to have a branch name in the output tree same as the data class name, but without prefix R3B. In this case it will be easy to recognise type of object stored. For example class R3BNeulandCalData will be stored in a branch "NeulandCalData". Concerning simulation part, I would not touch it now. So class R3BTofPoint is stored as TofPoint. The only change in the simulation part we have to do now, is that Digitizers or HitFinder arrive at the same HIT level as calibrated and analysed data.
Cheers,
Dima
|
|
|
|
Goto Forum:
Current Time: Sat Apr 27 07:46:50 CEST 2024
Total time taken to generate the page: 0.00742 seconds
|
GSI Forum
Search
Help
Members
Login
Home
