A configurable parameter has been implemented for the MFT Geometry builder, “MFTBase”, which is already on dev branch of O2 via PR# 3194. To test the parameter during the development it was only used to view the Geometry. Now, running a full simulation + reconstruction workflow one get errors related to a missing o2sim_Kine.root. Oddly, this error shows up even when MFTBase is set to default value, as in the case bellow:
> [O2/latest-dev-o2] ~/simtest $> o2-sim -m MFT -e TGeant3 -g fwmugen --configKeyValues 'MFTBase.minimal=false' -n 100
> [INFO] Running with 2 sim workers
> [INFO] CREATING SIM SHARED MEM SEGMENT FOR 2 WORKERS
> Spawning particle server on PID 8562; Redirect output to serverlog
> Spawning sim worker 0 on PID 8564; Redirect output to workerlog0
> Spawning hit merger on PID 8565; Redirect output to mergerlog
> [INFO] Process 8562 EXITED WITH CODE 0 SIGNALED 1 SIGNAL 6
> [FATAL] ABORTING DUE TO ABORT IN COMPONENT
> [INFO] Process 8564 EXITED WITH CODE 0 SIGNALED 1 SIGNAL 6
> [FATAL] ABORTING DUE TO ABORT IN COMPONENT
> [INFO] Merger process 8565 returned
> [INFO] Simulation process took 0.781139 s
> Error in <TSystem::ExpandFileName>: input: $ROOT_DYN_PATH/libRIO, output: $ROOT_DYN_PATH/libRIO
> Error in <TSystem::ExpandFileName>: input: $ROOT_DYN_PATH/libCling, output: $ROOT_DYN_PATH/libCling
> Error in <TFile::TFile>: file o2sim_Kine.root does not exist
For completeness, when running the same simulation in serial with o2-sim-serial I get an o2sim.root with MFT hits, but afterwards o2-sim-digitizer-workflow fails to output any digits whenever MFTBase has been set on the command line. Can someone shed some light here, please?
I see the problem only when using --configKeyValues for the MFTBase parameter. No problem when using --configKeyValues for setting BoxGun parameters, for instance.
I am running on Ubuntu 18.04, actually on a docker container. @manso also confirmed this problem on his system. His logs also shows the errors with $ROOT_DYN_PATH, which has been showing up for a week or so, even when running root:
[O2/latest-dev-o2] ~/simtest $> root -l
Error in <TSystem::ExpandFileName>: input: $ROOT_DYN_PATH/libRIO, output: $ROOT_DYN_PATH/libRIO
Error in <TSystem::ExpandFileName>: input: $ROOT_DYN_PATH/libCling, output: $ROOT_DYN_PATH/libCling
Error in <TSystem::ExpandFileName>: input: $ROOT_DYN_PATH/libMathCore, output: $ROOT_DYN_PATH/libMathCore
root [0]
Looking at the serverlog for o2-sim, I see [FATAL] Inexistant ConfigurableParam key: MFTBase.buildBarrel, while o2-sim-serial runs fine (but, again, it fails to produce digits afterwards) - see logs and outputs here. Thanks.
The problems with $ROOT_DYN_PATH are not related I think (I also have them).
Could you try to do a ldd o2-sim-serial as well as ldd o2-sim and send me the output?
This confirms my assumption: libO2MFTBase appears for o2-sim-serial but not for o2-sim.
However, this should not be the case as the link settings are exactly the same for both of them in the CMake file.
@laphecet: Do you have a clue what goes wrong here? How can we force cmake/linker to link against the listed dynamic libraries? Looks like ubuntu is doing some optimization here.
It’s ok. I’ll try to setup an Ubuntu container myself. @pezzi: Since you - in any case - work on containers, I would suggest to use the production system CC7.
Hi @swenzel, I started with CC7 container, however I could not find a quick way to rebuild O2:
aliBuild on cc7 takes a new minutes checking for updates on all packages before reaching O2 and doing a quick job there;
ninja fails to compile on the build directory. I tried alidock, a bare CentOS 7 installation, and a CentOS 7 container, all with the same outputs.
Thus I resorted to Ubuntu on Docker, were both listed methods work and are quick. I hear confirmation from @manso that he is running Kubuntu on a bare installation, thus this is not a Docker-related issue. Thanks for checking.