mit-crpg / opendeplete

A depletion framework for OpenMC
MIT License
15 stars 5 forks source link

Remove need of volume, materials lists #28

Closed cjosey closed 7 years ago

cjosey commented 7 years ago

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 an OpenMCSettings 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 returns None.

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 barebones Settings 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 of AtomNumber.

Also, with regards to #27, I see no deprecation warnings. Does https://github.com/mit-crpg/openmc/pull/800 not include these changes?

wbinventor commented 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.

cjosey commented 7 years ago

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.