> On 13 Sep 2018, at 15:59, Guilherme Saturnino <[email protected]> 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 <[email protected]> >>> 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 >>> >>> [email protected] >>> 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 >> >> >> > — 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 [email protected] http://onelab.info/mailman/listinfo/gmsh
