Dear Benjamin, I haven't checked out meshr yet but this sounds like great work! One quick question: I noticed a while back that 3D meshes generated in dolfin using CGAL were not reproducible in the sense that the same function call would result in meshes with slightly different numbers of vertices each time. Is this fixed in meshr, or is this something inherent in the way CGAL generates the meshes?
Many thanks, Max 2014-06-14 22:57 GMT+01:00 Benjamin Kehlet <[email protected]>: > Dear all > > During the last months I have made an effort to improve the mesh > generation code in FEniCS. The code is based on the mesh generation > code in Dolfin, but have now been separated places in a new component > called mshr. > > The code resides here: https://bitbucket.org/benjamik/mshr , but > should maybe be put in a repository owned by the fenics-project team? > > The primary focus has been on robustness and I believe the code has > been significantly improved in this respect. The module now contains a > small test suite and many bugs have been fixed. There is a buildbot > here: http://128.39.36.155:8010/builders/mshr-master-ubuntu-amd64 . It > recently turned green for the first time. Some new features have also > been added. I'm in the process of writing a readme file that will sum > up the functionality. > > Existing user code should run unchanged with the exception that one > will have to add "from mshr import *" (assuming the user has also done > "from dolfin import *"). The only exceptions here are the classes > PolyhedralMeshGenerator and PolygonalMeshGenerator. Their > functionality seems to overlap almost entirely with mshr, but user > code will not be compatible. Can they be removed? It would probably be > possible to make the dolfin python module try to import mshr into its > namespace if it is available, but I personally don't like this > solution as it is messy and introduces as kind of circular > "dependency". > > mshr now builds cgal and tetgen from source and links them statically > into the module. This approach avoids the issues we have seen with > different versions of CGAL and also makes it possible to patch CGAL if > bugs upstream are fixed between releases. The overhead is very small, > since CGAL is almost header only. > > A possible plan would be to release mshr 1.4 (assuming the component > should follow the version numbering scheme as the rest of the > components) now and replace the classes in dolfin/generation with > dummy classes that just informs the user that the code has moved. The > classes in the dolfin/generation directory (except the UnitFooMesh > classes) can then be removed completely at a later point. This can be > done as soon as Johannes has prepared debian/ubuntu packages for mshr. > > Some more details will be presented at FEniCS'14 on Tuesday. > > Best regards > > Benjamin Kehlet > _______________________________________________ > fenics mailing list > [email protected] > http://fenicsproject.org/mailman/listinfo/fenics >
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
