[Solid_software] GEMC benefits and larger frameworks

[Maurizio Ungaro]

Now I have to do the part of the “objective” gemc door-to-door representative… uff…

Joking ;-) here are some comments.


> 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

Let me add a few:

- FADC output - mode 1 right now but mode 5 and 7 coming soon. This is a 4ns sampled signal, same as real life.
- Luminosity weighted run period tagging in header bank. This address time-dependent calibration and channels status (i.e. was some paddle dead during part of a run?).
- Possibility of using same calibration numbers as real data (we’re starting to do this in clas12). This may address your point 3.
- Automatic true infos - includes process name catalogue.
- Documentation is getting there ;-) gemc.jlab.org <http://gemc.jlab.org/>
- Cosmic ray model
- Coming next week: merging of background events into generator
- GUI displays many true info variables, trigger windows and voltage vs time signal (gemc 2.3)


>   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.)
This is indeed a limitation. Currently in clas12 we do use the same parameters as reconstruction, because they come from a common DB. The calculations of parameters are done using the reconstruction java library.
If the reconstruction is in C++ this can be achieved with the plugin capability of gemc - using a shared library that is used in reconstruction as well.

Having said that, it’s not feasible to include in reconstruction ALL the passive volumes. Sometimes it’s just too many. It would be better to produce volumes that average the material densities. 

> 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.)
If the mysql DB is used in the API, the geometry is run and variation indexed. So it’s uniquely associated with an output (where run, variation and ALL geometry parameters are stored).


> 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.
Replicas are there. Copies are there. Divisions are not there (yet).


Admittedly gemc was not designed to be part of a framework, however a partial re-design is in process that could help in that regard. For example, using plugins for hit processes, for generator and output mechanisms.

Regards,
Mauri 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/solid_software/attachments/20160303/56ce9d47/attachment.html>