Bounds of derived variable are not read correctly #3678

schlunma · 2020-03-05T11:43:59Z

Hi guys,

in ESMValTool we found the following issue concerning files with derived variables (in particular atmosphere_hybrid_sigma_pressure_coordinate, see ESMValGroup/ESMValCore#543):

The bounds of the derived variable of model output that is consistent with the CF conventions cannot be read correctly with iris. Here is a minimal example using the nc file that is used on the CF convention webpage (without the optional attributes and the units of A replaced by 1):

netcdf a_new_file {
dimensions:
        eta = 1 ;
        lat = 1 ;
        lon = 1 ;
        bnds = 2 ;
variables:
        double eta(eta) ;
                eta:long_name = "eta at full levels" ;
                eta:positive = "down" ;
                eta:standard_name = "atmosphere_hybrid_sigma_pressure_coordinate" ;
                eta:formula_terms = "a: A b: B ps: PS p0: P0" ;
                eta:bounds = "eta_bnds" ;
        double eta_bnds(eta, bnds) ;
                eta_bnds:formula_terms = "a: A_bnds b: B_bnds ps: PS p0: P0" ;
        double A(eta) ;
                A:long_name = "a coefficient for vertical coordinate at full levels" ;
                A:units = "1" ;
        double A_bnds(eta, bnds) ;
        double B(eta) ;
                B:long_name = "b coefficient for vertical coordinate at full levels" ;
                B:units = "1" ;
        double B_bnds(eta, bnds) ;
        double PS(lat, lon) ;
                PS:units = "Pa" ;
        double P0 ;
                P0:units = "Pa" ;
        float temp(eta, lat, lon) ;
                temp:standard_name = "air_temperature" ;
                temp:units = "K" ;

Reading this file with iris

import iris
print(iris.__version__)
print("")

path = os.path.expanduser('~/a_new_file.nc')
cubes = iris.load(path)
print(cubes)
print("")

cube = cubes.extract_strict(iris.Constraint('air_temperature'))
air_pressure_coord = cube.coord('air_pressure')
print(air_pressure_coord)

gives

2.4.0

/miniconda3/envs/test/lib/python3.7/site-packages/iris/fileformats/cf.py:1074: UserWarning: Ignoring formula terms variable 'PS' referenced by data variable 'A_bnds' via variable 'eta': Dimensions ('lat', 'lon') do not span ('eta', 'bnds')
  warnings.warn(msg)
/miniconda3/envs/test/lib/python3.7/site-packages/iris/fileformats/cf.py:1074: UserWarning: Ignoring formula terms variable 'PS' referenced by data variable 'B_bnds' via variable 'eta': Dimensions ('lat', 'lon') do not span ('eta', 'bnds')
  warnings.warn(msg)
/miniconda3/envs/test/lib/python3.7/site-packages/iris/fileformats/netcdf.py:601: UserWarning: Unable to find coordinate for variable 'PS'
  '{!r}'.format(name))
/miniconda3/envs/test/lib/python3.7/site-packages/iris/fileformats/netcdf.py:601: UserWarning: Unable to find coordinate for variable 'PS'
  '{!r}'.format(name))
0: A_bnds / (1)                        (atmosphere_hybrid_sigma_pressure_coordinate: 1; -- : 2)
1: B_bnds / (1)                        (atmosphere_hybrid_sigma_pressure_coordinate: 1; -- : 2)
2: PS / (Pa)                           (-- : 1; -- : 1)
3: air_temperature / (K)               (atmosphere_hybrid_sigma_pressure_coordinate: 1; -- : 1; -- : 1)

AuxCoord(masked_array(data=[[[3004000.]]],
             mask=False,
       fill_value=1e+20), standard_name='air_pressure', units=Unit('Pa'))

As you can see, the air_pressure coordinate does not have bounds. When the optional attributes A:bounds = "A_bnds" and B:bounds = "B_bnds" are added to the file, iris is able to read the bounds correctly.

The text was updated successfully, but these errors were encountered:

pp-mo · 2020-08-25T10:04:39Z

Just been asked to look at this.
But I'm afraid don't see how we can possibly fix this in Iris.

The original example in the CF conventions does include the bounds attributes. I believe they are only "optional" in the sense that the file isn't actually invalid (by CF rules) without them.

If I put the file into the NERC online CF checker , it gives ...

File name:      a_new_file.nc

Output of CF-Checker follows...

CHECKING NetCDF FILE: /tmp/13135.nc
=====================
WARN: Cannot determine CF version from the Conventions attribute; checking against latest CF version: CF-1.7
Using CF Checker Version 3.1.1
Checking against CF Version CF-1.7
Using Standard Name Table Version 74 (2020-08-04T14:43:55Z)
Using Area Type Table Version 10 (23 June 2020)
Using Standardized Region Name Table Version 4 (18 December 2018)

WARN: (2.6.1): No 'Conventions' attribute present

------------------
Checking variable: eta
------------------

------------------
Checking variable: eta_bnds
------------------
INFO: attribute formula_terms is being used in a non-standard way
ERROR: (4.3.3): formula_terms attribute only allowed on coordinate variables
ERROR: (4.3.3): Cannot get formula definition as no standard_name

------------------
Checking variable: A
------------------

------------------
Checking variable: A_bnds
------------------
WARN: (3): No standard_name or long_name attribute specified
INFO: (3.1): No units attribute set.  Please consider adding a units attribute for completeness.

------------------
Checking variable: B
------------------

------------------
Checking variable: B_bnds
------------------
WARN: (3): No standard_name or long_name attribute specified
INFO: (3.1): No units attribute set.  Please consider adding a units attribute for completeness.

------------------
Checking variable: PS
------------------
WARN: (3): No standard_name or long_name attribute specified

------------------
Checking variable: P0
------------------
WARN: (3): No standard_name or long_name attribute specified

------------------
Checking variable: temp
------------------

ERRORS detected: 2
WARNINGS given: 6
INFORMATION messages: 3

So, I read that as attempting to interpret all the "_bnds" variables as primary data variables, and then complaining that they have no standard_name or units.

Without the linking bounds attributes, I think we cannot safely associate "A_bnds" with "A" (i.e. automatically in code): The only way to do it is to rely on a naming convention which, apart from being a rather weak and fragile approach, is definitely not in the CF conventions. So we would really not be keen on adding that to Iris.

I must say you're not alone in encountering files like this, even in standard model output or even archive data. I was shown some files in the CMIP archive which do not pass the current CF checker -- though they probably did pass the earlier version that was in place when they were submitted. ( I think it may have been invalid units in that case ?).

zklaus · 2020-08-31T12:21:17Z

Hi @pp-mo, thanks for taking a look at this!

Unfortunately, I am afraid it is a bit more than the usual data problems and really is the intended way of encoding things according to CF, not just leniency.

There are extensive discussions on the topic at the ESMValTool repo, the CMOR repo, the old CF trac and probably other places.

The long and short of it is that the formula term variables don't have bounds attributes because they are not auxiliary coordinates and thus the attribute would not have a standardized meaning.

Instead, the connection comes from the formula_terms attribute of the bounds variable of the parametric coordinate variable. Thus no reliance on naming conventions is necessary.

Does this make sense?

pp-mo · 2020-09-08T10:42:11Z

Thanks for explaining @schlunma
Apologies for long silence -- busy elsewhere !

Anyway, I just got a chance to look at this again + I can see you are 100% right 💐
So, this really is a missing feature + does need sorting out.
But unfortunately, in that case it is not a particularly quick thing to resolve, so I think won't make it into Iris 3.0.
( Iris 3 release is now pretty imminent : we are working on it the next week or 2 )

I've re-categorised this release "Iris 3,1" and label "CF 1.6/1.7" for now (though that label could do with a revamp).
I'm hoping we will soon find time to address a number of the outstanding CF issues -- that label hints at a list of them.

bjlittle · 2022-09-30T10:02:35Z

@zklaus and @schlunma is this still a blocker for you guys?

Any sense of priority on this issue from your side?

schlunma · 2022-10-04T09:16:55Z

Hi @bjlittle, this is still relevant for us, but only with a medium priority (we, the ESMValTool devs, assigned priorities to each issue with Feature: ESMValTool here: ESMValGroup/ESMValCore#1738).

At the moment we have a (lenghty) custom solution for this that does the trick, but it would be of course much nicer and cleaner if this would be handled by iris 🚀 Thanks!!

pp-mo · 2022-10-04T09:54:42Z

Hi @bjlittle, this is still relevant for us, but only with a medium priority ... it would be of course much nicer and cleaner if this would be handled by iris 🚀 Thanks!!

Thanks @schlunma.
I think we have this correctly flagged for importance, but it's rather tricky to do + we don't think it can make it into the forthcoming Iris 3.4, early November

schlunma · 2022-10-04T10:01:46Z

No worries at all @pp-mo! Thanks for all your support on ESMValTool-related issues, we really appreciate it 👍

stephenworsley · 2023-03-30T13:03:59Z

@zklaus , @schlunma how important would it be to preserve the form in which the bounds are attached to the variable when round tripping load/save?
It seems like a solution to this problem would involve Iris being able to recognise two ways to connect bounds to a variable:

With a formula on the derived variable and bounds attached to each of the variables it derives from.
With bounds attached to the derived variable and a formula on those bounds which refers to the bounds it derives from.

However, within Iris, there is just one way in which the bounds are attached (which structurally mirrors 1. at the moment). In order to solve this as simply as possible, I would expect that a cube loaded from a file of form 2 would save the same as a cube loaded from a file of form 2 currently does. It may be a seperate issue to make sure that this saved form aligns as closely to the best possible interpretation of CF, but would this be acceptable as a solution for the time being?

schlunma · 2023-03-31T08:10:27Z

Hi @stephenworsley, thanks for working on this, much appreciated!

In my opinion, the priority for ESMValTool would be to be able to read files of form 2 without additional code. So yes, I think your proposed solution would definitely work for us! 👍

It would of course be nice if a CF-compliant file of form 2 actually saves in the same form, but this is only has a secondary priority for us.

trexfeathers · 2024-10-25T16:48:56Z

@schlunma @bouweandela would you say that our own hybrid_height.nc in iris-sample-data is invalid CF? The coordinates that are part of formula_terms have their own bounds attributes.

When we applied the changes in #6190, Iris no longer loads hybrid_height.nc correctly.

schlunma · 2024-10-28T11:53:38Z

@schlunma @bouweandela would you say that our own hybrid_height.nc in iris-sample-data is invalid CF? The coordinates that are part of formula_terms have their own bounds attributes.

When we applied the changes in #6190, Iris no longer loads hybrid_height.nc correctly.

Yes, the text here suggests that this is indeed invald CF:

"If a parametric coordinate variable with a formula_terms attribute (section 4.3.2) also has a bounds attribute, its boundary variable must have a formula_terms attribute too."

This seems to be not the case for hybrid_height.nc:

...
float level_height(model_level_number) ;
                level_height:bounds = "level_height_bnds" ;
                level_height:axis = "Z" ;
                level_height:formula_terms = "a: level_height b: sigma orog: surface_altitude" ;
                level_height:units = "m" ;
                level_height:standard_name = "atmosphere_hybrid_height_coordinate" ;
                level_height:long_name = "level_height" ;
                level_height:positive = "up" ;
        float level_height_bnds(model_level_number, bnds) ;
        float sigma(model_level_number) ;
...

Here is an example of a valid file (taken from the link above):

float eta(eta) ;
   eta:long_name = "eta at full levels" ;
   eta:positive = "down" ;
   eta:standard_name = " atmosphere_hybrid_sigma_pressure_coordinate" ;
   eta:formula_terms = "a: A b: B ps: PS p0: P0" ;
   eta:bounds="eta_bnds" ;
 float eta_bnds(eta, 2) ;
   eta_bnds:formula_terms = "a: A_bnds b: B_bnds ps: PS p0: P0" ; // This attribute is mandatory
 float A(eta) ;
   A:long_name = "'a' coefficient for vertical coordinate at full levels" ;
   A:units = "Pa" ;
   A:bounds = "A_bnds" ; // This attribute is included for the optional second method
 float B(eta) ;
   B:long_name = "'b' coefficient for vertical coordinate at full levels" ;
   B:units = "1" ;
   B:bounds = "B_bnds" ; // This attribute is included for the optional second method
 float A_bnds(eta, 2) ;
 float B_bnds(eta, 2) ;
 float PS(lat, lon) ;
   PS:units = "Pa" ;
 float P0 ;
   P0:units = "Pa" ;
 float temp(eta, lat, lon) ;
   temp:standard_name = "air_temperature" ;
   temp:units = "K";
   temp:coordinates = "A B" ; // This attribute is included for the optional second method

pp-mo · 2024-10-30T12:16:02Z

As discussed today @SciTools/peloton (and after)

@pp-mo wanted to make clear that I don't think it is "bad CF" for the dependencies to have bounds connected via a "bounds" attribute, as for coords.
But according to the above-quoted CF statement :

"If a parametric coordinate variable with a formula_terms attribute (section 4.3.2) also has a bounds attribute, its boundary variable must have a formula_terms attribute too."

So, it is wrong to do that if the parametric coordinate variable itself has a 'bounds' attribute -- which is the case here.
This case seems a bit weird - but please see further investigations (below).

So, I think that :

the 'old way' is still valid, and
Iris should support either form on load, and
eventually we may need to provide a switch to save in either style
-- since it seems clear that the "new way" is now deemed preferable, but we probably need to retain "old style" for backwards compatibility (at least for a while, so maybe a FUTURE flag?)

pp-mo · 2024-10-30T12:23:22Z

What about the sample `hybrid_height.nc` file ?

On closer inspection, I think the real problem here is that the 'level_height' variable both defines a parametric coordinate, and contains the 'level_height' term of the formula : so that it includes itself within its own 'formula_terms'.

Although that sounds a bit odd, it is in fact done that way in CF examples.
In fact, it is in the very first parametric coordinate example given, here.
There we see lev:formula_terms = "sigma: lev ps: PS ptop: PTOP" ;
So 'the 'sigma' term of the 'lev' coordinate is 'lev' itself.

According to the above quote, this means that the level_height variable in "hybrid_height.nc" should not have a 'bounds' attribute which simply points to a level_height_bounds variable, as in fact it does (!) :
So, it does appear that this is definitely "bad CF".

On inspecting the history, I find that this file was originally generated by loading PP data and saving it.
So, the mistake lies in some older version of the Iris save code.
Which I think raises more questions :

does the current save code do the same ?
is this clearly 'bad' according to earlier versions of CF, or was that clarification added later ?

pp-mo · 2024-10-30T13:49:47Z

does the current save code do the same ?

Experimented with this.
Short answer - yes, Iris save does (still) create data like "hybrid_height.nc", which according to above statements is actually "wrong".

It looks like the dataset from which "hybrid_height.nc" was called "theta_and_orog_subset.pp", and PP data of that name still exists in iris-test-data.

Example:

>>> cube = iris.load_cube(iris.tests.get_data_path(["PP", "COLPEX", "theta_and_orog_subset.pp"]), "air_potential_temperature")
>>> print(cube)
air_potential_temperature / (K)     (time: 6; model_level_number: 70; grid_latitude: 100; grid_longitude: 100)
    Dimension coordinates:
        time                             x                      -                  -                    -
        model_level_number               -                      x                  -                    -
        grid_latitude                    -                      -                  x                    -
        grid_longitude                   -                      -                  -                    x
    Auxiliary coordinates:
        forecast_reference_time          x                      -                  -                    -
        level_height                     -                      x                  -                    -
        sigma                            -                      x                  -                    -
        surface_altitude                 -                      -                  x                    x
    Derived coordinates:
        altitude                         -                      x                  x                    x
    Scalar coordinates:
        forecast_period             0.0 hours
    Attributes:
        STASH                       m01s00i004
        source                      'Data from Met Office Unified Model'
        um_version                  '7.4'
>>>
>>> iris.save(cube[0], "tmp.nc")  # single timepoint to be more like sample data
>>> exit()

$ ncdump -h tmp.nc
netcdf tmp {
dimensions:
	model_level_number = 70 ;
	grid_latitude = 100 ;
	grid_longitude = 100 ;
	bnds = 2 ;
variables:
	float air_potential_temperature(model_level_number, grid_latitude, grid_longitude) ;
		air_potential_temperature:standard_name = "air_potential_temperature" ;
		air_potential_temperature:units = "K" ;
		air_potential_temperature:um_stash_source = "m01s00i004" ;
		air_potential_temperature:grid_mapping = "rotated_latitude_longitude" ;
		air_potential_temperature:coordinates = "forecast_period forecast_reference_time level_height sigma surface_altitude time" ;
	int rotated_latitude_longitude ;
		rotated_latitude_longitude:grid_mapping_name = "rotated_latitude_longitude" ;
		rotated_latitude_longitude:longitude_of_prime_meridian = 0. ;
		rotated_latitude_longitude:earth_radius = 6371229. ;
		rotated_latitude_longitude:grid_north_pole_latitude = 37.5 ;
		rotated_latitude_longitude:grid_north_pole_longitude = 177.5 ;
		rotated_latitude_longitude:north_pole_grid_longitude = 0. ;
	int model_level_number(model_level_number) ;
		model_level_number:axis = "Z" ;
		model_level_number:units = "1" ;
		model_level_number:standard_name = "model_level_number" ;
		model_level_number:positive = "up" ;
	float grid_latitude(grid_latitude) ;
		grid_latitude:axis = "Y" ;
		grid_latitude:bounds = "grid_latitude_bnds" ;
		grid_latitude:units = "degrees" ;
		grid_latitude:standard_name = "grid_latitude" ;
	float grid_latitude_bnds(grid_latitude, bnds) ;
	float grid_longitude(grid_longitude) ;
		grid_longitude:axis = "X" ;
		grid_longitude:bounds = "grid_longitude_bnds" ;
		grid_longitude:units = "degrees" ;
		grid_longitude:standard_name = "grid_longitude" ;
	float grid_longitude_bnds(grid_longitude, bnds) ;
	double forecast_period ;
		forecast_period:units = "hours" ;
		forecast_period:standard_name = "forecast_period" ;
	double forecast_reference_time ;
		forecast_reference_time:units = "hours since 1970-01-01 00:00:00" ;
		forecast_reference_time:standard_name = "forecast_reference_time" ;
		forecast_reference_time:calendar = "standard" ;
	float level_height(model_level_number) ;
		level_height:bounds = "level_height_bnds" ;
		level_height:units = "m" ;
		level_height:long_name = "level_height" ;
		level_height:positive = "up" ;
		level_height:standard_name = "atmosphere_hybrid_height_coordinate" ;
		level_height:axis = "Z" ;
		level_height:formula_terms = "a: level_height b: sigma orog: surface_altitude" ;
	float level_height_bnds(model_level_number, bnds) ;
	float sigma(model_level_number) ;
		sigma:bounds = "sigma_bnds" ;
		sigma:units = "1" ;
		sigma:long_name = "sigma" ;
	float sigma_bnds(model_level_number, bnds) ;
	float surface_altitude(grid_latitude, grid_longitude) ;
		surface_altitude:units = "m" ;
		surface_altitude:standard_name = "surface_altitude" ;
		surface_altitude:um_stash_source = "m01s00i033" ;
		surface_altitude:source = "Data from Met Office Unified Model" ;
		surface_altitude:um_version = "7.4" ;
	double time ;
		time:units = "hours since 1970-01-01 00:00:00" ;
		time:standard_name = "time" ;
		time:calendar = "standard" ;

// global attributes:
		:source = "Data from Met Office Unified Model" ;
		:um_version = "7.4" ;
		:Conventions = "CF-1.7" ;
}

That is ...

level_height variable has a formula_terms, and standard name atmosphere_hybrid_height_coordinate, so represents the hybrid coord.
but the formula contains "a: level_height", so the parametric coord variable is also the "a:" term of it's own formula.
and it has bounds = "level_height_bnds"
... and level_height_bounds is a plain bounds variable, with no formula_terms attribute.
So that is exactly what we have been saying is plain "wrong".

pp-mo · 2024-10-30T15:17:21Z

is this clearly 'bad' according to earlier versions of CF, or was that clarification added later ?

( The "other question" from above )
Briefly, it seems this was clarified in CF-1.7, and not anywhere explicitly addressed before that.

In the v1.7 spec, new text was added in section "7.1. Cell Boundaries" to the effect stated above

If a parametric coordinate variable with a formula_terms attribute (section 4.3.2) also has a bounds attribute, its boundary variable must have a formula_terms attribute too ...

This makes clear there that there are two means of recording bounds of formula terms. But it seems to insist that a separate bounds variable with its own formula_terms attribute would still always exist.
There is no specific indication that bounds could be attached to formula term only by having a 'bounds' on the term variable (as Iris has apparently done for a long time) : instead it suggests that in order for the 'bounds' attribute of a term variable to be meaningful, the term variable itself needs to be recognised as an aux-coord, by being referenced in a data variable via "coordinates" :

Whenever a formula_terms attribute is attached to a boundary variable, the formula terms may additionally be identified using a second method ...
... variables appearing in the vertical coordinates' formula_terms may be declared to be coordinate, scalar coordinate or auxiliary coordinate variables,
... and those coordinates may have bounds attributes that identify their boundary variables.

The example given there is somewhat similar to what Iris produces,
but it does not break the rules the way Iris does :

Example 7.1. Specifying formula_terms when a parametric coordinate variable has bounds.

float eta(eta) ;
   eta:long_name = "eta at full levels" ;
   eta:positive = "down" ;
   eta:standard_name = " atmosphere_hybrid_sigma_pressure_coordinate" ;
   eta:formula_terms = "a: A b: B ps: PS p0: P0" ;
   eta:bounds="eta_bnds" ;
 float eta_bnds(eta, 2) ;
   eta_bnds:formula_terms = "a: A_bnds b: B_bnds ps: PS p0: P0" ; // This attribute is mandatory
 float A(eta) ;
   A:long_name = "'a' coefficient for vertical coordinate at full levels" ;
   A:units = "Pa" ;
   A:bounds = "A_bnds" ; // This attribute is included for the optional second method
 float B(eta) ;
   B:long_name = "'b' coefficient for vertical coordinate at full levels" ;
   B:units = "1" ;
   B:bounds = "B_bnds" ; // This attribute is included for the optional second method
 float A_bnds(eta, 2) ;
 float B_bnds(eta, 2) ;
 float PS(lat, lon) ;
   PS:units = "Pa" ;
 float P0 ;
   P0:units = "Pa" ;
 float temp(eta, lat, lon) ;
   temp:standard_name = "air_temperature" ;
   temp:units = "K";
   temp:coordinates = "A B" ; // This attribute is included for the optional second method

So in this example, 'eta' is one of it's own terms, but 'eta_bounds' points at another variable with a 'formula_terms' describing all the term bounds, instead of just a simple bounds variable for the 'eta' term (which is what Iris does).
However, more like Iris, it also has A:bounds = "A_bnds" and B:bounds = "B_bnds", even though these are effectively redundant, since the same linkage is established via eta:bounds="eta_bnds" and then eta_bnds:formula_terms = "a: A_bnds b: B_bnds ps: PS p0: P0" . Hence, presumably, the comments "This attribute is included for the optional second method".

So What ?

This presents a real problem, since we probably want to retain the ability to use existing "wrong" behaviour, purely because it is so longstanding in Iris output

trexfeathers · 2024-11-01T11:26:23Z

Amazing work @pp-mo 🏅

schlunma mentioned this issue Mar 5, 2020

Dataset problem: Issues with hybrid height coordinate of UKESM1-0-LL (CMIP6) ESMValGroup/ESMValCore#543

Closed

pp-mo added the Type: Bug label May 14, 2020

pp-mo added this to the v3.0.0 milestone May 14, 2020

lbdreyer added Experience: High T-Shirt: Medium labels May 14, 2020

abooton added the Release: Patch label May 14, 2020

matthew-mizielinski mentioned this issue Aug 11, 2020

Correct iris faulty generation of altitude bounds when reading files with hybrid height coordinate MetOffice/cube_helper#39

Open

pp-mo added the Feature: ESMValTool label Aug 25, 2020

pp-mo added the Feature: NetCDF + CF-conventions label Sep 8, 2020

pp-mo modified the milestones: v3.0.0, v3.1.0 Sep 8, 2020

bjlittle removed the T-Shirt: Medium label May 13, 2021

bjlittle modified the milestones: v3.1.0, v3.3.0 Nov 1, 2021

stephenworsley modified the milestones: v3.3.0, Candidate for next release Jun 29, 2022

trexfeathers added this to Iris v3.4.0 Sep 27, 2022

trexfeathers moved this to 🆕 New in Iris v3.4.0 Sep 27, 2022

valeriupredoi mentioned this issue Sep 30, 2022

Ordering issues labelled Feature: ESMValTool from iris ESMValGroup/ESMValCore#1738

Open

trexfeathers added this to 🐻 Iris v3.5.0 Oct 7, 2022

trexfeathers removed this from Iris v3.4.0 Oct 7, 2022

bjlittle moved this to 📚 Backlog in 🌍 ESMValTool Surgery (Discussion Topics) Oct 10, 2022

trexfeathers moved this from 🆕 New to 📋 Backlog in 🐻 Iris v3.5.0 Oct 14, 2022

ESadek-MO assigned stephenworsley Dec 2, 2022

ESadek-MO moved this from 📋 Backlog to 🔖 Ready in 🐻 Iris v3.5.0 Dec 2, 2022

trexfeathers moved this to 🆕 New in ESMValTool Feb 20, 2023

trexfeathers added this to ESMValTool Feb 20, 2023

ESadek-MO assigned lbdreyer Mar 23, 2023

ESadek-MO moved this from 🔖Assigned to 🏗 In progress in 🐻 Iris v3.5.0 Mar 31, 2023

trexfeathers moved this from 🏗 In progress to 📋 Backlog in 🐻 Iris v3.5.0 Apr 3, 2023

trexfeathers added this to 🚴 Peloton Jun 23, 2023

trexfeathers unassigned lbdreyer and stephenworsley Aug 16, 2023

ehogan mentioned this issue Oct 13, 2023

Dataset problem: MIROC6 salinity contains zlev and sigma, which break fix with "unknown" units ESMValGroup/ESMValCore#2174

Open

scitools-ci bot removed this from 🚴 Peloton Dec 15, 2023

scitools-ci bot added this to 🚴 Peloton Dec 15, 2023

trexfeathers modified the milestones: Candidate for next release, v3.10 Feb 21, 2024

trexfeathers removed the status in ESMValTool Feb 29, 2024

ESadek-MO assigned HGWright Sep 9, 2024

ESadek-MO assigned trexfeathers Oct 7, 2024

trexfeathers mentioned this issue Oct 24, 2024

Bounds on derived coords #6190

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Bounds of derived variable are not read correctly #3678

Bounds of derived variable are not read correctly #3678

schlunma commented Mar 5, 2020

pp-mo commented Aug 25, 2020

zklaus commented Aug 31, 2020

pp-mo commented Sep 8, 2020 •

edited

Loading

bjlittle commented Sep 30, 2022

schlunma commented Oct 4, 2022

pp-mo commented Oct 4, 2022

schlunma commented Oct 4, 2022

stephenworsley commented Mar 30, 2023

schlunma commented Mar 31, 2023

trexfeathers commented Oct 25, 2024

schlunma commented Oct 28, 2024

pp-mo commented Oct 30, 2024

pp-mo commented Oct 30, 2024 •

edited

Loading

pp-mo commented Oct 30, 2024 •

edited

Loading

pp-mo commented Oct 30, 2024 •

edited

Loading

trexfeathers commented Nov 1, 2024

Bounds of derived variable are not read correctly #3678

Bounds of derived variable are not read correctly #3678

Comments

schlunma commented Mar 5, 2020

pp-mo commented Aug 25, 2020

zklaus commented Aug 31, 2020

pp-mo commented Sep 8, 2020 • edited Loading

bjlittle commented Sep 30, 2022

schlunma commented Oct 4, 2022

pp-mo commented Oct 4, 2022

schlunma commented Oct 4, 2022

stephenworsley commented Mar 30, 2023

schlunma commented Mar 31, 2023

trexfeathers commented Oct 25, 2024

schlunma commented Oct 28, 2024

pp-mo commented Oct 30, 2024

As discussed today @SciTools/peloton (and after)

pp-mo commented Oct 30, 2024 • edited Loading

What about the sample hybrid_height.nc file ?

pp-mo commented Oct 30, 2024 • edited Loading

pp-mo commented Oct 30, 2024 • edited Loading

So What ?

trexfeathers commented Nov 1, 2024

pp-mo commented Sep 8, 2020 •

edited

Loading

pp-mo commented Oct 30, 2024 •

edited

Loading

What about the sample `hybrid_height.nc` file ?

pp-mo commented Oct 30, 2024 •

edited

Loading

pp-mo commented Oct 30, 2024 •

edited

Loading