Dataset problem: EC-Earth data keeps NEMO halo at the edges (possibly IPSL-CM5A-LR too)

[monsieuralok]

We used ESMValTool for supporting unstructured grid in pilot project funded through IS-ENES3. But, interpolating results for tos dataset tos_Omon_EC-EARTH_historical_r1i1p1_199101-200512.nc on 1x1 latlon grid appears to very strange along closing of grid (Values going upto 600 degree). The reason for that could be in the source data with EC-Earth : Since it is the native grid, it is delivered exactly as written by NEMO. That means in this case, that there is duplication along the edges, ie the two side edges overlap by 2 cells and the top edge overlaps with itself by one cell. : a comment from Zimmermann Klaus after discussion. Same issue we (Myself and Klaus) noticed with NEMO grid in IPSL-CM5A-LR model. It would be better to look on this issue and resolve in future release of ESMValTool.

[valeriupredoi]

has the data been de-haloed ie have they removed the NEMO halo at the edges? This might be the problem - UKESM1 does this before pushing to ESGF

[valeriupredoi]

coming back to this one after a long hiatus - if the NEMO halo is not removed prior to final cmorization and push to ESGF, then I don't think ESMValTool should de-halo the data - this is something that should be done before the data is ready for ESGF upload, I believe @matthew-mizielinski would agree with me here :+1:

[matthew-mizielinski]

My approach was predicated on the idea that a novice users, e.g. those not involved in model development, would likely end up using the data and the halo rows would cause them problems*; duplicate cells can upset plotting and affect calculations such as global means (if only slightly). Alongside this there were concerns within the Met Office that the values written into these haloes by the version of NEMO being used in HadGEM3/UKESM1 were faulty.

(*Which I would have to help deal with, or at least explain what to do)

On top of this note that on several of the ORCA grids there are duplicate cells along the polar row, where the cells sit on the seam or "north-fold" in the grid. To avoid such duplication affecting novice user analysis we chose to mask the second half of the polar row as appropriate (i.e. this is different depending on which grid point [T/U/V/W] the data was produced on).

The ORCA grids are not familiar to many users of the data outside of the modelling groups themselves, and when I asked for appropriate regridding tools from our ocean modellers, e.g. for producing data on a simple lat-lon grid, nothing was forthcoming**.

(**Regridding is a challenging subject and choices of appropriate schemes may need to be made on a variable by variable basis).

[valeriupredoi]

excellent synopsis @matthew-mizielinski many thanks! So I suggest one asks nicely the model developers to use a de-haloer script (we used ncks wrapped in Python) and supply the data de-haloed :+1: @zklaus what you reckon?

[zklaus]

In terms of what should happen on the modeler's side, this is not so clear. I think the community needs to come together there and determine if there is any value in repeated cells and also how to deal with the staggering of the grids in standardized output.

In terms of ESMValTool, I think the best thing to do is to de-halo as a model fix. This, however, is a rather drastic change that should not happen for the present release.

Perhaps we need an "early-in-release-cycle" tag? For now, I will bump this to 2.5.0

[schlunma]

Moving this to v2.6 since there is not open PR yet.

[monsieuralok]

@zklaus @valeriupredoi I was thinking finally this problem would be fixed in ESMValTool or Should it be fixed from modeller side?