-
Notifications
You must be signed in to change notification settings - Fork 484
TRD calibration subdirectory added #5894
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
martenole
commented
Apr 9, 2021
- template for vDrift calibration
- after global tracking angular differences between TRD-only tracks and tracklets are collected
- small correction to always update to the correct pad plane during track following, since the pad row size depends also on the stack, not only on the layer
- template for vDrift calibration - after global tracking angular differences between TRD-only tracks and tracklets are collected - small correction to always update to the correct pad plane during track following, since the pad row size depends also on the stack, not only on the layer
bb5ba44 to
91d97c1
Compare
| constexpr int TIMEBINS = 30; // the number of time bins | ||
| constexpr int NBINSANGLEDIFF = 26; // the number of bins for the track angle used for the vDrift and ExB calibration based on the tracking (last bin is for under-/overflow entries) | ||
|
|
||
| // Trigger parameters |
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.
These two sections should be outside Constants.h. None of them are actually constants but configurable parameters, maybe in Simulation of Common parameters? One could pass the number of time bins through the steering code, then the trigger parameters are calculated based on that. So, yet another to-do.
| namespace trd | ||
| { | ||
|
|
||
| /// \brief VDrift calibration class |
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.
This is future ccdb object, right? Better move it to DataFormats
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.
Actually this class is supposed to do the actual calibration (create profile histograms and do some fitting) and create ccdb objects using the results. I am not sure how exactly the ccdb objects will look like, but those can then go into DataFormats.
We wanted to collect all code which does the processing for calibration in TRDCalibration, if that is ok?
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.
@martenole OK, I guessed it is an object since did not notice where the input data comes from. So, is this a future slot in the time-slot based calibration?
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.
Hi Ruben, I am not sure what you mean. This is supposed to get its input from the global tracking. After the matching of TRD tracklets to ITS-TPC tracks a refit is done for the TRD-only part and the difference between the angle of the refits and the tracklets are stored. This is the input for this device. The processing is supposed to be done every ~15 minutes. Is this what you mean with time-slot based calibration?
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.
Hi @martenole
the processing is done in parallel on 250 servers, how are planning to collect the data for 15 min? The standard way is to do the aggregation on separate server, filling the time-slots of detector-defined size, then run the calibration procedure on the content of these slots (or save them for further processing, e.g. the residuals for the SP calibration, yet to be implemented in your workflow). See https://github.com/AliceO2Group/AliceO2/tree/dev/Detectors/Calibration/README.md for details.
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.
@shahor02 I see. So yes, this is a future time-slot based calibration device. This PR is supposed to allow for the implementation and testing of the processing methods for calibration. Would it be OK to make the necessary modifications afterwards?
It will need to derive from o2::calibration::TimeSlotCalibration<> and we need to define a class for the input type and for the output container type.
|
@martenole sure, will merge it once the o2 test has passed. |
|
Not sure why the test failed (I did not see any errors in the build log, but two tests were apparently not executed). Added a small commit, since I noticed a copy paste artifact in the code and that leads to the CI running again now. |
|
@shahor02 could you merge this please when you get a chance? |
* TRD calibration subdirectory added - template for vDrift calibration - after global tracking angular differences between TRD-only tracks and tracklets are collected - small correction to always update to the correct pad plane during track following, since the pad row size depends also on the stack, not only on the layer * Remove copy-paste artifact (wrong comment)