ATLASSIM-4948: Bump Geant4/CLHEP versions to v10.6.3.2/v2.4.1.3

This implements the version bump to Geant4 10.6.3 + ATLAS patches requested in ATLASSIM-4948. This includes a version bump of CLHEP from CLHEP_2_4_0_1_atl02 to CLHEP_2_4_1_3 to match the version recommended by Geant4 for 10.6.3. No ATLAS patches appear needed for this CLHEP version, it includes those added in the atl02 patch to CLHEP_2_4_0_1_atl02.

No changes other than updating the tags were needed in atlasexternals. I've marked as WIP as the data libraries for 10.6.3 are on AFS, but require publication and the creation of the RPMs. If that should be done before testing/merging this MR, let me know and I'll raise the relevant ATLINFR ticket.

added 14 commits

• 4f510945...bacbbf8a - 13 commits from branch atlas:master
• 90893d27 - Bump Geant4/CLHEP versions to v10.6.3.2/v2.4.1.3

Compare with previous version

Rebased on latest master, ready to go from @jchapman so removing WIP

unmarked as a Work In Progress

AE Build FAILURE
Build logfiles are available at Jenkins [AE-MERGE-REQUEST-CC7 #428]

Hi @akraszna, I'm trying to trace the cause of this error but am struggling a bit. The base error is obvious in the Jenkins log at:

https://atlas-sit-ci.cern.ch/job/AE-gcc-build-CC7/lastFailedBuild/Executor_Label=aibuild20-041,PROJECT=AthSimulationExternals/consoleFull

[ 90%] Performing patch step for 'Geant4'
[ 90%] Performing update step for 'Geant4'
error: Your local changes to the following files would be overwritten by checkout:
	source/global/management/include/G4Version.hh
	source/run/src/G4RunManagerKernel.cc
Please, commit your changes or stash them before you can switch branches.
Aborting
CMake Error at /build2/atlasexternals/master/AthSimulationExternals/tmp/Geant4-gitupdate.cmake:144 (message):
  Failed to checkout tag: 'v10.6.3.2'


make[2]: *** [External/Geant4/CMakeFiles/Geant4Stamp/Geant4-update] Error 1
make[1]: *** [External/Geant4/CMakeFiles/Geant4.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

What I can't work out is why it's patching then updating as a fresh, local build does:

[ 45%] Performing forcedownload step for 'Geant4'
[ 45%] Creating directories for 'Geant4'
Forcing the re-download of Geant4..
[ 45%] Performing cleansource step for 'Geant4'
[ 54%] Performing download step (git clone) for 'Geant4'
Cloning into 'Geant4'...
Note: checking out 'v10.6.3.2'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at 2599bdc... Update version to geant4.10.6.patch03.atlas02
[ 63%] Removing previous build results for Geant4
[ 63%] Performing update step for 'Geant4'
[ 63%] Forcing the configuration of Geant4
[ 72%] Performing patch step for 'Geant4'
[ 72%] Performing configure step for 'Geant4'

I recall some discussion a long time ago about this (and hence the custom ExternalProject steps), but not sure if this is related. Not sure if I've messed something up in the new CMakeLists.txt for Geant4 here, but looks o.k.

The other option is to do the version patching in the ATLAS Geant4 repo when making the tags (@jchapman, could we do this, or is there a reason to run it here?).

added 5 commits

• 90893d27...317a45b6 - 4 commits from branch atlas:master
• 75b79909 - Bump Geant4/CLHEP versions to v10.6.3.2/v2.4.1.3

Compare with previous version

AE Build SUCCESS
Build logfiles are available at Jenkins [AE-MERGE-REQUEST-CC7 #434]

resolved all threads

Hi Ben,

Do we need any changes in the Athena code at the same time when we switch to these new external versions? I already have an update lined up for GeoModel (!745 (merged)), which will need such code changes. So if this update also requires such changes, then we should definitely upgrade atlas/athena separately to the two of them. But if your update is transparent in that way, then I would bunch them up.

Cheers, Attila

It should be transparent as the code on Athena's master already has all the patches I'm aware of needed for it to work with 10.6.

Okay, let's see how it goes...

merged

mentioned in commit 235130d8

mentioned in merge request !804 (merged)