Utilize CGAL wrapper independent of DUNE-FEM?

[krober10nd]

• DUNE-Mmesh is composed of a CGAL interface and DUNE-FEM code interface that are used to perform mesh adaptation to solve variational problems.
• While the combination of the two makes sense, I believe it would be more advantageous to the open-source community to have two separate levels of installation in which only the CGAL-Python wrapper that is called to perform mesh adaptation is the base installation and the DUNE interface could be installed on-top of it.
• Is it possible to separate out the two? In this way, the user could utilize complex mesh adaptation routines in Python and potentially interface with other DSL FEM libraries (e.g., Firedrake, FEINCS, Necktar, etc...) in addition to DUNE...

[samuelburbulla]

Hi Keith, thanks for coming up with this idea. It’s a good question if we could separate both.

First let me clarify some things: Dune-MMesh wraps the CGAL triangulations on the C++ side and acts there as a DUNE grid. Afterwards, we add the python interface by using the Python bindings of DUNE.

So the structure is CGAL -> DUNE -> Python -> Dune-Fem and not possibly CGAL -> Python -> Dune-Fem

Therefore, we can’t consider dune-mmesh as a pure python wrapper of CGAL. We rely on the DUNE grid interface.

Of course, it would be possible to use the DUNE grid dune-mmesh only - without dune-fem. Like as we could use any other DUNE grid with python bindings (e.g. dune-alugrid). I added dune-fem once as hard dependency because many useful things (and some internal utility functions) make use of dune-fem functionality.

Do you propose to remove this hard dependency such that we can dune-mmesh as pure DUNE grid with python interface? Do you think it really hurts to have dune-fem anyway?

[krober10nd]

Thanks, @samuelburbulla for the clarification.

I see so you utilized CGAL functionality at the C++ level.

Well, I think it can be more difficult to install in its current format. For example, I'm having difficulty installing DUNE on my Mac due to some dependencies it requires (openmp), but this will be a different issue that I will post shortly.

At this point, I don't think it would make sense to change the functionality given everything is already established and appears working.