Benjamin Uekermann
Benjamin Uekermann
> It would be fascinating to see how these changes affect the runtime of parallel cases in comparison to the PETSc implementation. and we should check CG again as alternative...
Ideally, we should remove all options at the same time, see #1364
I see the appeal of this suggestion in general. I am a bit afraid however that this could lead to mixed-up states, where we always have to distinguish different cases....
> Do you mean the different cases {2d, 3d} x {interface, volume}? That, but also that there could be combinations of the old and the new way: explicit and implicit...
I guess it would be good to try to reproduce the bug with an integration test. In which assertion do we actually run?
In my opinion, it doesn't hurt much if we keep it in the configuration. Maybe even better as it makes it transparent to the user that more data is needed...
I like. Just thinking a bit about the name. As a mathematical term, "adaptive" is sth different. ˋdynamicˋ could be another option or ˋremeshingˋ or ˋallow-remeshingˋ?
I like `static="true"` as well.
I share your observation in principle. Many of the attributes you use above are actually only meaningful for received meshes (`geometric-filter`, `safety-factor`). To have a really clean cut, I would...
> > Will the new file contain data of both interfaces (if same participant) or only of the last run? Or do we create a new file increasing some counter?...