openfoam-adapter
openfoam-adapter copied to clipboard
precice
Wrong Assertion for nearest projection mappings
At the time we implemented the nearest projection mapping, we asserted, that it is not used in FSI simulations, since there, the Solid participant needs to provide connectivity.
However, after introducing #125 , this is not valid any more, since we can use nearest-projection mappings for stress data.
https://github.com/precice/openfoam-adapter/blob/b1d80efe3c2ec964f157687753a675dd4502dba7/Adapter.C#L150-L159
Either we should remove this Assertion completely or just raise a warning, that this is only relevant for FSI in combination with stress data (which is currently only supported by our deal.II adapter).
Good point.
This is currently a warning + trigger exit. A rewording of the warning and removing the return false should do the job.
Yes sure, there is not that much work included. The main question for me is here: Should we raise a warning like 'you can just use FSI and nearest projection in combination with stress data' or should we just remove it completely, assuming that people know, what they are configuring?
I would not rely on the sanity of the user, there are many reasons on why one can misconfigure this. If they misconfigure it, I am not sure if preCICE will complain, so they will falsely think they are doing an NP mapping. In any case, the issue will be obscure.
We could still make the error more specific and move into the write/read methods of Force: https://github.com/precice/openfoam-adapter/blob/b1d80efe3c2ec964f157687753a675dd4502dba7/FSI/Force.C#L179
I am not sure if preCICE will complain
In case no connectivity is provided, preCICE raises a warning, that it falls back to a NN mapping.
We could still make the error more specific and move into the write/read methods of Force:
I agree in general, but let's try to place it somewhere, where it is not asserted in every iteration i.e. not in the write methods directly but e.g. in the constructor, if possible.
In the constructor it would be the best, but it currently does not have enough information. In any case, we should refactor this part in the future to not need to pass the connectivity flag through every function.
We currently have such condition checks in many write/read functions (look e.g. here), so I would not worry too much, if we can't avoid it.