You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When specifying a Material() with Isotopes and a name the program will look up the name internally and find might find (if it exsits) the corresponding name.
Then the isotopes, density and other attributes will be replaced with the internal definition.
Perhaps there should be a check that prevents this
The text was updated successfully, but these errors were encountered:
Generally with a call to a constructor like mat = nmm.Material(**kwargs) there shouldn't be any side effects that aren't clear to the user. The ability to create a material with no args (i.e. mat = nmm.Material()) should be feasible and have a sensible default (most likely all attributes None), but alternatively you could specify a minimum set of necessary kwargs to define an nmm material.
The other source of unpredictable behavior surrounds setters and getters. The setters for material.openmc_material and Material.mcnp_material and others should be removed because setting them does not create a consistent internal state for the Material object and subsequent exports will not produce what the user expects. The getters for these materials should also compute and return them on the fly rather than storing them in private attributes.
Generally, there should only be one way to set an attribute and the side effects of that should be minimized and carefully documented.
When specifying a Material() with Isotopes and a name the program will look up the name internally and find might find (if it exsits) the corresponding name.
Then the isotopes, density and other attributes will be replaced with the internal definition.
Perhaps there should be a check that prevents this
The text was updated successfully, but these errors were encountered: