[Halla12_software] ec_solid_gemc as an example

[Zhiwen Zhao]

Hi, Rich

Here is the work flow
parameters txt file is edited by hand (it can be generated by some tool, like a script, but not yet.)
solid_PVDIS_ec_forwardangle_real.pl read the parameters file in and produce geometry txt file
solid_ec_bank.pl produce bank txt file without any input
solid_ec_hit.pl produce hit txt file  without any input
solid_ec_materials.pl produce material txt file without any input
solid_PVDIS_ec_forwardangle.pl just group together solid_PVDIS_ec_forwardangle_real.pl,solid_ec_bank.pl
and solid_ec_hit.pl to run them at once.

To simply change geometry parameters, one just need to edit the parameters txt
To change hit,bank,material, one can simply edit their txt file by hand or use the perl script for 
them.
These perl script are very simple, not like the geometry perl script at all. They simply output some 
text in
these table format. Any other tool can do the same job.

Include unit in bank definition is a good idea, we should think about how to add them.
It's simple to have them in the description only, but a bit tricky to have unit in output like evio 
or a root tree.
We should at least follow some guideline for common things like MeV,ns,mm

I totally agree your comment about solid_ec_bank.pl
The ultimate goal is to have a single source for the output for both hit processing routine in 
simulation and
reconstruction and analysis code.
If we choose the bank txt file as the single source, the hit processing routine in C++ need to read 
it and
do hit processing and output accordingly and automatically.
But practically, this was not achieved for now.
Take a look at the solid_ec_hitprocess.cc, I don't have good way to do it yet.

geometry txt file is format Geant4-focused format for detector definition.
It's not input for other parts in the software framework.
The information is in parameter txt file, other software should read all from this
  parameter txt file, not the geometry txt file.
In principal, if we generalize the idea of the parameter txt file and combine it with 
material,hit,bank txt together
It's a complete description of the detector definition for simulation.
We can add more things into the  detector definition, not relevant for simulation, but for 
reconstruction, analysts etc.
Simulation code can just choose to ignore anything is irrelevant, just like reconstruction will 
ignore things irrelevant also.

Zhiwen

On 4/23/2015 11:03 AM, Richard S. Holmes wrote:
> Let me make sure I understand what's happening here. Are the various .txt files outputs of the .pl
> scripts? What writes solid_PVDIS_ec_forwardangle__parameters_Original.txt? Or is that an input? Is
> that read by solid_PVDIS_ec_forwardangle_real.pl which then
> outputs solid_PVDIS_ec_forwardangle__geometry_Original.txt? I think that's what your slides are
> saying, is that right?
>
> So if one wants to change the EC configuration one edits
> solid_PVDIS_ec_forwardangle__parameters_Original.txt, but to change the materials or bank definition
> you have to edit the Perl script?
>
> I like that in the bank definition there is a description of each field. However, I would urge that
> the description should include the units. Or there should be a separate column for units.
>
> This bothers me:
>
>     solid_ec_bank.pl <http://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?
>
> 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?
>
>
> On Wed, Apr 22, 2015 at 11:13 PM, Zhiwen Zhao <zwzhao at jlab.org <mailto:zwzhao at jlab.org>> wrote:
>
>     Dear All
>
>     We talked about showing an example for using the external parameter to
>     define a detector
>
>     Here is "ec_solid_gemc" as an example
>     https://jlabsvn.jlab.org/svnroot/solid/subsystem/ec/ec_solid_gemc/
>     The parameter file is
>     solid_PVDIS_ec_forwardangle__parameters_Original.txt
>     as shown on slide 14 of my talk a few weeks ago
>     http://hallaweb.jlab.org/12GeV/SoLID/download/software/talk/solid_software_zwzhao_20150326.pptx
>     http://hallaweb.jlab.org/12GeV/SoLID/download/software/talk/solid_software_zwzhao_20150326.pdf
>
>     see the "readme" file about how to use the example
>
>     Zhiwen
>     _______________________________________________
>     Halla12_software mailing list
>     Halla12_software at jlab.org <mailto:Halla12_software at jlab.org>
>     https://mailman.jlab.org/mailman/listinfo/halla12_software
>
>
>
>
> --
> - Richard S. Holmes
>    Physics Department
>    Syracuse University
>    Syracuse, NY 13244
>    315-443-5977