Discussion: useful deal.II adapter updates

[davidscn]

Thinking about the upcoming adapter presentation during the workshop it might be worth to modernize/update some structures and capabilities of the current adapter state. I have a lot of ready-to-use code floating around which might be useful. However, it's a preCICE project, so what do others think about these features:

• merge both solver in a single executable instead of two. Do not merge the codes itself, but rather bundle the codes together. In the long run, a base class implementation for the time loop might be useful as well
• add a separate CaseBase interface and a derived class for each test case (i.e. mesh and BCs) in order to reduce the current duplication between both solvers
• add a unit like GH test which tests each solver against a cpp solverdummy (for contribution)
• add a functionality for reading and writing on quadrature points in addition to DoFs
• add a functionality for writing data on equidistant meshes
• add a functionality to automate the creation of an output directory for simulation data

[uekerman]

Good points!

merge both solver in a single executable instead of two. Do not merge the codes itself, but rather bundle the codes together. In the long run, a base class implementation for the time loop might be useful as well
add a separate CaseBase interface and a derived class for each test case (i.e. mesh and BCs) in order to reduce the current duplication between both solvers

Yes, I think it's a good idea to merge both solvers. Also the building routines. Ideally, we should be able at runtime to switch between linear and nonlinear.

add a unit like GH test which tests each solver against a cpp solverdummy (for contribution)

A test would be good, but I am not sure whether testing against a cpp solverdummy is the right way to go. Better would be to either mock preCICE or do unit tests for all functions which are not using preCICE.
@BenjaminRodenberg is the expert on mock testing. We use this already in the FEniCS adapter and (open and currently stale PR precice/openfoam-adapter#122) in the OpenFOAM adapter.

add a functionality for reading and writing on quadrature points in addition to DoFs
add a functionality for writing data on equidistant meshes

Both could be interesting eventually, but low prio in my opinion right now.

add a functionality to automate the creation of an output directory for simulation data

"Low effort, low gain" in my opinion. No prio, but should also not take long.

[MakisH]

add a functionality to automate the creation of an output directory for simulation data

I upvote 👍, especially since this would make the cleaning (and the user experience) more consistent.

[MakisH]

Would it make sense to break this one into smaller issues? If something is easy, we could mark it as "good first issue" then.