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? On Apr 28, 2021, at 8:24 PM, Ali Sheikholeslam <[email protected]<mailto:[email protected]>> wrote: 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 [email protected]<mailto:[email protected]> View this message at https://list.nist.gov/fipy --- To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. <Converted.rar><FiPy exported.rar><FiPy exported Flac.png><FiPy exported OpenFOAM compare.png> -- To unsubscribe from this group, send email to [email protected] View this message at https://list.nist.gov/fipy --- To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
