Repository navigation
Bug Feat request : MOM6 temperature interpolation #773
Description
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
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?
Activity
[-]Bug Feat request : MOM6[/-][+]Bug Feat request : MOM6 temperature interpolation[/+]amrhein commentedon Dec 3, 2024
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 commentedon Dec 9, 2024
Following POP conversion method for QTY_POTENTIAL_TEMPERATURE to QTY_TEMPERATURE:
depth to pressure
potential temperature to sensible (in situ) temperature
feat: model_interpolate for QTY_TEMPERATURE
hkershaw-brown commentedon Dec 10, 2024
just for kicks here is thickness (h) summed up to get depth
hkershaw-brown commentedon Dec 10, 2024
May move this to a separate issue(s)
feat: model_interpolate for QTY_TEMPERATURE
hkershaw-brown commentedon Dec 11, 2024
elemental functions are f95 so no problem standard wise (a612e81)
johnsonbk commentedon Dec 17, 2024
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.