Add options for constructing an ORANGE geometry

[elliottbiondo]

This MR adds a ConstructionOptions struct in order to facilitate the study of performance-sensitive parameters that govern ORANGE geometry construction.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.85%. Comparing base (9dcc3f3) to head (0ddc337).
⚠️ Report is 2 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #2045      +/-   ##
===========================================
- Coverage    85.53%   82.85%   -2.68%     
===========================================
  Files         1696     1618      -78     
  Lines        75824    65367   -10457     
  Branches      4174     3859     -315     
===========================================
- Hits         64853    54163   -10690     
+ Misses        9466     9463       -3     
- Partials      1505     1741     +236     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[github-actions]

Test summary

 4 946 files   7 871 suites   5m 31s ⏱️
 1 645 tests  1 637 ✅  8 💤 0 ❌
25 574 runs  25 475 ✅ 99 💤 0 ❌

Results for commit 0ddc337.

♻️ This comment has been updated with latest results.

[elliottbiondo]

@sethrj can you take a preliminary look at this? We already have g4org::Options -> InputBuilder::Options, so the addition of OrangeInput::ConstructionOptions feels suspicious.

[sethrj]

It might make it more messy in the short term, but I think the preferred pattern will look more like the newer celeritas code: inp/Foo.hh has the setup options for Foo. So we'd have orange/inp/Bih.hh which would have struct inp::Bih and that would replace BihBuilder::Options. We'd likewise move orange/gorg/Options.hh to orange/inp/Converter.hh. Finally we'd also move OrangeInput to orange/inp/Model.hh or similar.

[elliottbiondo]

FWIW, I think Options makes more sense, lest we overload the word "input"; we already have an orangeinp folder. Likewise, below, I think semantically the input to the BIHBuilder are the bounding boxes, whereas the min_split_size is an option specifying how the process is done.

[elliottbiondo]

The orange/inp folder doesn't currently exist. I can make, but I am still not clear on how InputBuilder::Options fits in (seems like that should be defined at the OrangeInput level).

I also, I think g4org::Options should consist of: 1) a high-level struct will all general OrangeOptions, that is also used for a non-G4 workflow to specify all ORANGE options in one place, and 2) additional G4-specific options.

[sethrj]

The weirdness/confusion is because we've been inconsistent in the past and are transitioning toward having an inp namespace that has all of the input structs that were formerly called Input/Options. This namespace is to be the primary interface with the outside parts of the code: see #2029.

In a hypothetical/future refactorization that I am talking about:

• celeritas::OrangeInput -> celeritas::inp::Orange
• celeritas::detail::BIHBuilder::Options -> celeritas::inp::BihBuilder
• celeritas::g4org::Options -> celeritas::inp::Converter (?)
• celeritas::orangeinp -> celeritas::setup (?)
• celeritas::g4org -> celeritas::setup::g4org (?)

I don't know what's the right path between that future and our present, but I would at least like:

• BIH builder doesn't include half of orange transitively via the OrangeInput (since VariantSurfaces)
• OrangeInput doesn't include and rely on a detail namespace
• Mlutiple layers of nested options with only one member per struct

[sethrj]

if we move the struct, this'll become using Input = inp::BihBuilder; as is done in the other update celeritas classes.