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)