<div dir="ltr">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.<div><div><br><div>Affordances of GEMC: I can think of these:<div><br></div><div>1. Standard framework for simulation: event loop etc. is provided and a lot of the GEANT overhead is taken care of</div><div>2. GUI</div><div>3. Construction of geometry from database</div><div>4. Control of simulation jobs via gcard files</div><div>5. Output in evio format</div><div><br></div><div>Question: What other benefits does GEMC provide?</div><div><br></div><div>Notes:</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>  a. Use one or more separate databases for digitization / reconstruction / analysis in addition to the GEMC database files (a mess to be avoided). Or,</div><div><br></div><div>  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,</div><div><br></div><div>  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.)</div><div><br></div><div>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.)</div><div><br></div><div>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: <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"># This is a mock-up of information that will some day live in a geometry database.<br># For illustrative purposes we are using this file.</blockquote><div><br></div><div>I don't know anything about experiment-specific approaches to geometry databases for experiments using art.</div><div> </div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Comments?<br clear="all"><div><br></div>-- <br><div class="gmail_signature">- Richard S. Holmes<br>  Physics Department<br>  Syracuse University<br>  Syracuse, NY 13244<br>  315-443-5977<br></div>
</div></div></div></div></div>