Refactored Version of Electron Transport Capability

[melekderman]

❗ This PR is a refactor of #355 and closes #355. It should be merged after #383.

This pull request introduces foundational support for electron transport in the codebase, including new constants, data structures, and getter/setter modules for electron-related physics and tallying. The changes lay the groundwork for handling electron interactions in simulations, similar to existing neutron transport features.

The most important changes are:

Electron Physics Support and Constants

• Added new electron reaction types and a scoring type for energy deposition in mcdc/constant.py, as well as fundamental physical constants for electrons (mass, cutoff energy, fine structure constant, etc.). [1] [2] [3]
• Modified the simulation preparation logic in mcdc/main.py to initialize electron data for elements when electron transport is enabled.

Electron Data Structures and Accessors

• Introduced new getter and setter modules for electron reactions, elements, and related tallies in both mcdc_get and mcdc_set packages, including electron_reaction.py, electron_bremsstrahlung_reaction.py, electron_elastic_scattering_reaction.py, electron_excitation_reaction.py, electron_ionization_reaction.py, and element.py. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]

Native Material Extensions

• Added support for storing and accessing element IDs and densities in mcdc/mcdc_get/native_material.py, analogous to existing nuclide data. [1] [2]

Collision and Tally Infrastructure

• Added new getter and setter modules for collision data and collision tallies, supporting the new electron interactions. [1] [2] [3] [4] [5]

These changes establish the infrastructure needed for electron transport and tallying, bringing the codebase closer to supporting coupled neutron-electron physics.

[ilhamv]

Thanks, Melek - This is great!

I made some minor edits. And here are my not-so-minor comments/suggestions:

1. I'm wondering if the electron energy cutoff should be material-dependent rather than a single global value. This should be a separate, follow-up PR, though. Let's open up an Issue for this enhancement plan after we get this PR merged in.
2. Is MU_CUTOFF exclusively associated with the data library used? Should we make it part of the element data instead?
3. What is FINE_STRUCTURE_CONSTANT? Since the constant is only used in a single function, hard-coding the constant in that function would be more desirable. Unless it is more than likely that we are gonna use the constant somewhere else.
4. The Lockwood regression test takes too long (about 6 minutes?)... Can you adjust the problem or the parameters so that it runs within 10 seconds? (Note that the longer runs are for V&V tests, not regression.)
5. Will it be a good idea to put the electron data library generator as well in the mcdc/tools? Also, about the h5 element data library, it would be helpful for all physical quantities to have the unit as an attribute (e.g., xs_energy_grid), like the one that we have in the nuclide data library. Especially since the element and nuclide seem to use different energy units (eV and MeV, respectively).
6. Can you tell me why the error catcher in get_version() in output.py is necessary?

[melekderman]

Hi @ilhamv,

Thank you so much for your review.

1. There are publications in the literature indicating that this dataset produces unreliable results below 1 keV. For that reason, the cutoff is currently implemented as a single global value for the user. If we later change our physical models or introduce additional approaches, it may make sense to move away from a global parameter and adopt a more flexible approach. For now, a single global cutoff maintains consistency with the dataset's known limitations.

2. In the dataset we currently use, MU_CUTOFF is effectively constant and equal to 0.999999. However, I defined it as a global constant in the code to keep some flexibility in case we switch to a different data library in the future. (Also, I am still working on different approaches, so keeping it easily adjustable is the best way for me for now :) ) That said, it may conceptually belong to the data itself rather than the code. I think we could track this as a follow-up Issue and decide whether it should be stored in the element data library.

3. FINE_STRUCTURE_CONSTANT is a physical constant related to electromagnetic interactions. Since it is only used in a single function, I agree that putting it directly inside the equation would be cleaner. I will move it into the function.

4. Sounds good, then I will change the energy to reduce the runtime.

• The electron data library is currently generated from EPICS data using the PyEEDL tool. If needed, we could also include a script in the repository to automate that generation process. As a longer-term option, once the electron-related developments become more mature, I could adapt our Python library PyEPICS for electron data generation to match the latest MCDC dataset structure and make it available as a dependency.

• I thought that all quantities in the element data library were stored in eV. Could you clarify where MeV is currently used for the element data? I will double-check the file to confirm the units.
  EDIT: I totally misunderstood it, but after checking nuclide data, I got it now, and I think this is a great idea!

6. And, you are right about the error catcher in get_version(). It is not necessary, and was committed by accident. I will remove it. Thank you!

[ilhamv]

Great. So, 3, 4, and 6 will be addressed in this PR for merge, while 1, 2, and 5 will be tracked in Issues.
Thanks, @melekderman.