feat: use algorithms logger service in IrtCherenkovParticleID

[wdconinc]

Briefly, what does this PR introduce?

This PR ensures that IrtCherenkovParticleID uses the algorithms logger, so it does not have to be passed by the factory.

What kind of change does this PR introduce?

• Bug fix (issue #__)
• New feature (issue: migration to algorithms)
• Documentation update
• Other: __

Please check if this PR fulfills the following:

• Tests for the changes have been added
• Documentation has been added / updated
• Changes have been communicated to collaborators

Does this PR introduce breaking changes? What changes might users need to make to their code?

No.

Does this PR change default behavior?

No.

[veprbl]

I've looked into this yesterday, we could pass a algorithms::detail::LoggerStream, but, unfortunately, it doesn't yet implement fmt-style printing. Other case would be to dismantle adhoc Tools.h and move printing to the algorithms. There will be a little bit of code duplication then (acceptable level, IMO).

[wdconinc]

I've looked into this yesterday, we could pass a algorithms::detail::LoggerStream, but, unfortunately, it doesn't yet implement fmt-style printing. Other case would be to dismantle adhoc Tools.h and move printing to the algorithms. There will be a little bit of code duplication then (acceptable level, IMO).

I have this working locally with e.g.:

-  void Print(std::shared_ptr<spdlog::logger> m_log,
-             spdlog::level::level_enum lvl = spdlog::level::debug) {
-    m_log->log(lvl, "{:=^60}", " MergeParticleIDConfig Settings ");
-    auto print_param = [&m_log, &lvl](auto name, auto val) {
-      m_log->log(lvl, "  {:>20} = {:<}", name, val);
+  template<algorithms::LogLevel lvl = algorithms::LogLevel::kDebug>
+  constexpr void Print(const algorithms::LoggerMixin* log) {
+    log->report_fmt<lvl>("{:=^60}", " MergeParticleIDConfig Settings ");
+    auto print_param = [&log](auto name, auto val) {
+      log->report_fmt<lvl>("  {:>20} = {:<}", name, val);
     };
     print_param("mergeMode", mergeMode);
-    m_log->log(lvl, "{:=^60}", "");
+    log->report_fmt<lvl>("{:=^60}", "");
   }

All the log levels are available at compile time, never set based on runtime. We upgrade to template arg, then pass this as a const LoggerMixin pointer.

[wdconinc]

I have this working locally with e.g.:

"working"

[wdconinc]

This compiles now with eic/algorithms#22. protected for log(fmt, msg) was still a bit strict in this case, since the Tools are external. I didn't want to create a public logger either, so I make Tools a mix-in class that uses CRTP to properly gain access to the algorithm's logger.

Suggestions for better names for Tools are welcome.

[github-actions]

Capybara summary for PR 1839

• rec_dis_10x100_minQ2=0_craterlake
• rec_dis_10x100_minQ2=1000_craterlake_tracking_only
• rec_dis_18x275_minQ2=0_craterlake_18x275
• rec_dis_18x275_minQ2=1000_craterlake_18x275
• rec_dis_5x41_minQ2=0_craterlake_5x41
• rec_e_1GeV_20GeV_craterlake
• rec_pi_1GeV_20GeV_craterlake
  ^{_{Last updated 2025-05-02T18:20-04:00 39fc319}}

[torrijeske]

✅ Images for pipeline 117102 are now available. View here

[veprbl]

There are few things which move in a wrong way here, I would really prefer if Tools was moving towards becoming a namespace, instead of full fledged class (dissolving it would be a plus, but certainly outside of scope). Same goes for use of Config class, which now has to know about algorithm class.

[wdconinc]

There are few things which move in a wrong way here, I would really prefer if Tools was moving towards becoming a namespace

I'm on the same page: Tools needs to disappear. Same thing with the Print functions in the configs. The goal here was to not rewrite the algorithm in this PR, only how it prints. I don't know why a config needs to print (beyond having an operator<<).

I already have a branch locally that does some of that (doesn't get rid of Tools since too involved, but again here the Print functions should just become operator<<).

[wdconinc]

There are few things which move in a wrong way here, I would really prefer if Tools was moving towards becoming a namespace, instead of full fledged class (dissolving it would be a plus, but certainly outside of scope). Same goes for use of Config class, which now has to know about algorithm class.

@veprbl Tools is namespace now; some stuff taken out (maybe we can push it a level up into a detail/ directory). Probably another iwyu pass, but should be good for another review.