Closed RemDelaporteMathurin closed 2 years ago
Even if the initial user-defined tag is not material-type like 'component_1'
it makes more sense to have
'component_1'
--> 'Lead'
Yep I hope to get rid of this mat prefix. It is there because DAGMC needs a mat prefix. But that might be mat: instead of mat_ . We should be able to hide this prefix from the users as they don't need to know about it.
How come when I was using stl_toh5m I didn't have `matin
material_tag_to_material_dict` ?
Sorry for the slow reply, I still haven't had time to fix this but I remembered a tool that can be useful for inspecting h5m files.
conda install -c moab
mbsize -ll dagmc.h5m | grep 'NAME = mat:'
This shows that I've been adding the unnecessary mat_
to the front of material names. Material names need a prefix of mat:
and I think that I got mixed up.
There is a place in the workflow that checks for the existence of mat_
and if not present it adds mat_
. This would make sense if we were looking for mat:
which needs to be present, I can figure this out and tidy it up.
Output using this command line tool from a submersion reactor looks like this
mbsize -ll dagmc.h5m | grep 'NAME = mat:'
NAME = mat:mat_plasma
NAME = mat:mat_center_column_shield
NAME = mat:mat_inboard_tf_coils
NAME = mat:mat_outboard_firstwall
NAME = mat:mat_outboard_firstwall
NAME = mat:mat_blanket
NAME = mat:mat_blanket
NAME = mat:mat_divertor_upper
NAME = mat:mat_divertor_lower
NAME = mat:mat_supports
NAME = mat:mat_supports
NAME = mat:mat_outboard_rear_blanket_w
I wonder what the process looks like now, do users still need to add "mat:" themselves in a dict?
I think this could be something done in the backend and not the user side
No need for the users to add mat:
or mat_
or anything like that.
DAGMC needs mat:
to be present but the code (stl-to-h5m) takes care of that in the background. Nothing for the users to worry about
Awesome! Thanks for this Jon!!!
You will need stl-to-h5m version 0.2.1 and brep-to-h5m version 0.3.1 for this to work
ok but I reckon we can change the version numbers in fusion-neutronics-workflow no?
Yes we will need to update the versions used in fusion-neutronics-workflow.
I've also written up a minimal example of on the develop branch here https://github.com/shimwell/cad-to-dagmc-to-openmc-example/tree/develop
It took me a while to realise that
brep_to_h5m
was enforcing the prefix'mat_'
in material tags.Is this really required? In my case, the tags are already like "lead", "eurofer", etc.
So my workflow is: when I create the geometry:
internally,
'flibe'
becomes'mat_flibe'
Finally when I run the neutronics:
(user-defined tag)
'lead'
-->'mat_lead'
-->'Lead'
(odw readable material tag)this seems a bit redundant... especially when users don't even have a choice haha!
it would be a lot more straightforward to skip the middle step and have
'lead'
-->'Lead'