Closed cjosey closed 7 years ago
@cjosey first of all, these new changes sound amazing! I haven't gone through your code yet, but it sounds like it will make things much simpler for "naive" users like myself.
If I correctly understand your question about writing "materials.xml" files - this can be done as follows:
materials = openmc.Materials()
materials.materials = geometry.get_all_materials().values()
materials.export_to_xml()
Perhaps you are suggesting that the Geometry
class itself should be able to export the "materials.xml" file, in which case I agree that this would be a nice feature to have.
I have swapped to using volumes in materials as opposed to cells, just to make it internally consistent (in case a user is doing something silly).
I would recommend if the user knows what they're doing to compute material volumes from cells, to reduce stochastic uncertainty.
I will also merge this now, as even though it "relies" on mit-crpg/openmc#800, python can write to attributes that don't exist.
This PR, which requires https://github.com/mit-crpg/openmc/pull/800 and also includes https://github.com/mit-crpg/opendeplete/pull/25, hands over all handling of the burnables and volumes to OpenMC. As such, now a user can calculate volumes using the stochastic capabilities, tag materials as
burnable
as needed, construct anOpenMCSettings
object and then perform depletion. Hooray fewer steps. The downside is that the OpenMC API must be able to see the entire geometry at beginning of run, which will eventually pose scaling issues. An alternative initialization scheme will need to be written if, for example,cell.fill
returnsNone
.This also indicated to me an interesting gap in the OpenMC Python API. Why can't I, with a geometry in which all cells are filled with a material, easily write
materials.xml
?Currently, I only access cell-wise volumes. I would be interested in knowing if anyone has any issues with that.
I also performed a rather heavy refactorization.
Operator
is now an abstract class that provides three functions and a barebonesSettings
object. This is the complete interface a module needs to provide to use the integrator.OpenMCOperator
derives from this type and implements said interface. Further, I tried to deduplicate as many indexing methods as possible, moving a few arrays into the care ofAtomNumber
.Also, with regards to #27, I see no deprecation warnings. Does https://github.com/mit-crpg/openmc/pull/800 not include these changes?