wrong value of latitude/longitude in cmorized output about noresm2cmor HOT 23 CLOSED

Ideally, coordinate variables should not have any missing values which is also not the case for the gx1 grid.

In any case, the place to modify is in read_gridinfo_ifile in m_modelsice.F. E.g. you could try setting all values with exceeding 1e20 to 1e20. This might fix it (or at least hide) the problem.

from noresm2cmor.

set undefined latitude/longitude points to _FillValue (1e20)in cmorized output
However, please the CMOR will still report warning message during runtime, since the _FillValue (1e20) is obviously beyond the valid range (-90 to 90).
commit 5a37b78

from noresm2cmor.

As I already mentioned, there shouldn't be undefined coordinate values. So I agree with the cmor warning.

from noresm2cmor.

Yes, I know. I just made a note above that it still has warning (as expected), but the actual value in the cmorized output is correct now. I close the issue.

from noresm2cmor.

Just wanted to comment here: (for some reason) CICE seems to map the atmospheric (?) land/mask on the coordinate variables. I think the solution here is acceptable, another option could be to read in the actual binary grid file, but that seems like an unnecessary hassle. However, I was wondering if the lat/lon info should be carried also in the CMORized output. Don't we provide a grid file where this info is anyway?

from noresm2cmor.

Please check if cmorized files seem all right under (in progress now so don't look at the newest temporary files) :
/projects/NS9034K/CMIP6/.cmorout/NorESM2-LM/omip1/v20190923

btw, PrePARE Quality-check passes without error.

from noresm2cmor.

Thanks for the clarification, Aleksi.

It is unfortunate that the coordinate values are masked and I'm concerned that this will create trouble for some users. Note also that the cmor-tool guesses grid cell corner information from neighbouring points and this information is likely affected as well.

The cmor-ization tool reads the coordinate information of the sea ice component from the output files. It is not read from the grid file directly primarily because that one uses machine binary format and not NetCDF. Of course , it is possible to read machine binary but on expense of portability of the cmor-ization tool (e.g. it would require compiler specific options for endianness) and it would take some time to implement it. Probably better, one could create a sea ice grid-file in netcdf format and read that one in. But I will have to focus on the NorCPM1 DCPP output (which is not subject to the problem) and therefore won't have to fix it.

from noresm2cmor.

Follow up to my last comment:

One solution could be to introduce an "icegridfile" namelist entry (like for the ocean and atmosphere component). If set, read the coordinate information from the file specified in the entry and if not set, read the coordinate information from the history output as currently done. To generate the netcdf grid file the easiest would be to extract the coordinate information from the history output of a coupled simulation.

from noresm2cmor.

I thought we would actually do this anyway (i.e. provide a grid file for ocn, atm, ice components), but I guess we didn't do it for the ice in CMIP5. Anyway, I can maybe look into it because I think that would be definitely the cleanest solution.

from noresm2cmor.

Sounds good.

The reading of sea ice coordinate information is done in read_gridinfo_ifile (line 612) in https://github.com/NorwegianClimateCentre/noresm2cmor/blob/master/source/m_modelsice.F

The fields read are TLON, TLAT, ULON, ULAT and ANGLE.

The handling of the input namelists is done in https://github.com/NorwegianClimateCentre/noresm2cmor/blob/master/source/m_namelists.F

from noresm2cmor.

Can you directly overwrite the latitude/longitude in the cmorized output file? Is that allowed by CMOR library quality-check?
Then I don't need to recmorized all the files, but only to calculate the sha256sum.

from noresm2cmor.

Not sure about that, I think we should just go with the approach here and try to produce an ice grid file. In the end, the coordinates should be the same, just without the mask, so I don't think there should be a need to rerun anything.

from noresm2cmor.

Manipulating cmor-ized files is a practice that has been common but is strongly discouraged. The bigger problem is that noresm2cmor derives the cell-corners and trying to do that outside of noresm2cmor will most likely create more work than simply re-cmorizing the sea ice output (you don't need to cmor-ize the output of the other components).

from noresm2cmor.

My understanding is Ingo suggest create a separate ice grid file, read the lat/lon information from this grid file (if available) instead of reading from data file, during cmorizaion (need redo this).

Reply to Ingo: yes, I can redo the cmorization if this is the best solution.

from noresm2cmor.

I had a look at it seems that the problem is there also in coupled simulations. I will try to create the grid file by reading the original grid binary file to recover ULAT, ULON, whereas the TLON, TLAT we can get from the MICOM grid file (same as PLON,PLAT).

from noresm2cmor.

Can we just replace the ULAT/ULON, TLAT/TLON etc in the original model output with the correct values? using tools like nco? or NCL?

Indeed, this occurs in some coupled simulations too.

This is simplest solution as I can see.

from noresm2cmor.

Aleksi is right, the problem seems to be present in all our published NorESM2 sea ice output (just checked the historical output). So it is not OMIP specific.

I guess it makes sense to proceed with OMIP publication including this cosmetic error and place a note on the errata pages https://errata.es-doc.org/static/index.html with status set to "WONT FIX". At a later time, you can still decide to fix and re-publish.

Otherwise you may as well stop all further publication of NorESM2 output that is subject to the issue and re-cmorize and re-publish all already published sea ice output. This would be a major undertaking and significantly delay CMIP6 publication.

from noresm2cmor.

As Ingo mentioned, I think it is best to proceed with the 'error'. I will (try to) create that ice grid file anyway, so maybe we can find a way to publish that at later stage (or if not then at least we have that for future purposes). We should also figure out where this is happening, I had a quick look at the cice code, but not entirely sure if it is happening there.

from noresm2cmor.

This error are not fixed in the cmorzied in the cmorized data but get disregarded.
close the issue now.

from noresm2cmor.

I have now found the same problem with the sea ice grid (at least for siconc on both SIday and SImon):

Left is siconc (on sea ice grid), right is tos (on ocean grid).

This creates problem when interpolating to another grid. The quick-fix for me would have been to copy the longitude and latitude data from an ocean variable (e.g. tos), but it turns out the dimensions are actually not the same:
siconc: j = 384 ; i = 360 ; # (sea ice grid)
tos: j = 385 ; i = 360 ; # (ocean grid)
I suspected that it was just an extra row, so that values for j=1:384 and i=1:360 would be identical, but when comparing the longitude (or latitude) values it seems they are off by small values (1E-14 to 1E-6), e.g.
tos_lon[121,102] - siconc_lon[121,102] => 2.842171e-14
tos_lat[236,361] - siconc_lat[236,361] => 9.971866e-05

I see the point from Ingo that we should not edit the CMORized files in the archive. Have you already solved this by saving longitude and latitude in a separate file? If so, is it available somewhere?

from noresm2cmor.

Hi @OskarMETNO , yes, this error is present in all of the CMIP6 output, and no, I have not created a separate file with lat/lon info. Anyhow, in principle, the ocean grid has simply an extra row i.e the quick fix is to do what you suggest. If you dive into the details, it is true that the lat/lon info is not exactly the same on the CICE and BLOM output even if they technically run on the same grid. If I remember correctly, this is due to the way CICE calculates the grid point center vs the way BLOM calculates the grid point center.

I remember having some discussions about this with @IngoBethke and possibly with Mats some years back. I can't remember the details but somehow I think there were arguments for the BLOM way being the 'more correct' approach. In any case, these details should not matter for regridding (I would suggest doing any budget calculations on the natural grid), and if you want to be super safe, then you could just replace the masked values with those from the ocean grid. Unless you regrid to a very coarse grid, the lat/lon points taken from the ocean grid will end up under the land mask and will not affect the regridded fields.

from noresm2cmor.

Thanks a lot Aleksi for the fast and detailed reply! Then I will use the coordinate values from tos.

from noresm2cmor.

Good, and thanks to @AleksiNummelin for the reply!

from noresm2cmor.