I would like to collect some opinions on the mapping topic for local RBFs. Currently, the user has the option to define either a support radius or a shape parameter through a global variable in the xml config. A good choice is, however, usually not available for the user, even if he or she knows ‘enough’ about the mapping method, e.g. I would like to cover 4 vertices in each direction in my local RBF function in order to get a good trade off. The reason is mainly the missing information of the vertex distance in the coupling mesh.
I know we have some information on the website including a script and the reference paper, but using a script before each run is tedious.
However, the information is usually available in the solver (and or adapter). Would it be possible to add an option in the interface in order to determine the support radius/shape through the solverinterface?
I think it would simplify things and it would enable to spend some thoughts once when implementing a suitable algorithm in the adapter rather than each time when starting a simulation, e.g.
my_average_radius = // my algorithm
SolverInterface.set_support_radius(my_average_radius)
Using this method, the shape parameter definition would be independent of the global refinement level (or similar things) of my mesh (say you want to test on a coarse mesh before starting the real refined case).
@KyleDavisSA wanted to work on an approach that allows to compute the support radius adaptively within preCICE. So, no more user input would be necessary. @KyleDavisSA could you please give more details or link to a paper, where the method is described?
I think you touch on a few good points there. With the local RBF’s we can either specify a support radius OR a shape parameter. A good example is the Guassian RBF, where we need to specify a shape parameter. A good starting point is modifying it to accept a support radius and converting this to a shape parameter.
Regarding the idea of trying to “cover 4 vertices”, this has a few potential difficulties. 1) the mesh might not be distributed equally in all dimensions, and 4 vertices is also too few to get any reasonable level of accuracy (I know this number is just an example ). 2) How do you define 4 vertices in each direction, when each vertex is situated within all dimensions? i.e. 1 vertex might be the point chosen for 2 different directions. 3) Lets say we increase this from 4 to 40 points around our vertex of interest. How do we quickly find these 40 points? We have the rtree structure in preCICE, but this could become very expensive for large meshes (kNlogN as far as I know). These methods may also result in non-symmetric matrices in preCICE, needing changes to building these matrices and interfacing with PETSc. This problem is more pronounced for highly non-uniform meshes.
Lastly, how can we choose which shape parameter is best for our mesh and data value at these points? Which shape parameter is best? We could test an arbitrary test function on both input and output mesh, but then our shape parameter might not be applicable. There are other methods that we can use for estimating the mapping error (actually, the interpolation error by using only the input mesh and data), but this can only be done for small meshes (see Leave one out cross validation).
I am currently looking into these and definitely think the points you have mentioned above would be good additions to preCICE. I can find some papers and post some links
thanks a lot for your comprehensive answer. I was not aware that there is some work in progress.
The documentation on our website says:
To have a good trade-off between accuracy and efficiency, the support of each basis function should cover three to five vertices in every direction
maybe we should explain it there more in detail. The ‘non-equally distributed’ point is something you should probably handle as a user/in the adapter.
I think you describe potential solutions from solving the problem within preCICE without additional knowledge. My general idea was to keep the methods as they are in preCICE and just provide an additional interface in the adapter in order to determine the support radius (or whatever) in the adapter (more from a user perspective). I understand that determining all these things in preCICE becomes tricky due to the lack of knowledge.
). 2) How do you define 4 vertices in each direction, when each vertex is situated within all dimensions? i.e. 1 vertex might be the point chosen for 2 different directions. 3) Lets say we increase this from 4 to 40 points around our vertex of interest. How do we quickly find these 40 points? We have the rtree structure in preCICE, but this could become very expensive for large meshes (kNlogN as far as I know). These methods may also result in non-symmetric matrices in preCICE, needing changes to building these matrices and interfacing with PETSc. This problem is more pronounced for highly non-uniform meshes.