search

pwolfram / MPAS-Model

Repository for MPAS models and shared framework releases.
Other
1 stars 1 forks source link

Append instantaneous velocity to lagrPartTrack output #28

Open bradyrx opened 4 years ago

bradyrx commented 4 years ago

@pwolfram, I think it would be great to have an option to append the instantaneous velocity fields to lagrPartTrack output. I.e., the velocities that are interpolated to the particle position to advect them. In isopycnal particles, I imagine this would just be one value. In passive, maybe this is u,v,w or just magnitude.

Context: I'm reading through analysis methods for computing total transport from Lagrangian particles and Drake et al. 2018 (https://agupubs.onlinelibrary.wiley.com/doi/full/10.1002/2017GL076045) mention weighting transport trajectories by instantaneous velocity multiplied by the area of the cell the particle is at (methods, final paragraph).

pwolfram commented 4 years ago

@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.

bradyrx commented 4 years ago

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.

pwolfram commented 4 years ago

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?

pwolfram commented 4 years ago

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.