idaholab
MooseMesh::buildLowerDMesh function needs to put elements in different types into different subdomains
Motivation
Exdous output requires all elements in a subdomain to be in the same type. MooseMesh::buildLowerDMesh() with a 3D mesh can push side elements in different types into the same subdomain if the 3D mesh contains prisms, etc.
Design
We will need to check the types of the added lower-dimensional elements and add more subdomains based on their types. This will possibly affect downstream applications making use of the single subdomain name currently. Tag @yjung-anl
Impact
Make output of 3D solutions into Exodus possible for calculations that build the lower-dimensional mesh.
Alternatively, maybe Exodus output could automatically dispatch in separate blocks when this happens.
I think that is a good idea. It will require changes in the libMesh Exodus writer. @roystgnr
Another option would be to stop relying on the lower-d mesh for HFEM and use the side hierarchics instead
"Make the Exodus writer use separate blocks for different element types within the same subdomain, and make the reader merge them back seamlessly" has been on my TODO list for forever ... just never on my funding list. If we had a better excuse to do it than "it was a design mistake which annoys me on a fundamental level", I might be able to find time this summer, surely this fall.
Sweet. That'll give me a good reason to s/Block/Subdomain/g and s/block/subdomain/g in all our docs and API names while I'm at it (though I'd leave the old APIs around for backwards compatibility, naturally). Because I don't want to create confusion for users whose hybrid-element "subdomain N" is suddently getting split into "block N", "block N+Offset1", etc., naturally, not because I'm just annoyed by having failed to nip that category error in the bud.