-
Notifications
You must be signed in to change notification settings - Fork 2
Refactor discussion #107
Comments
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, 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, my_mesh = odw.RegularMesh2D(resolution=(400, 400)) If no bounding_box is provided, it will be set inside |
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 And we decided to opt for an openmc-like structure. 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. |
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
The text was updated successfully, but these errors were encountered: