David Schneider

To summarize once more what we have so far: use tags for each implementation in order to prevent useless attributes belonging only to one of the implementations and an attribute...

> We could make the solver options shorter: direct vs. iterative > > `` > > backend options could also be the implementations: petsc, ginko, Eigen, ... > How would...

> What about merging pou and non-pou? Meaning that we could reconstruct non-pou via pou via specific settings (1 subdomain or similar). This will lead to quite a few useless...

> Is it wise to reuse "acceleration" here? Could this potentially lead to confusion when searching the docs? Good point. Alternatives that come to my mind: executor, back-end, processing, implementation,...

Probably yes (we need to set a device id). The same holds for OpenMP usage (`OMP_NUM_THREADS`) or similar. > Maybe it is a good idea to ignore accelerator-related attributes until...

Let me remark here that https://github.com/precice/precice/issues/1417#issuecomment-1380375728 comes at the cost of default values for the support-radius and the shape-parameter. Right now, we have these attributes only selective depending on the...

What happened with > Not a big problem IMO. 99% of users will not change basis functions, but only copy whatever we say they should use. Using a subtag is...

Discussing in person once more. We decided to not apply this as it is hard to implement and there are no clear upsides.

Closing https://github.com/precice/precice/pull/1152 in order to keep track of the relevant PRs.

> Wouldn't it make sense to log only errors to stdout and everything to the file? Independent of my environment variables, I can't get a similar good output from the...