openmc icon indicating copy to clipboard operation
openmc copied to clipboard

created new function for recovering spectra of particles decay other …

Open Empi93 opened this issue 8 months ago • 4 comments

…than photon decay (e.g. beta decays). It must be debugged, especially for checking that it returns a continuous spectrum for beta decay. (at the moment I'm struggling to get the deplete module to work, so I don't have any simulations where to test the following functions).

As suggested by @eepeterson , I am creating this pull request to start iterating on the implementation and testing of this functionality.

Two functions were created: 1- in openmc/openmc/material.py def get_decay_energy( self, radiation_type: str = 'photon', # FIND DICTIONARY ENTRIES clip_tolerance: float = 1e-6, units: str = 'Bq', volume: Optional[float] = None ) -> Optional[Univariate]: 2- in openmc/openmc/data/decay.py def decay_energy_spectrum(nuclide: str, radiation_type: str = 'photon') -> Optional[Univariate]:

With respect to get_decay_photon_energy, the get_decay_energy function receives a string with a radiation type as argument. In the function description I included a list of possible string accepted as input: {'gamma', 'beta-', 'ec/beta+', 'alpha', 'n', 'sf', 'p', 'e-', 'xray', 'anti-neutrino', 'neutrino'}, which was copied from the _DECAY_MODES dictionary in openmc/openmc/data/decay.py .

I did not use the function decay_energy in openmc/openmc/data/decay.py because I was under the impression that the _DECAY_ENERGY dictionary contains only discrete energies, while beta decay has a continuum spectrum. If that is not the case, then decay_energy_spectrum is not needed.

Description

Please include a summary of the change and which issue is fixed if applicable. Please also include relevant motivation and context.

Fixes # (issue)

Checklist

  • [ ] I have performed a self-review of my own code
  • [ ] I have run clang-format (version 15) on any C++ source files (if applicable)
  • [ ] I have followed the style guidelines for Python source files (if applicable)
  • [ ] I have made corresponding changes to the documentation (if applicable)
  • [ ] I have added tests that prove my fix is effective or that my feature works (if applicable)

Empi93 avatar Nov 30 '23 18:11 Empi93

Thanks for proposing this feature I think it would be useful.

The two new methods decay_energy_spectrum and get_decay_energy look very similar to the existing methods decay_photon_energy_spectrum and get_decay_photon_energy and duplicate quite a lot of code.

Perhaps it would be more concise to add the additional radiation_type argument (which can still default to 'photon') to the existing methods and rename the existing methods to match the names of your proposed methods.

We can throw in a deprecated or a warning for anyone calling the old photon methods

What do people think

shimwell avatar Dec 01 '23 10:12 shimwell

one more tiny request if it is possible to add some tests that would be great

shimwell avatar Dec 01 '23 10:12 shimwell

Thanks very much for submitting this @Empi93! @shimwell raises a number of good points. It would be good to integrate this into the existing methods and change their names accordingly rather than adding new methods. My suggestions are below:

  1. in data.py change the method get_decay_photon_energy to get_decay_energy_distribution and add the radiation_type kwarg there (we may want to call this particle instead, but we can discuss that later). We will also want to keep get_decay_photon_energy as a separate method and issue a warning to the user and return the new method result. You can see how this is done with the decay_photon_energy property in material.py
  2. Rename the _DECAY_PHOTON_ENERGY module constant to _DECAY_ENERGY_DISTRIBUTIONS which will now be a dictionary with tuples of (nuclide, radiation_type) as keys or equivalent.
  3. Then in material.py you should just be able to replace source_per_atom = openmc.data.decay_photon_energy(nuc) with source_per_atom = openmc.data.decay_energy_distribution(nuc, radiation_type)

There may be some knockon effects elsewhere from changing the structure of the dictionary, but those should be straightforward to fix, but first let's get it integrated into the existing method.

We will also want tests, but I think we can add those to the existing unit tests test_data_decay.py and test_material.py

eepeterson avatar Dec 01 '23 14:12 eepeterson

I'm just working through the open PRs. I think this one is just missing a few tests but otherwise looks good to me

shimwell avatar Jan 02 '24 10:01 shimwell