Draft: YAML-based configuration in cbm::algo::Unpack.

Depends on !1176 (merged).

First steps for switching to YAML-based parameter initialization in cbm::algo::Unpack.

Currently for STS only. Additional systems will be added when YAML-support becomes available.

Path to parameter file is hard-coded until there is consensus on how to store / pass them. Perhaps another YAML file?

@fweig @v.friese

requested review from @v.friese

assigned to @v.friese

Path to parameter file is hard-coded until there is consensus on how to store / pass them. Perhaps another YAML file?

Path to the parameter folder should be passed as an argument to Init. And maybe fallback to your hardcoded value, if the path is empty? Basically the signature becomes bool Init(fs::path paramsDir="")?

I wouldn't go for a universal YAML-file that's used to configure everything. How to find the parameter directory is the problem of whoever invokes the Unpacker code. For cbmreco that's just passed as an argument on the command line.

We need one parameter file per detector, so we will need a long parameter list. And there eventually will be multiple versions of each, so we cannot just pass the path to the folder, but must pass the filename itself. Not sure what to do here. @v.friese @j.decuveland any suggestions?

I think we would be well served by one additional layer of indirection, i.e., a top-level .yaml file (and corresponding class) that contains the (usually relative) paths to the individual .yaml configuration files. This top-level file would be the one to specify on the command line (instead of the paramsDir), and provide the flexibility to mix and match configurations for a run.

However, this would require changes to the framework code. @fweig, what do you think?

I agree with Jan's suggestion. Originally I wanted to just create a seperate folder per setup. But this approach is too naive.

Implemenenting this is on my list. But I didn't get around to it yet.

Dear @f.uhlig, @v.friese, @p.-a.loizeau,

you have been identified as code owner of at least one file which was changed with this merge request.

Please check the changes and approve them or request changes.

added CodeOwners label

@fweig @v.friese We will have a problem with the file names when we include other detectors. The namespace "sts" will prevent a name clash for the class "sts::ReadoutConfig", but we still have source/header files ReadoutConfig.* which we will need for each detector.

mentioned in merge request !1193 (merged)

added 19 commits

• bad57550...92c4b9c1 - 18 commits from branch computing:master
• 2d02bef1 - Switched to YAML-based configuration of STS in cbm::algo::Unpack.

Compare with previous version

Rebased to account for !1176 (merged)

@d.smith This is marked draft. Do you want to proceed?

@v.friese I'm not sure. In principle, we will switch entirely to YAML based configuration, yes? Then this is the way to go. I marked it as draft, since accepting this change or not is more of a policy decision.

@v.friese @p.-a.loizeau @f.uhlig FYI: The formerly hardcoded, and now contained in a YAML file, parameters for STS are from 2021, so they do not apply to run 2391. We will hence need a new YAML file for the data challenge.

Do you know where we can find the parameters for that run?

Presumably in macro/beamtime/mcbm2021/mStsPar.par.

@a.toia @p.-a.loizeau Please correct me if I'm wrong.

For 2391 please use macro/beamtime/mcbm2021/mStsPar.par They work also for 2021 beamtime as the setup is the same, but in 2021 we misconfigured the modules that were switched off

For 2391 please use macro/beamtime/mcbm2021/mStsPar.par They work also for 2021 beamtime as the setup is the same, but in 2021 we misconfigured the modules that were switched off

I think Alberica means macro/beamtime/mcbm2022/mStsPar.par.

In fact, didn't we already make this mapping correction for the 2nd mSTS station in the algo hard-coded parameters? or was it something in your "new" FairMQ device?

sorry... indeed mcbm2022 it should be in the master

@d.smith Please update on the status. From the open threads I take that this would be preliminary only. If so, is it then needed for the DC in July?

@v.friese I think this should be kept as draft for the time being. It may or may not be needed in the future, but is certainly not needed for the data challenge, where we will go for hard-coded parameters mostly. This MR may be superceded by work done of the FIAS group at some point.

@a.toia @fweig @v.friese @p.-a.loizeau @j.decuveland Coming back to this now, I would like to bring all of the recently added features (walk correction, channel masking, adc cuts) into the YAML-based sts::ReadoutConfig class. This raises the question as to the proper structure of the enlarged .yaml file(s) that will be needed.

I lean towards keeping all of the setup-specific stuff that is rather static, i.e. essentially everything that is currently in (addresses etc.), in one file and all of the stuff that might be changed on the fly (presumably all of the new features) in separate place. The question is whether we should use separate .yaml files for each of the new features (walk correction, channel masking, adc cuts) or whether these should be combined.

I don't have a clear idea what is better. I suppose this somewhat dependent on user-behavior. Maybe @a.toia can comment. It boils down, in my opinion, to the fact that different parameters have different degrees of persistency. We might want to group the ones together that have roughly equal rank.

This would to me imply roughly the following groups:

1. Very persistent (constant over the course of one beam time, perhaps longer): All of the addresses.
2. Somewhat persistent (constant in principle, but might need to be changed): Walk correction (updated when an Asic blows out and is replaced?)
3. Not very persistent (can in principle be updated during a single run): Channel masking, adc cuts.

In group 3, presumably channel masking is more persistant than adc cuts: If nothing goes wrong then channel masking isn't needed at all, whereas adc-cut tuning is part of standard operations.

So, how many files should we have? Anything from 1 to 4 is imaginable.

Quick note: I see parameters that change during a run as fundamentally tricky. If that becomes necessary, we should discuss it on a case-by-case basis. Otherwise, the prevailing expectation of a run is that it is a period of constant parameters.

My vocabulary on this issue is probably imprecise.

@v.friese I think given the accumulated backlog (>1400 commits away before next rebase) and the fact that we now have YAML params support (also not as organized as Dominik was trying to reach in the discussions here) we can probably close this MR
=> Maybe also making an issue targeted at next/over-next release to keep track of what was attempted here?

Closing as alternative implementation done and remaining unpackers with hard-coded configs have pending MRs which will introduce the YAML config (!2098 for MUCH and !2097 for MVD)

closed