Crash of "o2-sim-serial -m MFT -e TGeant4 -g boxgen -n 1" : G4ENSDFSTATEDATA variable

O²
#1

I have a crash while running “o2-sim-serial -m MFT -e TGeant4 -g boxgen -n 1”.
I have an Ubuntu 18.04, updated gcc and g++ to the version 9. All is fine using TGeant3. I made also a fresh pull rebase both in O2 and alidist directories.

Here is the error message:
Info in TGeoManager::Export: Exporting ccdb_object FAIR geometry as root file. Optimizations streamed.
[21:34:38][INFO] Init CcdApi with UserAgentID: clraliceport15-1657395250-30TFHz, Host: http://alice-ccdb.cern.ch/
Error in : Failed to get any credentials
Error in TJAlienFile::Open: No JAliEn Grid connection available!
[21:34:50][INFO] ccdb reads http://alice-ccdb.cern.ch/MFT/Calib/Align/1635322620830/a974ae51-bc3f-11ec-b66d-2a010e0a0b16 for 1657395250835 (retrieve, agent_id: clraliceport15-1657395250-30TFHz),
[21:34:50][INFO] Alignment from http://alice-ccdb.cern.ch/ for timestamp 1657395250835: applied to [MFT]
Info in TGeoManager::Export: Exporting ccdb_object FAIR geometry as root file. Optimizations streamed.
Info in TObject::SetNavigator: TG4RootNavigator created and registered to G4TransportationManager
isMaster=1

-------- EEEE ------- G4Exception-START -------- EEEE -------
*** G4Exception : PART70000
issued by : G4NuclideTable
G4ENSDFSTATEDATA environment variable must be set
*** Fatal Exception *** core dump ***

*** Break *** segmentation violation

#2

How do you setup the environment? What is the output of the export command?

#3

Hello,
I haven’t defined any specific setup (except “export ALIBUILD_WORK_DIR=”$HOME/alice/sw"), I’m working after the loading of O2 software (alienv enter O2/latest-dev-o2). The last time, several months ago, it was not needed and worked fine without any specific action. In the build O2 software on github, I don’t see any advice for GEANT4.

I have attached the output of the export:
out.txt (34.9 KB)

#4

It should definitely work. When I do alien enver O2/latest, I get

declare -x G4ABLADATA="/home/aliperf/aliperf_workspace/sw/slc7_x86-64/GEANT4/v10.7.2-alice1-5/share/Geant4-10.7.2/data/G4ABLA3.1"
declare -x G4ENSDFSTATEDATA="/home/aliperf/aliperf_workspace/sw/slc7_x86-64/GEANT4/v10.7.2-alice1-5/share/Geant4-10.7.2/data/G4ENSDFSTATE2.3"
declare -x G4INCLDATA="/home/aliperf/aliperf_workspace/sw/slc7_x86-64/GEANT4/v10.7.2-alice1-5/share/Geant4-10.7.2/data/G4INCL1.0"
declare -x G4LEDATA="/home/aliperf/aliperf_workspace/sw/slc7_x86-64/GEANT4/v10.7.2-alice1-5/share/Geant4-10.7.2/data/G4EMLOW7.13"
declare -x G4LEVELGAMMADATA="/home/aliperf/aliperf_workspace/sw/slc7_x86-64/GEANT4/v10.7.2-alice1-5/share/Geant4-10.7.2/data/PhotonEvaporation5.7"
declare -x G4NEUTRONHPDATA="/home/aliperf/aliperf_workspace/sw/slc7_x86-64/GEANT4/v10.7.2-alice1-5/share/Geant4-10.7.2/data/G4NDL4.6"
declare -x G4PARTICLEXSDATA="/home/aliperf/aliperf_workspace/sw/slc7_x86-64/GEANT4/v10.7.2-alice1-5/share/Geant4-10.7.2/data/G4PARTICLEXS3.1.1"
declare -x G4PIIDATA="/home/aliperf/aliperf_workspace/sw/slc7_x86-64/GEANT4/v10.7.2-alice1-5/share/Geant4-10.7.2/data/G4PII1.3"
declare -x G4RADIOACTIVEDATA="/home/aliperf/aliperf_workspace/sw/slc7_x86-64/GEANT4/v10.7.2-alice1-5/share/Geant4-10.7.2/data/RadioactiveDecay5.6"
declare -x G4REALSURFACEDATA="/home/aliperf/aliperf_workspace/sw/slc7_x86-64/GEANT4/v10.7.2-alice1-5/share/Geant4-10.7.2/data/RealSurface2.2"
declare -x G4SAIDXSDATA="/home/aliperf/aliperf_workspace/sw/slc7_x86-64/GEANT4/v10.7.2-alice1-5/share/Geant4-10.7.2/data/G4SAIDDATA2.0"
declare -x G4VMCINSTALL="/home/aliperf/aliperf_workspace/sw/slc7_x86-64/GEANT4_VMC/v5-4-29"

as part of the environment. So I assume something is likely wrong with the modulefiles.

What is the content of sw/ubuntu..../GEANT4/latest/etc/modulefiles/GEANT4 ?

#5

The content of GEANT4 modulefile is:

#%Module1.0
proc ModulesHelp { } {
global version
puts stderr “ALICE Modulefile for GEANT4 v10.7.2-alice1-local3”
}
set version v10.7.2-alice1-local3
module-whatis “ALICE Modulefile for GEANT4 v10.7.2-alice1-local3”

Dependencies

module load BASE/1.0

Our environment

set GEANT4_ROOT $::env(BASEDIR)/GEANT4/$version
setenv GEANT4_ROOT $GEANT4_ROOT
prepend-path PATH $GEANT4_ROOT/bin
prepend-path LD_LIBRARY_PATH $GEANT4_ROOT/lib

#6

I have also a GEANT4.unrelocated

#%Module1.0
proc ModulesHelp { } {
global version
puts stderr “ALICE Modulefile for GEANT4 v10.7.2-alice1-@@PKGREVISION@410c341fb8d421704e1335c9908e0593630ae044@@”
}
set version v10.7.2-alice1-@@PKGREVISION@410c341fb8d421704e1335c9908e0593630ae044@@
module-whatis “ALICE Modulefile for GEANT4 v10.7.2-alice1-@@PKGREVISION@410c341fb8d421704e1335c9908e0593630ae044@@”

Dependencies

module load BASE/1.0

Our environment

set GEANT4_ROOT $::env(BASEDIR)/GEANT4/$version
setenv GEANT4_ROOT $GEANT4_ROOT
prepend-path PATH $GEANT4_ROOT/bin
prepend-path LD_LIBRARY_PATH $GEANT4_ROOT/lib

#7

Potentially the last installation part in the geant4.sh recipe fails for you:

# Data sets environment
$INSTALLROOT/bin/geant4-config --datasets |  sed 's/[^ ]* //' | sed 's/G4/setenv G4/' >> "$MODULEFILE"

Can you try to check manually the output of this command? (Please also verify that this line is in fact present in your alidist/geant4.sh file)

As a side note, I am not using export ALIBUILD_WORK_DIR=$HOME/alice/sw (not sure if this can make a difference, just wanted to mention)

#8

Since $INSTALLROOT is not defined by default, I used the following command (which is in alidist/geant4.sh):

sw/ubuntu1804_x86-64/GEANT4/latest-dev-o2/bin/geant4-config --datasets | sed ‘s/[^ ]* //’ | sed ‘s/G4/setenv G4/’ >> “$MODULEFILE”

The result is unclear:

bash: : Aucun fichier ou dossier de ce type
Segmentation fault (core dumped)

#9

Ok. One more try: What about just typing geant4-config --datasets inside the O2 alienv environment?

#10

Still the same:

[O2/latest-dev-o2] ~/alice/Simul $> geant4-config --datasets
Segmentation fault (core dumped)

I’m going to remove the ALIBUILD_WORK_DIR variable, perfomr a latest rebase and building of O2 to check that question.

#11

Ok. But that means that maybe this G4 tool is buggy and we need to report this to G4.

Maybe you can try to run the above command in a debugger and extract a backtrace. Then we can see where and why it crashes.