MOM6 icon indicating copy to clipboard operation
MOM6 copied to clipboard

Vertical velocity estimates and ALE remapping

Open hmkhatri opened this issue 4 years ago • 13 comments

We are looking into the layer-wise momentum budget in MOM6 in z* coordinate. All terms in the momentum budget are available as diagnostics in MOM6 except the dia-surface velocity acceleration term. Is it possible to compute this term online in the remapping step? Following the same, can we estimate vertical velocity online and output as a diagnostic in MOM6?

hmkhatri avatar May 15 '20 23:05 hmkhatri

wmo is currently calculated offline as the convergence of umo and vmo cumulatively summed from the bottom up. While we had originally sanity checked that the vertically summed wmo matched PmE, we did not include a term that accounts for the stretching of the z* coordinate due to changes in SSH. Additionally, it is possible that we are making a systematic error because the averages of any nonlinear terms are assumed to be zero.

The implementation of this diagnostic online is non-trivial because the calculation of wmo depends on the remapped values of umo and wmo which are only calculated during post_data and unavailable afterwords. How to implement this will require some discussion on how to extend the diagnostics framework to account for these dependencies.

ashao avatar Jun 11 '20 17:06 ashao

@hmkhatri asks two questions. @ashao answered the second.

The remapping term is the first question. Does anyone have a sense for whether we can get the remapping term diagnosed online for the velocity equation, in a manner similar to how we now get the analogous term for the tracer budgets?

StephenGriffies avatar Jun 11 '20 18:06 StephenGriffies

I have no solution, but more questions to ask. First though a clarification:

the analogous term for the tracer budgets?

@StephenGriffies you're referring to the vertical remapping tendency for a tracer C diagnosed as:

C_vert_remap_tendency = C_post_ALE*h_post_ALE - C_pre_ALE*h_pre_ALE

and @hmkhatri and @StephenGriffies are wondering what an analogous term is for an implied vertical velocity.

I almost feel like this is a broader question about how to transform between the vertical momentum equation in the Leclair and Madec flavor of ALE, vs. the regrid/remap flavor.

My gut reaction is that it will be hard to define this transformation because of the vertically non-local nature of the regrid, remap operation. For example. Let's say that you went from the situation diagram where at t=1, the k=1,2 layers have vanished due to the regridding. For a tracer, this is an easy tendency to calculate as given by the above equation- the entire tracer content in the vanished layers has been depleted.

The velocity of an interface can be calculated as the difference in its position pre and post ALE, but I don't know how you would define the velocity across the interface let alone its acceleration.

@hmkhatri @StephenGriffies , what are your thoughts on what the accelerations would be in this case?

ashao avatar Jun 12 '20 17:06 ashao

N to M layer remapping is implemented in the code by using max(N,M)+1 interfaces and implies abs(N-M) vanished layers in one or the other.

adcroft avatar Jun 12 '20 19:06 adcroft

The question wasn't necessarily about the N-M mappings, but more about the vertical velocities that's implied by the vanishing of the bottom layers.

w velocity of the second interface is [h(k=2)+h(k=3)]/Delta T IF it's calculated from a fixed frame of reference. My question is what does this mean rom the frame of reference of the interface itself and moreover in the interpretation of the momentum budget diagnostic that @hmkhatri is asking about?

ashao avatar Jun 12 '20 21:06 ashao

Deep down in the algorithm the remapping calculates the change in interface position, which is your w*time step. That's why we need that same number of interfaces in both pictures and represent a change in degrees of freedom with vanished layers. The particular solution for your setup is w(1)=0, w(2)=2, w(3)=1, w(4)=0 which takes your 3 cells of thickness 1 and produces h(1)=3, h(2)=h(3)=0.

adcroft avatar Jun 12 '20 21:06 adcroft

Gotcha, thanks for clarifying. You're referring to the dzInterface that comes from the grid generator, e.g. https://github.com/NOAA-GFDL/MOM6/blob/2179c8813e21811006f96fade03850a8ad09faf1/src/ALE/MOM_regridding.F90#L855-L861

ashao avatar Jun 12 '20 21:06 ashao

So hypothetically, this is already there (without the division by Delta T):

https://github.com/NOAA-GFDL/MOM6/blob/2179c8813e21811006f96fade03850a8ad09faf1/src/ALE/MOM_ALE.F90#L397

ashao avatar Jun 12 '20 21:06 ashao

Yes, and the tendency due to remapping for scalars is https://github.com/NOAA-GFDL/MOM6/blob/2179c8813e21811006f96fade03850a8ad09faf1/src/ALE/MOM_ALE.F90#L838-L855, but a few lines down there is no similar diagnostic for the components of momentum.

adcroft avatar Jun 12 '20 21:06 adcroft

I guess it's kind of redundant to have the remap_cont_2d because it should be 0.

ashao avatar Jun 12 '20 21:06 ashao

@ashao @adcroft I couldn't follow much of the conversation above but it seems to me that acceleration term due to dia-surface velocity can be obtained as a diagnostic to close the momentum budget. Is that correct?

hmkhatri avatar Jun 12 '20 21:06 hmkhatri

Yes, a diagnostic needs to be added as mentioned in https://github.com/NOAA-GFDL/MOM6/issues/1112#issuecomment-643488958

adcroft avatar Jun 12 '20 21:06 adcroft

@hmkhatri please give see if you can write the diagnostic and see if it makes sense. This is encouraging.

StephenGriffies avatar Jun 13 '20 11:06 StephenGriffies