update cap to receive u_surf,v_surf on C-grid

[DeniseWorthen]

• fixes update NUOPC cap to export C-grid velocities and slopes #170

[sanAkel]

@DeniseWorthen can you not make use of https://github.com/mom-ocean/MOM6/blob/f5ae5cfeb1ec726af655041acb3d10a51a48c689/config_src/drivers/FMS_cap/ocean_model_MOM.F90#L1183?

If it is only available in the fms_coupler, extending to the NUOPC is trivial, no?

[DeniseWorthen]

@sanAkel Thanks. It doesn't appear that routine is ever called anywhere in MOM6. It looks like the FMS cap uses an analog to what the NUOPC cap has, which is the convert_state_to_ocean_type routine

MOM6/config_src/drivers/FMS_cap/ocean_model_MOM.F90

Line 840 in b4d9a23

subroutine convert_state_to_ocean_type(sfc_state, Ocean_sfc, G, US, patm, press_to_z)

The problem I ran into is not being able to add additional elements to the ocean_public_type (I couldn't get it to compile) and given this comment I'm not sure I should try:

!> This type is used for communication with other components via the FMS coupler.
!! The element names and types can be changed only with great deliberation, hence
!! the persistence of things like the cutesy element name "avg_kount".
type, public ::  ocean_public_type
....

The current solution is able to reproduce B4B the current RTs (with the exception of HAFS) if we leave the two stagger definitions at their current values (A).

[sanAkel]

We should be able to those "helper" functions to public types to extract another stagger.

I added them (or extended) in the fms coupler.

[DeniseWorthen]

@sanAkel I can try again to explicitly add two more surface velocities to the ocean_public. It simplifies the changes required in the cap a bit, but probably by less than what you might expect.

[sanAkel]

@sanAkel I can try again to explicitly add two more surface velocities to the ocean_public. It simplifies the changes required in the cap a bit, but probably by less than what you might expect.

Whatever is easiest and to maintain!

[sanAkel]

@DeniseWorthen Are you already testing the c stagger? If so, I have following suggestion.

As I understand it,

1. We will always want to pass to the ocean everything on A-stagger.
2. Whereas the ocean can return currents on different staggered grids.

To make sure the logic for 1 is "matched" with whatever it is that is set at run time- you never know what some random user does! So I did it this way..

Similarly for 2.

[DeniseWorthen]

@sanAkel The ocean will always get the forcing on the A-grid (WIND_STAGGER=A) because that is where the forcing ->OCN is calculated. In icy water, that forcing is a merge of the ocn-atm and ocn-ice forcing.

The OCN will always return the U,V on the A-grid for use by atm/datm to calculate net surface stress and for WAV to do whatever it does w/ the ocean currents.

Because MOM and CICE are always identical grids, we could potentially send extra MOM6 variables on the C-grid directly to CICE on the C-grid and that would be "better". However, now that I have the two cases working in a test configuration, I haven't yet been able to verify that this idea is in fact better (or at least better enough to justify the code modifications). I will update this issue w/ some figures (soon-ish).

However, I'm still not entirely clear on what CICE means by C-grid dynamics. For example, in the CICE history files we now have variables like the U,V on the north face and the U,V on the east face. That makes me imagine that the C-grid implementation is essentially the B-grid (co-located U,V on corners) where each face now has a pair of velocities shifted from the corner to the mid-point of an adjacent face.

[sanAkel]

@sanAkel The ocean will always get the forcing on the A-grid (WIND_STAGGER=A) because that is where the forcing ->OCN is calculated. In icy water, that forcing is a merge of the ocn-atm and ocn-ice forcing.

The OCN will always return the U,V on the A-grid for use by atm/datm to calculate net surface stress and for WAV to do whatever it does w/ the ocean currents.

@DeniseWorthen Your ⬆️ plan and description sounds good.

However, I will once again suggest to add a check within in the (NOUPC) cap that the in (out) stagger set via MOM_input (at run time) is indeed A (A). This check seems redundant but that will simply rule out anyone using the system in an unintended manner like you just discovered with HAFS and folks trying within RTOFS group.

(As you stated earlier in a related issue elsewhere) The sea ice stagger (C) can not be tested in the above fashion because MOM_input anyway lets you specify only one option for both in (wind) and out (surface) staggering.

It is conceivable that for now you can default ocean ➡️ ice stagger to A and create an option for C. That way the answers will be preserved.

(When that option is triggered, then you ask MOM to return C staggered currents.)

And the testing for the ⬇️ and whatever else can proceed.

Because MOM and CICE are always identical grids, we could potentially send extra MOM6 variables on the C-grid directly to CICE on the C-grid and that would be "better". However, now that I have the two cases working in a test configuration, I haven't yet been able to verify that this idea is in fact better (or at least better enough to justify the code modifications). I will update this issue w/ some figures (soon-ish).

However, I'm still not entirely clear on what CICE means by C-grid dynamics. For example, in the CICE history files we now have variables like the U,V on the north face and the U,V on the east face. That makes me imagine that the C-grid implementation is essentially the B-grid (co-located U,V on corners) where each face now has a pair of velocities shifted from the corner to the mid-point of an adjacent face.

[DeniseWorthen]

@sanAkel My current implementation in CICE/MOM/CMEPS does reproduce current baselines when the settings mimic the current default (once HAFS fixes their MOM_input).

I do have some minimal inconsistency checks, but I can probably add additional checking. This would involve making CICE "aware" of what MOM6 is doing and vice-versa. But at some point, the user has to be responsible for knowing what they're doing ;-).

[sanAkel]

We should echo that (you are on your own!) at run time!