Organize the connectivity of the parts of protoDUNE and DUNE FD
single-phase detectors.
FIXME: only TPC related parts are supported for now!
FIXME: this design is currently ambigous as to whether each part is
"logical" or "touchable" (in the Geant4 sense of these words). It
allows for both and it is up to the user to determine interpretation.
Future development may provide explicit interpretation.
This organization separates into the following conceptual parts:
- part identifiers :: the database provides a table for each type
of detector part relevant to identifiers that may be present in
its data.
- part connectivity :: relationships between part tables and join
tables form edges in an overall connectivity graph.
- connectivity ordering :: edges in the connectivity graph have a
scalar ordering based on one or more table columns or class
attributes.
- numbering convention :: the database does not assume any
particular numbering convention except in so much as it can be
expressed in terms of the connectivity ordering attributes.
A part table has relationships to others which fall into one of these
categories:
- child :: a part may have a child sub-part which is considered
contained by the part.
- parent :: a part may itself be a child and maintain a connection
to its parent part.
- peer :: two parts may reference each other
- simple :: a table may simply reference another in a
unidirectional manner.
- special :: a relationship of convenience
The child and parent connectivity is maintened, in part, through a
join table ("link") which allows specifying one or more connectivity
ordering attributes. These conections are expressed in two
relationships as rows/attributes on the part table/class. they take
names after the "other" part:
- parts :: a sequence of the other connected parts with has no
explicit order.
- part_links :: a sequence of links from the part to its children
or its parent(s). When referencing children, the links are
ordered by the connectivit ordering attributes held in the link
objects. Each link object gives access to both parent and child
parts.
As a convenience, a child part may be associated to a parent part
through the parent's `add_<part>()` method. These methods accept an
existing child object and all connection ordering parameters. A join
object is constructed and returned (but can usually be ignored).
Note, in detector description limited to a single detector where each
part is considered "touchable" (see FIXME above) the parent-child
relationship is one-to-many. OTOH, multiple connections from one
child back to multiple parents are supported. As an example, a
database may contain descriptions for both protoDUNE and DUNE where
with two Detector objects and where the former merely references six
anodes of the latter.
The branches of the parent-child tree terminate at the channels leaf,
although channels have "peer" links to conductors (see below).
Conceptually, if one considers a containment tree, the tree also
terminates at wire leafs. However, there are cycles in relationship.
Wires are contained both by conductors which connect up through
electronics back to the detector and in planes which connect up
through structural elements to the detector. Likewise boards are
conceptually "in" both WIBs and Faces.
The "peer" relationship is a simple one-to-one connection. Each part
on either end of the connection has an attribute named after the
"other" part. These are used to directly express a connection which
either can not be expressed or which would require traversal up and
down many intermeidate branches of the parent/child tree. For example
a Channel has a "conductor" and a Conductor has a "channel". Also,
Crates and Anodes share a peer relationship. To indirectly associate
the two would require redundancy in the join tables and require
complex queries. Instead, an explicit relationship is formed which
represents a physical soldering of a conductor to a wire board layer
and spot. A side effect benefit is that mistakes in such physical
connections can be represented.
The "peer" relationships must be set explicitly set either at the time
of constructing the final end point object or later by setting the
corresponsing attribute on one (not both) of the end point objects.
A "simple" relationship is used to compose compound values such as
referencing rays which themselves reference points. In some cases
"special" relationships are provided. For example, a Point can
determine which Rays refer to it, but other tables may reference a
Point and no back reference will exist.
1.8.11