Skip to content

Conversation

@martenole
Copy link
Contributor

  • 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

bazinski
bazinski previously approved these changes Apr 9, 2021
tdietel
tdietel previously approved these changes 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
@martenole martenole dismissed stale reviews from tdietel and bazinski via 91d97c1 April 10, 2021 11:37
@martenole martenole force-pushed the trd-calib-combined branch from bb5ba44 to 91d97c1 Compare April 10, 2021 11:37
bazinski
bazinski previously approved these changes Apr 10, 2021
jolopezl
jolopezl previously approved these changes Apr 10, 2021
Comment on lines 58 to 61
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
Copy link
Contributor

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
Copy link
Collaborator

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

Copy link
Contributor Author

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?

Copy link
Collaborator

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?

Copy link
Contributor Author

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?

Copy link
Collaborator

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.

Copy link
Contributor Author

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.

@shahor02
Copy link
Collaborator

@martenole sure, will merge it once the o2 test has passed.

@martenole martenole dismissed stale reviews from jolopezl and bazinski via 291ebf1 April 12, 2021 13:59
@martenole
Copy link
Contributor Author

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.

@martenole
Copy link
Contributor Author

@shahor02 could you merge this please when you get a chance?

@davidrohr davidrohr merged commit 902bdd8 into AliceO2Group:dev Apr 13, 2021
@martenole martenole deleted the trd-calib-combined branch April 13, 2021 09:47
cortesep pushed a commit to cortesep/AliceO2 that referenced this pull request Jun 11, 2021
* 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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

6 participants