Benjamin Rodenberg

When #280 is there, we could actually test these kind input errors that should trigger a preCICE error. We decided to not fix this before we can test it. When...

In the fenics adapter we currently use a [work around](https://github.com/precice/fenics-adapter/blob/1d3258f7a20a44183d020e0770bb715452886f1c/fenicsadapter/fenicsadapter.py#L321-L325), since no bulk actions are available: ``` # Set mesh edges in preCICE to allow nearest-projection mapping for i in...

Let's try to implement this soon and use aliases in the configuration for making it non-breaking. We can deprecate the old configuration tags remove them in the next major release.

This action is removed in the context of #1358. So we will be able to close this issue with v3.

[This code](https://github.com/precice/precice/pull/935/files/0ee5d5af9f5a1393c49812dd6869808a45ce6aeb#diff-77d4c4cc6ff34a09a88b532f34bf52b866f14df95ab2d29643121a460877410cR28-R30) needs an update, if #935 gets merged.

I realized that the same is true for `getMeshVertices` :see_no_evil:

> Makes sense. If not too complicated maybe we could raise a warning if a user initializes data, which is never used. (Serial cpl, first participant sends, no waveform relaxation)...

#1368 now throws a warning, if a serial coupling with waveform order zero is used and `initialize="true"` for initial data sent by the first participant.

> * Moreover, the `SolverInterface` is a class, but I still have to manually call `finalize()` myself. Related discussion: https://github.com/precice/fenics-adapter/pull/59#issuecomment-632575122

Hi @gdenayer, thanks for pointing us to this issue! The fix that you prepared looks correct. I think that originally data initialization was not part of the solverdummies, but generally...