Append instantaneous velocity to lagrPartTrack output about mpas-model HOT 4 OPEN

@bradyrx, we previously had this capability to compute particle diffusivity. But, this increased cost because these values had to be both computed, stored, and then communicated (adding to the main LIGHT bottleneck). This is something we could get backonline, especially given the infrastructure we put together.

The key question-- can you afford additional slowdown at runtime due to having this included?

cc @maltrud to make sure he is engaged in the conversation too.

from mpas-model.

Would this fundamentally be additive slowdown relative to what we already have going? Currently, every two days (in our I/O case), the instantaneous tracer fields are interpolated to the particles and added to the netCDF to be stored. The velocity fields are also interpolated to the particles to advect for the next time step, so couldn't these be stored in the same manner as the tracers? Theoretically I feel like it would be the same I/O bottleneck we have, but of course we'd have to see in practice what it would cost.

I'm only suggesting it since I'm seeing the volume transport computation coming up in the literature so much. Although, the caveat there seems to be you need to densely seed a given grid cell for that volume transport to be conserved. So it would really have to go hand-in-hand with an initialization that densely seeds and resets a specific region of the ocean.

from mpas-model.

If I recall correctly, we aren't super densely seeding and then rapidly resending a portion of the ocean, are we? Ideally, how do you want this to work in practice in terms of horizontal resolution and reset time?

from mpas-model.

The slowdown would be largely due to communication, so if you have X BGC tracers now, it would roughly run something like (X+2)/X longer.

from mpas-model.