Benjamin Uekermann
Benjamin Uekermann
Another potential application of this feature is motivated by @ahmed-h-elsheikh s case. There we want a parabolic inflow profile on some OpenFOAM geometry by only communicating one value (the max...
I don't think this is a bug, closing. Please re-open if anyone doesn't agree.
> Move the actual basis-function to an attribute I like, but why not also making the backend an attribute? Then, we could define a default in the long run (probably...
Yes, makes sense.
Option 2 sounds too cumbersome to me. Option 1 could be good. How would you then encode PoU? We could make the solver options shorter: `direct` vs. `iterative` ```xml ```...
We still need the `mapping` in the tag: - `mapping:rbf-pou-direct` etc ... but still looks too complicated to me
What about merging `pou` and `non-pou`? Meaning that we could reconstruct `non-pou` via `pou` via specific settings (1 subdomain or similar). In the long run we want that `mapping:rbf` gives...
Discussed in person with @davidscn All mappings have the standard attributes: `from`, `to`, `constraint`. All explicit RBF mappings have the following additional attributes: `basis-function`, `support-radius`, `shape-parameter`. Then, we distinguish: ```xml...
> 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...
> Maybe it is a good idea to ignore accelerator-related attributes until we have a concrete implementation. :+1: