Skip to content

Conversation

@matthias-kleiner
Copy link
Contributor

  • will be used for scaling of vdrift and gain

Optimizing temperature processing

  • move fitting of temperature to definition of temperature struct
  • optimize fit procedure by merging last interval in case it is needed

Adding processing of DCS pressure values and storage in CCDB

  • first pressure sensor in the cavern serves as the reference
  • second pressure sensor in the cavern and third sensor at the surface are normalized to reference pressure sensor

@github-actions
Copy link
Contributor

github-actions bot commented Jun 4, 2025

REQUEST FOR PRODUCTION RELEASES:
To request your PR to be included in production software, please add the corresponding labels called "async-" to your PR. Add the labels directly (if you have the permissions) or add a comment of the form (note that labels are separated by a ",")

+async-label <label1>, <label2>, !<label3> ...

This will add <label1> and <label2> and removes <label3>.

The following labels are available
async-2023-pbpb-apass4
async-2023-pp-apass4
async-2024-pp-apass1
async-2022-pp-apass7
async-2024-pp-cpass0
async-2024-PbPb-apass1
async-2024-ppRef-apass1
async-2024-PbPb-apass2
async-2023-PbPb-apass5

- will be used for scaling of vdrift and gain

Optimizing temperature processing
- move fitting of temperature to definition of temperature struct
- optimize fit procedure by merging last interval in case it is needed

Adding processing of DCS pressure values and storage in CCDB
- first pressure sensor in the cavern serves as the reference
- second pressure sensor in the cavern and third sensor at the surface are normalized
to reference pressure sensor
@matthias-kleiner
Copy link
Contributor Author

Hello @wiechula ,
if the output format of the pressure is fine, I can make the upload request to the CCDB. I already put it in the test CCDB for testing (http://ccdb-test.cern.ch:8080/browse/TPC/Calib/Pressure)

@shahor02
Copy link
Collaborator

shahor02 commented Jun 4, 2025

@matthias-kleiner how the TPCPressureTemperatureSpec device will be used? Does it go to the global reconstruction workflow?

@matthias-kleiner
Copy link
Contributor Author

@matthias-kleiner how the TPCPressureTemperatureSpec device will be used? Does it go to the global reconstruction workflow?

I think it will be used wherever the v-Drift is used. Perhaps @wiechula can comment on this?

wiechula
wiechula previously approved these changes Jun 4, 2025
@wiechula
Copy link
Collaborator

wiechula commented Jun 4, 2025

@shahor02 , yes, the idea is to inject the pressure and temperature values into the data stream during reconstruction.
It should then be used in the vdrift and gain calibration.

@wiechula
Copy link
Collaborator

wiechula commented Jun 4, 2025

@matthias-kleiner , thanks a lot! For me this looks fine.

@shahor02
Copy link
Collaborator

shahor02 commented Jun 4, 2025

@matthias-kleiner @wiechula I am wondering if it is worth running a separate processes just to send downstream a couple of numbers. This might be necessary in case e.g. ITS-TPC matching running with tracks,clusters input from the files, but for full production workflow it would be more economical to call a helper from the TPC reco device and send the values from it.

@wiechula
Copy link
Collaborator

wiechula commented Jun 4, 2025

@matthias-kleiner , could you implement such a helper? I think we can also keep the separate process.

@matthias-kleiner
Copy link
Contributor Author

@shahor02 Could you explain how such a helper function should be implemented and where exactly to put it?
@wiechula can correct me, but I think we would also use it in the tpc digitizer to simulate the dependence of gain and vdrift on p/T and use it not only in the reconstruction.

@shahor02
Copy link
Collaborator

shahor02 commented Jun 4, 2025

@matthias-kleiner my main concern is adding a new process which will cost ~100 MB or more just to send a few numbers.
I could be a helper like the TPC VDriftHelper, which knows how to add needed CCDB inputs to the externally provided inputs vector and how to digest them, see

void VDriftHelper::extractCCDBInputs(ProcessingContext& pc, bool laser, bool itstpcTgl)
{
if (mForceParamDrift && mForceParamOffset) { // fixed from the command line
return;
}
if (laser && !mForceParamDrift) {
pc.inputs().get<o2::tpc::LtrCalibData*>("laserCalib");
}
if (itstpcTgl) {
pc.inputs().get<o2::tpc::VDriftCorrFact*>("vdriftTgl");
}
if (mUpdated) { // there was a change
// prefer among laser and tgl VDrift the one with the latest update time
auto saveVD = mVD;
mVD = mVDTPCITSTgl.creationTime < mVDLaser.creationTime ? mVDLaser : mVDTPCITSTgl;
auto& loserVD = mVDTPCITSTgl.creationTime < mVDLaser.creationTime ? mVDTPCITSTgl : mVDLaser;
if (mForceParamDrift) {
mVD.refVDrift = saveVD.refVDrift;
mVD.corrFact = saveVD.corrFact;
mVD.corrFactErr = 0.f;
}
if (mForceParamOffset) {
mVD.refTimeOffset = saveVD.refTimeOffset;
mVD.timeOffsetCorr = 0.f;
}
mSource = mVDTPCITSTgl.creationTime < mVDLaser.creationTime ? Source::Laser : Source::ITSTPCTgl;
auto loseCTime = loserVD.creationTime;
loserVD = mVD; // override alternative VD to avoid normalization problems later
loserVD.creationTime = loseCTime;
std::string rep = fmt::format("Prefer TPC Drift from {} with time {} to {} with time {}",
SourceNames[int(mSource)], mVD.creationTime, mSource == Source::Laser ? SourceNames[int(Source::ITSTPCTgl)] : SourceNames[int(Source::Laser)],
mSource == Source::Laser ? mVDTPCITSTgl.creationTime : mVDLaser.creationTime);
if (mForceParamDrift || mForceParamOffset) {
std::string impos = mForceParamDrift ? "VDrift" : "";
if (mForceParamOffset) {
impos += mForceParamDrift ? " and DriftTimeOffset" : "DriftTimeOffset";
}
rep += fmt::format(" but {} imposed from command line", impos);
}
LOGP(info, "{}", rep);
}
}
//________________________________________________________
void VDriftHelper::requestCCDBInputs(std::vector<InputSpec>& inputs, bool laser, bool itstpcTgl)
{
if (laser) {
addInput(inputs, {"laserCalib", "TPC", "CalibLaserTracks", 0, Lifetime::Condition, ccdbParamSpec(CDBTypeMap.at(CDBType::CalLaserTracks))});
}
if (itstpcTgl) {
// VDrift calibration may change during the run (in opposite to Laser calibration, at least at the moment), so ask per-TF query
addInput(inputs, {"vdriftTgl", "TPC", "VDriftTgl", 0, Lifetime::Condition, ccdbParamSpec(CDBTypeMap.at(CDBType::CalVDriftTgl), {}, 1)});
}
}
//________________________________________________________
void VDriftHelper::addInput(std::vector<InputSpec>& inputs, InputSpec&& isp)
{
if (std::find(inputs.begin(), inputs.end(), isp) == inputs.end()) {
inputs.emplace_back(isp);
}
}
//________________________________________________________
bool VDriftHelper::accountCCDBInputs(const ConcreteDataMatcher& matcher, void* obj)
{
if (matcher == ConcreteDataMatcher("TPC", "VDriftTgl", 0)) {
accountDriftCorrectionITSTPCTgl(static_cast<VDriftCorrFact*>(obj));
return true;
}
if (matcher == ConcreteDataMatcher("TPC", "CalibLaserTracks", 0)) {
accountLaserCalibration(static_cast<LtrCalibData*>(obj));
return true;
}
return false;
}

Then it can be used either inside the existing device, e.g., as shown in

mTPCVDriftHelper->extractCCDBInputs(pc);
, with its output sent out from the same device, or it can be wrapped into a standalone process.

@matthias-kleiner
Copy link
Contributor Author

Many thanks for the explanation @shahor02 . This makes indeed more sense. I will then implement it as you suggested

@matthias-kleiner
Copy link
Contributor Author

Hello @shahor02 @wiechula
I implemented the helper function. Is it what you had in mind?

Copy link
Collaborator

@shahor02 shahor02 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly, thanks!

@wiechula wiechula merged commit 1fb877f into AliceO2Group:dev Jun 6, 2025
13 checks passed
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.

3 participants