eicd issueshttps://eicweb.phy.anl.gov/EIC/eicd/-/issues2022-07-18T17:30:48Zhttps://eicweb.phy.anl.gov/EIC/eicd/-/issues/28Add an (Open Source) license?2022-07-18T17:30:48ZDmitry KalinkinAdd an (Open Source) license?The project lacks COPYING/LICENSE file.The project lacks COPYING/LICENSE file.https://eicweb.phy.anl.gov/EIC/eicd/-/issues/27Develop an exclusive data structure2022-04-30T15:17:32ZWouter DeconinckDevelop an exclusive data structure-t, misisng invariant mass for all particles, missing invariant mass for all non-far-forward particles, etc-t, misisng invariant mass for all particles, missing invariant mass for all non-far-forward particles, etcWouter DeconinckWouter Deconinckhttps://eicweb.phy.anl.gov/EIC/eicd/-/issues/26Raw (digitized) hit model redundant, use single unified RawHit2022-03-01T17:15:28ZSylvester JoostenRaw (digitized) hit model redundant, use single unified RawHitCurrently all digitized hit structures store the same basic information: 64bit cell ID, 32bit time stamp and 32bit value. There is no good reason for them to be separate classes. We should unify them into a single RawHit structure as thi...Currently all digitized hit structures store the same basic information: 64bit cell ID, 32bit time stamp and 32bit value. There is no good reason for them to be separate classes. We should unify them into a single RawHit structure as this will provide us with more flexibility down the road. And when needed we can add data structures that actually store different information as we go. Proposed structure:
```
RawHit:
Description: Raw detector hit storing one 32-bit word of information
Members:
- uint64_t cellID
- uint32_t timeStamp
- uint32_t value
```https://eicweb.phy.anl.gov/EIC/eicd/-/issues/23Add ProtoTrack structure2021-12-07T20:51:11ZWouter DeconinckAdd ProtoTrack structureCurrently we store this in output ROOT files outside of the eicd data model, as:
```
/// A proto track is a collection of hits identified by their indices.
using ProtoTrack = std::vector<size_t>;
/// Container of proto tracks. Each proto...Currently we store this in output ROOT files outside of the eicd data model, as:
```
/// A proto track is a collection of hits identified by their indices.
using ProtoTrack = std::vector<size_t>;
/// Container of proto tracks. Each proto track is identified by its index.
using ProtoTrackContainer = std::vector<ProtoTrack>;
```
Hmm, one-to-many relation...Sylvester JoostenSylvester Joostenhttps://eicweb.phy.anl.gov/EIC/eicd/-/issues/22Rebranding of Trajectory to TrackProjection2021-12-07T20:51:51ZWouter DeconinckRebranding of Trajectory to TrackProjectionSylvester JoostenSylvester Joostenhttps://eicweb.phy.anl.gov/EIC/eicd/-/issues/21add IRT output data structures2022-02-11T16:12:10ZChristopher Dilksadd IRT output data structuresChristopher DilksChristopher Dilkshttps://eicweb.phy.anl.gov/EIC/eicd/-/issues/20VectorXYZT operator+ and operator-2021-10-12T00:15:01ZWouter DeconinckVectorXYZT operator+ and operator-Currently not operators are defined on the four vectors.Currently not operators are defined on the four vectors.https://eicweb.phy.anl.gov/EIC/eicd/-/issues/19VectorXYZT::mag() may be confusing since not four-vector magnitude2022-02-24T02:43:09ZWouter DeconinckVectorXYZT::mag() may be confusing since not four-vector magnitude`mag()` is defined as
```code
double mag() const {return std::hypot(x, y, z);}
```
but the magnitude of a fourvector is traditionally defined as `mass()` (maybe up to a sign)
```code
double mass() const {return sqrt(t*t - x*x - y*y - z*z...`mag()` is defined as
```code
double mag() const {return std::hypot(x, y, z);}
```
but the magnitude of a fourvector is traditionally defined as `mass()` (maybe up to a sign)
```code
double mass() const {return sqrt(t*t - x*x - y*y - z*z);}
```
This might lead to confusion when people start to use this in things like `q2 = (ef-ei).mag()`.https://eicweb.phy.anl.gov/EIC/eicd/-/issues/18Provide constructor for eic::VectorXYZT from dd4pod::VectorXYZ and double2021-10-13T02:28:09ZWouter DeconinckProvide constructor for eic::VectorXYZT from dd4pod::VectorXYZ and doubleCreating an eic::VectorXYZT fourvector from a dd4pod mcparticles entry requires individual x,y,z setters. Ideally, we'd have
```code
for (const auto& p : mcparts) {
if (p.genStatus() == 4 && p.pdgID() == 11) {
// Incomi...Creating an eic::VectorXYZT fourvector from a dd4pod mcparticles entry requires individual x,y,z setters. Ideally, we'd have
```code
for (const auto& p : mcparts) {
if (p.genStatus() == 4 && p.pdgID() == 11) {
// Incoming electron
eic::VectorXYZT ei(p.ps(), p.E());
break;
}
}
```https://eicweb.phy.anl.gov/EIC/eicd/-/issues/17Use consistent namespaces and include directories2021-10-11T19:48:33ZWouter DeconinckUse consistent namespaces and include directoriesRight now we are using a mixture of
- header files in `eicd/`
- namespace `eic::` for data structures in CamelCase
- namespace `eicd::helpers::` for helper functions in lowercase
This causes confusion when
```code
#include "eicd/Reconst...Right now we are using a mixture of
- header files in `eicd/`
- namespace `eic::` for data structures in CamelCase
- namespace `eicd::helpers::` for helper functions in lowercase
This causes confusion when
```code
#include "eicd/ReconstructedParticleCollection.h"
```
provides `eic::ReconstructedParticleCollection`, but
```code
#include "eicd/helpers.h"
```
provides `eicd::helpers::momenta_from_tracking`.
Proposal:
- keep namespaces as `eic::`,
- change install paths to `eic/`,
- remove `eic::helpers::` as an intermediate namespace in favor of e.g. `eic::KinematicsHelpers::`,
- provide headers for helpers in the same structure are the intermediate namespaces, e.g.
```code
#include "eic/KinematicsHelpers.h"
```https://eicweb.phy.anl.gov/EIC/eicd/-/issues/16Provide single header to include for all collection types2021-10-11T19:05:15ZWouter DeconinckProvide single header to include for all collection typesDownstream analysis codes now require
```code
#include "eicd/InclusiveKinematicsCollection.h"
#include "eicd/ReconstructedParticleCollection.h"
```
while it may be easier and more transparent for users to use a single overall header
```c...Downstream analysis codes now require
```code
#include "eicd/InclusiveKinematicsCollection.h"
#include "eicd/ReconstructedParticleCollection.h"
```
while it may be easier and more transparent for users to use a single overall header
```code
#include "eicd.h"
```
or mabye
```code
#include "eicd/DataModel.h"
```https://eicweb.phy.anl.gov/EIC/eicd/-/issues/14CI doesn't properly run on tagged releases2021-08-18T23:13:38ZSylvester JoostenCI doesn't properly run on tagged releaseshttps://eicweb.phy.anl.gov/EIC/eicd/-/issues/2Add some basic usage examples2021-09-20T19:42:30ZWhitney ArmstrongAdd some basic usage examplesor links to examples.or links to examples.Documentation