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.
--
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>
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