Add lon,lat info in iHAMOCC output to more comply to cdo commands

[jmaerz]

Hi @JorgSchwinger and @TomasTorsvik , after listing up #340, I thought it might be useful to integrate the cdo-compatibility already now to make more use of the v1.6.0+ (by merging this enhancement also into v1.6.0).

With this PR, it becomes possible to e.g. performing a simple regridding:

module load CDO/1.9.8-intel-2019b
cdo -remapbil,r360x180 -selvar,silvl test_lonlat.blom.hbgcm.0001-01.nc remapped.nc

For a conservative regridding, we would also need to add the cell corners in the output (while I once had issues with the order, BLOM has them in the grid file, if I remember correctly). If that is wished, I can try to incorporate this as well - while I see this use case less often. It runs through with the GLB_COMPFLAG (after moving to the xml-list by Mariana now reachable via GLB_COMPFLAG@DIABGC), but at least ncview doesn't like the output (as in it doesn't show the output as usual - not sure, if this is the typical behavior).

[jmaerz]

Hi @YanchunHe , @TomasTorsvik made me aware that you might want to skim over these changes as well, since it might affect the way you build the cmorization scripts. If this is a real issue, let me/us know. Essentially, I/we want to add the longitude and latitude information (thus far only stored in the respective gridfile) into each output file so that it becomes easier to use cdo commands on the fly when doing some quick investigations of raw output.

[JorgSchwinger]

Looks good to me. I would almost be in favor of adding the lat/lon vertices, too. For atmosphere-ocean fluxes conservative remapping is something one might want to do.... But does not need to be at this stage.

[jmaerz]

Hi @JorgSchwinger , yeah, I wasn't sure about it - it means adding 4 more fields per file on top of the lon,lat info that I already added. I will look up the recipe that I used for conservative remapping - I post it here and we can then re-consider the implementation (I vaguely remember that some re-ordering of the corners would be needed - I don't know the reason, why they currently have the order as they have in the gridfile - is there any particular reason that you are aware of? - that was holding me a bit back)

[JorgSchwinger]

I'm not aware of any reason for the ordering. But also it's not a very high priority I would say. Usually when calculating total fluxes you want do this on a time-series of files, so you anyway have to combine several files. So I clearly see more application for the lat/lon.

[jmaerz]

Dear @JorgSchwinger and @TomasTorsvik , here some recipe that can be used for conservative regridding (done with output after including the changes, while it would add a few more steps with the old output):

Scenario, when one has stuff on a different grid than BLOM (note that I have an alias set for the gridfile):

# load the modules needed:
module load CDO/1.9.8-intel-2019b 
module load NCO/4.9.3-intel-2019b

# select variables needed for generating the regridding weights from the gridfile
cdo -selvar,plon,plat,pclon,pclat,parea $gridfile_tnx2v1 grid.nc

# Rename the attributes from corners to bounds
ncrename -a plon@corners,bounds -a plat@corners,bounds grid.nc

# Reorder the bounds (corner) information from (nv,y,x) to (y,x,nv)
ncpdq -O --rdr=y,x,nv grid.nc grid_tnx2v1.nc

# Add coordinate information to `parea`
ncatted -a coordinates,parea,c,c,"plon plat" grid_tnx2v1.nc

# generate variable `silvl` on regular grid for testing the regridding 
# (not conservative, here, would require adding plat and plon to the file 
# in case of old output without the plon,plat information introduced in this PR)
cdo -remapbil,r360x180 -selvar,silvl test_lonlat.blom.hbgcm.0001-01.nc sil_reggrid.nc

# generating re-usable weights for conservative regridding
cdo gencon,grid_tnx2v1.nc sil_reggrid.nc weights_tnx2v1.nc

# remap the regular grid file back to tnx2v1 in a conservative manner
cdo remap,grid_tnx2v1.nc,weights_tnx2v1.nc sil_reggrid.nc sil_back-to-tnx2v1.nc

or some simple conservative regridding to a regular grid:

# merge all necessary information, incl. the variable to remap
cdo -merge -selvar,pclon,pclat $gridfile_tnx2v1 -selvar,silvl test_lonlat.blom.hbgcm.0001-01.nc merged.nc

# reorder the boundary information
ncpdq -O --rdr=y,x,nv merged.nc merged_reordered.nc

# add the information of bounds (corners) to `plat` and `plon`
ncatted -a bounds,plat,c,c,"pclat" -a bounds,plon,c,c,"pclon" merged_reordered.nc

# conservative remapping to a regular grid
cdo remapcon,r360x180 merged_reordered.nc merged_r360x180.nc

I hope this helps in the future.

[jmaerz]

@YanchunHe , @TomasTorsvik , any objections from your side on this PR? - otherwise I would like to merge it latest at the end of the week.

[TomasTorsvik]

@jmaerz - Thanks! This looks fine to me.

[YanchunHe]

Sorry for the late response.

It does not have impact on the cmorization tools.

In principle, the CDO should be able to combine merging lat/lon to the data and remap without having intermediate output, for example:

cdo -remapbil,global_1 -merge -selname,sst input.blom.hm.nc -selname,plat,plon grid.nc /tmp/remapped.nc

However, seems that the selname operator discards the 'coordinate: plat plon' attribute, so that the file operator remapbil does not work. I don't have solution for that.

So I don't have any objections to have plat/plon directly in the HAMOCC output.

[jmaerz]

@TomasTorsvik , if possible/applicable, this PR could also be merged into the v1.6.x release.

[TomasTorsvik]

@TomasTorsvik , if possible/applicable, this PR could also be merged into the v1.6.x release.

I will make a v1.6.1 release on master, since nothing else has changed since v1.6.0.