StFwdQAMaker for optional QA of fwd systems and tracking #694
Conversation
There was a problem hiding this comment.
I'm a bit foggy on what I see in these two files: there are a lot of persistent classes here.... tracks and clusters that will be written to files? And all of these are distinct from the persistent track and cluster classes for StEvent/MuDst/PicoDst? Clarification on this strategy would be appreciated, and my apologies if I missed the explanation for this elsewhere.
|
@genevb I did not even think to reuse the MuDst io containers, but that is obviously the best thing. I removed all of the custom classes (except where some additional info is needed) and reworked it. I have a student working on integrating a handful of histograms for offline QA - will follow as a small additional PR. Note: These trees replace the previous trees produced in the StFwdTrackMaker - they provide compact trees for offline studies, fwd event visualization, and some development oriented checks while things are still changing (i.e. initial analysis tests). |
| @@ -33,6 +31,7 @@ class ObjExporter { | |||
| int p, s, i, j; | |||
| float x, y, z, out; | |||
| int nPitch = nLongitude + 1; | |||
| const float DEGS_TO_RAD = 3.14159f/180.0f; | |||
There was a problem hiding this comment.
No need to change this, but, FYI, I tried compiling this class with DEGS_TO_RAD = TMath::DegToRad() and it compiled, so somewhere amidst all the included dependencies, TMath.h is already included :-) I'm sure the compiler optimizes this calculation away such that it isn't done at run-time.
In PR #571 I removed the TTree generation that was previously baked into the StFwdTrackMaker.
This separates that functionality into a separate maker, and lays a foundation for additional QA histograms based on the full FWD tracking + matching for offline QA
Note, this depends on some changes in PR #571 - so build may fail until that is merged