Load geometry from ROOT file instead of GDML file
The standard configuration of all LArSoft experiments'
Geometry service loads the geometry from a GDML file.
This requires parsing the GDML file each time.
It is possible to save the parsed GDML into a ROOT file, and subsequently load it.
My unscientific test on a fast machine (
woof.fnal.gov) shows that
Geometry service in MicroBooNE takes 8-9 seconds to load. Loading the same GDML file from ROOT command line takes about 6 seconds; I assume
Geometry uses the remaining 2-3 seconds to build its own representation of it. Loading the same geometry from a ROOT file takes less than half a second.
The potential gain of, say, 5 seconds is not relevant in production, but it may quite change the feeling when testing simple code interactively.
It would be good to explicitly support reading geometry from a ROOT file, and to establish a protocol for it.
An example could be:
- get the ROOT file name from the configuration
.gdml, learn if the matching GDML file exists
- consistency check: if the GDML file exists:
- compute MD5 sum of the GDML file (this took negligible time, but it might be because in my test the O.S. had cached the file content already)
- compare it with the MD5 sum in the ROOT file
- if the MD5 sum does not match, throw an exception: ROOT and GDML file are not consistent
- if the ROOT file contains no MD5 sum, throw an exception: MD5 of the source GDML must travel with ROOT file
- load the geometry from the ROOT file
If the specified file has a
.gdml suffix, go straight to GDML file.
The gain in a machine where files are slow to fetch hasn't been checked. These files are relatively small, and ROOT file is about one fourth of the corresponding GDML.
#4 Updated by Katherine Lato over 3 years ago
- Target version changed from 2017-4-quarter to 2019-1-quarter
11/16/17 update - This feature is probably still worthwhile, although it is a low priority and remains that because one can get by without it, but it would be nice to have. The gain is faster load time for the geometry.
#5 Updated by Robert Hatcher over 3 years ago
This helps to the degree that one is either using the LArSoft representation of the geometry, or GENIE event generation. Any stage that involves Geant4 must construct it's own representation in memory which there is an interface for from GDML (but not ROOT).