Salinity fixes for Red Sea

[kieranricardo]

CM2 had additional mixing in the Red sea (and other areas) to fix salinity issues. Can the same fixes be applied to MOM6?

[MartinDix]

CM3 is using a newer version of the 1 degree mask than CM2 and has a slightly wider Red Sea and Persian Gulf. Seems it's not enough to keep the salinity in check by itself.

[ofa001]

Hi @MartinDix @kieranricardo Looking at the code yes I think its doable its not relying on any MOM5 specific mixing code I think, just might need updating for the correct variable names being used in MOM6. Dave set up the integer points that represented the locations of the Red Sea and Gulf in a separate subroutine in directory ocean_access (it was called auscom_ice_parameters.F90, as it had other things in it back then but it could be anything now in CM3), he mixed the top 5 levels down to 50m. He then set up clock timings in the main ocean_model subroutine to do the mixing every 12 hours. He then called a specific mixing subroutine which he added to the end of this module (ocean_model.F90) subroutine redsea_gulfbay_hmix_s.

I will have to look at the MOM6 "ocean_model.F90 routine and see where it fits, if it will fit in the same place, its use of more generalized vertical co-ordinates may have changed the names around a bit but I don't remember anything obviously standing out last time, I looked but I haven't done it closely side by side for moving code over. We can also discuss it directly with the ocean folk I guess at the CM3 section of the Ocean workshop, if I get invited :(

[ofa001]

Hi @MartinDix I have had a look at the code, to find the equivalent location to put the change to where we put it in the CM2 MOM5 code its line 969 of MOM.F90 in subroutine step.MOM its between the calls to the ensemble DA system (if switched on) and the check the surface state at the end of the subroutine.

Still need to check the approach to clock timing calls and variable names will all match, as its focussed on 1 degree perhaps we should read the integer values in as a namelist rather than a parameter. F90 file or .h file. Also the ocean team have yet to update any of the MOM6 code. staying with the NCAR ESCOMP version, I guess this change when input it should have an #ifdef ACCESS-CM type flag on it so we can always find it easily.

[ofa001]

HI again, it looks like the parameter that it was happening every 12 hours may not be the case it may be every time step so that makes it easier to implement. It may have been a legacy setting and comment statement.

[ofa001]

@MartinDix For the subroutine redsea_gulfbay_hmix its key inputs are the layer thickness and salinity. The vertical co-ordinate in MOM6 means that there are various variables for "Thickness" in including most likely h and h_dyn, h_new (after regridding?) that need to be used at the end of this time step cycle, I am looking to map where the salinity tracer is the equivalent of T_prog(index_salt) in MOM5 its most likely in a CS% type array but I will keep digging, CS is frequently used for lots of options and variables, 'CS' stands for 'Control structure',
No I found its in 'tv' tv%S based on subroutine step_MOM_thermo, and 'tv' stands for thermodynamic variable.
So once we know which the correct "h" variable is to use probably 'h_new' as thats the new regridded one for the time step, we can put it in the can start considering building a new subroutine but we should check with the local MOM6 experts first.