[Halla12_software] another point about geometry API.

[Richard S. Holmes]

The whole hard coded geometry vs. not question strikes me as the wrong
question. There really is not much difference, at least for users, between
a geometry defined in a Perl script and a geometry defined in source code.

Rather, the question should be: How to parameterize the geometry?

Keep in mind that the simulation, the digitization, and the reconstruction
all need to know about geometry, but need to represent it in different
forms. The simulation needs to represent it as GEANT geometry objects. The
digitization and reconstruction will probably have their own ways of
representing the apparatus. Whatever approach we take, we have to guarantee
that all these representations are consistent and compatible, and that
whenever you change the geometry, you change it for all parts of the
software automatically.

Describing a set of GEMs by describing the 23 (or however many) layers of
the first segment of the first detector, then the 23 layers of the second
segment of the first detector, then [dot dot dot] and then the 23 layers of
the 30th segment of the fifth detector is a poor parameterization.
Digitization and reconstruction don't even need to know about all 23
layers, and simulation doesn't need to know about strip pitches and angles.
Instead there should be a generic description of a GEM sector (or I guess
potentially three generic descriptions, one each for simulation,
digitization, and reconstruction) embodied somewhere in the code — in
compiled C++ or interpreted Perl or Python or whatever — and a small set of
parameters describing the number, sizes, positions, and orientations (etc.)
of the sectors. Also in the code/scripts would be methods to obtain the
parameter set and build the specific internal representations needed by
putting the generics together according to the recipe specified by the
parameter set. If anyone needs to study, say, a GEM design with a different
number of layers, then they'll have to get into the nitty gritty of
modifying the code/scripts that contain the generic descriptions; but most
of the time, if GEMs need to be changed at all, it's changes that can be
described just by modifying that small set of parameters. And for each
output file, whether in the file or in an immutable database table pointed
to by the file, the parameter set is what we store for retrospection (along
with, say, the version control tag for the source codes / scripts used with
those parameters to build the geometry).

So it's not a matter of "which should users have to modify, C++ code or
Perl scripts?" In all but rare instances it should be neither, but a small
and easily understood parameter set.

Now, given that, it does seem to me that hard coding the generic
descriptions in the C++ would be easier and less error prone than doing it
in scripts, because in the latter case you have to define file formats for
the script outputs, you have to implement writing to those formats in the
scripts and reading from them in the C++, and you have to make sure those
files are created and stored in such a way that there's no possibility
they'll get out of synch with each other (if the
simulation/digitization/reconstruction representations are stored
separately) or with the original parameter set that's supposed to describe
them. Less work for us and less potential for confusion if the parameter
set is read directly by the C++ code and the internal representations are
built by the classes that use them.

But for the users, I don't see it as mattering much which way it's done, as
long as they never (hardly ever) have to look inside either the C++ code or
a script, or anything else that represents the geometry in microscopic
detail, to make most changes.



On Thu, Apr 2, 2015 at 4:11 PM, Zhiwen Zhao <zwzhao at jlab.org> wrote:

> Dear All
>
> Another point about geometry API.
> Our simulation needs to support both individual detector R&D and the whole
> SoLID simulation.
> And it needs fast simulation besides full simulation in the same framework.
> So having a geometry API, no matter what format it is, instead of hard
> code many things into source
> code is essential to make it effortless to unify different types of
> simulation in one single framework.
> Other collaborations have done something similar and this should one thing
> we try to understand how
> they did it.
>
> Zhiwen
> _______________________________________________
> Halla12_software mailing list
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.jlab.org/pipermail/halla12_software/attachments/20150402/5062b629/attachment.html