Changes to run pandora on tracks created from generator-level particles #43
Conversation
|
Hi Giovanni, can you add to the release note that this is a work around needed because currently one can not us the edm4hep <--> lcio converters when using functionals? |
|
Done |
| Gaudi::Property<float> m_Bz{this, "Bz", 2., "Z component of the (assumed constant) magnetic field in Tesla."}; | ||
| /// Inner radius of the ECAL | ||
| Gaudi::Property<float> m_RadiusAtCalo{this, "RadiusAtCalo", 2172.8, "Inner radius (in mm) of the calorimeter where the TrackState::AtCalorimeter should be defined."}; |
There was a problem hiding this comment.
Since we are modifying this anyway, shall we profit from the occasion to add GeoSvc here and retrieve the magnetic field from there + the inner calorimeter radius?
There was a problem hiding this comment.
ok will try to have a look at this
| Gaudi::Property<float> m_Bz{this, "Bz", 2., "Z component of the (assumed constant) magnetic field in Tesla."}; | ||
| /// Inner radius of the ECAL | ||
| Gaudi::Property<float> m_RadiusAtCalo{this, "RadiusAtCalo", 2172.8, "Inner radius (in mm) of the calorimeter where the TrackState::AtCalorimeter should be defined."}; |
There was a problem hiding this comment.
what would this be called for the endcap? Lower z?
There was a problem hiding this comment.
I guess for endcap we would need to know innerZ and also lowerR. But if we retrieve the info from GeoSvc, then we don't need to think about the name of these properties ;)
| auto MCRecoTrackParticleAssociationCollection = new edm4hep::TrackMCParticleLinkCollection(); | ||
|
|
||
| // loop over the gen particles, find charged ones, and create the corresponding reco particles | ||
| int iparticle = 0; |
There was a problem hiding this comment.
Is this useful? If you want a unique identifier, what about genParticle.getObjectID() in the print below?
There was a problem hiding this comment.
iparticle is not to provide a unique identifier, just to print in the debug information the position in the MCParticle vector in case one would like to look at more details in the simulation file.
| for (const auto& hit : *coll) { | ||
| const edm4hep::MCParticle particle = hit.getParticle(); | ||
| std::array<double,6> ahit{hit.x(), hit.y(), hit.z(), hit.getMomentum()[0], hit.getMomentum()[1], hit.getMomentum()[2]}; | ||
| if(particle.getVertex() == genParticle.getVertex() && particle.getMomentum() == genParticle.getMomentum()) trackHits.push_back(ahit); |
There was a problem hiding this comment.
Why not if(particle.getObjectID() == genParticle.getObjectID()?
There was a problem hiding this comment.
This line was just copied over from Archil's code. I can replace it with your proposed change
|
|
||
| if(!trackHits.empty()) | ||
| { | ||
| // particles with at least one SimTrackerHit |
There was a problem hiding this comment.
is there an indentation problem or just my display?
| debug() << "Number of SimTrackerHits: " << trackHits.size() << endmsg; | ||
|
|
||
| // sort the hits according to radial distance from beam axis | ||
| // FIXME: does this work well also for tracks going to endcaps of vtx/wrapper? |
There was a problem hiding this comment.
I think we have to go in Pandora to see how this should be defined for the endcap... It would likely become the "z" coordinate I guess. If yes, we have to add the GeoSvc and use the flags DETYPE_ENDCAP
There was a problem hiding this comment.
well, one has to pass to pandora the latest track hit before the ECAL, so that is well defined, I'd say. It's just to think if sorting in radial distance is the most robust way to get the last hit for all tracks - probably in the endcap it will be the hits with largest |z| ?
|
|
||
| // TrackState at First Hit | ||
| auto trackState_AtFirstHit = edm4hep::TrackState {}; | ||
| auto firstHit = trackHits.front(); |
|
|
||
| // TrackState at Last Hit | ||
| auto trackState_AtLastHit = edm4hep::TrackState{}; | ||
| auto lastHit = trackHits.back(); |
| trackState_AtFirstHit.omega = helixAtFirstHit.getOmega(); | ||
| trackState_AtFirstHit.Z0 = helixAtFirstHit.getZ0(); | ||
| trackState_AtFirstHit.tanLambda = helixAtFirstHit.getTanLambda(); | ||
| trackState_AtFirstHit.referencePoint = edm4hep::Vector3f((float)posAtFirstHit[0],(float)posAtFirstHit[1],(float)posAtFirstHit[2]); |
There was a problem hiding this comment.
Does Pandora expect this as the "real" first hit present in the track or is it rather a convention to define also the trackState at the first layer of the tracking system (regardless of whether there is an actual hit or not)? (possibly look at how they are defined for CLD)
There was a problem hiding this comment.
The same question holds for the other trackStates
There was a problem hiding this comment.
to be investigated. Anyway for truth primary tracks and no detector inefficiency the two things are more or less the same (things differ from secondaries of course..)
Started from Archil's implementation in https://github.com/Archil-AD/k4RecTracker/tree/pandora but
BEGINRELEASENOTES
ENDRELEASENOTES
Tagging @BrieucF - let's have a look at the code not just in terms of style but also at what it does so that we do things right. For instance might be things that need to be done a bit differently for tracks that point towards the ECAL endcap rather than the barrel. I will make it a draft while we iterate over it