Storing information for post-proc

[tdixon97]

There is information not included in the GDML file that is useful for post-processing.

• mapping of remage ID (det001 etc.) to the channel name,
• which surface has which type, can be obtained from legend-pygeom-hpges given the metadata block,

This is partly solved by #56 but we should think about if this fits better there or in the remage output and on what auxval info we want.

• just mapping to channel name ?
• also the full metadata block
  also GDML is not very human readable so maybe we can do something better eg attaching this information to the remage lh5 output.
  What do you think @gipert / @ManuelHu ?

[gipert]

I think that what we have to do is to store the full (legend-)metadata detector dictionary (geometry, characterization data, etc.) along with the sensitive detector in the output GDML file. This would simplify post processing by a lot and minimize the amount of mistakes. I think storing in GDML makes more sense than the simulation output, since it is logically related to "geometry".

In remage, I am kinda convinced that we should store the step data in a table named after the detector (e.g. "C0000RG1"). See legend-exp/remage#153.

[tdixon97]

Another idea we considered (@ManuelHu ) was splitting the HPGe sensitive volume into 2 parts. A central part and a surface (ie everything within 5 or 10 mm), this might allow us to speed up significantly the post-processing if we find that the activness is the bottleneck

[gipert]

I have opened a remage issue about this

[ManuelHu]

There are two ways to attach any user defined data in a GDML file:

• globally, to the file
• locally, to a logical volume

for the sensitive detectors we needed to use the global way, as they are part of the physical volumes. And there we cannot attach auxvals.

for the hpge data we could store them in the logical volume auxvals, as they are more part of the geometry (and not really part of the volume tree).

if we need the data for sipms, we need to use the global way - they do not have indivisual logical volumes (they only have individual physical volumes).

[tdixon97]

How easy is it to read back the information?

…

________________________________ From: Manuel Huber ***@***.***> Sent: Sunday, November 10, 2024 8:30 PM To: legend-exp/legend-pygeom-l200 ***@***.***> Cc: Dixon, Toby ***@***.***>; Author ***@***.***> Subject: Re: [legend-exp/legend-pygeom-l200] Storing information for post-proc (Issue #59) ⚠ Caution: External sender There are two ways to attach any user defined data in a GDML file: * globally, to the file * locally, to a logical volume for the sensitive detectors we needed to use the global way, as they are part of the physical volumes. And there we cannot attach auxvals. for the hpge data we could store them in the logical volume auxvals, as they are more part of the geometry (and not really part of the volume tree). if we need the data for sipms, we need to use the global way - they do not have indivisual logical volumes (they only have individual physical volumes). — Reply to this email directly, view it on GitHub<#59 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANSET425WMGRYH3F5X6N45TZ76X6ZAVCNFSM6AAAAABRPMX2BGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRWHA2TSMRQGI>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[gipert]

for the sensitive detectors we needed to use the global way, as they are part of the physical volumes. And there we cannot attach auxvals.

Can you elaborate on this? As you said the SiPM metadata cannot be attached to the logical volume and I would not implement things differently. Would we store something like a mapping between sensitive (physical) volume names and metadata?

[ManuelHu]

How easy is it to read back the information?

In python you can easily get the information, it's essentially available as a key-value store (not a dict, so you have to iterate all attached pairs, I think). In C++, I never used it, but I think it's similar.
If we attach information to LV's, one first has to retrieve the volume instance, but that's (in python) also very straight-forward.

Would we store something like a mapping between sensitive (physical) volume names and metadata?

That would be one option (and probably also the "easiest"). Essentially, this would be very similar to #56 (which is a mapping between physical volume name and sensitive detector type & detector uid)

[ManuelHu]

fixed with #72

>>> reg = pyg4ometry.gdml.Reader("geom-2024-12-07.gdml").getRegistry()
>>> import pygeomtools as p
>>> p.get_sensvol_metadata(reg, "V02160B")
{'name': 'V02160B', 'system': 'geds', 'type': 'icpc', 'production': {...}, 'geometry': {...}, 'characterization': {...}, 'analysis': {...}, ...}