NPPS Leadership Team

[Brett Viren <bv AT bnl.gov>]

Hi,

Torre Wenaus via Phys-npps-mgmt-l <phys-npps-mgmt-l AT lists.bnl.gov>
writes:

> Thanks Brett, it’s good to have your assessment. Do you have an
> example of “right way” geometry?

Maybe two parts to an answer:


My first attempt at a "model oriented" approach to geometry is at:

  https://github.com/brettviren/gegede/

This is used by several DUNE detector groups to describe their detector
geometries.  They typically use it as a programmable GDML generator but
the GeGeDe concept is a bit more broad.  Here are the main ingredients:

 - construct the geometry description as a set of objects in memory
   which follow a strict, formal and "generic" schema (but one which is
   highly synergistic with G4's conceptual geometry schema).

 - provide a minimal, Python-based programming framework to allow
   development of simple, focused "builder" objects.  Each builder
   instance knows how to construct some portion of the geometry either
   by directly constructing one or more volumes or by aggregating
   volumes that were constructed by other builders (or both).  Typically
   the builders are developed so that their classes shadow the hierarchy
   and symmetries of the detector itself.  

 - provide a simple, high-level configuration language (Python's
   built-in language aka "INI") and integrate a configuration mechanism
   into the builder framework.  Configuration then controls details of
   how a builder builds (eg, set the diameter of your PMTs, set the
   thickness of your planes) as well as large scale structure (set
   number of PMTs, build the full detector geometry, build only this
   sub-detector, build nominal but leave out this sub-detector, etc).

 - provide various export methods to serialize the geometry objects.
   GDML is by far the main one.  There's also a JSON dumper and some
   experimental support for SceneGraph (I toyed with FreeCAD for a
   while).  With PyROOT available, ROOT TGeo can be produced (gegede is
   pre-uproot which might be a better dependency today).  It is fairly
   easy to add new exporters depending on the complexity of the actual
   target format.

BTW, I presented GeGeDe to JLab's round table seminar some time ago.  No
one ever followed up or indicated they elected to use it.


Now, lately I have been exploring this idea of high-level model-oriented
development in a few ways by creating models in the Jsonnet language and
developing compilers/interpreters that output code.  In some cases, using
Jinja2 to "compile" Jsonnet to some other file language like Protobuf or
the XML that is used by ZeroMQ's Zproto.  

Jsonnet is a pure-functional language so maybe a bit too "awkard" for
most people (myself included) to consider replacing Python eg in GeGeDe.
Jsonnet could be useful in the context of GeGeDe if the configuration
information became complex enough.

For example, in Wire-Cell Toolkit, we use Jsonnet for all its
configuration.  You might say that it provides expressing a declarative
model for what the WCT job should do and then WCT compiles the Jsonnet
to effectively exhaustive JSON and then each WCT component interprets
its portion.  As some WCT components aggregate others, the overall jobs
structure is also specified in the Jsonnet (similar to the GeGeDe
pattern, I now just realize).

-Brett.

Attachment: signature.asc
Description: PGP signature