Add muon-catalyzed fusion process/model skeletons

[stognini]

This PR adds the basic structure for the muon-catalyzed fusion process. See issue #1508 for details.

It is an at rest process, and it applies only to d-t mixtures. The model executor is responsible for taking a muon at rest and:

• Create the muonic atom
• Apply any secondary effect (e.g. isotopic transfer, where the muon transfers to a heavier atom)
• Create the muonic molecule
• Verify if fusion happens before the muon decays
• Call appropriate interactor (decay or fusion)

[github-actions]

Test summary

 5 766 files   9 268 suites   17m 33s ⏱️
 2 111 tests  2 082 ✅  29 💤 0 ❌
31 576 runs  31 444 ✅ 132 💤 0 ❌

Results for commit c571e0d.

♻️ This comment has been updated with latest results.

[sethrj]

I appreciate the detail classes for the context of long term planning, but I think they should be deleted since they're not used and not tested: having them there is an easy way to introduce zombie code into the codebase.

[stognini]

I appreciate the detail classes for the context of long term planning, but I think they should be deleted since they're not used and not tested

Agreed that they are not tested yet, but they are actively being called in the executor. Do you prefer me to make a todo in the executor and remove them until a future PR?

[sethrj]

Agreed that they are not tested yet, but they are actively being called in the executor. Do you prefer me to make a todo in the executor and remove them until a future PR?

Oh I didn't catch that. I'll take another look at your comments later this afternoon.

[sethrj]

I would prefer to have at least some level of testing (even if it's running through a bunch of null-ops) here. I see now that the executor is being used, but it would be very helpful to have a code coverage tool tell us what is actually being called and tested.

Maybe it's possible to set up a test that creates a state vector and the model (manually setting all the particle attributes that are needed), and calls the step operator for the mucf model?

[codecov]

Codecov Report

❌ Patch coverage is 0% with 330 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.14%. Comparing base (4443c2e) to head (c571e0d).
⚠️ Report is 4 commits behind head on develop.

Files with missing lines	Patch %	Lines
...eleritas/mucf/model/detail/MucfMaterialInserter.cc	0.00%	75 Missing and 1 partial ⚠️
src/celeritas/mucf/model/DTMixMucfModel.cc	0.00%	38 Missing and 17 partials ⚠️
src/celeritas/mucf/executor/DTMixMucfExecutor.hh	0.00%	45 Missing ⚠️
src/celeritas/inp/MucfPhysics.cc	0.00%	27 Missing ⚠️
src/celeritas/mucf/data/DTMixMucfData.hh	0.00%	14 Missing and 1 partial ⚠️
src/celeritas/mucf/interactor/DDMucfInteractor.hh	0.00%	14 Missing ⚠️
src/celeritas/mucf/interactor/DTMucfInteractor.hh	0.00%	14 Missing ⚠️
src/celeritas/mucf/interactor/TTMucfInteractor.hh	0.00%	14 Missing ⚠️
src/celeritas/mucf/process/MucfProcess.cc	0.00%	14 Missing ⚠️
...eleritas/mucf/executor/detail/DDChannelSelector.hh	0.00%	7 Missing ⚠️
... and 10 more

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #2174      +/-   ##
===========================================
- Coverage    86.82%   86.14%   -0.69%     
===========================================
  Files         1292     1309      +17     
  Lines        40958    41288     +330     
  Branches     12625    12707      +82     
===========================================
+ Hits         35562    35566       +4     
- Misses        4222     4532     +310     
- Partials      1174     1190      +16     

Files with missing lines	Coverage Δ
src/celeritas/Types.hh	100.00% <ø> (ø)
src/celeritas/mucf/model/DTMixMucfModel.hh	0.00% <0.00%> (ø)
src/celeritas/mucf/process/MucfProcess.hh	0.00% <0.00%> (ø)
src/celeritas/phys/PDGNumber.hh	85.18% <0.00%> (-10.65%)	⬇️
...tas/mucf/executor/detail/MuonicAtomSpinSelector.hh	0.00% <0.00%> (ø)
src/celeritas/inp/MucfPhysics.hh	0.00% <0.00%> (ø)
...eleritas/mucf/executor/detail/DDChannelSelector.hh	0.00% <0.00%> (ø)
...eleritas/mucf/executor/detail/DTChannelSelector.hh	0.00% <0.00%> (ø)
...as/mucf/executor/detail/DTMixMuonicAtomSelector.hh	0.00% <0.00%> (ø)
...ucf/executor/detail/DTMixMuonicMoleculeSelector.hh	0.00% <0.00%> (ø)
... and 11 more

... and 6 files with indirect coverage changes

🚀 New features to boost your workflow:

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

[sethrj]

Good enough. I do think we should avoid "skeleton" PRs. I know this is a fairly complex piece of machinery, but in the future let's build up one piece at a time: no skeletons in the code. It's hard to tell if a piece of construction code is correct or optimal if it's not used.

[sethrj]

@stognini looks like you're missing some CELER_FUNCTION decorators:

  /__w/celeritas/celeritas/src/celeritas/mucf/executor/DTMixMucfExecutor.hh(56): error #20014-D: calling a __host__ function from a __host__ __device__ function is not allowed
        detail::DTMixMuonicAtomSelector form_atom;
                                        ^
  
  Remark: The warnings can be suppressed with "-diag-suppress <warning-number>"
  
  /__w/celeritas/celeritas/src/celeritas/mucf/executor/DTMixMucfExecutor.hh(69): error #20014-D: calling a __host__ function from a __host__ __device__ function is not allowed
        detail::DTMixMuonicMoleculeSelector form_muonic_molecule;
                                            ^
  
  /__w/celeritas/celeritas/src/celeritas/mucf/executor/DTMixMucfExecutor.hh(118): error #20014-D: calling a __host__ function from a __host__ __device__ function is not allowed
                DDMucfInteractor interact(
                                 ^
  
  /__w/celeritas/celeritas/src/celeritas/mucf/executor/DTMixMucfExecutor.hh(125): error #20014-D: calling a __host__ function from a __host__ __device__ function is not allowed
                DTMucfInteractor interact(
                                 ^
  
  /__w/celeritas/celeritas/src/celeritas/mucf/executor/DTMixMucfExecutor.hh(132): error #20014-D: calling a __host__ function from a __host__ __device__ function is not allowed
                TTMucfInteractor interact(
                                 ^

[sethrj]

@amandalund @stognini are we ready to merge this? According to codecov, literally none of the new code is tested or even executed; it simply compiles. I really do not like that. It took three weeks to review and fix the builds, and we can't even know if it works yet.

Next time we have to put in a big feature, maybe we focus on hardcoding the main use case, then refactoring and refining as we support more fine-grained features. (E.g., start with supporting only DD fusion, one spin, etc., and at least test that it works.) I think right now our muon code has zero coverage at all.

[stognini]

Agree that the lack of testing is a problem. This also is one single executor. E.g. a discrete EM interaction we were in general able to make the interactor and model in one or two PRs.

One option, if you'd like, is to revert the ordering I was planning. Keep this as draft, and:

• The next PR can be one of the interactors (which can use mock data for a test). And will use the bare minimum from this branch (since the big picture here is mostly set);
• Then spin selection;
• Then material calculation;
• Then we add the process into the stepping loop;

[sethrj]

The interactor we had the ability to test individually, which was great. I don't want to spend any more time on muons than necessary, but I'd say the next follow-on should be a PR with an integration-level test of muon physics: either in accel/ or the lower-level stepper test.

[sethrj]

I'm going to merge this out of expedience to reduce the time spent mitigating code rot; @stognini 's next task is to add a unit test that builds the µCF model and compares low level interactor distributions against the G4 code. Then we'll add an integration test that uses muons.