Re: [Gmsh] Meshing algorithms and suggestions
> On 13 Sep 2018, at 15:59, Guilherme Saturnino wrote: > > Dear Christophe, > > I would recommend using the default one. > > (Is the quality of the STL meshes sufficient, or do you need to remesh them?) > We have several steps of cleaning, smoothing and and re-sampling surfaces > before volume meshing in GMSH. We actually want to do "curvature-weighed > re-sampling". That is, we want to re-sample our surfaces but keep the node > density higher where the mesh is more curved. Do you know of any algorithm > that can do that? > Recent Gmsh versions optimize automatically. We will introduce some > fine-tuning in the future to change the speed/quality tradeoff ; currently a > good compromise is hardcoded. > > Looking forward to it! When we create our meshes, we still notice a few > bad-shaped elements. Is it because of the surfaces? How do the surfaces > constrain the volume meshing and optimization? As the volume algorithm does not (well, tries really hard not to) modify the surface mesh, a bad quality triangle will automatically lead to a bad tetrahedron in the volume. > The official Linux binaries are compiled on the "old-stable" Debian, in order > to support even quite old Linux distributions. Can you share the error you > get on CentOS 6 ? > > I get > > gmsh-4.0.1-Linux64/bin/gmsh: /usr/lib64/libstdc++.so.6: version > `GLIBCXX_3.4.14' not found (required by gmsh-4.0.1-Linux64/bin/gmsh) > gmsh-4.0.1-Linux64/bin/gmsh: /usr/lib64/libstdc++.so.6: version > `CXXABI_1.3.5' not found (required by gmsh-4.0.1-Linux64/bin/gmsh) > gmsh-4.0.1-Linux64/bin/gmsh: /usr/lib64/libstdc++.so.6: version > `GLIBCXX_3.4.15' not found (required by gmsh-4.0.1-Linux64/bin/gmsh) > CentOS 6 comes with an old glibc version, and updating it is not trivial. > Compiling gmsh on a CentOS 6 VM should solve this issue > Can you try installing the newer glibc and libstdc++ and let us now if this works (you can use LD_PRELOAD to make sure you load the correct one)? If this works you could ship it along with your code. Maintaining an extra linux build represents a significant amount of work: that's why we stick to Debian "old-stable", which ensures quite a bit of backward compatibility with older distributions (such as those usually found on HPC clusters) - but is still recent enough to have up-to-date distributions (typically used on development machine) ship compatibility libraries (gfortran, glibc, ...) if necessary. > Yes, that's indeed in our plans for a future revision of the MSH4 format, > together with even better handling of very large meshes/datasets. > > Nice! > > By the way, I was implementing an I/O function for version 4 binaries and I > believe I found a mistake in the documentation: > > "numNodes" in the blocks of both $Nodes and $Elements seems to be an int, > unsigned long. I think this is fixed in the latest version of the docs? > I also found that I need to skip 4 bytes after each block header. That's strange. Can you check with our reference implementation (Geo/GModelIO_MSH4.cpp) and file a issue if there is a discrepancy? Thanks, Christophe > > > Best Regards, > > Guilherme > > On 09/12/2018 10:32 PM, Christophe Geuzaine wrote: >> >>> On 12 Sep 2018, at 14:31, Guilherme Saturnino >>> wrote: >>> >>> Dear Gmsh developers, >>> >>> I'm working on a package called SimNIBS ( >>> http://simnibs.org/ >>> ) that does FEM simulations in human head models. We use gmsh to create >>> tetrahedral meshes from stl surfaces of brain and other tissues. Is there >>> any particular meshing algorithm you would suggest for this application? >>> >> I would recommend using the default one. >> >> (Is the quality of the STL meshes sufficient, or do you need to remesh them?) >> >> >> >>> What about optimization algorithms? We prefer robustness and quality over >>> speed. >>> >> Recent Gmsh versions optimize automatically. We will introduce some >> fine-tuning in the future to change the speed/quality tradeoff ; currently a >> good compromise is hardcoded. >> >> >>> I would also like to suggest 2 improvements for future Gmsh versions: >>> >>> 1. Is it possible to provide Gmsh 4 binaries that are compatible with >>> CentOS 6? It is an old but still widely used Linux distribution. This has >>> been holding us back in adopting Gmsh 4. >>> >> The official Linux binaries are compiled on the "old-stable" Debian, in >> order to support even quite old Linux distributions. Can you share the error >> you get on CentOS 6 ? >> >> >>> 2. Would it be possible in future releases to have more flexible data types >>> in $NodeData and $ElementNodeData? I think it would be very useful to store >>> single-precision floats (to save space) or integers (to have additional >>> labels for elements and nodes) . >>> >> Yes, that's indeed in our plans for a future revision of the MSH4 format, >> together with even better handling of very large meshes/datasets. >> >> Thanks for the
Re: [Gmsh] Meshing algorithms and suggestions
On Wed, 2018-09-12 at 14:31 +0200, Guilherme Saturnino wrote: > > I would also like to suggest 2 improvements for future Gmsh versions: > > 1. Is it possible to provide Gmsh 4 binaries that are compatible > with > CentOS 6? It is an old but still widely used Linux distribution. > This > has been holding us back in adopting Gmsh 4. What is preventing you from compiling the source code? -- jeremy www.seamplex.com ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Meshing algorithms and suggestions
Dear Christophe, /I would recommend using the default one. / /(Is the quality of the STL meshes sufficient, or do you need to remesh them?)/ We have several steps of cleaning, smoothing and and re-sampling surfaces before volume meshing in GMSH. We actually want to do "curvature-weighed re-sampling". That is, we want to re-sample our surfaces but keep the node density higher where the mesh is more curved. Do you know of any algorithm that can do that? /Recent Gmsh versions optimize automatically. We will introduce some fine-tuning in the future to change the speed/quality tradeoff ; currently a good compromise is hardcoded. / Looking forward to it! When we create our meshes, we still notice a few bad-shaped elements. Is it because of the surfaces? How do the surfaces constrain the volume meshing and optimization? /The official Linux binaries are compiled on the "old-stable" Debian, in order to support even quite old Linux distributions. Can you share the error you get on CentOS 6 ? / I get gmsh-4.0.1-Linux64/bin/gmsh: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by gmsh-4.0.1-Linux64/bin/gmsh) gmsh-4.0.1-Linux64/bin/gmsh: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.5' not found (required by gmsh-4.0.1-Linux64/bin/gmsh) gmsh-4.0.1-Linux64/bin/gmsh: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by gmsh-4.0.1-Linux64/bin/gmsh) CentOS 6 comes with an old glibc version, and updating it is not trivial. Compiling gmsh on a CentOS 6 VM should solve this issue /Yes, that's indeed in our plans for a future revision of the MSH4 format, together with even better handling of very large meshes/datasets./ Nice! By the way, I was implementing an I/O function for version 4 binaries and I believe I found a mistake in the documentation: "numNodes" in the blocks of both $Nodes and $Elements seems to be an int, unsigned long. I also found that I need to skip 4 bytes after each block header. Best Regards, Guilherme On 09/12/2018 10:32 PM, Christophe Geuzaine wrote: On 12 Sep 2018, at 14:31, Guilherme Saturnino wrote: Dear Gmsh developers, I'm working on a package called SimNIBS (http://simnibs.org/) that does FEM simulations in human head models. We use gmsh to create tetrahedral meshes from stl surfaces of brain and other tissues. Is there any particular meshing algorithm you would suggest for this application? I would recommend using the default one. (Is the quality of the STL meshes sufficient, or do you need to remesh them?) What about optimization algorithms? We prefer robustness and quality over speed. Recent Gmsh versions optimize automatically. We will introduce some fine-tuning in the future to change the speed/quality tradeoff ; currently a good compromise is hardcoded. I would also like to suggest 2 improvements for future Gmsh versions: 1. Is it possible to provide Gmsh 4 binaries that are compatible with CentOS 6? It is an old but still widely used Linux distribution. This has been holding us back in adopting Gmsh 4. The official Linux binaries are compiled on the "old-stable" Debian, in order to support even quite old Linux distributions. Can you share the error you get on CentOS 6 ? 2. Would it be possible in future releases to have more flexible data types in $NodeData and $ElementNodeData? I think it would be very useful to store single-precision floats (to save space) or integers (to have additional labels for elements and nodes) . Yes, that's indeed in our plans for a future revision of the MSH4 format, together with even better handling of very large meshes/datasets. Thanks for the feedback, Christophe Thanks a lot for putting so much time and effort into making this great piece of software. Best Regards, Guilherme Saturnino ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh — Prof. Christophe Geuzaine University of Liege, Electrical Engineering and Computer Science http://www.montefiore.ulg.ac.be/~geuzaine Free software: http://gmsh.info | http://getdp.info | http://onelab.info ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
[Gmsh] Meshing algorithms and suggestions
Dear Gmsh developers, I'm working on a package called SimNIBS (http://simnibs.org/) that does FEM simulations in human head models. We use gmsh to create tetrahedral meshes from stl surfaces of brain and other tissues. Is there any particular meshing algorithm you would suggest for this application? What about optimization algorithms? We prefer robustness and quality over speed. I would also like to suggest 2 improvements for future Gmsh versions: 1. Is it possible to provide Gmsh 4 binaries that are compatible with CentOS 6? It is an old but still widely used Linux distribution. This has been holding us back in adopting Gmsh 4. 2. Would it be possible in future releases to have more flexible data types in $NodeData and $ElementNodeData? I think it would be very useful to store single-precision floats (to save space) or integers (to have additional labels for elements and nodes) . Thanks a lot for putting so much time and effort into making this great piece of software. Best Regards, Guilherme Saturnino ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
