Open shimwell opened 2 years ago
I remember a while ago we had the discussion wether we include the h5m in these objects or just in geometry. I'm happy to have it in odw.Geometry only
I think we need to stick to an openmc-like structure though, otherwise we are asking users that already know openmc to learn another structure.
We could have the current odw.Geometry class that has the h5m, a odw.Materials that doesn't need the h5m as argument, a odw.Model inheriting from openmc.Model.
The communication between odw.Materials and odw.Geometry can then be done inside odw.Model at instanciation
h5m_filename = "neutronics_workflow-0.0.2/example_02_multi_volume_cell_tally/stage_2_output/dagmc.h5m"
geometry = odw.Geometry(h5m_filename=h5m_filename)
materials = odw.Materials(
correspondence_dict={
"blanket_mat": "Li4SiO4",
"blanket_rear_wall_mat": "Be",
"center_column_shield_mat": "Be",
"divertor_mat": "Be",
"firstwall_mat": "Be",
"inboard_tf_coils_mat": "Be",
"pf_coil_case_mat": "Be",
"pf_coil_mat": "Be",
"tf_coil_mat": "Be",
},
)
tally1 = odw.MeshTally2D(
tally_type="photon_effective_dose",
plane="xy"
)
tally2 = odw.MeshTally2D(
tally_type="neutron_effective_dose",
plane="xy"
)
tallies = openmc.Tallies([tally1, tally2])
settings = odw.FusionSettings()
settings.batches = 2
settings.particles = 100
settings.photon_transport = True
settings.source = FusionRingSource(fuel="DT", radius=350)
my_model = odw.Model(
materials=materials, geometry=geometry, settings=settings, tallies=tallies
)
statepoint_file = my_model.run()
In such a structure, odw.Materials
would run checks()
at its instanciation but rather in odw.Model.__init__()
.
def checks(self, h5m_filename):
materials_in_h5m = di.get_materials_from_h5m(h5m_filename)
# # checks all the required materials are present
for reactor_material in self.correspondence_dict.keys():
if reactor_material not in materials_in_h5m:
msg = (
f"material with tag {reactor_material} was not found in "
f"the dagmc h5m file. The DAGMC file {h5m_filename} "
f"contains the following material tags {materials_in_h5m}."
)
raise ValueError(msg)
if "graveyard" in materials_in_h5m:
required_nb_of_materials = len(materials_in_h5m) - 1
else:
required_nb_of_materials = len(materials_in_h5m)
if required_nb_of_materials != len(self.correspondence_dict.keys()):
msg = (
f"the number of materials provided in the correspondence_dict "
f"{len(self.correspondence_dict.keys())} "
f"is not equal to the number of materials specified in the "
f"DAGMC h5m file {required_nb_of_materials}"
)
raise ValueError(msg)
silently_remove_file("materials.xml")
In such a structure, odw.RegularMesh2D
would be defined as:
my_mesh = odw.RegularMesh2D(resolution=(400, 400))
If no bounding_box is provided, it will be set inside odw.Model
from odw.Geometry.h5m_filename
.
To be honest it makes sense to me, but a while ago we decided to keep the h5m_filename attached to all these objects
Btw, not so long ago we had that: a single neutronics_model
class (https://github.com/fusion-energy/openmc-dagmc-wrapper/blob/v0.1.3/openmc_dagmc_wrapper/neutronics_model.py)
And we decided to opt for an openmc-like structure. It makes sense cause as I explained in #105 , I think ODW is more of an openmc-extension for dagmc-based neutronics than an abstraction. We don't want to hide potentially useful openmc features to users by having a higher level of abstraction.
The goal of odw is to make cad-based openmc users' life easier.
Ok this sounds like a nice line saver, lets move a few checks into the Model part.
Ok this sounds like a nice line saver, lets move a few checks into the Model part.
I mean I don't know if it will save that many lines... 1 at Materials instanciation, 1 in each MeshTally (that according to #105 could go away)...
I think we should do it still, but let's not expect a tremendously lower line count
@RemDelaporteMathurin
We have a lot of places where we parse in the h5m geometry to check the bounding box or materials present. We are passing information between the class of settings, materials, tallies.
How about we just make the whole model in one class. Then all the methods have access to the h5m geometry and other aspects of the model. The example here uses the current approach is not much shorter than using native openmc. Combining into a single object could reduce that example to about half the line count