GeoModelHelpers -- Introduce cloneVolume

Introduce new function to clone physical volumes.

• If a fullphysical volume in the subtree is detected, then a clone of the volume is made
• Otherwise, it's steered via the boolean argument

The question is what are we doing with the clone methods of the GeoPhysVol & the GeoFullPhysVol. They don't have this detection mechanism. I'd propose to remove them

Tagging: @mbandier, @boudreau, @tsulaia, @rbianchi

added 1 commit

• 1d238efa - Add depreciated flag

Compare with previous version

I don't think we have clone() method for regular physical volumes. As for full physical volumes, this method simply makes a clone without checking whether it contains another full physical volume in the subtree or not.

Your implementation seems to be more involved, so I'm OK with dropping the old one.

As a general comment, I would not touch GeoModelKernel in the main branch until we fix the situation with transitioning Athena to 5.1.0

added 1 commit

• fd6a5dbc - Remove warning again

Compare with previous version

That was just for me to find out where the clone method is used and where not ;-)

resolved all threads

added 1 commit

• 619ecdbc - Improve documentation

Compare with previous version

added 1 commit

• f8a8cc3c - Blub

Compare with previous version

Happy to merge?

Is it critical for 5.2.0? If not, then I'd first merge !288 (merged) (assuming the pipeline finally succeeds), make 5.2.0 from it, and then merge this one.

If it is critical for 5.2.0, then I'd still first merge !288 (merged), then rebase this one on GeoModel main, rerun the pipeline with all recently added tests, and merge only when the pipeline succeeds.

OK?

It's not really critical ;).

added 9 commits

• f8a8cc3c...5fc6ac02 - 4 commits from branch main
• 4d2885ee - Introduce cloneVolume
• 2abec5a5 - Add depreciated flag
• 31eeeae8 - Remove warning again
• 3e272542 - Improve documentation
• 06a350e2 - Blub

Compare with previous version

merged

mentioned in commit 4dcef060