Non reproducible order of daughter volumes in Geant4 geometry.

[WitekPokorski]

Check duplicate issues.

• Checked for duplicates

Goal

When the geometry is converted from TGeo to Geant4 the order in which the daughter volumes are attached to mother volumes is not preserved. This can be seen by using the

inline size_t GetNoDaughters() const;
// Returns the number of daughters (0 to n).


inline G4VPhysicalVolume* GetDaughter(const G4int i) const;
// Returns the ith daughter. Note numbering starts from 0,
// and no bounds checking is performed.

methods of G4LogicalVolume. Between two runs, the results can be different for each ‘i’ index.

This may be a source of non-reproducibility if an algorithm iterates over the daughter volumes, and in particular in the case of overlaps, this gives non-reproducibilty of potential crashes.

The source of the problem (thanks to Markus’ investigation) is in:

"""

DD4hep/DDCore/include/DD4hep/GeoHandler.h

Line 68 in 169fc4f

class GeometryInfo {

When scanning the ROOT geometry DD4hep stores the object handles to be converted in sets,
which are then indexed by the pointer values.
Depending on the value the OS returns pointers to the process, the order in the set is defined.
This order on moderns OSes in indeterministic due to address randomization.
This then leads to orders, which are not the same.
"""

The idea would be to find a way of preserving the order of TGeo daughter volumes when attaching daughter volumes in Geant4 geometry. This would guarantee the reproducibility between the runs.

Operating System and Version

any

compiler

any

ROOT Version

any

DD4hep Version

any

Reproducer

inline G4VPhysicalVolume* GetDaughter(const G4int i) const;

Additional context

No response

[andresailer]

Hi @WitekPokorski

Can you test #1277 ?

Thanks!

[WitekPokorski]

Is the build of it available anywhere? I am using dd4hep through the LHCb stack and I don't have a local build (nor of ROOT, nor of any dependencies), so I am wondering how can I tried it out without building everything from scratch.

[MarkusFrankATcernch]

Then you will probably have to wait until Ben will prepare a new LHCb stack, because LHCb also does not use the LCG views.

[WitekPokorski]

I have tested v01-29 with the LHCb geometry and I confirm that the problem is fixed.