Move DECLARE_SEGMENTATIONs for CartesianGridXYStaggered and HexGrid to ReadoutSegmentations.cpp

[veprbl]

This fixes runtime errors like:

libc++abi: __cxa_guard_acquire detected recursive initialization

BEGINRELEASENOTES

• Fixed runtime issues during initialization caused by incorrectly placed DECLARE_SEGMENTATION for CartesianGridXYStaggered and HexGrid.

ENDRELEASENOTES

[github-actions]

Test Results

       6 files         6 suites   6h 45m 30s ⏱️
   356 tests    354 ✔️ 0 💤 2 ❌
1 058 runs  1 056 ✔️ 0 💤 2 ❌

For more details on these failures, see this check.

Results for commit b087cae.

♻️ This comment has been updated with latest results.

[andresailer]

It seems that something in the ROOT HEAD changed the checksums, which is why the tests are failing in dev3 based checks.

[MarkusFrankATcernch]

Should have nothing to do with ROOT. I use the 64 bit checksum from DDCore/src/Primitives.cpp.
Unless the binary representation of 64bit integers changes, this should be invariant.
I need to investigate this a bit.

[andresailer]

The test also fails in DD4hep-master, but was still working on October 19, only the tag was done in the master branch.

[MarkusFrankATcernch]

This must mean that some string is different. Is there anywhere access possible to the "buggy" version or can I build it somewhere on the public platforms ?

[andresailer]

The latest dev3 nightlies are on CVMFS: /cvmfs/sft-nightlies.cern.ch/lcg/views/dev3/latest/

[MarkusFrankATcernch]

@andresailer Do the nightlies also publish somewhere the sources ?
Makes debugging somehow simpler ;-)

[andresailer]

@MarkusFrankATcernch No the sources are not published for the nightlies

[MarkusFrankATcernch]

I think I identified 2 entries, where the problem originates:
good:

DetectorChecksum       +++ Solid     ForwardLowZ_layer1_shape_0x562b922a1660_left    0x9d4f6c7c70c3eb3e
<subtraction lunit="mm" aunit="deg">
 <first ref="0x18cb06802b07fb40">
  3695612514963747814
  9487646648968612427
 </first>
 <second ref="0xd8e9f80287ed466d">
  2554733727480708909
  13351767629364974133
 </second>
</subtraction>
DetectorChecksum       +++ Solid     ForwardLowZ_layer1_shape_0x562b922a1660    0xee0f502c9edb95a8
<subtraction lunit="mm" aunit="deg">
 <first ref="0x9d4f6c7c70c3eb3e">
  3695612514963747814
  9487646648968612427
 </first>
 <second ref="0xd77e4dd72fb4348a">
  11005821857262182534
  8140283773950079902
 </second>
</subtraction>

bad (/cvmfs/sft-nightlies.cern.ch/lcg/views/dev3/latest/):

DetectorChecksum       +++ Solid     ForwardLowZ_layer1_shape_0x4f31340_left    0x86c662618750c673
<subtraction lunit="mm" aunit="deg">
 <first ref="0x18cb06802b07fb40">
  3695612514963747814
  9487646648968612427
 </first>
 <second ref="0xd8e9f80287ed466d">
  2554733727480708909
  9487646648968612427
 </second>
</subtraction>
DetectorChecksum       +++ Solid     ForwardLowZ_layer1_shape_0x4f31340    0xcad2ed1091a6deba
<subtraction lunit="mm" aunit="deg">
 <first ref="0x86c662618750c673">
  3695612514963747814
  9487646648968612427
 </first>
 <second ref="0xd77e4dd72fb4348a">
  11005821857262182534
  9487646648968612427
 </second>
</subtraction>

Unclear is where the difference comes from.
The problem is somewhere in the hashing of the rotations. However, the rotations are clearly different
and hence the hash-code should be different.

DetectorChecksum       +++ Rotation    13351767629364974133
<rotation unit="deg" x="0.000" y="-0.010" z="0.000"/>
and:
DetectorChecksum       +++ Rotation    8140283773950079902
<rotation unit="deg" x="0.000" y="0.010" z="0.000"/>

vs.

DetectorChecksum       +++ Rotation    9487646648968612427
<rotation unit="deg" x="0.000" y="0.000" z="0.000"/>

In the bad model the two rotations are claimed to be equal....
Are we here at the end running into some precision problem?
For the conversions I have set the precision to 3 digits.
Is it possible that due to precision AND deg<->rad the "0.010" got lost ?
Using the nightly does not tell, because there the positions and rotations cannot be not dumped.