Add theta range input

[beomki-yeo]

This PR allows to set a theta range input instead of eta when use-theta-range-input is ON.

Currently this is the best I could come up with but I wonder if we can block the set of theta-range when use-theta-range-input is OFF.

[krasznaa]

🤔 How about going something like this?

https://www.boost.org/doc/libs/1_86_0/libs/program_options/example/real.cpp

I.e. define both --gen-eta and --gen-theta, and throw an error if the user specified both. (With a help message explaining this behaviour.)

As far as I could find with a quick search, there's no built-in functionality in boost::program_options for expressing this relationship between two options. But we can put in an if(...) statement ourselves for this. 🤔

[niermann999]

yes, we do smth like that also in detray : https://github.com/acts-project/detray/blob/a05a161a063b2ae4d71e408424c052f0d679a42d/tests/tools/include/detray/options/track_generator_options.hpp#L137
Btw, can't we do smth like in https://github.com/acts-project/traccc/blob/main/examples/options/src/track_propagation.cpp and fill the detray track generator config directly (https://github.com/acts-project/detray/blob/main/tests/include/detray/test/utils/simulation/event_generator/random_track_generator_config.hpp)? Then you could maybe pass the theta or eta ranges to the detray config in the read method, which converts them on the fly anyway

[beomki-yeo]

I followed the example code provided by @krasznaa . @niermann999 's sugesstion sounds reasonable but let's do this in the next PRs

[krasznaa]

I'm very on board with this, just let's see about these technicalities first. 😉

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

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

See analysis details on SonarCloud

[krasznaa]

I was a bit hesitant about the public dependency at first, but in the end this is part of the "example code". Having traccc::options publicly depend on traccc::performance is not actually a big deal. And keeping the private dependency would make the code a whole lot uglier. 🤔

So yeah, let's just go with this! 👍