VomMover

[colinjcotter]

Describe the current issue
I want to be able to support moving particles stored as a VOM (Vertex Only Mesh).

Describe the solution you'd like

The proposal is to have a class called VOMMover, which is constructed from a VOM and a vector-valued function containing the new coordinates of the particles.
It has methods:

• new_VOM: returns a new VOM with vertices at those new coordinates
• move_function: takes in a Function on the old VOM and returns a corresponding function on the new VOM

move_function should interpolate from a Function on the old VOM to a Function on the _input_ordering VOM of the old VOM. Then, do a .dat.data copy from that Function to a Function on the _input_ordering VOM of the new VOM, which can be returned.

Describe alternatives you've considered

Additional info

[ksagiyam]

There was a potentially related discussion about composed VOM here: #2936 (comment). If input coordinates of the new_vom is some vector-valued function on the old_vom, move_function could be represented as (using the notation in the linked comment):

func_on_new_vom = new_vom._distribution_sf.bcast(func_on_old_vom)

as parent of new_vom is old_vom, if I understand what move_function is to do correctly. The idea of composed VOM is that we should be able to compose this process if we want to shuffle particles multiple times.

I think we should also note that this process is very similar to that for loading functions using CheckpointFile; we shuffle entities multiple times (redistribute the loaded topology(->distSF) and add partition overlaps(->overlapSF)), and move saved function data, which compares to data on input_ordering, to the product topology.

[dham]

This isn't quite the situation described above because the parent of new_vom isn't old_vom. Instead new_vom and old_vom share a parent mesh. This is important because you still need to be able to interpolate between new_vom and the parent (non-vom) mesh.

[colinjcotter]

@jshipton said that she has code for this!

[ksagiyam]

So, I was not clear. Yes, they share the same parent non-vom mesh, while new_vom now carries new "parent", which I termed _distribution_parent in the linked comment, which is the old_vom.

[drhodrid]

This is also very high on our "Christmas" list!