[PWGHF,Tools] Address Bug tracker issues in LcToPKPi-related files

[lubynets]

Clang-tidy issues present in workflows related to $\Lambda^+_c\rightarrow pK\pi^+$ reconstruction are fixed.
I am not 100% sure that some of the narrowing conversion issues are addressed in proper places (e.g. change of the Configurable double->float when it is consumed by function with float parameter; or issues with int8_t values), therefore an attentive look and feedback is appreciated.
UPD: addressed (part of) issues in Tools/KFparticle/KFUtilities.h - clang-tidy and O2 linter.

[github-actions]

O2 linter results: ❌ 36 errors, ⚠️ 83 warnings, 🔕 11 disabled

[lubynets]

Help wanted

1. The clang-tidy tracker produces a "narrowing conversion from 'double' to 'float' " warning to the Tools/KFparticle/KFUtilities.h line 299 (and a few similar warnings), while both r.h.s. and l.h.s. of the assignment are float. Is it a bug of clang-tidy or am I overlooking something?
2. Is it possible to use O2 constants in order to determine particle's mass knowing its PDG code? - in order to get rid of TDatabasePDG here?

[vkucera]

1. clangd agrees with Clang-Tidy. sqrt returns double. If I change it to std::sqrt it returns float.
2. O2 linter tells you what to do. If you know the PDG code at compile time, use a header constant, otherwise, use the service.

[vkucera]

This will invalidate existing wagon configuration. Not sure we want that.

[lubynets]

So will it be a better solution to revert Configurables' types to double and static_cast to float functions' arguments?

[lubynets]

So, we define Configurables with double precision which we never use, since immediately cast it to float. Is it worth fixing once with taking care of wagons adjusting (also once, and the place of concern is well known)?
I will take the responsibility to wide-post in the HF chat the announcement and ask service wagons owners to do adjustment.

[vkucera]

OK, up to you (provided that @gluparel @xinyepeng agree).

[lubynets]

Dear @gluparel and @xinyepeng,
This PR changes the type of several Configurables from double to float in candidateCreator3Prong and candidateSelectorLc workflows. According to Vit's concern this may discard existing wagon settings.
I checked 15 HF service wagons containing "CandidateCreator3Prong" in their names - all of them have default values of changed Configurables. Thus no adjustment of numerical values of Configurables will be needed.
Also I did not find any HF service wagon with "candidateSelectorLc" in its name.
Therefore, the only place where wagon settings adjustment may be required is analyzers' custom wagons (if they use non-default values). If the PR is merged as is, I will notify analyzers in the HF chat.
Could you please approve or dis-approve such a change of Configurables types?

[xinyepeng]

Dear @lubynets ,
Thanks a lot for the implementation. For the changing of the configurable type, we would prefer not to do it unless it's mandatory. As Vit pointed out, the changes will invalidate existing wagon configurations, we have related analysis pushing for SQM2026 in D2H, we don't want to introduce additional inconvenience for the analyzers (it happened last time, the analyzers spent a lot time to spot the problem). But we're not against if you have agreement with all the related analyzers.

[lubynets]

Dear @xinyepeng, thanks for the feedback. I reverted Configurables type change and addressed narrowing conversion issues via explicit static_cast<float>.

[lubynets]

1. clangd agrees with Clang-Tidy. sqrt returns double. If I change it to std::sqrt it returns float.

   2. O2 linter tells you what to do. If you know the PDG code at compile time, use a header constant, otherwise, use the service.

Hi @vkucera, thanks for your feedback!
2. The function where mass is required, is a free (non-member) function. Will not be a problem from the CPU time point of view to instantiate the Service<o2::framework::O2DatabasePDG> in the function?
And if that's a problem, will making it static solve it?

[vkucera]

2. You should pass the pointer to the object.

[lubynets]

Do you mean the Service should be instantiated in the global scope, and the pointer to it should be passed as an argument to the function which needs particle's mass?

No, it should be instantiated as a member of a workflow struct.

UPD: Done (O.L.)

[lubynets]

Hi @vkucera, thanks for the feedback to the PR and comments. From my side I would keep it as it is now and undraft, but still some threads are unresolved. Can you comment on them (or resolve)?

[lubynets]

@vkucera, thanks for approving the PR.
Dear codeowners of the Tools part, could you please check the PR and approve if you do not have objections?