[Solid_software] GEMC benefits and larger frameworks

[Richard S. Holmes]

Having gotten a better picture of what we can expect from a software
framework, I am returning to thinking about what we get from GEMC, and how
and whether GEMC continues to be useful in a broader software framework.
References are made here to art but perhaps similar remarks would apply to
many or all other framework options.

Affordances of GEMC: I can think of these:

1. Standard framework for simulation: event loop etc. is provided and a lot
of the GEANT overhead is taken care of
2. GUI
3. Construction of geometry from database
4. Control of simulation jobs via gcard files
5. Output in evio format

Question: What other benefits does GEMC provide?

Notes:

1. Using GEMC as a library, one presumably could incorporate its useful
features into an art module (or modules); then the event loop would be
driven by art, calling on GEMC code as needed.

2. The GUI is generally pretty nice. From what I've seen it looks as though
similar functionality might be implemented from the ground up as an art
module. It would require a lot of effort, however.

3. One problem here is that the GEMC database is not useful to digitization
/ reconstruction / analysis. To use GEMC within our framework one would
need to:

  a. Use one or more separate databases for digitization / reconstruction /
analysis in addition to the GEMC database files (a mess to be avoided). Or,

  b. Devise a way to use a single database of geometry parameters directly
or indirectly in digitization / reconstruction / analysis, as well as
indirectly in simulation (i.e. scripts converting geometry parameters into
GEMC database files). Note that GEMC provides a mechanism by which Perl
scripts can read a parameter file and use it to govern how it generates a
database file. But there are several drawbacks: 1. these parameters are
scalars only. 2. This is a separate step from the simulation, meaning that
there is potential for synchronization to be lost and for a simulation to
erroneously use an outdated version of a database file. 3. Loss of
provenance: The database files carry no information about the parameters
and software versions used to generate them, meaning that provenance cannot
be preserved in the simulation outputs. Or,

  c. Make a major modification to GEMC to have it get geometry parameters
from a database that can also be used by digitization / reconstruction /
analysis, and inflate that into GEANT4 geometry. (Rather like b., but with
the geometry inflation occurring inside the simulation job, guaranteeing
synchronization with the database and with provenance preserved. Presumably
the simulation job would have to "know" the basic geometry of the
components of SoLID, with the parameter database just providing possible
combinations and variations.)

Whatever approach is used, we need to implement ways to preserve the
geometry information used in a job and include or link it in that job's
output. (As opposed to what we have now, where a parameter file or database
entry can be erased or modified, destroying the version that was used, and
where no geometry information nor link to geometry information is
associated with the GEMC output.)

As far as I can tell, art itself does not (yet?) have a ready-made solution
to the geometry database problem. See
./products/toyExperiment/v0_00_29/databaseFiles/geom01.fcl in which
parameter sets are defined to control a simulation:

# This is a mock-up of information that will some day live in a geometry
> database.
> # For illustrative purposes we are using this file.


I don't know anything about experiment-specific approaches to geometry
databases for experiments using art.

Also note: GEMC does not allow (I think) taking advantage of GEANT4's
ability to replicate logical volumes; e.g. each calorimeter module must be
a separately-defined entry in the database.

4. Arguably art's FHiCL (.fcl) files provide a more user friendly mechanism
for job control. This gets back to note 1: presumably a FHiCL-controlled
art code could make use of GEMC as a library.

5. We would like to have output in a choice of formats: root or evio.
Output should include information about geometry, software version, and job
control parameters, or pointers thereto.

Comments?

-- 
- Richard S. Holmes
  Physics Department
  Syracuse University
  Syracuse, NY 13244
  315-443-5977
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/solid_software/attachments/20160303/47a127e0/attachment.html>