search

nschloe / meshio

:spider_web: input/output for many mesh formats
MIT License
1.93k stars 397 forks source link

[BUG] Exodus File containing lower dimensional block fails - KeyError: 'TRUSS' #1436

Open Florian-Konrad opened 1 year ago

Florian-Konrad commented 1 year ago

Describe the bug Loading my exodus mesh consisting of two blocks: tetraheadral elements block and 1D lower dimensional block --> causes KeyError: 'TRUSS'

To Reproduce I attached a small exodus mesh that can be opened in paraview and works perfectly in moose framework but can not be opened with meshio: boxmesh_nowell_well_6bcs.e.zip

Diagnose pip freeze | grep meshio output: meshio==5.3.4

Context I'm encountering these kinds of mixed dimensional meshes regularily in the context of porous flow and geothermal reservoir simulations. 2D lower dimensional blocks representing fault-planes as triangular meshes work fine together with meshio. I only get the error wenn adding a 1D block.

Florian-Konrad commented 1 year ago

can this be fixed by just adding "TRUSS":"line" to exodus_to_meshio_type dictionary?

I also found there are more element types than just TRUSS that seem to end up as EDGE2 elements in libmesh: https://mooseframework.inl.gov/docs/doxygen/libmesh/exodusII__io__helper_8C_source.html

Would it make sense to add those missing as well: "EDGE" "EDGE2" "TRUSS" "TRUSS2" "BAR2"

I think I encountered EDGE2 before and couldn't load it into meshio!

How is this element type information preserved when storing the exodus mesh with meshio? Cant find a better source but seems like these element types have an effect on degrees of freedom (edit: at least in some software codes, moose doesn't distinguish): https://coreform.com/cubit_help/finite_element_model/exodus/model_definitions.htm