AggregatedRunInfo can be requested via GRPGeomHelper + related fixes#13586
AggregatedRunInfo can be requested via GRPGeomHelper + related fixes#13586shahor02 merged 4 commits intoAliceO2Group:devfrom
Conversation
shahor02
requested review from
a team,
Barthelemy,
benedikt-voelkel,
costing and
sawenzel
as code owners
|
REQUEST FOR PRODUCTION RELEASES: This will add The following labels are available |
| mAggregatedRunInfo.orbitEOR = (mAggregatedRunInfo.eor * 1000 - mOrbitResetTimeMUS) / o2::constants::lhc::LHCOrbitMUS; | ||
| // adjust to the nearest TF edge to satisfy condition (orbitSOR % nOrbitsPerTF == 0) | ||
| mAggregatedRunInfo.orbitSOR = (mAggregatedRunInfo.orbitSOR / mAggregatedRunInfo.orbitsPerTF + 1) * mAggregatedRunInfo.orbitsPerTF; // +1 to choose the safe boundary ... towards run middle | ||
| mAggregatedRunInfo.orbitEOR = mAggregatedRunInfo.orbitEOR / mAggregatedRunInfo.orbitsPerTF * mAggregatedRunInfo.orbitsPerTF; |
There was a problem hiding this comment.
I do not understand this part. It seems that the calculation of of AggregateRunInfo::buildAggregateRunInfo is repeated. Could this be avoided (by potentially refactoring methods in AggregatedRunInfo) ?
There was a problem hiding this comment.
Sure, it was a partial copy-paste from the previous AggregateRunInfo code, should be changed.
ccdbParamSpec run-dependence flag changed from bool to int. The new convension is: ccdbParamSpec(path) : not run-depndent ccdbParamSpec(path, 1) : run-dependent object with usual timestamp and runNumber requested via metadata ccdbParamSpec(path, 2) : run-dependent object with runNumber used instead of timestamp. So, the entry like RCT/Info/RunInformation should be requested by passing 2.
To do this, request it after creating auto ggRequest = std::make_shared<o2::base::GRPGeomRequest>(...) as ggRequest->requireAggregateRunInfo(inputs); Then, in the task, once the GRPGeomHelper::checkUpdates was called, one can access AggregatedRunInfo as const auto& rInfo = GGCCDBRequest.getAggregatedRunInfo() TODO: filling of AggregatedRunInfo requires CTP/Calib/FirstRunOrbit which is populated only starting from 15 Aug 2023. Need to retrofit it for all runs and also for special non-anchored MC range.
| int64_t ctp_run_number = (*ctfFirstRunOrbitVec)[1]; | ||
| int64_t ctp_orbitSOR = (*ctfFirstRunOrbitVec)[2]; | ||
| if (creation_timeIGNORED == -1 && ctp_run_number == -1 && ctp_orbitSOR == -1) { | ||
| LOGP(warn, "Default dummy CTP/Calib/FirstRunOrbit was provide, ignoring"); |
There was a problem hiding this comment.
In case the of the CTP/Calib/FirstRunOrbit corresponds to the newly uploaded default object https://its.cern.ch/jira/browse/O2-5422 no error will be produced, just a warning.
3 participants
Fix fetching CCDB metadata, extend ccdbRunDependent behaviour
ccdbParamSpec run-dependence flag changed from bool to int. The new convension is:
ccdbParamSpec(path) : not run-depndent
ccdbParamSpec(path, 1) : run-dependent object with usual timestamp and runNumber requested via metadata
ccdbParamSpec(path, 2) : run-dependent object with runNumber used instead of timestamp.
So, the entry like
"RCT/Info/RunInformation"should be requested by passing requesting input e.g.{"RCTRunInfo", "RCT", "RunInfo", 0, Lifetime::Condition, ccdbParamSpec("RCT/Info/RunInformation", 2)}Add a separate method to extract run-duration from RCT info headers
AggregatedRunInfo can be requested via GRPGeomHelper
To do this, request it after creating
auto ggRequest = std::make_shared<o2::base::GRPGeomRequest>(...)asggRequest->requireAggregateRunInfo(inputs);Then, in the task, once the
GRPGeomHelper::checkUpdateswas called, one can access theAggregatedRunInfoasconst auto& rInfo = GGCCDBRequest.getAggregatedRunInfo()TODO: filling of AggregatedRunInfo requires CTP/Calib/FirstRunOrbit which is populated only starting from 15 Aug 2023.
Need to retrofit it for all real runs and also for the special non-anchored MC range.