LArSoft

Logo

Software for Liquid Argon time projection chambers

View My GitHub Profile

Data architecture: where we stand, what we think

Definition

Data product: a class representing data, that is stored in a ROOT tree

Charge1


Design goals

Design principles

Questions

Q. Are dictionary libraries independent of art etc.?
A. Currently they are not.
It might be possible to fix that for some of the products which do not explicitly require art.


Dependencies

Question

Is CET library (cetlib) allowed in the implementation too7?

The only part positively needed is an exception that can be recognized by the frameworks (it could be derived from std::exception).

Technical guidelines

Data products can contain data members:

They must not contain:

The data members will be /private/, accessed through the class interface11.
The interface should offer a read-only access12.
The object will not operate on its data, leaving the task to additional layers and algorithms13.


Suggestions:

   
3-vectors (position…) TVector3 (unless there are data size issues) or double[3]? (both are currently used)
3-vectors (momentum…) TVector3 or float[3] (as above, except that we don’t have, nor need, more than 6 digits precision)
4-vectors TLorentzVector (unless there are data size issues)
error/correlation matrices TMatrixTSym<> or float[6]? (both TMatrixD and double[6] are currently used)
wire/time pair short int[2], float[2]
 

Semantics

Each data product represents a physics quantity or some concept.
First step: identify and define those concepts for the existing and needed objects.

In the standard MicroBooNE simulation + reconstruction chain, 34 classes from LArSoft (lardata) are used as data products, plus 4 more for simulation from nutools.

Let’s start from the largest chunk of correlate objects: reconstruction (base)

This encompasses 13 LArSoft classes:

recoblock_simple.svg legend.svg

“(version with modules creating each associations)”:recoblock_assns.svg

raw::RawDigit

The sequence of (uncalibrated?) ADC counts measured on one channel in the full time window.

raw__RawDigit.svg

recob::Wire

The signal deposited on a single channel as function of data acquisition time (TDC).

The signal may have been be zero-suppressed, filtered from noise and deconvoluted from electronics effects.

recob__Wire.svg

recob::Hit

The observed charge from a travelling particle that drifted to a single wire .

A hit describes the charge profile in time using a shape hypothesis .
Its position information is two-dimensional: wire location and time.
It includes:

recob__Hit.svg

Pending questions

recob::Cluster

A sequence of hits showing geometrical correlation.

Its position information is two-dimensional.
It includes:

recob__Cluster.svg

recob::EndPoint2D

Two-dimensional coordinate on a plane

Questions

recob__EndPoint2D.svg

recob::Track

The observed information from a single physical particle with well-defined trajectory.

Questions

Q. All the information? or just trajectory? or…?

recob__Track.svg

recob::Shower

The observed information from a single physical particle evolving in a shower.

recob__Shower.svg

recob::SpacePoint

A geometrical point in the detector.

recob__SpacePoint.svg

recob::Vertex

A point in the detector origin of particles

recob__Vertex.svg

Questions

anab::Calorimetry

Calorimetric information of a particle.

anab__Calorimetry.svg

anab::CosmicTag

Cosmic-ray-like attributes of a particle.

anab__CosmicTag.svg

anab::ParticleID

Hypothesis on the nature of a particle.

anab__ParticleID.svg

recob::PFParticle

The evolution of a particle in the event (particle flow).

recob__PFParticle.svg


  1. From discussion on September 15, 2014

  2. From discussion on October 6, 2014

  3. From discussion on October 6, 2014

  4. From discussion on October 6, 2014

  5. From discussion on October 6, 2014

  6. From discussion on October 6, 2014

  7. From discussion on October 6, 2014

  8. From discussion on October 6, 2014

  9. From discussion on October 6, 2014

  10. From discussion on October 6, 2014

  11. From discussion on October 6, 2014

  12. From discussion on October 6, 2014

  13. From discussion on October 6, 2014

  14. From discussion on October 13, 2014

  15. From discussion on October 13, 2014

  16. From discussion on October 13, 2014

  17. After discussion at [^24], two proposals have been evaluated: adding the channel ID as a new data member, or adding it in the geo::WireID structure. No compelling reason was identified to prefer either. The decision was in the end taken from the idea of having geo::WireID reflect a strictly geometric concept, as opposed to integrate a data acquisition concept. 

  18. From discussion on October 13, 2014

  19. From discussion on October 13, 2014

  20. From discussion on October 13, 2014

  21. After discussion at [^25], two proposals have been evaluated: adding the channel ID as a new data member, or adding it in the geo::WireID structure. No compelling reason was identified to prefer either. The decision was in the end taken from the idea of having geo::WireID reflect a strictly geometric concept, as opposed to integrate a data acquisition concept. 

  22. From discussion on MicroBooNE Analysis Tools meeting, October 16, 2014, and following private e-mail exchange with Brian Rebel. 

  23. From discussion on MicroBooNE Analysis Tools meeting, October 16, 2014, and following private e-mail exchange with Brian Rebel.