BenjaminRodenberg
commented
2 years ago Generally sounds like a good plan. One thing that alarmed me a bit:
When calling
eval(), we must provide the list of vertices and the cells where they live (e.g. "sample function at point (0.5, 0.7) assuming the point is in cell 14").
You are talking about the following API here, right? scalar_function.eval([x,y,z],cell_id)
Why is this necessary? Is this the normal use of the eval() function or is this a special preCICE thing which makes using the function more complicated? I just imagine that this might higher the entry barrier for new users. Currently, I don't understand from where I should know the cell ID. Is there a way to also have a (less performant, of coure) eval() function that saves you as a user the additional work of finding out about the cell? Example signature: scalar_function.eval([x,y,z])
(after looking at the code I understood that the eval() function already requires the user to provide the cell, so it's not really an issue of this PR, so you can also ignore it here and we discuss this elsewhere, where it fits)
boris-martin
(Merging on #1 as it relies on it, but deserves a separe discussion)
Fixed the bug where writing vector data failed. More generally, I rewrote the data writing code to be more flexible. Instead of deciding whether to look at DOFs or geometrical vertices then doing ugly conversion, we simply look where the preCICE vertices are located and evaluate (
Function.eval()) the function at these points. So if at some point we decide to switch from mesh-based mapping to DOF-based mapping, nothing to change here :)Also fixed a bug where
determine_function_typereturned the wrong result. New implementation is shorter and simpler.I removed the old
convert_fenicsx_to_precicefunction as new ones are used.Tests were adapted, and now the write_vector_data test passes.
When calling
eval(), we must provide the list of vertices and the cells where they live (e.g. "sample function at point (0.5, 0.7) assuming the point is in cell 14"). The cells are computed once at initialization, so actual evaluation is pretty efficient (there is no nearest-neighbor like search of the matching cell at each call).