openmc-dev
Squashing nuclides with same percent units when adding nuclides to a material
Description
This PR changes the behaviour of material.add_nuclide so that if a nuclide with the same name and percentage type exists in the material then the new nuclide will be combined with the existing one.
If the nuclide exists in the material but has a different percentage type then a warning message will be printed to the user.
I think this PR puts us in better place than currently as it solves the issue of adding like nuclides in some cases and warns the user in other cases. Previously the nuclides were silently duplicated.
As discussed on the forum https://openmc.discourse.group/t/question-about-percent-type-argument-of-the-new-method-add-elements-from-formula-introduced-in-version-0-12/702/5
Fixes # (issue)
Checklist
- [x] I have performed a self-review of my own code
- [x] I have followed the style guidelines for Python source files (if applicable)
- [x] I have made corresponding changes to the documentation (if applicable)
- [x] I have added tests that prove my fix is effective or that my feature works (if applicable)
Not suggesting that this should be a blocker, but I've heard a number of times from analysts they often like to see repeated nuclides when they come from different mixtures, i.e. keeping the contributions from different nucldies printed in blocks by mixtures, repeating nuclides as needed. I can see it both ways, you have a clear record in the python file which made your problem, so thats tracable, alhtough you might keep the xml file left behind. So might it be worth haveing a flag which gives the option to squash as an argument to that function, which defaults to true?
analysts they often like to see repeated nuclides when they come from different mixtures, i.e. keeping the contributions from different nucldies printed in blocks by mixtures, repeating nuclides as needed.
ok fair enough,
optional squashing (default true) when exporting to xml sounds like a more suitable solution then
I see that we currently have Materials with nuclides : list of tuples (string , float)
I think there are a few cases where dicts can take up less memory than the list of tuples
For small dicts I think dicts can be smaller memory than the list of tuples
from pympler import asizeof
data_list = [('Li6', 1.6345345), ('Be9', 2.2323423), ('U235', 5.3234234)]
data_dict = dict(data_list)
print("Total list size:", asizeof.asizeof(data_list))
print("Total dict size:", asizeof.asizeof(data_dict))
>>>Total list size: 472
>>>Total dict size: 400
This appears to also be true for larger materials
from pympler import asizeof
data_list = [(f"Fe{50 + i}", (i + 1) * 0.1234) for i in range(1000000)]
data_dict = dict(data_list)
print("Total list size:", asizeof.asizeof(data_list))
print("Total dict size:", asizeof.asizeof(data_dict))
>>>Total list size: 143649128
>>>Total dict size: 109958720
If there are duplicate entries for nuclides in the list of tuples (like 10 entries for Fe56) then these can be combined to a single entry in a dict.
