Why add the prefix 'mat_' before the material tag?

[RemDelaporteMathurin]

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:

mats = ['inner_tank_wall', 'outer_tank_wall', 'lead', 'flibe']

internally, 'flibe' becomes 'mat_flibe'

Finally when I run the neutronics:

material_tag_to_material_dict = {
    "mat_lead": "Lead",
    "mat_flibe": nmm.Material.from_library(name="FLiBe", enrichment=90, temperature=650+273.15, pressure=1e5, temperature_to_neutronics_code=False),
    "mat_inner_tank_wall": "SS_316L_N_IG",
    "mat_outer_tank_wall": "SS_316L_N_IG",
}

(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'

[RemDelaporteMathurin]

Even if the initial user-defined tag is not material-type like 'component_1' it makes more sense to have

'component_1' --> 'Lead'

[shimwell]

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.

[RemDelaporteMathurin]

How come when I was using stl_toh5m I didn't have `matinmaterial_tag_to_material_dict` ?

[shimwell]

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

[RemDelaporteMathurin]

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

[shimwell]

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

[RemDelaporteMathurin]

Awesome! Thanks for this Jon!!!

[shimwell]

You will need stl-to-h5m version 0.2.1 and brep-to-h5m version 0.3.1 for this to work

[RemDelaporteMathurin]

ok but I reckon we can change the version numbers in fusion-neutronics-workflow no?

[shimwell]

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