Nested volumes in GDML not added to physical and logical volumes names (?)

[mariajmz]

I was trying to use a gdml where one volume (gasVolume) contains a nested physical volume (sample) defined like this inside the structure node:

<volume name="sampleVolume">
    <materialref  ref="Copper"/>
    <solidref ref="sampleSolid"/>
</volume>

<volume name="gasVolume">
    <materialref ref="Ar_ISO"/>
    <solidref ref="gasSolid"/>
    <physvol name="sample">
        <volumeref ref="sampleVolume"/> <!-- sample inside the gas -->
        <position name="sample.position" x="sample_XPosition" y="sample_YPosition" z="sample_ZPosition" unit="mm"/>
    </physvol>
</volume>

Then the gas physical volume is placed inside the world volume:

<volume name="World">
        <materialref ref="Air"/>
        <solidref ref="WorldSolid"/>

        <physvol name="vesselTopcover">
            <volumeref ref="vesselTopcoverVolume"/>
            <position name="vesselTopcover.position" z="vesselTopcover_ZPosition" unit="mm"/>
        </physvol>

       <physvol name="readout">
            <volumeref ref="readoutVolume"/>
            <position name="readout.position" z="readout_ZPosition" unit="mm"/>
        </physvol>

        <physvol name="gas">
            <volumeref ref="gasVolume"/>
            <position name="gas.position" z="gas_ZPosition" unit="mm"/>
        </physvol>
        
        <physvol name="cathode">
            <volumeref ref="cathodeVolume"/>
            <position name="cathode.position" z="cathode_ZPosition" unit="mm"/>
        </physvol>

        <physvol name="gasbelow">
            <volumeref ref="gasbelowVolume"/>
            <position name="gasbelow.position" z="gasbelow_ZPosition" unit="mm"/>
        </physvol>

        <physvol name="vesselBottomcover">
            <volumeref ref="vesselBottomcoverVolume"/>
            <position name="vesselBottomcover.position" z="vesselBottomcover_ZPosition" unit="mm"/>
        </physvol>

        <physvol name="vessel">
            <volumeref ref="vesselVolume"/>
            <position name="vessel.position" z="vessel_ZPosition" unit="mm"/>
        </physvol>

   </volume>

ROOT is capable of parsing this geometry, because I can visualize it

The problem appears when I try to use this geometry in a restG4 simulation. The sample volume is not recognized and is missing from the list of physical and logical volumes:

This message is displayed while launching the simulation:

TRestGeant4GeometryInfo::GetIDFromVolume - volume 'sample' not found in store!

Is this an expected behaviour and should I redefine the geometry in a different way?

I think the problem may lie on the TRestGeant4GeometryInfo::PopulateFromGdml method where the list of physical and logical volume names is generated. If this method only iterates over the direct children of the World volume, the sample volume won't be added to the fGdmlNewPhysicalNames list.

[lobis]

I have quickly gone through the issue but I fail to understand the underlying problem. What you describe should work. For instance, the vetoes have multiple levels of depth (veto system, veto layer, individual veto, plastic block, etc.) and this works for them. What is the difference I am missing? Perhaps @JPorron or @mariajmz can expand on this.

The handling of nested volumes is very finicky and not tested properly (as is most of the codebase) so introducing a modification to this behaviour can have unintended consequences.

If possible I would try to make your example work with the existing functionalities, if this is not possible I would be super careful with the changes not to break any existing functionality or simulation, such as the cosmic neutrons simulations, in particular those using scintillating plastic as sensitive / volume of interest together with the cadmium layers / capture volumes also as volumes of interest.

Please @JPorron @mariajmz keep an eye on this!

[mariajmz]

As I understand, for the case of nested volumes, now we can only work with assemblies, that is the case of how all the veto system of the IAXO/BabyIAXO geometries are build. But it's not really a structure based on mother/child volumes. For example, to make this example work, we should make the gas volume surrounds the sample (by making a subtraction on the gas volume) and then the sample can be inside (with the assembly or without it). Otherwise, the geometry would present overlaps. It can be done in this case as it's very simple. But for more complex geometries, like TREXDM chamber, that have many elements inside the gas volume, could be challenging (I think @AlvaroEzq manage to do it with a python code that traduces the geometry from CAD to GDML).

We have to check if the changes break the simulations that are based on assemblies... This will be a problem for all the IAXO's simulations... :(

Ideally, it would be best if it worked with both options, assemblies and parent/child volume structures, but I don't know if that's even possible

[lobis]

We have to check if the changes break the simulations that are based on assemblies... This will be a problem for all the IAXO's simulations... :(

Ideally, it would be best if it worked with both options, assemblies and parent/child volume structures, but I don't know if that's even possible

Indeed it can be very problematic, we either need to write better tests to check this before merging, or adding some kind of "switch" to choose either functionality, just to make sure our assembly sims keep working

[AlvaroEzq]

Ideally, it would be best if it worked with both options, assemblies and parent/child volume structures, but I don't know if that's even possible

I am working on this in the mentioned PRs: #144 and rest-for-physics/restG4#141. After a lot of work, I am confident that is possible to add the nested volumes without breaking the previous behaviour. At the end, its just a matter of mapping correctly de Geant4 physical volume names with their gdml names (paths better said) and these with their logical volumes. Also, to keep the behaviour of previous simulations, this mapping has to be done in the same order to keep the same volumeID, which is simple as previous simulations have plain geometries (no nested volumes, just nested assemblies which their physical volumes end up imprint as direct children of the world volume).