Skip to content

dpl-workflow: Add missing flags to disable ctp-lumi-request #15446

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.

Sign up for GitHub

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

Merged
davidrohr merged 1 commit into from
May 28, 2026
+2 −2
Merged

dpl-workflow: Add missing flags to disable ctp-lumi-request #15446

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions prodtests/full-system-test/dpl-workflow.sh
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -542,7 +542,7 @@ if [[ -n $INPUT_DETECTOR_LIST ]]; then
DISABLE_DIGIT_ROOT_INPUT=
TOF_INPUT=digits
GPU_INPUT=zsonthefly
has_detector TPC && add_W o2-tpc-reco-workflow "--input-type digits --output-type zsraw,disable-writer $DISABLE_MC --pipeline $(get_N tpc-zsEncoder TPC RAW 1 TPCRAWDEC)"
has_detector TPC && add_W o2-tpc-reco-workflow "--input-type digits --output-type zsraw,disable-writer $DISABLE_MC $([[ $TPC_CORR_OPT == *--disable-ctp-lumi-request* ]] && echo --disable-ctp-lumi-request) --pipeline $(get_N tpc-zsEncoder TPC RAW 1 TPCRAWDEC)"
Copy link
Copy Markdown
Collaborator

@shahor02 shahor02 May 29, 2026

Choose a reason for hiding this comment

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

@davidrohr @fweig Does o2-tpc-reco-workflow ever need the tpc-scaler workflow if the output-type is not tracks. And the same for the CTPLumi (used only to scale TPC tracks syst errors).

In opposite, for the same reason, if in the o2-gpu-reco the we add --disable-ctp-lumi-request (e.g. because the scaling is done with IDC), how the TPC syst errors scaling will be done? https://github.com/fweig/AliceO2/blob/cba61dce62a1a213e20e68581ffc5c0adf225825/prodtests/full-system-test/dpl-workflow.sh#L615

Copy link
Copy Markdown
Collaborator

@davidrohr davidrohr May 30, 2026

Choose a reason for hiding this comment

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

@shahor02 : if i inderstand correctly, this fix was suggested by @matthias-kleiner

Copy link
Copy Markdown
Contributor

@matthias-kleiner matthias-kleiner May 31, 2026

Choose a reason for hiding this comment

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

Hi @davidrohr @shahor02 ,

Does o2-tpc-reco-workflow ever need the tpc-scaler workflow if the output-type is not tracks. And the same for the CTPLumi (used only to scale TPC tracks syst errors).

If the o2-tpc-reco-workflow does not have output type tracks, then I think in principle you also dont need the tpc-scaler-workflow. If I understand correctly the tpc-scaler-workflow is now always added when we run with TPC. So if you run only with output type cluster and dont need the tracks, then we could disable the tpc-scaler-workflow. But then you would still need to set the --disable-ctp-lumi-request in the tpc-reco-workflow.

In opposite, for the same reason, if in the o2-gpu-reco the we add --disable-ctp-lumi-request (e.g. because the scaling is done with IDC), how the TPC syst errors scaling will be done? https://github.com/fweig/AliceO2/blob/cba61dce62a1a213e20e68581ffc5c0adf225825/prodtests/full-system-test/dpl-workflow.sh#L615

I think we set the --disable-ctp-lumi-request only in case CTP is not available or? It should not be used for switching to IDC scaling in the tpc-scaler-workflow. The scaling source for the corrections in the tpc-scaler-workflow should always be set with the addOption(options, ConfigParamSpec{"lumi-type", o2::framework::VariantType::Int, 0, {"1 = use CTP lumi for TPC correction scaling, 2 = use TPC scalers for TPC correction scaling"}}); https://github.com/AliceO2Group/AliceO2/blob/babe031809ef7185a73c2a04ecaa66eff1b95df2/Detectors/TPC/calibration/src/CorrectionMapsOptions.cxx#L47`

Before we made the PR with all the changes for the map merging we had only that one option --disable-ctp-lumi-request that disabled the CTP for correction maps scaling and the cluster errors and since both were done in one workflow we needed this option only once. But now we need it for the scaler-workflow and the tpc-reco-workflow. But perhaps there is also a better way to do that...

So to my understanding this PR should be correct, but we could disable the tpc-scaler-workflow if we dont need TPC tracks. Or do I miss something?

Copy link
Copy Markdown
Collaborator

@shahor02 shahor02 May 31, 2026

Choose a reason for hiding this comment

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

Thanks @matthias-kleiner! My concern is not this PR per se (except that we could eliminate the tpc-scaler process from the o2-tpc-reco in absence of tracks output and always suppress the ctp input) but the way input of the ctp lumi to o2-gpu-workflow (and other workflows dealing with TPC syst.errors) is organized: it is true that currently the setenv-extra adds --disable-ctp-lumi-request to TPC_CORR_SCALING only in absence of the CTP (thus, adding a redundant input in case of the IDC scaling), but I don't like that if for some reason we restrict the tpc-scalers input to strictly needed ones, then the TPC syst.errors scaling will be broken. I would disable the request for CTP inputs in these workflows only in the absence of CTP detector directly.

BTW, now I realized that the TPC errors scaling is incorrect already now: the $TPC_CORR_KEY is added to tpc-scaler, and matching workflows, but not the to o2-gpu-reco. Hence, in the case of PbPb, the TPCCorrMap.lumiInstFactor=2.414 is not passed to the o2-gpu-reco and the scaling is done at the face value of the ZDC lumi counter. I'll add it, but I think the most robust way (working also in the absence of the CTP) would be to force the tpc-scaler to send a dedicated "pp-equivalent" lumi scaler, which the downstream processes would subscribe to instead of the CTP lumi. In the presence of the CTP, it could send the scaler equivalent to what we have today (ctp_lumi * TPCCorrMap.lumiInstFactor). When CTP is absent, it could send the IDC scaler rescaled by the appropriate factor.

Copy link
Copy Markdown
Contributor

@matthias-kleiner matthias-kleiner May 31, 2026

Choose a reason for hiding this comment

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

I agree that the current handling of the CTP scaling is somewhat fragile. Sending a dedicated pp-equivalent luminosity scaler that other workflows consume would indeed be cleaner.
Looking at the code, it seems that instLumi is already stored as the scaled value in tpc-scaler and forwarded downstream. Am I missing where o2-gpu-reco bypasses this and uses the raw CTP lumi instead?

The instLumi is stored as the scaled value here:

AliceO2/Detectors/TPC/calibration/src/CorrectionMapsLoader.cxx

Line 82 in babe031

setInstLumiCTP(mInstLumiCTPFactor * (mLumiCTPSource == 0 ? lumiObj.getLumi() : lumiObj.getLumiAlt()));

and then forwarded here:

AliceO2/Detectors/TPC/workflow/src/TPCScalerSpec.cxx

Line 175 in babe031

const float lumiCTP = mTPCCorrMapsLoader.getInstLumiCTP();

In that case, renaming it as you suggested would also make sense. Then the only missing part would be the conversion from IDC to the corresponding pp-equivalent luminosity value, if I understand correctly?

Copy link
Copy Markdown
Collaborator

@shahor02 shahor02 May 31, 2026

Choose a reason for hiding this comment

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

Thanks! Indeed, I did not check that now global matchers and gpu reco. get the lumi output of the tpc-scaler, rather than accessing the CTP input directly and rescaling it if needed. But then, we don't need to pass the $TPC_CORR_KEY to the global matchers (which confused me).
Indeed, as it is now, we just need to emulate with the IDC data a scaled CTP lumi in case the CTP is absent.
What I would do additionally is to avoid adding the tpc-scaler-process from the TPC workflows and global matchers in the --disable-root-inputs mode: in the dpl-workflow driven workflows, it is already added as a separate workflow, in the MC it will be added together with readers when needed, as all dependencies.

has_detector MID && add_W o2-mid-digits-reader-workflow "$DISABLE_MC" ""
else
if [[ $NTIMEFRAMES == -1 ]]; then NTIMEFRAMES_CMD= ; else NTIMEFRAMES_CMD="--max-tf 0 --loop $NTIMEFRAMES"; fi
Expand Down Expand Up @@ -577,7 +577,7 @@ if [[ $CTFINPUT == 0 && $DIGITINPUT == 0 ]]; then
RAWTODIGITOPTIONS+=" --ignore-trigger"
fi
add_W o2-tpc-raw-to-digits-workflow "--input-spec \"\" --remove-duplicates $RAWTODIGITOPTIONS --pipeline $(get_N tpc-raw-to-digits-0 TPC RAW 1 TPCRAWDEC)"
add_W o2-tpc-reco-workflow "--input-type digitizer --output-type zsraw,disable-writer --pipeline $(get_N tpc-zsEncoder TPC RAW 1 TPCRAWDEC)" "GPU_rec_tpc.zsThreshold=0"
add_W o2-tpc-reco-workflow "--input-type digitizer --output-type zsraw,disable-writer $([[ $TPC_CORR_OPT == *--disable-ctp-lumi-request* ]] && echo --disable-ctp-lumi-request) --pipeline $(get_N tpc-zsEncoder TPC RAW 1 TPCRAWDEC)" "GPU_rec_tpc.zsThreshold=0"
fi
has_detector ITS && ! has_detector_from_global_reader ITS && add_W o2-itsmft-stf-decoder-workflow "--nthreads ${NITSDECTHREADS} --raw-data-dumps $ALPIDE_ERR_DUMPS $ITS_STAGGERED --pipeline $(get_N its-stf-decoder ITS RAW 1 ITSRAWDEC)" "$ITS_STF_DEC_CONFIG;$ITSMFT_STROBES;VerbosityConfig.rawParserSeverity=warn;"
has_detector MFT && ! has_detector_from_global_reader MFT && add_W o2-itsmft-stf-decoder-workflow "--nthreads ${NMFTDECTHREADS} --raw-data-dumps $ALPIDE_ERR_DUMPS $MFT_STAGGERED --pipeline $(get_N mft-stf-decoder MFT RAW 1 MFTRAWDEC) --runmft true" "$MFT_STF_DEC_CONFIG;$ITSMFT_STROBES;VerbosityConfig.rawParserSeverity=warn;"
Expand Down