More accurately simulate the neutron flux profile

[OceanNuclear]

Description

Calculates the neutron flux profile in the first wall and blanket, using an extremely simplified diffusion-based model of an infinite slab sandwich.

Reason for choosing this model

It's better than not having a neutronics model.
It's also very simplified, so it can be calculated on the fly, without installing any deterministic neutron transport codes as dependency.

Checklist

I confirm that I have completed the following checks:

• My changes follow the PROCESS style guide
• I have justified any large differences in the regression tests caused by this pull request in the comments.
• I have added new tests where appropriate for the changes I have made.
• If I have had to change any existing unit or integration tests, I have justified this change in the pull request comments.
• If I have made documentation changes, I have checked they render correctly.
• I have added documentation for my change, if appropriate.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 58.38509% with 335 lines in your changes missing coverage. Please review.
✅ Project coverage is 48.24%. Comparing base (771e4d2) to head (7a2b943).
⚠️ Report is 10 commits behind head on main.

Files with missing lines	Patch %	Lines
process/models/neutronics/base.py	63.32%	172 Missing ⚠️
process/models/neutronics/data.py	51.48%	163 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3653      +/-   ##
==========================================
+ Coverage   47.81%   48.24%   +0.42%     
==========================================
  Files         143      145       +2     
  Lines       29993    30930     +937     
==========================================
+ Hits        14342    14921     +579     
- Misses      15651    16009     +358     

☔ 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.

[OceanNuclear]

The current state of this branch is:

• 1-group 2-layer model is written
• 1-group 2-layer model is fully tested (regression & unit tests)
• Multi-group model & >2-layer model is written
• Multi-group model & >2-layer model is tested
• incorporated real data
• Wrote function that accepts collapsed cross-section data (The downloading and collapsing of nuclear data has to be done by the user using a class that inherits from ENDFRecord.)
• Plotting is already available, example 1-group 2-layer model:

• Plotting is tested

[OceanNuclear]

@chris-ashe In the new folder structure, would you prefer the neutronics.py and neutronics_data.py to live in model/ or core/?

[je-cook]

I'm not sure descriptors is the right way to go. Most descriptor stuff I've written I have eventually rewritten without descriptors because I found a better way.

On the atomic data is there any reason we cant use something like periodictable which we use in elsewhere.

[OceanNuclear]

Happy to hear out examples of where descriptors were removed and see if I can implement anything similar. So far I'm unaware of any other ways of writing the code that wouldn't make it even more spaghetti: the @summarize_values decorator is doing a lot of heavy lifting and cutting the amount of code that I have to write down by half.

[je-cook]

Great, need to have a think but will let you know

[OceanNuclear]

periodictable sounds good, thanks for the suggestion, I'll likely replace the atomic_data.json with it, and possibly cutting down the size of the PR as a result.

I haven't figured out yet the right way of getting the abundance values in periodictable (in the same format as written at the top of the atomic_data.json), but I'm sure I'll find it eventually.

[OceanNuclear]

I'll add a bit of context for your consideration while thinking about refactoring away the descriptors:

Regarding the @summarize_values decorators, I think they can be improved upon as well, for the following reasons:

1. I observed redundancy. The NeutronFluxProfile class has the following list of ..._in_layer() methods:

• groupwise_neutron_flux_in_layer
• groupwise_neutron_current_in_layer
• groupwise_neutron_heating_in_layer
• groupwise_tritium_production_in_layer
  and it also has the following list of ..._in_layer() methods, which simply chooses the correct layer according to the x value:
• groupwise_neutron_flux_at
• groupwise_neutron_current_at
• groupwise_neutron_heating_at
• groupwise_tritium_production_at
  This suggest that there's definitely duplicated code that can be abstracted away.

2. I'm unhappy with the signature of the _in_layer methods:

• Current signature: (self, n: int, num_layer: int, x: float | npt.NDArray)
• Preferred signature: (self, num_layer: int, n: int, x: float | npt.NDArray), which aligns with the indexing order of the coefficients.