[Halla12_software] another point about geometry API.

Fri Apr 3 13:25:58 EDT 2015

Hi Richard

I agree very much with the point of view you articulated.  What you
describe as what I'll call a "core" geometry description is, I think, an
example of the concept that Ole referred to as an "API".

Let me see if I can try to make this more explicit and ask you guys to tell
me if this is consistent with your view.  I think you are indicating a
paradigm that begins with defining a "core" geometry representation.  That
might be kind of like this:

i-  For a given element (detector, magnet, baffle, ...) we define a simple,
logical, and convenient "core-geometry" description.
ii- We administratively require that the various "projections" of this
information into some other basis (you mention simulation, digitization,
and reconstruction) all be formulated using the "core-geometry" as their
source.

I'm inferring from your note that you believe that keeping the "core"
definition aligned closely with the offline/reconstruction world is the
best way to ensure that the onslaught of users we would get after real data
arrives would not immediately break the design construct.  I agree with
this very much.  Making things most closely resemble the world of the
coders who will never fully learn/appreciate the overall design philosophy
is the best defense.

I would add that the concept of calibrations has a similar multi-forked
utility (digitization and reconstruction) and would be amenable to the very
same "core description" paradigm.

My interpretation of what Ole was suggesting (design a smart/clean API) is
that the collection of these various "core" representations and the
requirement that the all codes use core descriptions as their basis allows
offline development of alignments, calibrations, corrections, dead channel
maps, etc  (components of the "core modules") to propagate immediately from
the real data world back to the simulation in an intrinsically
self-consistent manner.

Sounds like a good start to an API to me...
Tom

On Thu, Apr 2, 2015 at 11:36 PM, Richard S. Holmes <rsholmes at syr.edu> wrote:

> 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
>
> _______________________________________________
> Halla12_software mailing list
> Halla12_software at jlab.org
> https://mailman.jlab.org/mailman/listinfo/halla12_software
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.jlab.org/pipermail/halla12_software/attachments/20150403/7c1e36f4/attachment.html 