Fibers and ToFD calibration, parameter and Tracking update.

[enlorenz]

Fibers and ToFD calibration, parameter and Tracking update.

Fibers: Adjusted parameter calculation and application. Minor changes, ToF and ToT calculation now consistent.

ToFD: Cal2Hit adjusted to be used with new parameter structure. Adjusted mathematical operations, and introduced some failsafes. Code is not "clean" yet, but needed so that the parameters can be used for further analysis. Cal2HitPar is in a "running" state and delivers parameters for "s522/s509". Not advised to use for other experiments yet. Code needs a proper re-work, before it is safe for general use. Individual calibration steps/functions with minor changes. introduced higher order correction step using physics data.

Fragment tracker: Standalone task. Uses Fibers and ToFD to track fragments behind GLAD and calculate in real time observables and deliver PID. Still under development.

Checklist:

• [ ] Rebased against dev branch
• [ ] My name is in the resp. CONTRIBUTORS/AUTHORS file
• [ ] Followed the seven rules of great commit messages

[YanzhaoW]

2000 warnings for a PR with 5000+ lines of changes. Both are too big for a PR. But as I have suggested in the last meeting, if you want to disable the clang-tidy warnings for a code block, you can do:

// NOLINTBEGIN

// ... code block ...

// NOLINTEND

I would still suggest you should fix the warnings as many as possible.

[enlorenz]

I only had a quick look at Tofd so far. Also, I could not check if your changes produce different results than my code. I will try to get it running and message you then.

Not advised to use for other experiments yet. Code needs a proper re-work, before it is safe for general use.

If your code should be used for those two experiments only, why not introduce ExpId dependent functions, or do you plan to make it compatible for other experiments? What are the

The code should be of course compatible with other experiments and especially for future experiments. Backwards compatibility is another question. I would like to avoid ExpID dependent functions, since most of the dependencies should be possible to have flags and/or variables set in the macro. Individual functions make the code unnecessarily blown up. If it is OK for everyone, I would actually like to make this code a WiP version, so that it can be merged in the future.

higher order correction step using physics data

did the number of calibration parameters change, are thy now used in a different way? I might have missed it, because comparing the two versions is not easy due to a lot of changes. Maybe you can show this in one of the next analysis meetings?

Yes, I will definitely present in detail what it is. Briefly, it is an extra calibration step which can or cannot be used, depending on the situation. This adjusts the values of the final charge parameters, so that the application of the parameters in the Cal2Hit itself does not change.

I don't know if one should merge if there are hundreds of lines commented and you say the code is not "clean" or it is "running". Why not create a branch and let people who need the code pull from your fork, create a WIP or something.

Yes, that should be the best option for now.

[ajedele]

General comment/question (and maybe @lbott193 you can help): There are 2 ways to do the position dependent charge correction - smiley and double exponential. In theory, both should give the same results. Both are also present in the calibration.

However, the double exponential currently crashes because the parameters are not included in the R3BTofdHitPar or R3BTofdHitModulePar. The smiley, from my understand is also simpler and produces better results, faster.

Should we continue to support the double exponential if it's currently not possible to use?

[lbott193]

General comment/question (and maybe @lbott193 you can help): There are 2 ways to do the position dependent charge correction - smiley and double exponential. In theory, both should give the same results. Both are also present in the calibration.

However, the double exponential currently crashes because the parameters are not included in the R3BTofdHitPar or R3BTofdHitModulePar. The smiley, from my understand is also simpler and produces better results, faster.

I can see them in the current R3BTofdHitModulePar.h they are named (maybe one should come up with more descriptive names): fPar1a-c and fPar2a-c: https://github.com/R3BRootGroup/R3BRoot/blob/dev/tofd/pars/R3BTofDHitModulePar.h#L154-L155

Why it doesn't work anymore, I don't know.

Should we continue to support the double exponential if it's currently not possible to use?

Charge correction with tdfiff and double exponential was difficult in the past under certain circumstances, for example interference effects on the electronics card. The ToT method is less sensitive to such effects and at that time we got better results. You might want to check that for your setup and use the best option, that's why I left both methods in.