possible msr2data in global+ mode bug #16

New Issue

2026-08-22T15:43:30+02:00

salman commented

2026-08-22 15:43:30 +02:00

When using msr2data in global+ mode, the fitted parameters of the first run are not transferred to the final +global MSR file if the first run number is also the template run number.

For example:

msr2data 514 515 516 _asy global+ msr-514

global+ correctly generates and fits:

514-OneRunFit_asy.msr
515-OneRunFit_asy.msr
516-OneRunFit_asy.msr

However, in the resulting

514+global_asy.msr

the run-specific parameters for runs 515 and 516 contain the results of their individual fits, while the parameters for run 514 still contain the values from the original template rather than the fit results from 514-OneRunFit_asy.msr.

Expected behaviour

In global+ mode, the run-specific parameters for all runs, including a run whose number is identical to the template run number, should be initialized from the corresponding fitted OneRunFit file.

Likely cause

In PMsr2Data::PrepareGlobalInputFile(), all OneRunFit files are generated and fitted first. The code subsequently starts constructing the global file.

For the first run, however, reading the fitted OneRunFit file and copying its fitted parameter values is inside:

if (newRunNumber.str().compare(tempRunNumber.str())) {
// in global+ mode, read in the single run msr-file
if (globalPlus) {
singleRunMsrFile = GetSingleRunMsrFile();
...
}

...

if (globalPlus && singleRunMsrFile) {
    fMsrHandler->SetMsrParamValue(...);
    fMsrHandler->SetMsrParamStep(...);
}

}

Thus, when

newRunNumber == tempRunNumber

this complete block is skipped. No renaming is required in this case, but the fitted parameter values from the corresponding OneRunFit file still need to be imported. The subsequent runs do not have this problem because their run numbers differ from the template run number. This conditional is visible in the current PMsr2Data.cpp implementation.

The documented behaviour of global+ is that the resulting global file includes the fit results from the OneRunFit files for the run-specific parameters, so I believe the template-number case is an unintended special case. A possible solution would be to separate the loading/copying of the OneRunFit parameter values from the code that renames parameters and RUN blocks. The latter should remain conditional on the run number differing from the template, whereas importing the fitted values should happen for every run in global+ mode.

When using msr2data in global+ mode, the fitted parameters of the first run are not transferred to the final +global MSR file if the first run number is also the template run number. For example: msr2data 514 515 516 _asy global+ msr-514 global+ correctly generates and fits: 514-OneRunFit_asy.msr 515-OneRunFit_asy.msr 516-OneRunFit_asy.msr However, in the resulting 514+global_asy.msr the run-specific parameters for runs 515 and 516 contain the results of their individual fits, while the parameters for run 514 still contain the values from the original template rather than the fit results from 514-OneRunFit_asy.msr. Expected behaviour In global+ mode, the run-specific parameters for all runs, including a run whose number is identical to the template run number, should be initialized from the corresponding fitted OneRunFit file. Likely cause In PMsr2Data::PrepareGlobalInputFile(), all OneRunFit files are generated and fitted first. The code subsequently starts constructing the global file. For the first run, however, reading the fitted OneRunFit file and copying its fitted parameter values is inside: if (newRunNumber.str().compare(tempRunNumber.str())) { // in global+ mode, read in the single run msr-file if (globalPlus) { singleRunMsrFile = GetSingleRunMsrFile(); ... } ... if (globalPlus && singleRunMsrFile) { fMsrHandler->SetMsrParamValue(...); fMsrHandler->SetMsrParamStep(...); } } Thus, when newRunNumber == tempRunNumber this complete block is skipped. No renaming is required in this case, but the fitted parameter values from the corresponding OneRunFit file still need to be imported. The subsequent runs do not have this problem because their run numbers differ from the template run number. This conditional is visible in the current PMsr2Data.cpp implementation. The documented behaviour of global+ is that the resulting global file includes the fit results from the OneRunFit files for the run-specific parameters, so I believe the template-number case is an unintended special case. A possible solution would be to separate the loading/copying of the OneRunFit parameter values from the code that renames parameters and RUN blocks. The latter should remain conditional on the run number differing from the template, whereas importing the fitted values should happen for every run in global+ mode.

salman added the bug label 2026-08-22 15:43:58 +02:00

suter_a referenced this issue from a commit

2026-08-23 09:52:05 +02:00

fix 'possible msr2data in global+ mode bug' bug report #16 gitea

suter_a commented

2026-08-23 09:53:21 +02:00

sha 3236df1678 fixes the issue

sha 3236df1678301ebd03a3ca691b0ae1fed805cc3d fixes the issue

suter_a closed this issue

2026-08-23 09:53:21 +02:00

lmu-gitea referenced this issue from a commit

2026-08-23 10:26:43 +02:00