Add Geant track info (g2t) to StFcsHit #379
Conversation
…rimary in StFcsDb
|
I believe that will work.
…On 2022-07-29 09:02, akioogawa wrote:
@akioogawa commented on this pull request.
-------------------------
In StRoot/StEvent/StFcsHit.cxx [1]:
> @@ -139,3 +141,26 @@ void StFcsHit::print(Option_t *option) const {
}
cout << endl;
}
+
+void StFcsHit::addGeantTrack(const unsigned int id, float e){
+ // auto cmp = [](auto t){ return t.first == id; }; //c++20
+ auto cmp = [id](decltype(mGeantTracks)::value_type t){ return
t.first == id; };
+ auto trk = find_if(begin(mGeantTracks), end(mGeantTracks), cmp);
auto trk = find_if(rbegin(mGeantTracks), rend(mGeantTracks), cmp);
if(trk == rend(mGeantTracks)){...}
Will this make the auto to be reverse iterator automatically? Or do I
need do something like
std::vector<pair<unsigned int,float>::reverse_iterator trk=
find_if(...)
--
Reply to this email directly, view it on GitHub [1], or unsubscribe
[2].
You are receiving this because your review was requested.Message ID:
***@***.***>
Links:
------
[1] #379 (comment)
[2]
https://github.com/notifications/unsubscribe-auth/ANL4LVAQNS5YZV3Z3VE7Q4DVWPI6DANCNFSM54Z7A5NQ
|
|
@akioogawa can you elaborate on how the new data member |
|
A student is working on cluster finder for charged hadrons at StEvent file right now. Once this is in the place, Daniel will be adding this to Mudst, and we move on to Mudst. |
| @@ -87,9 +87,13 @@ class StFcsHit : public StObject { | |||
| void setCluster(StFcsCluster* clu) {mCluster = clu;} | |||
| StFcsCluster *cluster() {return mCluster;} | |||
|
|
|||
| const vector<pair<unsigned int, float>>& getGeantTracks() const {return mGeantTracks;} | |||
There was a problem hiding this comment.
Do we really need this information? It's not complete enough to learn something about the shower, but too complicated to learn about what caused the hit. I don't see why the analyzers couldn't get by with just unsigned int idTruth() and float qaTruth() (aka fraction in your current PR). This should be enough for two-particle studies (energy fraction that is not associated with the leading particle must be coming from the other one). I suppose, unlike for TPC, you also wanted to store the particle that arrived to the detector (getParentG2tTrack) in the current PR, but again, this is not equivalent to storing energy and id of every hit.
I'm mostly asking because I'm pretty sure the interface from StEvent is going to migrate to MuDst without a change.
There was a problem hiding this comment.
Yes, it is needed. A single ID truth is insufficient to understand the relative contributions of electromagnetic and hadronic components to the cluster energy response (You don't know what the "rest" of the energy is...)
With the list of track IDs hitting each cluster, their contribution to the energy deposition in the cluster, and the MC track's kinematics from the MC event record, you have the complete information needed to understand the clustering performance.
There was a problem hiding this comment.
Yes, it is needed. A single ID truth is insufficient to understand the relative contributions of electromagnetic and hadronic components to the cluster energy response (You don't know what the "rest" of the energy is...)
Okay, but if that is the case, I need to also save PDG id. If not, I need to look into geant.root, and at this point I might as well not save anything to event.root. Right?
With the list of track IDs hitting each cluster, their contribution to the energy deposition in the cluster, and the MC track's kinematics from the MC event record, you have the complete information needed to understand the clustering performance.
Again, for any foreseeable study, there are just two particles that could merge into the same cluster, one fraction per cell describes that case it well enough.
There was a problem hiding this comment.
Okay, but if that is the case, I need to also save PDG id. If not, I need to look into geant.root, and at this point I might as well not save anything to event.root. Right?
PDG ID is available in the MuDst MuMcTrack branch.
Again, for any foreseeable study, there are just two particles that could merge into the same cluster, one fraction per cell describes that case it well enough.
Relative contribution of hadronic and electromagnetic particles to the energy of a cluster is one such study which requires this information.
There was a problem hiding this comment.
PDG ID is available in the MuDst MuMcTrack branch.
I'm not very familiar with that facility. And this answer also implies that this structure will be propagated to MuDst.
Again, for any foreseeable study, there are just two particles that could merge into the same cluster, one fraction per cell describes that case it well enough.
Relative contribution of hadronic and electromagnetic particles to the energy of a cluster is one such study which requires this information.
Okay, so that would be a study that looks at cluster merging and hadronic/electromagnetic fractions at the same time. Thank you for the explanations. I hope other experts/analyzers can chime in.
There was a problem hiding this comment.
- Yes, idTruth is not enough, especially when many towers contributing to a cluster, and hadron showers are fat and big.
- Yes, when we get to mudst, since Mudst has StMcTrack, but not g2t_hits.
- No, when reading event.root file and geant.root file in sync. But this means we essentially re-run StFcsFastSimulationMake and creating new StFcsHits. (for historical reason, we don't have StMcTrack in StEvent).
| return &g2ttrk[primary[order].first-1]; | ||
| } | ||
|
|
||
| const g2t_track_st* StFcsDb::getParentG2tTrack(StFcsCluster* c, g2t_track_st* g2ttrk, float& fraction, int& ntrk, unsigned int order){ |
There was a problem hiding this comment.
I think it would be good to document somewhere what order means in these functions. It appears to me that invoking these functions with different values of order will be mean repeating all the code as nothing about the parents is stored/cached, so I'd really like to better understand the use cases of order to understand if this is the best way to encode these functions.
Thanks,
-Gene
There was a problem hiding this comment.
- It is in commet in StFcsDb.h file
- With order=0 returns the highest contributing g2t_track_id
- With order=1 returns the 2nd highest contributing g2t_track_id
- Yes, I can make sorted vector available to user....But then user need to delete them.
- Or cache sorted results somehow, but then delete when & where?
- Any suggestions will be welcomed
- const taken out from passing by value StFcsDb - "using namespace std;" added - doxygen-style (///) comment, including what "order" means - std::sort => std::nth_element
Make use of getG2tTrack for StFcsHit as well using dummy cluster Changing to range loop instead of index loop in getG2tTrack.
|
I adopted your idea of fake cluster and also dropped auto sorting in StFcsFastSimulagtorMaker, leaving all sorting done in StFcsDb utility function at analysis stage. |
plexoos
changed the title
|
Just did merge main into this branch. Any other comments? |
|
Hi Daniel, looks like we need your approval to include this change in the next SL22c release |
[skip ci]
Adding parent g2t track info to StEvent/StFcsHit.
Update StFcsFastSimulatorMaker to push these info from g2t table to StFcsHit.
Adding utility functions to trace back to immediate parent and primary g2t track for a given StFcsHit and StFcsCluster in StFcsDb.