celeritas-project / celeritas

Celeritas is a new Monte Carlo transport code designed to accelerate scientific discovery in high energy physics by improving detector simulation throughput and energy efficiency using GPUs.
https://celeritas-project.github.io/celeritas/
Other
65 stars 35 forks source link

Override and save Geant4 dataset variables at configure time #1475

Closed pcanal closed 3 weeks ago

pcanal commented 3 weeks ago

This is necessary for proper operation when building and testing Celeritas in a ATLAS build environment. In the ATLAS build environment the Geant4 cmake fragment contains incorrect information about the location of the data file (it points to the long gone build directory) so we need to trust the environment variables instead.

This is essential the same as fe52da7ebaadce8f6fd3199a95490d048094c18a

github-actions[bot] commented 3 weeks ago

Test summary

 3 356 files   5 179 suites   3m 54s :stopwatch:  1 562 tests  1 534 :white_check_mark: 28 :zzz: 0 :x: 17 188 runs  17 122 :white_check_mark: 66 :zzz: 0 :x:

Results for commit da068a86.

:recycle: This comment has been updated with latest results.

sethrj commented 3 weeks ago

Should we do this at a global level in our Findgeant4 module?

pcanal commented 3 weeks ago

It might make sense. I noted that the 2 set of variable is slightly different:

-- Value for G4LEDATA taken from the environment rather than the Geant4 cmake fragment
-- Value for G4ENSDFSTATEDATA taken from the environment rather than the Geant4 cmake fragment
-- Value for G4PARTICLEXSDATA taken from the environment rather than the Geant4 cmake fragment

vs

-- For apps value for G4NEUTRONHPDATA taken from the environment rather than the Geant4 cmake fragment
-- For apps value for G4LEDATA taken from the environment rather than the Geant4 cmake fragment
-- For apps value for G4LEVELGAMMADATA taken from the environment rather than the Geant4 cmake fragment
-- For apps value for G4RADIOACTIVEDATA taken from the environment rather than the Geant4 cmake fragment
-- For apps value for G4PARTICLEXSDATA taken from the environment rather than the Geant4 cmake fragment
-- For apps value for G4PIIDATA taken from the environment rather than the Geant4 cmake fragment
-- For apps value for G4REALSURFACEDATA taken from the environment rather than the Geant4 cmake fragment
-- For apps value for G4SAIDXSDATA taken from the environment rather than the Geant4 cmake fragment
-- For apps value for G4ABLADATA taken from the environment rather than the Geant4 cmake fragment
-- For apps value for G4INCLDATA taken from the environment rather than the Geant4 cmake fragment
-- For apps value for G4ENSDFSTATEDATA taken from the environment rather than the Geant4 cmake fragment
sethrj commented 3 weeks ago

Yeah the unit tests only use a subset of the data. The app runs coupled hadronic so it needs all of it. Since this is a fix up to the Geant4 cmake data would you add code to update it there and save in cache?

pcanal commented 3 weeks ago

to update it there and save in cache?

Do you mean to then use the same set of environment variables (i.e. for all the data sets) for both the test and app cases?

sethrj commented 3 weeks ago

I mean overwriting and saving the geant4 dataset variables that are loaded through Geant config

sethrj commented 3 weeks ago

I'd like to have our unit test code look like:

  foreach(_ds G4EMLOW G4ENSDFSTATE G4PARTICLEXS)
    list(APPEND CELERITASTEST_G4ENV
      "${Celeritas_DATASET_${_ds}_ENVVAR}=${Celeritas_DATASET_${_ds}_PATH}"
     )
  endforeach()

i.e. replacing Geant4->Celeritas. In the helper macro to be called, we can just use set(${Celeritas_DATASET_${_ds}_ENVVAR} ${Geant4_DATASET_${_ds}_ENVVAR}}), and then during the first configure we can save Celeritas_DATASET_${_ds}_PATH based on the environment variable, or empty to indicate that it'll be pulled from Geant4. We probably want the latter behavior (rather than copying and caching) because the user could reconfigure again with a different g4 version if they got it wrong the first time, for example.