Open brownbaerchen opened 2 months ago
Huh, interesting.. you're right, the transfer operations are not as generic as I thought. For mesh_to_mesh
I understand this, but are your sure about mesh_to_mesh_fft
?
👍 for the first item.
Huh, interesting.. you're right, the transfer operations are not as generic as I thought. For
mesh_to_mesh
I understand this, but are your sure aboutmesh_to_mesh_fft
?
No, I think mesh_to_mesh_fft
is fine actually. I got stuff mixed up ;)
I started looking into the transfer operators a little bit and noticed some issues. I will collect what I find here because I don't know if I have time to fix everything.
Side effects of
MultiComponentMesh
First of all, there are some side effects of the implementation of
imex_mesh
viaMultiComponentMesh
. I have seen, for instance here:However, because an object is an instance of all classes its own class is derived from, an
imex_mesh
object is also an instance ofmesh
and the wrong condition will be entered. I expect we need to be mindful of this distinction throughout the code, not just in the transfer classes. I suggest instead:The
type
function contains no information about inheritance and by using__name__
, we can check against a string and avoid importing the data type. This will be handy for GPU agnostic code. Eventually, I wantif type(G).__name__ in ["mesh", "cupy_mesh"]:
.Want non-normalised grids
I tested the order of interpolation and restriction for some classes. Here are some limitations I found:
mesh_to_mesh
interpolation and restriction work only for grids normalised to 1Feel free to check the boxes after a respective fix. Let me know when you find more restrictions or add them to this issue yourself.