Differences and similarities between DUNE adapter and dumux-precice

[ajaust]

Hi!

thanks for this nice adapter in #1. I have written an adapter for DuMuX which is called dumux-precice. The dumux-precice repository has been private for way too long, but has been set to public recently: https://git.iws.uni-stuttgart.de/dumux-appl/dumux-precice

The DuMuX adapter shares some features with the DUNE adapter. That is not a surprise since DuMuX itself is based on DUNE. I went through the pull request to figure out some similarities and differences.

Similarities/Differences

I will refer to the DuMuX adapter either as "DuMuX adapter" or as dumux-precice which is the name of the repository and also the DUNE module. (Note: The DuMuX adater/dumux-precice is a DUNE module)
If there is only one of the adapters mentioned for some of the points, it means that the other adapter does not do the same thing or does the opposite.

• dumux-precice has a lot of similar/same functionality. I was also thinking of splitting my adapter into a more generic wrapper around the preCICE API, similar to what the DUNE adapter does, and then wrap around that with in the DuMuX adapter. I have not really thought about the details for this yet. For example, I am currently not sure which data structure I would/neet want to support.
• At the moment dumux-precice does not provide functionality of every preCICE API function, but only functions that I have needed so far. I did not want to expose more functionality before other users or I would need it.
• dumux-precice could be based on the DUNE adapter, but I found some problems with that at the moment. Examples for that would be:
  • I am not sure about the extra dependency in dumux-precice. ;) However, it does not make sense to reproduce code too much either.
  • Some merging (multiple data fields), more/different control over the initialization (dumux-precice does not used the interpolation from DUNE) would have to be done.
• dumux-precice has a bit more DuMuX specific implementation regarding interpolation/extrapolation of data onto the coupling boundary etc. Since DuMuX has a CouplingManager which is used for monolithic simulation dumux-precice also aims to provide similar convenience functions as this CouplingManager where suitable. However, I believe some of these functions could also be achieved by wrapping around some kind of base adapter (let it be the DUNE adapter or my on base implementation). Example for convenience functions: Mapping between IDs of degrees of freedom
• dumux-precice allows for more than one dataset per coupling interface to be read/written. I have used that in some case where I needed to exchange the pressure and another scalar quantity over one surface.
• The dune adapter uses more templates than dumux-precice does. This is on some todo list for dumux-precice, but not implemented.
• The DUNE adapter uses more DUNE specific data structures such as FieldVector while dumux-precice is relying more on standard data structures from the STL at the moment. I wanted to go more to DUNE- or DuMuX-specific data structures where suitable or directly go for templates. if possible I am not sure if it really matters what data structures are used internally in the adapter. However, DUNE data structures might feel more natural to other users if they want to extend the adapter.
• dumux-precice has tests and example cases. Also some monolithic test cases are included.
• The dumux-precice repository is more of a mess compared to the DUNE adapter and should be restructured. Example what I have to do for dumux-precice: Seperate the adapter implementation and the actual examples into different directories.
• dumux-precice does not use the interpolate function supplied by DUNE. I am not sure whether this is finite-element specific or not. Why does the DUNE adapter do interpolation instead of asking preCICE to do this? More general: Why is it necessary to do the interpolation in the initialization of the DUNE-adapter
• In dumux-precice some of the preCICE API functions have been renamed in the wrappers. Partially since dumux-precice was introduced with preCICE v1. In preCICE v2 the naming of functions has been improved.
• dumux-precice currently is a Singleton. However, I was planning to change this in the future such that it can/has to be handled more like the CouplingManager for monolithic coupling in DuMuX. This means the adapter will be a normal class afterwards that is shared via some pointers.
• None of the projects has a license yet. I guess the DUNE license or something similar could make sense. The DUNE license is basically GPL2 with a "runtime exception".

Questions/Remarks

• What should we do from here? Does it make sense to join efforts for something like a compatible DUNE adapter? Would this even be possible?
• I would have some remarks regarding the code of the DUNE adapter if a review would be needed.

Further info/links

• DuMuX
• DuMuX adapter

[maxfirmbach]

@ajaust Thanks for the nice overview! Maybe I can clearify some small things. The DUNE-adapter is for now only used in regards of a finite element discretization. The naming of the interpolate function inside DUNE that is used inside the initialization is maybe a bit misleading. Normally it's used to map a continuous function (e.g. initial condition) to the discrete points of a finite element basis. The way it's used inside the adapter is just returning the coordinates of the basis support points at the boundary, where the coupling with preCICE happens.

Feel free to modify/merge the adapter!

[ajaust]

Sorry for the late reply! I will try to check out your example this week to get a better feeling for the usage of your adapter and how the usage compares to the DuMuX-adapter. At the same time I try to cleanup my repository a little bit.