added SecondaryVertex container #132
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -9,7 +9,7 @@ | |
| ## If there are schema version changes that can be evolved, see the podio documentation | ||
| ## for an example: https://github.com/AIDASoft/podio/tree/master/tests/schema_evolution | ||
| ## | ||
| schema_version: 850 | ||
|
|
||
| options : | ||
| # should getters / setters be prefixed with get / set? | ||
|
|
@@ -511,6 +511,35 @@ datatypes: | |
| OneToManyRelations: | ||
| - edm4eic::ReconstructedParticle associatedParticles // particles associated to this vertex. | ||
|
|
||
| edm4eic::SecondaryVertex: | ||
| Description: "EIC secondary vertex" | ||
| Author: "X. Dong" | ||
| Members: | ||
| - int32_t type // Type flag, to identify what type of vertex it is (e.g. primary, secondary, genera | ||
| - float chi2 // Chi-squared of the vertex fit | ||
| - int ndf // NDF of the vertex fit | ||
| - edm4hep::Vector4f position // position [mm] + time t0 [ns] of the vertex. Time is 4th component in vector | ||
| - edm4eic::Cov4f positionError // Covariance matrix of the position+time. Time is 4th component, similarly to 4vect | ||
| - edm4hep::Vector3f parentMomentum // parent momentum | ||
| - float parentInvariantMass // parent invariant mass | ||
| - float parentInvariantMassError // parent invariant mass error | ||
| - float parentDecayLength // parent decay length | ||
| - float parentDecayLengthError // parent decay length error | ||
| - float parentDca2PV // parent dca to primary vertex | ||
| - float parentDca2PVError // parent dca_error to primary vertex | ||
| VectorMembers: | ||
| - edm4hep::Vector3f daughterMomentum // daughter track momentum at the decay vertex | ||
| - int daughterPDG // daughter PDG | ||
| - float daughterDca2PV // daughter dca to primary vertex | ||
| - float daughterDca2PVError // daughter dca_error to primary vertex | ||
| - int daughterPairIndices // track indices for any pair | ||
|
Contributor
There was a problem hiding this comment. Building on some of the discussion from EDM4eic#127: this is one field that would be made redundant if rather than storing an explicit subset of kinematic info for the daughters, we utilized relations. For example, if we link to the vertex to the daughter particles in a one-to-many relation, then PODIO will auto-generate a branch in the ROOT output to store the indices of linked daughters (the branches prepended with a Not to mention, this also deviates from our current standard practice of preferring PODIO relations over storing specific indices (see here). |
||
| - float daughterPairDca // dca between any pair of tracks | ||
| - float daughterPairDcaError // dca_error between any pair of tracks | ||
| OneToOneRelations: | ||
| - edm4eic::Vertex primaryVertex // associated primary vertex | ||
|
Contributor
There was a problem hiding this comment. For my own understanding: is there a reason why it we would always want to link to only the primary vertex? I'm imagining something like an upsilon decay where we might have an intermediate resonance that decays further, e.g. an upsilon. In which case, the relevant decay length for the intermediary (like a D0) would be between the upsilon vertex and the intermediary's decay vertex... |
||
| OneToManyRelations: | ||
| - edm4eic::ReconstructedParticle associatedParticles // particles associated to this vertex. | ||
|
Contributor
There was a problem hiding this comment. This, e.g., could be the relevant field to link to the decay products and the mother! |
||
|
|
||
| ## ========================================================================== | ||
| ## Kinematic reconstruction | ||
| ## ========================================================================== | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the availability of track state propagated to the decay vertex, but I think only providing the 3-momentum is just a subset of that. In particular, it doesn't have the covariance matrix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouter, I agree that a full covariance matrix including momentum with positions (DCA positions of the tracks w.r.t the reconstructed vertex) would be more complete. From previous experience to my knowledge, the relevant covariance matrices were used in reconstruction and fitting, but not really used in the downstream analysis. Most of the downstream analysis will work on optimization with the selection cuts on various topology (error-normalized) variables saved here. But if there is an interest to keep them, it shouldn't be difficult to add the full covariance in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think adding that info is the way to go! I understand that right now that only the 3-momenta is really used in analysis, but I think that offering a more complete set of information on the daughters goes a long way towards ensuring that the datatype (or datatypes) implemented here can support a much wider array of analyses in the near(ish) term.