2014-07-22 12:09 GMT+02:00 Garth N. Wells <[email protected]>: > It was decided some time ago to remove CGAL from DOLFIN and move the meshing > functionality into a focussed project, mshr > > https://bitbucket.org/benjamik/mshr > > which interfaces to CGAL and DOLFIN. The question now is how to remove CGAL > from DOLFIN? Three option are: > > 1. Just remove CGAL code from DOLFIN. Those using the CGAL mesh generation > functionality can then build mshr, and the in the case of C++ link to it, > and in the case of Python import the mshr module. > > 2. Have the CGAL classes print an error message pointing to mshr. > > 3. Deprecating the CGAL interfaces and removing the CGAL code in a future > release. > > For simplicity, I favour option (1). Normally, we would adopt (3) but a > problem at present is that the CGAL code is blocking improvements to the > test system because compiling the CGAL code uses a large amount of memory > (prohibitive on small systems) and takes a long time. > > Please reply with any comments or suggestions on the removal of the CGAL > code. It would also be useful to start getting more testing of mshr.
I agree, mshr is already in a better state than the code in Dolfin. If pyDolfin imports mshr into its namespace (if mshr is available), the majority of the users (and in particular those who don't build Dolfin from source) will hardly notice the change. In this case (2) is meaningless and will lead to name clashes, I guess. The only argument I see for waiting is that we don't have Debian/Ubuntu packages available from the FEniCS PPA. I know Johannes had a look at that, but I don't know the details. He can - if not on holiday - comment more on this. Benjamin > > Garth > > _______________________________________________ > fenics mailing list > [email protected] > http://fenicsproject.org/mailman/listinfo/fenics _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
