Benjamin Uekermann

So far we have not considered such changes to be breaking. I would not change this now. I will remove the label. Please protest if you strongly disagree.

When touching this part of the code again, I would vote for removing the structure: https://github.com/precice/precice/blob/70a2362a6d1e30d9842c589405a79a54c41b11b2/src/cplscheme/BaseCouplingScheme.cpp#L796 Instead, one could ask the acceleration "do you have specialized data fields to write?"....

* How to work with duplicated vertices and ghost layers is a problem, where we at some point need a decent solution. Potentially within the scope of @DavidSCN 's thesis....

makes sense 👍

Could you please describe the use case as far as you remember? And also give a small code example? If I understand correctly, `resetMesh()` could then be a bit confusing,...

Thanks! In such examples, it could still be more efficient to define a larger access region and redefine it less often. But we cannot know without testing :)

> The user queries vertices via getMeshVertexCoordinatesAndIDs. In case the received mesh changes, but the access region remains unchanged, the user has no awareness of potential changes, unless he uses...

I think we still have some misunderstandings. > > or we forbid combining allow-remeshing with direct access momentarily. > Well, the issue intends to enable this right? No. This issue...

> From what I understand, we have now option 1) (using resetMesh) or option 3) (introducing a new API function). For me, 3) introduces less potential for misunderstandings. > A...

I think I understood the problems you describe. These are indeed tricky. Probably, we need to have a careful look at the applications that actually need such a feature to...