Update metadata volume information print

[lobis]

Be more clear on the print and show the volume id for the active volume (instead of the active volume id which is just their user-specified order)

[lobis]

@jgalan please let me know if this solves the issue, if using the now-displayed volume ids to compute the quantities returns the correct values, and feel free to merge this PR

[jgalan]

Yes, it works for me, now when I call md0_restG4run->PrintMetadata() I get the IDs as it should be.

@girardcarillo does this solve also your issue? I.e. when you use the ids that print out on your metadata you get the right values?

@lobis A topic aside is the fact that when testing the CosmicMuons.rml example, I would expect that the muon goes through both detectors up and down. I modified a bit the geometry so that the active area would cover all the XY plane, but still cosmics were not going through both detectors. This is because cosmic seem to be randomly distributed in the 3 dimensions. I would expect that the cosmic would be generated on the TOP wall of the World volume, isn't?

This is the generator:

        <generator type="cosmic">
            <source particle="mu-">
                <energy type="formula2" name="CosmicMuons" nPoints="5000"/>
                <angular type="formula2" direction="(0,-1,0)" nPoints="500"/>
            </source>
        </generator>

[lobis]

Yes, it works for me, now when I call md0_restG4run->PrintMetadata() I get the IDs as it should be.

@girardcarillo does this solve also your issue? I.e. when you use the ids that print out on your metadata you get the right values?

@lobis A topic aside is the fact that when testing the CosmicMuons.rml example, I would expect that the muon goes through both detectors up and down. I modified a bit the geometry so that the active area would cover all the XY plane, but still cosmics were not going through both detectors. This is because cosmic seem to be randomly distributed in the 3 dimensions. I would expect that the cosmic would be generated on the TOP wall of the World volume, isn't?

This is the generator:

        <generator type="cosmic">
            <source particle="mu-">
                <energy type="formula2" name="CosmicMuons" nPoints="5000"/>
                <angular type="formula2" direction="(0,-1,0)" nPoints="500"/>
            </source>
        </generator>

No, the cosmic generator does not necessarily generate the primaries from the top, they could be generated for example from the side of the world if the sampled zenithal angle was close to 90º. It would be equivalent to having an infinite plane above the detector (but very far away) so in some cases it looks like it's being produced from the side.

With this generator is not possible to garantee that both detectors will be hit (as it would be impossible with regular muons) but I imagine in a good % of events this is the case.

[jgalan]

Ok, then I will check the percentage of events crossing both and place as a validation pipeline at this PR.

[jgalan]

Would not be better to re-implement the method GetActiveVolumeID?

We could just:

Int_t GetActiveVolumeID( name ) { return fGeant4GeometryInfo.GetIDFromVolume(name); }

[lobis]

I'm not sure it won't cause problems elsewhere but it could be done. But in that case why not just implement TRestGeant4Metadata::GetVolumeID(const std::string& name)? The idea of the TRestGeant4GeometryInfo is to not overload TRestGeant4Metadata with members and methods related to geometry (same things for TRestGeant4PhysicsInfo, but I guess some of them could be duplicated, if it's deemed useful.

[girardcarillo]

@girardcarillo does this solve also your issue? I.e. when you use the ids that print out on your metadata you get the right values?

No it doesn't seem to have changed my problem

[jgalan]

Hi @girardcarillo , please make sure you are on the latest geant4lib version.

If you do git log inside the source/libraries/geant4/ directory you should get:

commit de9a39207d082a65f402ed41dd7ec72e82f98f8a (HEAD -> 99-problem-retrieving-volume-id-at-getenergyinvolume, origin/99-problem-retrieving-volume-id-at-getenergyinvolume)
Author: Javier Galan <[email protected]>
Date:   Mon Mar 20 19:44:03 2023 +0100

    TRestGeant4Metadata::GetActiveVolumeID now uses fGeant4GeometryInfo

Then, when you open your file using restRoot file.root, check the output of:

ev0->PrintEvent()`

identify some volume names appearing in your event, that got some energy deposits, and do:

ev0->GetFirstPositionInVolume( md0_restG4run->GetActiveVolumeID( "det_dw_01") ).Print()

where det_dw_01 is the volume you identified in your geometry (The line above works using the file generated from the example 04.MuonScan/CosmicMuons.rml).

[jgalan]

If you compiled the right version, then the 04.MuonScan/CosmicMuons.rml example will produce the following output:

              ||                                ++++++++++ Detector +++++++++++                                 ||              
              ||                                 Energy range (keV): (0, 1e+20)                                 ||              
              ||                                 Number of sensitive volumes: 1                                 ||              
              ||                                  Sensitive volume: det_dw_01                                   ||              
              ||                                  Number of active volumes: 2                                   ||              
              ||                        Name: det_dw_01, ID: 1, maxStep: 1mm , chance: 1                        ||              
              ||                        Name: det_up_01, ID: 0, maxStep: 1mm , chance: 1                        ||              
              ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++  

[lobis]

I just noticed this small PR was left hanging, should we merge it @jgalan ?