Config Printing Updates, main branch (2025.02.04.)

[krasznaa]

As I said a couple of times, I quite like the formatting of the printouts introduced in #822 by @stephenswat, but I don't really like some of the technicalities in there. So this is my proposal for how I'd prefer to have the code. 🤔

I moved the classes into separate header and source files, and moved them into the traccc::options library. Thereby removing the traccc::utils library. (I was not a fan of having a separate shared library with just that one header and source file...)

I changed the classes to use a generic std::ostream internally, and the public API to return an std::string with the formatted configuration, instead of printing it itself to std::cout.

In the client classes I removed a whole lot of unnecessary dynamic casting.

Finally, I changed the printout format a little. Going (as an example) from:

Running Full Tracking Chain on the Host

Detector options:
├ Detector file:                   tml_detector/trackml-detector.csv
├ Material file:                   
├ Surface grid file:               
├ Use detray detector:             no
└ Digitization file:               tml_detector/default-geometric-config-generic.json
Input data options:
├ Use ACTS geometry source:        no
├ Input data format:               csv
├ Input directory:                 tml_full/ttbar_mu20/
├ Number of input events:          1
└ Number of skipped events:        0
Output data options:
├ Output data format:              csv
└ Output directory:                
Clustering options:
├ Threads per partition:           256
├ Target cells per thread:         8
├ Max cells per thread:            16
└ Scratch space multiplier:        256
Track seeding options:
Track finding options:
├ Max branches per seed:           10
├ Max branches at surface:         10
├ Track candidate range:           3:100
├ Min step length to next surface: 0.500000 mm
├ Max step count to next surface:  100
├ Max Chi2:                        10.000000
├ Max branches per step:           10
├ Max holes per candidate:         3
└ PDG number:                      13
Track propagation options:
├ Navigation:
│ ├ Min mask tolerance:            0.000010 mm
│ ├ Max mask tolerance:            3.000000 mm
│ ├ Mask tolerance scalar:         0.050000
│ ├ Path tolerance:                1.000000 um
│ ├ Overstep tolerance:            -0.300000 um
│ └ Search window:                 0 x 0
├ Transport:
│ ├ Min step size:                 0.000100 mm
│ ├ Runge-Kutta tolerance:         0.000100 mm
│ ├ Max step updates:              10000
│ ├ Step size constraint:          340282346638528859811704183484516925440.000000 mm
│ ├ Path limit:                    5.000000 m
│ ├ Min step size:                 0.000100 mm
│ ├ Enable Bethe energy loss:      yes
│ ├ Enable covariance transport:   yes
│ └ Covariance transport:
│   ├ Enable energy loss gradient: no
│   └ Enable B-field gradient:     no
└ Geometry context:
Ambiguity resolution options:
└ Run ambiguity resolution:        yes
Performance measurement options:
└ Run performance checks:          no

To:

Running Full Tracking Chain on the Host, with options:

┬ Detector options
├─ Detector file:                   tml_detector/trackml-detector.csv
├─ Material file:                   
├─ Surface grid file:               
├─ Use detray detector:             false
└─ Digitization file:               tml_detector/default-geometric-config-generic.json

┬ Input data options
├─ Use ACTS geometry source:        false
├─ Input data format:               csv
├─ Input directory:                 tml_full/ttbar_mu20/
├─ Number of input events:          1
└─ Number of skipped events:        0

┬ Output data options
├─ Output data format:              csv
└─ Output directory:                

┬ Clustering options
├─ Threads per partition:           256
├─ Target cells per thread:         8
├─ Max cells per thread:            16
└─ Scratch space multiplier:        256

┬ Track seeding options
└─ <empty>

┬ Track finding options
├─ Max branches per seed:           10
├─ Max branches at surface:         10
├─ Track candidate range:           3:100
├─ Min step length to next surface: 0.500000 mm
├─ Max step count to next surface:  100
├─ Max Chi2:                        10.000000
├─ Max branches per step:           10
├─ Max holes per candidate:         3
└─ PDG number:                      13

┬ Track propagation options
├─┬ Navigation
│ ├─ Min mask tolerance:            0.000010 mm
│ ├─ Max mask tolerance:            3.000000 mm
│ ├─ Mask tolerance scalar:         0.050000
│ ├─ Path tolerance:                1.000000 um
│ ├─ Overstep tolerance:            -0.300000 um
│ └─ Search window:                 0 x 0
├─┬ Transport
│ ├─ Min step size:                 0.000100 mm
│ ├─ Runge-Kutta tolerance:         0.000100 mm
│ ├─ Max step updates:              10000
│ ├─ Step size constraint:          340282346638528859811704183484516925440.000000 mm
│ ├─ Path limit:                    5.000000 m
│ ├─ Min step size:                 0.000100 mm
│ ├─ Enable Bethe energy loss:      true
│ ├─ Enable covariance transport:   true
│ └─┬ Covariance transport
│   ├─ Enable energy loss gradient: false
│   └─ Enable B-field gradient:     false
└─┬ Geometry context
  └─ <empty>

┬ Ambiguity resolution options
└─ Run ambiguity resolution:        true

┬ Performance measurement options
└─ Run performance checks:          false

I personally find the latter a little easier on my eyes. But I fully admit that this is a subjective thing. 🤔

Finally, I started using std::format(...) in a bunch of places in the code. For instance for printing bool values. To replace all of the (foo ? "yes" : "no") code pieces. This is also not a completely objective thing, I admit.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[krasznaa]

Before working on a traccc::opts::track_finding class (as discussed in #842 (review)), this should be merged in first. 🤔

All feedback is welcome!

[stephenswat]

I like the changes to the way we return the printables from the interface classes, but the rest of this PR is way, way over-engineered.

Also, I much prefer the previous output format but as you say that's a subjective matter.

[stephenswat]

Mind you that support for std::format is still all over the place, especially in the Mac world.

[stephenswat]

I think it's a good idea to have a library where stuff that we use across the examples can live, I'd suggest we just keep this.

[stephenswat]

Friend classes are a huge code smell and the code was working perfectly without them before; suggest we refactor this to at least get rid of these friend classes.

[stephenswat]

We are not seriously splitting up an 80-line header file and a 100-line C++ file into 3 translation units and 4 header files, right? To be frank that's just silly...

[stephenswat]

This amount of typedeffing is frivolous and can be removed.

[stephenswat]

This is not going to fly; when we move to using loggers here we will need to be able to print this configuration line-by-line, and producing a whole string first and then splitting it on newlines is not practical.

[krasznaa]

Replaced by #845.