Gmsh → meshio → CDB for MAPDL: tetrahedral elements misinterpreted, face extraction fails

[AltoAuto]

Hi everyone I ran into a critical issue with face extraction logic failing due to bad-looking elements in mapdl.mesh.elem.
After meshing a solid .step part with Gmsh and exporting to .cdb, I get this in PyMAPDL:

[157, 199, 165, 165]
[195, 214, 160, 160, 241, 241, 241, 241]

These elements have, duplicated nodes, only 3–4 unique node IDs total node count ≠ expected 8 (for SOLID185) or 10 (for SOLID187), yet the original .msh file shows 'tetra' in mesh.cells_dict, which suggests a proper volume mesh.

The .cdb writer is:
Assigning wrong ET (e.g. ET=4, assumed to be SOLID185)
Using invalid NNODE=4 with only partial node lists
Producing garbage EBLOCK rows like:
1 4 1 1 ... 4 0 1 1 2 97 97
Which MAPDL loads, but the elements become unusable for face extraction.
By contrast, .cdb files from the Ansys website use ET=101 with proper 10-node tets:
1 101 1 1 ... 10 0 1 95 97 ... 57572

Questions:
Is there a correct way to map tetra cells from Meshio to SOLID187 when writing .cdb?
Is there a recommended .cdb writer for volume tetra meshes compatible with PyMAPDL?
Is PyMAPDL's mesh.elem supposed to only show corner nodes (and if so, should face extraction use only [:4])?

Any help or reference implementations would be appreciated — I’m aiming to build a general face-tagging engine for structural simulations across tet and hex meshes.

Thanks in advance!

[mikerife]

Hi @AltoAuto I don't see where Meshio supports writing of cdb files on its site...are you using meshio or a different package based on meshio? Can you give a sample script? The two element node connectivities you show are correct for MAPDL. [157, 199, 165, 165] would be correct for a degenerate triangle shape of a 4 node plane element (182). And [195, 214, 160, 160, 241, 241, 241, 241] would be correct for the degenerate tet shape of a linear hex element (185). Is there a specific error you are running into?
mike

[AltoAuto]

Hi Mike, really appreciate you replying that explanation actually cleared up a huge chunk of what we were stuck on.

You're absolutely right, we had been interpreting the repeated node patterns as corrupted or malformed, but your clarification makes it clear they’re just degenerate versions of valid MAPDL elements (especially for SHELL182 or SOLID185). That changes our understanding of what we were seeing entirely, thank you for that.

We had been experimenting with .msh to .cdb conversion using a custom script (initially inspired by meshio’s loading functions), but we now realize .cdb export isn’t officially supported by meshio, and that's probably a core reason for our downstream issues in MAPDL especially around element types, face extraction, and pressure application.

We’ll be pivoting away from meshio-based export and focusing on generating clean .cdb files ourselves with stricter control over ET types and element formatting (likely SOLID285/187 only). Your insight about degenerate shapes and the valid interpretation by MAPDL helps a lot as we start tightening that process.

I would love to keep this thread open in case we can tap into your expertise again. Really appreciate your time, and hope you'll find the direction we’re going with this as interesting as we do!

Thank You
Aiden

[mikerife]

Hi @AltoAuto I've not had time to test this myself, but since you are using PyMAPDL you may want to check out PyPrimeMesh as well. It is a meshing tool but it can import an Ansys (Fluent) msh file and export Ansys (MAPDL) cdb file format.

[germa89]

@AltoAuto so you are also building a tool to convert the gmsh step geometry to CDB files? If it is that so, as PyMAPDL developer, I would love to see that tool somewhere and help to contribute. I think MAPDL lacking step support is a big miss. So let me know if you are planning to make that tool available.

[AltoAuto]

@germa89 Yes, we’re building a full workflow that converts STEP to Gmsh (.msh), converts to CDB using meshio, runs PyMAPDL automation for FEA (pressure, constraints, etc.), and uses face-to-element mapping for targeted loads. Right now we’re stuck hard on SFE() , can’t get it to apply pressure even on clean SOLID185 blocks. It silently fails even when the element IDs are valid, face numbers are correct, and we’ve applied material + constraints. We switched to nodal forces as a workaround, but it breaks the whole point of face-based automation. If you’ve ever seen mapdl.sfe() work reliably in server mode, please let me know. This seems like a core blocker for fully automating FEA with imported meshes. Would love to show you our pipeline and get your input.

[AltoAuto]

Hi Mike, thanks again for the quick and helpful reply.

We’ve been looking into PyPrimeMesh, and it definitely seems promising. That said, we’re a bit concerned about potential licensing constraints, especially when it comes to using PyPrimeMesh inside a project like ours.

Specifically, we're building a lightweight FEA automation tool aimed at students and small teams. We'd love to use PyPrimeMesh for .cdb generation, but we’re unsure if it’s intended to be used only within the full Ansys ecosystem, or if there’s any way to use it externally (e.g., as part of a standalone conversion script) without running into redistribution or commercial usage issues.

Would you happen to know how Ansys handles this, or if there’s any flexibility for tools like ours?

[germa89]

I dont think this should be an issue, since PyPRIME is MIT license.

However, I think this should be better answered in PyPrime repo, so I did create an issue for this.

ansys/pyprimemesh#1014