[Halla12_software] ec_solid_gemc as an example

[Maurizio Ungaro]

Hi Richard,

A couple of clarifications:

1. There are currently 2 “factories” in the perl api: TEXT and MYSQL. They can be selected using the string “TEXT” or “MYSQL” in the configuration file. What Zhiwen is showing is the output of the "text” factory (text files). They are basically tables in ascii format. 
When using “mysql” those tables are put in a mysql - which is the natural (and original!) gemc mode because any change is immediately seen by the whole collaboration and there are no ambiguities.  

2. All geometry, materials, hit definitions are versioned by “variation” and, for mysql db, by run number as well. In the text api, the variation is indicated in the file name. In this case “Original” .  This is done so we can have several variations of the same detector.
For example, in clas12 we have “target” with variations “lH2”, “lD2”, “ND3”, they all refer to different geometry and materials.

3. The “parameter” file is a collection of “mother parameters” that are used by the perl api to create geometry/materials/mirrors, AND by the digitization routines. The parameter file can be edited manually or created with the perl api.


> This bothers me:
> 
> solid_ec_bank.pl defines output bank "solid_ec", it needs to exactly match hit processing routine in solid_ec_hitprocess.cc under solid_gemc2/source
> Every time, you add or remove an entry, you need to modify the source code and recompile "solid_gemc" by following instruction there
> Isn't this exactly the sort of thing we're trying to avoid? Having definitions of things in multiple places all of which have to be in synch for it to work?
The definition is actually in one place only (output of bank script). The digitization routine “fills” the variable. 
They are actually quite independent, in other words you can modify the definitions w/o breaking the executable. What will happen is that that new variable won’t be filled.


> What about the digitization, calibration, and analysis software? Presumably they don't read solid_PVDIS_ec_forwardangle__geometry_Original.txt since that's a GEANT-focused description; instead do they read solid_PVDIS_ec_forwardangle__parameters_Original.txt? And the other .txt files?
Currently the parameters can be used by digitization. However this is not sufficient for a digitization where one would want to use the same constants coming/used from/in calibration. The reason is that modifying these parameters should be done in the context of the calibration suites, and not be dependent of any  gemc api.  
In the devel version of gemc, to be released in 4-6 weeks in version 2.3, this is solved by having the user decide how to read the calibration constants in the digitization routine.



I also want to point out that either 2.3 or 2.4 will move the digitization routines out of the gemc core: they will be plugins to be loaded at run time, and they will be part of the detector definitions. Thats the final step in making gemc “detector independent”.



One final point: I don’t particularly like “perl”. This choice was done 8 years ago, there were not many cross platform script choices back then. We have better tools nowadays (java, python) that I would want to replace the gemc perl api.


Let me know if you have any questions or something is not clear, or you need more details!

Regards,
Mauri