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

Separate ImportOpticalModels from ImportOpticalMaterials #1439

Closed hhollenb closed 1 month ago

hhollenb commented 1 month ago

Separate ImportOpticalModels from ImportOpticalMaterials

Mean free paths (MFPs) used by optical models in optical physics are imported from Geant4 through the G4MaterialPropertiesTable, and have been previously stored in ImportOpticalMaterials. This PR moves the MFP tables to be stored instead in ImportOpticalModels, which allows a common way to access MFP tables used by discrete optical models, as well as extensibility for creating mock data or user optical models.

Discrete optical model data in ImportOpticalMaterials now contains model specific data (e.g. parameters for WLS or parameters for Rayleigh scattering to build its own MFP tables).

Optical models are imported from Geant4 in mostly the same way that EM processes are imported. When iterating over G4VProcesses, if they're a recognized optical process then they're loaded as an optical model. This now also respects the GeantOpticalPhysicsOptions for absorption, rayleigh_scattering, and wavelength_shifting, and supports CelerOpticalPhysics physics lists. Therefore we can set these options in Json files used by celer-export-data and only those specified models will be propagated to the root file.

In a similar manner, it may be useful to handle the optical generators (Cerenkov, scintillation) in the import process loop so all the Geant4 processes are handled in the same way.

github-actions[bot] commented 1 month ago

Test summary

 3 264 files   5 062 suites   3m 43s :stopwatch:  1 524 tests  1 497 :white_check_mark: 27 :zzz: 0 :x: 16 884 runs  16 821 :white_check_mark: 63 :zzz: 0 :x:

Results for commit 74d29f10.

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

hhollenb commented 1 month ago

do you have any idea how the ROOT file decrease 45% in size? 🤔

Looking at test/celeritas/ext/RootImporter.test.cc, the test description says to use the option reader_data = false in app/celer-export-geant to reduce the size of the root files. Doing a quick test shows with read_data = true:

-rw------- 1 kcr8wx users 166K Oct  3 12:35 /home/kcr8wx/celeritas-project/celeritas-2/test/celeritas/data/four-steel-slabs.root
-rw------- 1 kcr8wx users 102K Oct  3 12:35 /home/kcr8wx/celeritas-project/celeritas-2/test/celeritas/data/lar-sphere.root

And with read_data = false:

-rw------- 1 kcr8wx users 76K Oct  3 12:33 /home/kcr8wx/celeritas-project/celeritas-2/test/celeritas/data/four-steel-slabs.root
-rw------- 1 kcr8wx users 66K Oct  3 12:33 /home/kcr8wx/celeritas-project/celeritas-2/test/celeritas/data/lar-sphere.root

The value of read_data is hard-coded to be true in celer-export-geant, so I'm guessing that at some point the root files started getting auto generated with the larger size and never got caught since both sizes pass tests.

stognini commented 1 month ago

That sounds reasonable. Also, since we reorganized things over time, the comment in RootImporter.test.cc could be updated from

* GeantImporter::DataSelection::reader_data = false

to something like

* GeantImportDataSelection::reader_data = false in GeantImporter.hh
hhollenb commented 1 month ago

I added an extra optional flag to celer-export-geant called --gen-test so that we can set data selection flags / other options for root files that will be stored in test data directories. I added it to the update-root-test-data so test data will be automatically generated with the smaller files.