Add neutron inelastic process

[whokion]

Description

This MR includes

• Add a initial skeleton of neutron inelastic process, model and interaction cross section (following up Add neutron inelastic process #1150)
• Add a necleon-nucleon channel cross section below 320 MeV where the pion production is unlikely (For the first pass, it is decided to limit the Bertini nuclei model implementation below 320 MeV where pion production is unlikely, so that particle-nucleon channels are deduced to nucleon-nucleon channels. This is based on two important considerations: 1) the majority of neutrons from typical HEP applications is below the pion threshold - for example, more than 98% of neutrons are below 140 MeV in ttbar or Higgs event simulation with the CMS detector at the LHC collision, 2) computing performance should be enhanced significantly as only nucleons, photons and nuclei are produced at the end of inelastic neutron-nuclei interactions, which simplify the chain of inter-nucleus cascades.)
• Add a nucleon-nucleon cross section calculator and a unit test to check cross sections.

[whokion]

@sethrj, @amandalund : this MR is just to pick up most of #1150 codes (sorry for losing all review comments with this new MR) - will add remaining codes later as they are not necessary pieces for initial code base at the moment. Only new addition to the earlier MR are for nucleon-nucloen cross sections in 1) NeutronInelasticModel.cc and 2) NucleonNucleonXsCalculator.hh. Thanks for your review.

[amandalund]

Thanks @whokion, this looks great!

[amandalund]

Maybe check that ch_id is less than the array size?

[whokion]

Do you mean to check ch_id < NeutronInelasticScalars::num_channels()?

[amandalund]

Did we ever decide on the best way to reduce the duplicate code for the neutron micro xs calculators?

[whokion]

Kind of, but not yet. There is another one (capture process) which may look very similar, but may have some variations if isotope dependent xs are added. So, let's leave this duplication for now and then consolidate codes later (may need your help on that).

[sethrj]

@whokion The data and implementation seem identical to NeutronElasticData (setting aside capture for now). Would it be OK to define:

template<Ownership W, MemSpace M>
struct NeutronXsData
{
    //! Microscopic (element) cross section data (G4PARTICLEXS/neutron/elZ)
    ElementItems<GenericGridData> micro_xs;

    // Backend data
    Items<real_type> reals;

    // (plus copy constructor, bool)
};

and then replace the micro_xs and (if needed) reals in both NeutronElasticData and NeutronInelasticData with an instance of that class? E.g.

template<Ownership W, MemSpace M>
struct NeutronElasticData
{
    // ...
    NeutronXsData<W, M> xs;
    // ...
};

Then NeutronElasticMicroXsCalculator could be renamed NeutronMicroXsCalculator and used for both elastic and inelastic. Is there anything I'm overlooking that would make this complicated?

[whokion]

@sethrj I resolved conflicts and updated codes reflecting @amandalund's review comments, then rebased the local neutron-inelastic with origin/develop (which was successful). Now, git push still fails with

To https://github.com/whokion/celeritas
 ! [rejected]            neutron-inelastic -> neutron-inelastic (non-fast-forward)
error: failed to push some refs to 'https://github.com/whokion/celeritas'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.

I remember that you suggested to merge instead of push --force. After merging the branch to the local develop and pushed the develop to the remote develop, I tried to push the local neutron-inelastic to the remote neutron-inelastic, which still fails (i.e., error above). Probably I missed something here. Thank you for your help.

[sethrj]

@whokion Please don't do any rebasing once reviews have started. You should instead git merge. If you can push your current branch to a new neutron-inelastic-temp I can try to fix it. Or you could try git rebase -i --onto aa5f3b7 upstream/develop to see if that puts your changes back on what's already pushed here. (And then follow up with git merge upstream/develop.)

As a reminder for why merging is preferred once a PR has left draft mode: rebasing destroys the CI logs and messes with the review history.

[whokion]

Thanks @sethrj! Good to know and to learn. I just to push a new neutron-inelastic-temp as the other suggested instruction seems not working for me. Sorry and thanks again for your help.

[sethrj]

Looks great, @whokion ! Sorry for taking so long to review. If you think the consolidation of the XS calculators should wait, I accept that, but it looks like a pretty easy change to make now.

[sethrj]

@whokion The data and implementation seem identical to NeutronElasticData (setting aside capture for now). Would it be OK to define:

template<Ownership W, MemSpace M>
struct NeutronXsData
{
    //! Microscopic (element) cross section data (G4PARTICLEXS/neutron/elZ)
    ElementItems<GenericGridData> micro_xs;

    // Backend data
    Items<real_type> reals;

    // (plus copy constructor, bool)
};

and then replace the micro_xs and (if needed) reals in both NeutronElasticData and NeutronInelasticData with an instance of that class? E.g.

template<Ownership W, MemSpace M>
struct NeutronElasticData
{
    // ...
    NeutronXsData<W, M> xs;
    // ...
};

Then NeutronElasticMicroXsCalculator could be renamed NeutronMicroXsCalculator and used for both elastic and inelastic. Is there anything I'm overlooking that would make this complicated?

[whokion]

@sethrj Thanks for reviewing and extra comments. Regarding to the consolidation of the Xs calculators, your suggestion looks good. However, I still want to postpone it to later as there may be an extension for the inelastic interaction cross sections as there are several special elements which have isotope-dependent cross sections. Once the capture cross sections (which are mostly isotope-dependent and are different structure from elastic ones), I would reconsider which way is better to consolidate; elastic vs. inelastic (element-dependent) or inelastic vs. capture (isotope-dependent). Anyway, I pushed a branch name, neutron-inelastic-temp2 (and sorry again for the extra rebase/merging treatment).

[amandalund]

@sethrj did you incorporate the changes from the neutron-inelastic-temp2 branch?

[sethrj]

God damn it, I pushed to my origin instead of Soon's. Thanks for the catch @amandalund .