write ANSYS fluent .msh format

[ly16302]

trafficstars

Describe the bug I would like to write a simple .msh file readable by ANSYS Fluent.

To Reproduce import meshio tet_mesh = meshio.Mesh( [ [0.0, 0.0, 0.0], [1.0, 0.0, 0.0], [1.0, 1.0, 0.0], [0.0, 1.0, 0.0], [0.5, 0.5, 0.5], ], [("tetra", [[0, 1, 2, 4], [0, 2, 3, 4]])], ) tet_mesh.write("tet.msh",file_format="ansys")

Did I help? It will generate a msh file, but the .msh mesh can't be read in fluent. After read the file, fluent reports: Meshing> Reading ''... meshio 5.3.4 3D mesh nodes: 5 cells: 2 warning: flushed 1 bytes of data in section 3010. generating pointers...done extracting boundary entities 0 boundary nodes. 0 boundary faces. 0 boundary face zones. done. analyzing boundary connectivity...done

[1oyue]

I have a same problem. Converting a vtk file to a obj file is perfect. While converting a vtk file to a msh file, neither my ANSYS FLUENT nor IANSYS CEM can not read the msh file.

[Aligorith]

I've been investigating a similar issue here today too.

It seems that there are several things going on, when cross-referencing both the Ansys .msh format spec [1], and the results of passing a few simple sample objects through Ansys (i.e. Blender -> STL Test Object -> Ansys -> Export to .msh). In short: the more I find out, the more it looks less like a simple "format conversion" problem, and more like an intensive remeshing / recomputation exercise. I hope I'm wrong about this though ;)

Unfortunately, I don't have direct access to a copy of Ansys or the other CFD tools this stuff is being used for myself. The sample files attached were ones I got the colleague (who I'm helping to do some workflow/export pipeline optimisations work) to help process + test.

Findings so far:

• meshio currently exports face geometry as "xf-cell"'s (block-type 12), whereas it seems that most of these should end up as "xf-face"'s (block-type 13) instead.

• According to the spec, both block-types 12 and 13 are required to be in the generated files

• Examining a few test objects (i.e. the Default Cube from Blender (-1,-1,-1) -> (1,1,1), and two of these glued together - see attached zip files), it appears that Ansys actually remeshes everything into a regular grid, then tries to span faces ("13" blocks) between vertices/nodes of that graph ("10" blocks). Current mysteries:

  • 1. How do the "12" blocks ("xf-cell") come about (particularly how the "end-index" value is determined). They don't otherwise seem to contain any data at all, other than those size declarations.
  • 2. Is the sampling rate always 10 subdivisions? Or was that just the setting used on the test files?
  • 3. Why are some of the geometries assigned to regions/zone-id's (e.g. "4") that don't correspond to one of the block-type "45" defines? (Also, not all the regions/zones have block 10/12/13's assigned to them)

Reference spec for the .msh format that I've been basing this analysis on: [1] https://romeo.univ-reims.fr/documents/fluent/tgrid/ug/appb.pdf

Sample Files (I originally tried to upload/attach them here, but that didn't work): [2] https://drive.google.com/file/d/1OwAHoD0Dv6c6aGIPKROMvboiDX1aoYd1/view?usp=sharing

(I've also got some much larger TPMS lattice meshes, but those have a lot of other complications, making it harder to figure out what may be going on)

[anlijun]

I've been investigating a similar issue here today too.

It seems that there are several things going on, when cross-referencing both the Ansys .msh format spec [1], and the results of passing a few simple sample objects through Ansys (i.e. Blender -> STL Test Object -> Ansys -> Export to .msh). In short: the more I find out, the more it looks less like a simple "format conversion" problem, and more like an intensive remeshing / recomputation exercise. I hope I'm wrong about this though ;)

Unfortunately, I don't have direct access to a copy of Ansys or the other CFD tools this stuff is being used for myself. The sample files attached were ones I got the colleague (who I'm helping to do some workflow/export pipeline optimisations work) to help process + test.

Findings so far:

• meshio currently exports face geometry as "xf-cell"'s (block-type 12), whereas it seems that most of these should end up as "xf-face"'s (block-type 13) instead.

• According to the spec, both block-types 12 and 13 are required to be in the generated files

• Examining a few test objects (i.e. the Default Cube from Blender (-1,-1,-1) -> (1,1,1), and two of these glued together - see attached zip files), it appears that Ansys actually remeshes everything into a regular grid, then tries to span faces ("13" blocks) between vertices/nodes of that graph ("10" blocks). Current mysteries:

  • 1. How do the "12" blocks ("xf-cell") come about (particularly how the "end-index" value is determined). They don't otherwise seem to contain any data at all, other than those size declarations.
  • 2. Is the sampling rate always 10 subdivisions? Or was that just the setting used on the test files?
  • 3. Why are some of the geometries assigned to regions/zone-id's (e.g. "4") that don't correspond to one of the block-type "45" defines? (Also, not all the regions/zones have block 10/12/13's assigned to them)

Reference spec for the .msh format that I've been basing this analysis on: [1] https://romeo.univ-reims.fr/documents/fluent/tgrid/ug/appb.pdf

Sample Files (I originally tried to upload/attach them here, but that didn't work): [2] https://drive.google.com/file/d/1OwAHoD0Dv6c6aGIPKROMvboiDX1aoYd1/view?usp=sharing

(I've also got some much larger TPMS lattice meshes, but those have a lot of other complications, making it harder to figure out what may be going on)

After opening the file with Fluent software, I found that, unlike other formats, in order to express the connectivity of the cell, "xf-face" (block-type 13) must be created.

In this example, the connection relationship of the tetrahedron is not expressed in "xf-cell", but written in the adjacent cell of each triangle in the "xf-face" section. Other formats will list the four vertices of the tetrahedron directly, rather than scattered and unobvious like the Fluent msh file format

Here is an easy-to-understand example that can be opened by Fluent software:

(0 "m41m41")

(2 3)

(10 (0 1 8 0)) (13 (0 1 10 0)) (12 (0 1 4 0))

(10 (5 1 8 2 3) ( -0.5 -0.5 -0.5 0.5 0.5 0.5 -0.5 0.5 0.5 0.5 0.5 -0.5 0.5 -0.5 0.5 0.5 -0.5 -0.5 -0.5 0.5 -0.5 -0.5 -0.5 0.5 ))

(13 (1 1 10 3 3) ( 1 2 3 3 0 2 4 1 1 0 2 5 1 2 0 1 3 5 4 0 6 2 1 2 0 7 2 1 1 0 6 1 5 2 0 1 7 3 4 0 7 1 4 1 0 6 5 2 2 0 1 8 2 3 0 7 4 2 1 0 1 3 8 3 0 1 5 7 4 0 2 8 3 3 0 3 7 5 4 0 ))

(12 (3 1 4 11 2))