Problem in Gmsh3D import: messed up mesh system

78 views
Skip to first unread message

Ali Sheikholeslam

unread,
Apr 28, 2021, 8:24:56 PM4/28/21
to fi...@list.nist.gov

Before anything else, I would like to appreciate FiPy group moderators and experts for their continued activities. My problem is solved, but I decided to write about a problem that I was faced with and it seems to be an issue, for further investigations if it is needed.

There is a problem in importing by Gmsh3D, which will, perhaps, affect the final results. I have updated my last discussion, by new outcomes, in this new one. I have meshed my model in Gmsh, OpenFOAM, and Flac and converted them to gmsh -2 format ascii. I have tested their mesh systems, before and after conversion, by Gmsh.exe and paraview, and I made sure they were correct. Each of these meshes is created in a different way. The problem becomes apparent when exporting gmsh mesh file by FiPy and checking the output by visualizing softwares. Gmsh’s geo and msh mesh files are read by FiPy without any problem, but FiPy reads Flac and some OpenFOAM meshes wrongly. It seems, some cell node orderings for cell creation are changed by FiPy [I know that FiPy solve problems and define meshes based on its internal conventions; but some cells seem to have wrong node numberings that affect cell shapes in some parts of the models], which is under the influence of mesh creation methods of the meshing softwares, as the picture below. In investigated meshes, it seems that the problem is related to intersection of the blocks during mesh system creation, when creating a cylinder by rotating one created-quarter of it and with different node numberings of the neighbored blocks (in the geo file, it did not cause any problems, perhaps for not rotating the quarter). As it is shown in the picture, the two OpenFOAM created meshes, which are created by two different right-hand rule directions, the right method results in a true meshed-model. It seems from the picture that the same direction of right-hand rule on the intersecting nodes, in separate blocks, will prevent the problem (orange circles are showing the direction on the nodes, top-right pic is the true one). In the weird meshes, it seems that FiPy identified cell geometries wrongly from the beginning after import, in the intersection parts, and will result in wrong outcomes. The results need to be checked. All of the discussion is about FiPy exported gmsh files; which must be the same as the imported one for cell creating node orderings, but it is not for a few cells. This problem is related to some mesh files, not all of them.

The picture shows the problem. I attach converted-original msh files and FiPy-exported ones for further investigations if it is a problem and needs to be investigated and be corrected.

Converted.rar
FiPy exported.rar
FiPy exported Flac.png
FiPy exported OpenFOAM compare.png

Guyer, Jonathan E. Dr. (Fed)

unread,
Apr 29, 2021, 7:29:52 AM4/29/21
to FIPY
I am having trouble parsing this. I gather that some meshes are not importing the way you expect? Or they’re not exporting correctly? 

I understand that the images display meshes that appear to be malformed, but I don’t understand where those meshes came from or where you are observing a problem. 

When you import these meshes to FiPy, do you get solutions that don’t make sense? Or is it that when FiPy re-exports these meshes that your external tools no longer understand them?


Can you please systematically explain:

What you did?

What happened?

What you expected to happen?

What is a .rar file?



--
To unsubscribe from this group, send email to fipy+uns...@list.nist.gov
 
View this message at https://list.nist.gov/fipy
---
To unsubscribe from this group and stop receiving emails from it, send an email to fipy+uns...@list.nist.gov.
<Converted.rar><FiPy exported.rar><FiPy exported Flac.png><FiPy exported OpenFOAM compare.png>

Ali Sheikholeslam

unread,
May 7, 2021, 7:02:40 PM5/7/21
to fipy, jonatha...@nist.gov, FIPY

I have tested my problem again to find out why the results are different for the same meshes made in different ways. It seems that the problem is only in FiPy gmsh re-exports, not in the solution results.

I have tested by different created meshes and there was not any stopping-error during imports. Some of these created meshes were exported by FiPy as they were tested before by gmsh and paraview. My external tools understand FiPy-gmsh exported meshes, but malformed for some of them and for some part of them. Meshes are created in different softwares and in different ways.

My problem was Python-second software coupled and FiPy was one side of the solution and the second software uses FiPy “mesh._cellVertexIDs.T” to define mesh structures for itself.

I wrote a code to rearrange “mesh._cellVertexIDs.T” data for two different created meshes to make them the same, so the second part of the solution become similar for the two meshes. One of the FiPy-exported meshes was shown as it was tested before importing, but the other one was shown malformed after FiPy-export. I have tested these two meshes to find out if these differences are only related to FiPy exported meshes or they are pointing to a solution problem. The results were the same and it turned out that it will be only related to the FiPy gmsh export problem. I attach the two created meshes to this text for further investigations if needed.

The .rar files were windows-compressing formats and involve created meshes with different softwares for further tests.

I have updated my last conversation ''Problem in mesh visualization after Gmsh3D import: Weird mesh system'' to new one entitled "Problem in Gmsh3D import: messed up mesh system". Please delete the older one.

yours sincerely

Converted Insided.msh
Converted Rotated.msh
Reply all
Reply to author
Forward
0 new messages