Project

General

Profile

Feature #11066

Load geometry from ROOT file instead of GDML file

Added by Gianluca Petrillo over 3 years ago. Updated almost 2 years ago.

Status:
Accepted
Priority:
Low
Assignee:
-
Category:
Geometry
Target version:
Start date:
12/04/2015
Due date:
% Done:

0%

Estimated time:
Experiment:
-
Co-Assignees:
Duration:

Description

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:

  1. get the ROOT file name from the configuration
  2. replace .root with .gdml, learn if the matching GDML file exists
  3. consistency check: if the GDML file exists:
    1. 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)
    2. 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
  4. 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.

History

#1 Updated by Lynn Garren over 3 years ago

  • Status changed from New to Assigned

#2 Updated by Katherine Lato almost 3 years ago

  • Status changed from Assigned to Accepted
  • Assignee deleted (Gianluca Petrillo)
  • Target version set to 2017-2-quarter

This should be done after current geometry work on dual-phase support.

#3 Updated by Katherine Lato over 2 years ago

  • Target version changed from 2017-2-quarter to 2017-4-quarter

#4 Updated by Katherine Lato almost 2 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 almost 2 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).



Also available in: Atom PDF