[ERROR] in lon_bnds

[adagj]

Describe the error For the NorESM2-LM Amon piControl files, most lon_bnds values are wrong (lon_bnds are set to the same values as the lon values) for the years 1600 - 1899. The lon_bnds seem to be correct from year 1900.

Way to correct I'm not sure if it make sense to fix this, but maybe make a note? I run into problems using python and xarray, and I guess similar problems can occur for other python or NCO based analysis tools, and also for regridding tools.

[YanchunHe]

Hi @adagj , which variables/file(s) have this issue?

I quickly checked tas at year 1600-1609, and it looks right.

Thanks! Yanchun

[adagj]

Hi @YanchunHe , I don't agree :) I think the lon_bnds for years 1600 - 1900 are shifted. 0 should not be a boundary value for lon = 0

In tas @year 1600-1609 lon = 0, 2.5, 5, 7.5, 10, ... , 355, 357.5 lon_bnds = 0, 1.25, 1.25, 3.75, 3.75, 6.25, 6.25, 8.75, .... 353.75, 356.25, 356.25, 360 ; }

If you look at year 1901-1910, they differ from year 1600-1609 and look more correct I think lon = 0, 2.5, 5, 7.5, 10, ... , 355, 357.5 lon_bnds = -1.25, 1.25, 1.25, 3.75, 3.75, 6.25, 6.25, 8.75, 8.75, 11.25, ... 353.75, 356.25, 356.25, 358.75 ;

Some reading problems arise if you try to read all these files at once with e.g. xarray in python (it can be solved in python by using e.g. compat = 'override', but then you end up with the first lon_bnds). I have a work around, and it may not be a big issue, but I wanted to let you know.

[YanchunHe]

Yes, I noticed that difference, but thought it still falls with the boundaries.

But, I looked back to the code changes, and see that I made a bug fix (as referred above), that should fixed an even worse error, I can recall.

Anyway, after that, the first lon boudary should extend more west. And that is why after year 1900, there is no such issue.

I actually can't tell which datasets are affected, so hard to report an erratum.

Maybe we can report erratum for only this piControl simulation.

[adagj]

You know better than me what qualify for reporting erratum, but if there are several problems it is probably worth reporting. The 1pctCO2 and historical simulations, member r1i1p1f1, NorESM2-LM, also contain wrong lon_bnds and thus maybe the other error you fixed?

[YanchunHe]

I have an impression that I changed that line of code, but can't recall what errors in the datasets are fixed related to that..

If only the first lon_bnds is the same as lon(1), this is not mathematically "wrong" but just the lon(1) value is not centered, and it is "technically" wrong.

As the above-referred commit 7631168 was committed at 21 Aug 2019, all atmospheric datasets of version v20190815 might be wrong.

But I don't really check every datasets of v20190815.

Probally we can simply tag all Amon, AERmon of dataset version 20190815 might have this issue, that the first lon_bnds should be -1.25 instead of 0?

[adagj]

Sounds good. Yes, he first lon_bnds should be -1.25 instead of 0 and that the last value of lon_bnds should be 358.75 instead of 360.

[YanchunHe]

@monsieuralok Could you report errata for all datasets that falls in atmos and aerosol realms, of version 20190815, that "the first lon_bnds should be -1.25 instead of 0 and that the last value of lon_bnds should be 358.75 instead of 360".

If you can't easily filter out the datasets of atmos and aerosol realms, you can just filter datasets of Amon and AERmon tables, which should includes most of the atmospheric datasets.

[adagj]

Hi again @YanchunHe , sorry for all this, but I tried to regrid some siconc files (everything crashed!) and it seems like for the same simulations there are problems with the fill values of longitude and latitude. This problem is fixed after 1900 it seems, but that may be the error you already mentioned? The ocean files are OK.

[YanchunHe]

this might be a technical issue wrt specific softwares, e.g., python.

I see CDO should be able to deal with the missing values of inland points of lat/lon.

for example,

cdo -O remapbil,global_1 siconc_SImon_NorESM2-LM_piControl_r1i1p1f1_gn_160001-160912.nc /tmp/siconc1x1d.nc

which should give the right answer?

[adagj]

Yes, I for python you can just use areacello and skip the last j-row. But seems like python, ncview, NCO have problems with these values. Anyway, probably not worth making an errata

[YanchunHe]

Looks at leat ncview and CDO work well at my side. We can come back to this if some thing more happens.

[adagj]

Sure, I'm a bit surprised that you don't run into problems when e.g. regridding (even when using CDO) since all latitude values are set to 1 in the southern hemisphere. Seems to be the case for all SImon variables and files, at least for piControl. But I'll use areacello from now on, so let's leave it :-) Have a nice weekend!

[YanchunHe]

OK, this sounds much more worse at your side than what I can see.

So I seriously put what I can see at my side, with NcView.

for file: /projects/NS9034K/CMIP6/CMIP/NCC/NorESM2-LM/piControl/r1i1p1f1/SImon/siconc/gn/v20210118/siconc_SImon_NorESM2-LM_piControl_r1i1p1f1_gn_160001-160912.nc

The latitude values at some in-land points are set as missing value, 1.0e+30, not '1'.

7e+30, 0000001504747e+30, 1.00000001504747e+30, 1.00000001504747e+30, .6427459716797, -78.6427459716797, -78.6427459716797,
    -78.6427459716797, -78.6427459716797, -78.6427459716797,
    -78.6427459716797, -78.6427459716797, -78.6427459716797,
    -78.6427459716797, -78.6427459716797, -78.6427459716797,
    -78.6427459716797, -78.6427459716797, -78.6427459716797,
    -78.6427459716797, -78.6427459716797, -78.6427459716797,
    -78.6427459716797, -78.6427459716797, -78.6427459716797,
    -78.6427459716797, -78.6427459716797, -78.6427459716797,
    -78.6427459716797, -78.6427459716797, -78.6427459716797,
    -78.6427459716797, -78.6427459716797, -78.6427459716797,
    -78.6427459716797, -78.6427459716797, -78.6427459716797,
    -78.6427459716797, -78.6427459716797, -78.6427459716797,
    -78.6427459716797, -78.6427459716797, -78.6427459716797,
    -78.6427459716797, -78.6427459716797, -78.6427459716797,
    1.00000001504747e+30, 1.00000001504747e+30, 1.00000001504747e+30,
    1.00000001504747e+30, 1.00000001504747e+30, 1.00000001504747e+30,
    1.00000001504747e+30, 1.00000001504747e+30, 1.00000001504747e+30,
    1.00000001504747e+30

[adagj]

Sorry @YanchunHe , my bad! The latitude values are OK. Just python problems.

[YanchunHe]

OK, that is great to hear! God helg!

[monsieuralok]

@adagj I have not reported any Errata on that. Probably, I missed it. I will do it now. Alok

[monsieuralok]

@YanchunHe @adagj Do we want to open the Errata issue only for version 20190815 as Gareth reported: The files (for tas) that seem to be affected are files from tas_Amon_NorESM2-LM_piControl_r1i1p1f1_gn_171001-171912.nc to tas_Amon_NorESM2-LM_piControl_r1i1p1f1_gn_189101-190012.nc revision : 20210118

which is revision 20210118?

[YanchunHe]

@monsieuralok

It is right to use version 20210118, instead of v20190815 (refer to issue #122). As all the piControl datasets have been retracted and published with this uniforming 20210118 version.

So please go ahead with reporting this errata for version 20210118.

[adagj]

Hi, Just to be clear, it is not just tas variables and not only picontrol files which are affected. I think I have listed more experiments and variables previously in this issue. Maybe take a look there, or I can have a second look at the data later today.

Cheers, Ada

On Fri, 7 Jan 2022, 13:48 Yanchun He, @.***> wrote:

@monsieuralok https://github.com/monsieuralok

It is right to use version 20210118, instead of v20190815 (refer to issue

122 https://github.com/NorESMhub/noresm2cmor/issues/122). As all the

piControl datasets have been retracted and published with this uniforming 20210118 version.

So please go ahead with reporting this errata for version 20210118.

— Reply to this email directly, view it on GitHub https://github.com/NorESMhub/noresm2cmor/issues/310#issuecomment-1007381935, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADZUHH6G2PZYATDJ3QOD2HLUU3OLJANCNFSM5HLACNBQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[YanchunHe]

I have a quick check, and see that the following datasets of piControl are at least affected:

• Amon
• day
• AERmon

The others look OK..

[monsieuralok]

I have a quick check, and see that the following datasets of piControl are at least affected:

* Amon

* day

* AERmon

The others look OK..

@YanchunHe fx Table ID is also exists in atmos and aerosol relam; is it affected? with revision 20190815 where PiControl was retracted, there more than 80 variables with these realm for other experiemnts. For piControl, I will take all variables from realm atmos and aerosol.

[adagj]

@YanchunHe @monsieuralok The 1pctCO2 and historical simulations, member r1i1p1f1, NorESM2-LM, also contain wrong lon_bnds

[monsieuralok]

@adagj I will report it for experiments as @YanchunHe mentioned: 1pctCO2,abrupt-4xCO2,hist-GHG,hist-piAer,hist-piNTCF,historical,piClim-4xCO2,piClim-BC,piClim-OC,piClim-SO2,piClim-aer,piClim-control,piClim-ghg,piClim-lu with realm aerosol and atmos and revision 20190815 for all except PiControl

[adagj]

@monsieuralok Great! Thanks!

[monsieuralok]

@YanchunHe piControl experiment is having many other Table ID in aerosol and atmos relam. Do we need to report all? 6hrLev (5) 6hrPlev (9) 6hrPlevPt (11) AERday (5) AERmon (66) Amon (50) CF3hr (2) CFday (20) CFmon (3) Eday (16) Emon (10) Omon (2) day (23) fx (2)

[monsieuralok]

@YanchunHe @adagj opened Errata issue: https://errata.es-doc.org/static/view.html?uid=e3bb30f7-b863-8731-b967-99515894b93a