[Halla12_software] another point about geometry API.

Tue Apr 7 15:00:51 EDT 2015

Hi Tom et al.,

I'm a bit surprised by that response. My point was that both Hall B & D
at JLab do not base their reconstruction and simulation frameworks on
ROOT. Additionally, Hall B's software is primarily written in Java. So
are parts of CODA nowadays, as well as much of the JLab compute farm
software. I doubt that the respective groups consist entirely of fools;
I'd keep an open mind.

I'm personally quite in favor of ROOT and C++, but, as I said, the
result of that choice could be to make us effectively incompatible with
the other JLab frameworks. This is not a trivial point! Note that these
frameworks already exist; we wouldn't be "writing our own ROOT".

No one suggests not to use Geant4. Geant4 does not require ROOT anyway.
I think we are set on Geant4 as the simulation engine. So is Hall B, and
Hall D is in the process of transitioning from 3 to 4.

I'd like to discuss general requirements on SoLID software first and
then to look which existing package(s) would be the best starting point
to address the requirements. Whether we end up with streamers or
otherwise is just a detail.

As for the geometry information, we seem to have identified the
following points:

1) We want to express the geometry in terms of certain "core
parameters", from which each component (simulation, reconstruction
modules, etc.) will derive a suitable internal representation.

2) A central database stores these core parameters, but users should be
able to override some or all values with local ones.

3) The geometry for each detector components should be encapsulated in
objects. The objects hence define each component's geometry API.
Components do not directly query the database for geometry information,
but indirectly so through their respective geometry objects.

4) Data input files should be allowed to contain "metadata" that are
usable as a source for local parameter values.

5) Some or all data contents of geometry objects must be writable to
output files.

This sounds like a good start, but it's not complete. For example:

- How is geometry information indexed in the central database? Run
number? Versions? Variations?

- How would users introduce local parameter values? Explicit Set methods
on the geometry object? Local files that geometry objects can read? If
so, of arbitrary format?

- Where and when are geometry objects instantiated and initialized? By
analysis modules? At global package initialization?

- Are geometry objects singletons or finer-grained, e.g. per detector?

- How much of a geometry object is written to file, and under which
circumstances (only if modified/always/fully/partly)?

- What if definitions change during reconstruction? Do we write multiple
versions out then? (This applies typically to calibrations, but in
principle could also affect geometry.)

- Should there be support for "uploading" geometry objects to the
central database? This would be a seriously non-trivial capability
(unless one allows binary blobs perhaps, but one won't get away with
that shortcut).

Etc etc.

Let's think of typical usage scenarios and make a list of what we'd need
to be able to do (e.g. set parameters from Perl scripts? How, why?) I
think that'll be productive.

Ole

On 04/07/2015 01:28 PM, Thomas K Hemmick wrote:
> Thanks Ole, that explains A LOT of what people have not yet said.  Two
> questions:
> 
> A:  Without root, what would we use?  PAW...home grown...?  
> B:  Without C++ what would we use?  FORTRAN...perl...python...?
> 
> As you might have guessed, I have operated under the presumption of a
> root/geant4 code base.  It seems to me that any other choice is more
> work for the core team than I care to think about in my worst nightmare!
> 
> 1)  Does anyone among us believe that we have the capability to write
> our own root or geant4?
> 2)  Among those who believe item 1, do you think that we are wise to do
> this?
> 
> Perhaps this is first thing we should discuss.  My opinion is simple:
> root/geant4 should be the basis of SoLID software.  I'm curious to hear
> if any of us has a different opinion on this.
> 
> All the best,
> Tom
> 
> On Tue, Apr 7, 2015 at 12:28 PM, Ole Hansen <ole at jlab.org
> <mailto:ole at jlab.org>> wrote:
> 
>     On 04/06/2015 10:56 PM, Richard S. Holmes wrote:
>     > On Mon, Apr 6, 2015 at 4:51 PM, Thomas K Hemmick
>     > <hemmick at skipper.physics.sunysb.edu
>     <mailto:hemmick at skipper.physics.sunysb.edu>
>     > <mailto:hemmick at skipper.physics.sunysb.edu
>     <mailto:hemmick at skipper.physics.sunysb.edu>>> wrote:
>     >
>     >     I)  Root streamers mean that with ZERO WORK, we can store/retrieve
>     >     the detector definition objects to/from a file.
>     >
>     >
>     > It seems to me, unless I'm mistaken, there's a few words missing from
>     > the end of this sentence, which are: "in a C++ program linked against
>     > ROOT".
> 
>     Rich's point is similar to one I wanted to bring up: The idea of using
>     ROOT streamers implies major design decisions that haven't been made
>     yet: That (at least parts of) the framework will require C++ and ROOT,
>     and that we wish to standardize on ROOT files.
> 
>     This point is significant because, among other things, neither the Hall
>     B nor the Hall D framework are built on ROOT, and Hall B's framework (as
>     well as much other JLab software) is not primarily written in C++. In
>     other words, if we want to build on ROOT, we're effectively ruling out
>     building on either of those frameworks. Similarly, neither framework
>     relies primarily on the ROOT file format; for instance, Hall D's
>     framework makes heavy use of XML and its own schema definitions.
>     (ROOT/C++/streamers are being used in the Hall A analyzer, however.)
>     This just for reference.
> 
>     I still thinking about the wisdom of using streamers in general for
>     things like geometry parameters. There are pros and cons. More on that
>     later.
> 
>     Ole
> 
> 
>     _______________________________________________
>     Halla12_software mailing list
>     Halla12_software at jlab.org <mailto:Halla12_software at jlab.org>
>     https://mailman.jlab.org/mailman/listinfo/halla12_software
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ole.vcf
Type: text/x-vcard
Size: 321 bytes
Desc: not available
Url : https://mailman.jlab.org/pipermail/halla12_software/attachments/20150407/62602d8f/attachment.vcf 