Updating ocean transport plots to include GM+submeso velocity

[alicebarthel]

A note (following up on a discussion with @xylar) that a couple of mpas-analysis tasks need to be updated to use normalTransportVelocity rather than normalVelocity. This can also be done by adding the GM and submeso velocities if they exist in the output.
So far, @xylar and I identified:

• time_series_transport.py is missing the submeso velocity
• the barotropic/SPG streamfunction should also include the total velocity, not just the resolved one.

@xylar suggested this code block as a good example of how to add these, as long as we also add the submeso velocity.

Anyone should feel free to add to this list if you notice other tasks that require correcting.

Note that the velocity plots (e.g. sose transects use velocityMeridional velocityZonal (i.e. resolved velocities) which is not necessarily wrong if we are investigating momentum but it's important to keep in mind that the plots do not include the total transport velocity.

[milenaveneziani]

@alicebarthel, @xylar: could you please elaborate on the use of normalTransportVelocity vs normalVelocity?
Also, I do not believe normalTransportVelocity is standard output.

[milenaveneziani]

At least I do not see it in the v2.1 picontrol simulation.

[alicebarthel]

@milenaveneziani,
As far as I understand: when we calculate GM and/or submeso parameterized velocities, they are added to normalVelocity to form normalTransportVelocity. The latter is then used to do horizontal thickness advection etc.
My point is that when we calculate/plot transport through sections, we need to include the GM and submeso bolus velocities. time_series_transport.py shows a good example of how xylar included the GM bolus velocity (either using normalTransportVelocity if it is available, or rebuilding it using its components). We just need to extend that to also include the submeso MLE velocities.

I'm happy to discuss whether normalTransportVelocity should be standard output. The point to remember is that if we output the GM and MLE velocities, then we can reconstruct the total transport velocity. But maybe it makes more sense to have normalTransportVelocity one of the standard outputs, and output the details of GM and MLE velocities only when we specifically need to break down the various parameterized eddy components?

[milenaveneziani]

Personally, I think it is better to output the single components, because:

1. subsequent (post-processing) computations are more transparent;
2. we can compute quantities (transport, streamfunction) due to the GM component, for example, separately from the total velocity.

Here is what I have in my compute_transport post processing script at the moment, and I quite like it (it should be pretty similar to what we have in time_series_transport):

            if 'timeMonthly_avg_normalTransportVelocity' in ncid.variables.keys():
                vel = ncid.variables['timeMonthly_avg_normalTransportVelocity'][0, edgesToRead, :]
            elif 'timeMonthly_avg_normalVelocity' in ncid.variables.keys():
                vel = ncid.variables['timeMonthly_avg_normalVelocity'][0, edgesToRead, :]
                if 'timeMonthly_avg_normalGMBolusVelocity' in ncid.variables.keys():
                    vel += ncid.variables['timeMonthly_avg_normalGMBolusVelocity'][0, edgesToRead, :]
                if 'timeMonthly_avg_normalMLEvelocity' in ncid.variables.keys():
                    vel += ncid.variables['timeMonthly_avg_normalMLEvelocity'][0, edgesToRead, :]
            else:
                raise KeyError('no appropriate normalVelocity variable found')

my 2c.

[xylar]

@milenaveneziani,

Personally, I think it is better to output the single components, because:

1. subsequent (post-processing) computations are more transparent;
2. we can compute quantities (transport, streamfunction) due to the GM component, for example, separately from the total velocity.

I totally get this but I think we also need to have configurations where we cut down significantly on the ocean output, particularly the 3D output, because it kills the performance. It'd make a big difference to reduce the velocity-related output by 67%!

My proposal to @alicebarthel was that we have some "framework" in MPAS-Analsysis that computes the transport velocity in a standard way and we use that for:

• transport transects
• the barotropic streamfunction
• the MOC
  MPAS-Analysis can first look for the full transport velocities if available and add up the components if not. It can also do sanity checks to make sure the appropriate components are there given the namelist options (e.g. error out if you ran with GM but don't have that component in the output).

The output question is really one for E3SM or E3SM-Ocean-Discussion, rather than here.