NorESM2-LM Z-axis and mask

[ledm]

The NorESM2-LM Z-axis units are in density units, rho in kg m^-3.

While I'm not sure whether this is a standards compliance failure, it certainly makes sense to write a fix to convert the density into more common z axis units: depth or pressure. I had previously thought that density depended on temperature, salininty & pressure which would make creating a fix a fairly complex issue. Perhaps @zklaus or @jvegasbsc knows of a more straightforward equation?

I've also found some strange behaviour in the model behaviour. I don't fully understand this behaviour, as I don't understand how a density z-axis works, so perhaps someone can help me understand. To explain why I'm confused, I'll use the file on jasmin:

• /badc/cmip6/data/CMIP6/CMIP/NCC/NorESM2-LM/historical/r1i1p1f1/Omon/thetao/gn/latest/thetao_Omon_NorESM2-LM_historical_r1i1p1f1_gn_186001-186912.nc

and look at the point (13, 290), which is (77S, 180.5E.), which is in the Southern ocean near Antarctica. The strange behaviour is with the temperature masks:

• If you look along the z axis, for instance in the water column (0, :, 13, 290):, there's water at the surface, then a masked region, then more water and a masked region. Does this mean that ice doesn't float in this model?

>>> c.data[0, :, 13, 290]
masked_array(data=[1.5298066139221191, 1.4884201288223267, --, --, --, --,
                   --, --, --, --, --, --, --, --, --, --, --, --, --,
                   1.7477706670761108, 1.8460874557495117,
                   1.8278450965881348, 1.613585114479065,
                   1.1960657835006714, 1.1990944147109985,
                   1.1253836154937744, 0.9993360042572021,
                   0.8532164096832275, 0.638198971748352,
                   0.4565475583076477, 0.23463541269302368,
                   0.025913620367646217, -0.17937014997005463,
                   -0.36640700697898865, -0.5377004146575928,
                   -0.6983621120452881, -0.896456778049469,
                   -0.8937646746635437, -0.8754621148109436,
                   -1.0617223978042603, -1.1499974727630615,
                   -1.005820631980896, -1.0168300867080688,
                   -1.1161129474639893, -1.183548092842102,
                   -1.233231544494629, -1.268554925918579,
                   -1.3060572147369385, -1.3390512466430664,
                   -1.365854024887085, -1.3898261785507202, --, --],
             mask=[False, False,  True,  True,  True,  True,  True,  True,
                    True,  True,  True,  True,  True,  True,  True,  True,
                    True,  True,  True, False, False, False, False, False,
                   False, False, False, False, False, False, False, False,
                   False, False, False, False, False, False, False, False,
                   False, False, False, False, False, False, False, False,
                   False, False, False,  True,  True],
       fill_value=1e+20,
            dtype=float32)

• However, at the same point at the end of this file, (-1, :, 13, 290), the sea floor becomes much shallower! This doesn't make sense to me, as the z axis doesn't vary with time, the rho is a fixed 1D array!

masked_array(data=[0.46962690353393555, 0.31001922488212585, --, --, --,
                   --, --, --, --, --, --, --, --, --, --, --, --, --, --,
                   --, --, --, --, --, 1.910569429397583,
                   2.874126672744751, 2.124772310256958,
                   2.432654619216919, 1.6376512050628662,
                   1.4526057243347168, 0.9151172041893005,
                   0.6075135469436646, 0.27238935232162476,
                   -0.04585791751742363, -0.3239957392215729,
                   -0.8409612774848938, -0.7318549752235413,
                   -0.9377536177635193, -0.9377527832984924,
                   -0.6493227481842041, -0.7179690003395081,
                   -0.7744532823562622, -0.8318480849266052,
                   -0.890520453453064, -0.9372105598449707,
                   -0.9872353076934814, -1.0290050506591797,
                   -1.037105679512024, --, --, --, --, --],
             mask=[False, False,  True,  True,  True,  True,  True,  True,
                    True,  True,  True,  True,  True,  True,  True,  True,
                    True,  True,  True,  True,  True,  True,  True,  True,
                   False, False, False, False, False, False, False, False,
                   False, False, False, False, False, False, False, False,
                   False, False, False, False, False, False, False, False,
                    True,  True,  True,  True,  True],
       fill_value=1e+20,
            dtype=float32)

Weird, right?

[valeriupredoi]

so I see the units are in degC so those need to change to K, but I also see the first point of the latitude points array is:

[250.5 251.5 252.5 253.5 254.5 255.5 256.5 257.5 258.5 259.5 260.5 261.5
 262.5 263.5 264.5 265.5 266.5 267.5 268.5 269.5 270.5 271.5 272.5 273.5
 274.5 275.5 276.5 277.5 278.5 279.5 280.5 281.5 282.5 283.5 284.5 285.5
 286.5 287.5 288.5 289.5 290.5 291.5 292.5 293.5 294.5 295.5 296.5 297.5
 298.5 299.5 300.5 301.5 302.5 303.5 304.5 305.5 306.5 307.5 308.5 309.5
 310.5 311.5 312.5 313.5 314.5 315.5 316.5 317.5 318.5 319.5 320.5 321.5
 322.5 323.5 324.5 325.5 326.5 327.5 328.5 329.5 330.5 331.5 332.5 333.5
 334.5 335.5 336.5 337.5 338.5 339.5 340.5 341.5 342.5 343.5 344.5 345.5
 346.5 347.5 348.5 349.5 350.5 351.5 352.5 353.5 354.5 355.5 356.5 357.5
 358.5 359.5   0.5   1.5   2.5   3.5   4.5   5.5   6.5   7.5   8.5   9.5
  10.5  11.5  12.5  13.5  14.5  15.5  16.5  17.5  18.5  19.5  20.5  21.5
  22.5  23.5  24.5  25.5  26.5  27.5  28.5  29.5  30.5  31.5  32.5  33.5
  34.5  35.5  36.5  37.5  38.5  39.5  40.5  41.5  42.5  43.5  44.5  45.5
  46.5  47.5  48.5  49.5  50.5  51.5  52.5  53.5  54.5  55.5  56.5  57.5
  58.5  59.5  60.5  61.5  62.5  63.5  64.5  65.5  66.5  67.5  68.5  69.5
  70.5  71.5  72.5  73.5  74.5  75.5  76.5  77.5  78.5  79.5  80.5  81.5
  82.5  83.5  84.5  85.5  86.5  87.5  88.5  89.5  90.5  91.5  92.5  93.5
  94.5  95.5  96.5  97.5  98.5  99.5 100.5 101.5 102.5 103.5 104.5 105.5
 106.5 107.5 108.5 109.5 110.5 111.5 112.5 113.5 114.5 115.5 116.5 117.5
 118.5 119.5 120.5 121.5 122.5 123.5 124.5 125.5 126.5 127.5 128.5 129.5
 130.5 131.5 132.5 133.5 134.5 135.5 136.5 137.5 138.5 139.5 140.5 141.5
 142.5 143.5 144.5 145.5 146.5 147.5 148.5 149.5 150.5 151.5 152.5 153.5
 154.5 155.5 156.5 157.5 158.5 159.5 160.5 161.5 162.5 163.5 164.5 165.5
 166.5 167.5 168.5 169.5 170.5 171.5 172.5 173.5 174.5 175.5 176.5 177.5
 178.5 179.5 180.5 181.5 182.5 183.5 184.5 185.5 186.5 187.5 188.5 189.5
 190.5 191.5 192.5 193.5 194.5 195.5 196.5 197.5 198.5 199.5 200.5 201.5
 202.5 203.5 204.5 205.5 206.5 207.5 208.5 209.5 210.5 211.5 212.5 213.5
 214.5 215.5 216.5 217.5 218.5 219.5 220.5 221.5 222.5 223.5 224.5 225.5
 226.5 227.5 228.5 229.5 230.5 231.5 232.5 233.5 234.5 235.5 236.5 237.5
 238.5 239.5 240.5 241.5 242.5 243.5 244.5 245.5 246.5 247.5 248.5 249.5]

is this right? I forgot how these ocean grids look like.

[zklaus]

That is weird! Note the comment on the thetao variable:

thetao:comment = "Please note that the layer depth information is stored separately in "zfull" and "zhalf" while approximate layer density values are stored together with "msftmrhoz"., CMIP_table_comment: Diagnostic should be contributed even for models using conservative temperature as prognostic field."

So the depth information is given in two completely independent variables, namely (Omon, zfullo) and (Omon, zhalfo). Unfortunately, they are not on jasmin at the moment. Maybe we should request them and somehow write a fix that incorporates that information into the cubes? I cannot check the data itself right now, so I cannot say if this has any bearing on the weird mask behaviour.

[ledm]

V: I think the fix already addresses the issues there. At least, I haven't found that either iris or ESMValTool has trouble loading and preprocessing these datasets (aside from the depth issue).

Thanks Klaus! Good spot, I hadn't realised that models were even allowed to do that. Every new model I look at comes with it's unique set of exceptions to the rules.

[tomaslovato]

@ledm @zklaus
I've been working on this dataset for a while and I used NorESM2-LM ocean 3D data provided on a regular grid format gr (while 2D variables are provided only on the native grid gn). The only issue I found is that we cannot mix in the same recipe two types of grids for the same model, like for example analyzing both 2D and 3D ocean variables.
Probably, it would be more rational to use regular data provided by the originator instead of recomputing them from the native grid files, at least for ocean 3D vars.