Bug Feat request : MOM6 temperature interpolation

[hkershaw-brown]

Use case

The MOM6 model_mod was made super naively (by yours truly).
Currently it only interpolates a QTY if the QTY is in the state vector.
This is not sufficient for observations.

Filter output

This is world obs, with MOM6 only for the North Atlantic, so load of fails. But all temperature obs fail.
Side note: I need to trim the obs by region for CROCODILE.
The temp obs are all fails (because not QTY_TEMPERATURE)

There are some salinity fails, not sure if this is bugs or run-of-the-mill fails?

Required interpolations

Required interpolation QTY - note not exhaustive, this is just looking at what is in POP. There may be way more. Also I don't know the difference between the various temperatures, so watch out.

• QTY_TEMPERATURE
• QTY_SEA_SURFACE_ANOMALY - maybe this can be direct from ave_ssh?

      double ave_ssh(Time, lath, lonh) ;
               ave_ssh:long_name = "Time average sea surface height" ;
               ave_ssh:units = "meter" ;
               ave_ssh:checksum = "17D219172997BA46" ;

• QTY_SEA_SURFACE_PRESSURE (units? POP v MOM6)

Is your feature request related to a problem?

Failing temperature forward operators.

Describe your preferred solution

step one: learn how temperature works in models.

step two(?):
In MOM6 We don't have depth, we have layer thickness so I'm not sure if I can just rip out the POP calculations and use in both MOM6 and POP (even assuming the units conversion is not a problem).

MITgcm_ocean has PTMP as QTY_TEMPERATURE
'PTMP', 'QTY_TEMPERATURE',

DART/models/MITgcm_ocean/trans_mitdart_mod.f90

Lines 382 to 383 in 55eaf62

	TVarID = define_variable(ncid,"PTMP", nf90_real, all_dimids, MITgcm_3D_FIELD)
	call add_attributes_to_variable(ncid, TVarID, "Potential Temperature", "C", "degrees celsius")

Describe any alternatives you have considered

Why doesn't obs_def_mod take care of the mapping between observation and qty for things like:
potential temp, salinity, local pressure -> sensible temp? Is this a unit disaster (salinity, pressure, etc) waiting to happen when you swap ocean models?

[amrhein]

The differences between in situ and potential temperature should be pretty small in a lot of the ocean, especially in the upper ocean where most of our obs are, see e.g. the profile in figure 1 here. Can you plot the model-data misfit to make sure it's not a K vs C issue?

That said I think we'll still want to do the calculation to potential temp (maybe MITgcm folks figured it didn't matter for their obs?). I think we do have depth in MOM6 (we need this for the FOs anyway, right?) so maybe it's a matter of checking that we're using the right var and then testing out the POP code as a first step.

[hkershaw-brown]

Following POP conversion method for QTY_POTENTIAL_TEMPERATURE to QTY_TEMPERATURE:

depth to pressure
potential temperature to sensible (in situ) temperature

[hkershaw-brown]

just for kicks here is thickness (h) summed up to get depth

[hkershaw-brown]

May move this to a separate issue(s)

1. Surface obs - do these need to be treated differently? Probably, e.g. skip the vertical. Maybe also conversion needed?
2. Ocean obs - are these only in VERTISHIEIGHT/VERTISURFACE? Assuming this at the moment, should force in model_interpolate (like POP) to avoid nonsense calculations, e.g. pressures getting treated as depth.

[hkershaw-brown]

elemental functions are f95 so no problem standard wise (a612e81)

[johnsonbk]

Salinity
MOM6's salinity are in units of parts per thousand which, from a very technical perspective, is not exactly equivalent to Practical Salinity Units (PSU). The Practical Salinity Scale was invented in order to uniformly calibrate in situ salinometers, which use electrical conductivity to infer salinity concentration. This calibration was dependent on the relative concentrations of ions in seawater (Na, Mg, K, Ca, S, Cl) which varies between ocean basins. The Practical Salinity Scale sidesteps this problem standard using a lab-created mixture of H20, K, and Cl. However, the error caused by ion variation is on the order of 0.02 psu, so for the sake of the MOM6 interface, it's sensible to implement the interface using ppt equivalent to grams of salinity per kilogram of seawater.

Depth
I've just run MOM6 compiled from CESM2.1.5 using the TL319_t232 resolution and the G_JRA compset. The vertical coordinate of the restart file is "Layer" measured in units of meters. The dpth2pres subroutine seems to correctly convert depth in meters to pressure in bars. Oceanographers typically use dbars just a matter of convenience because 1 dbar of pressure ≈ 1 meter of depth.