CDO

amanda gounou wrote:

Hi,

is it possible to transfert uv field from rotated NEMO grid to a regular grid?

best regards,

Amanda

I have tried cdo rotuvb,vozocrtx,vomecrty uv.nc out.nc
but I am getting this error message cdo rotuvb (Abort): Only rotated lon/lat grids supported

Hi!
I think you best ask the NEMO developers how to do that properly.

cheers
ralf

This might work:
cdo mrotuvb,noint -selname,vozocrtx uv.nc -selname,vomecrty uv.nc out.nc

However, if you have the original NEMO output the u and v grids should be different and u and v should be in separate files:
cdo mrotuvb u.nc v.nc out.nc

I have not tested either of these so plot your results and check if they look correct. And please let us know if it works!

Brendan DeTracey wrote:

This might work:
cdo mrotuvb,noint -selname,vozocrtx uv.nc -selname,vomecrty uv.nc out.nc

However, if you have the original NEMO output the u and v grids should be different and u and v should be in separate files:
cdo mrotuvb u.nc v.nc out.nc

I have not tested either of these so plot your results and check if they look correct. And please let us know if it works!

Thank you Brendan, i ll try this, i ll let you know the results.

I have poked about and seen that muvrotb is hard-coded to flip the sign of v. To compensate for this I tried

cdo mrotuvb u.nc -mulc,-1 v.nc out.nc

Hi Brendan,

I try to do the same than Amanda on ORCA12 (NEMO 1/12°, Arakawa, curvilinear grid) and we have compared this method with what is coded in NEMO for vector rotation. On this screenshot:

- fileV.nc is the original meridional velocity field (V grid)
- mergeUV_rotate is the meridional velocity field obtained when applying the procedures detailed within the NEMO routines
- test0.nc is the meridional velocity field obtained when applying mrotuvb without multiplying the V component by 1
test1.nc is the meridional velocity field obtained when applying mrotuvb with multiplying the V component by -1

diff1, bottom, is the difference between the mrotuvb method and the NEMO method for the v,meridional component (test1.nc - mergeUV_rotate.nc)

diff1, top, is the same diffence, but for the u,zonal component.

As you can see, the differences are not so big (~E-5 m/s), mostly near the coast and probably because we didn't use extrapolation. But, the main concern comes for the -180/180 lon line and the western side border that are badly handled with the cdo rot method. Is this because this was developed for regional models ? Can we hope a fix in the future for global models ?

Cheers, Stéphane and Romain from Mercator Océan.

Hi Guys!

Thanks for sharing your results. I keep trying to spread the message (cdo, CF-metadata, esmvaltool, et cetera) that a tool is needed for this purpose. I think the hot spots near your coastline are from the differences in the land mask between u and v Arakawa grid locations. In some places a value of 0 is being used for u and v, instead of the location being masked out. That is my guess. Keep in mind this cdo function was developed for a specific model grid for use in-house at MPI. I think that is why there is that seam at the anti-meridian.

I am just a cdo, user, like you. I have no idea if this could be easily fixed. Perhaps you could suggest this functionality in the cdo "Issues" as a request for a new feature, i.e. a mrotuvb that works for NEMO ocean grids.

Just found and might be worth a look: [https://xgcm.readthedocs.io/en/latest/index.html]
Edit: Does not do vector interpolation/rotation

Hi Guys,

You cannot use that function to rotate the vectors from the orca grid. The MPIO grid has a different configuration than the orca grid. For instance, the latitude of the MPIO grid is flipped. That is why people obtain those results where the v component is inverted. Now you cannot change the sign of the rotated v component because the u and v depend on the velocity components of the rotated grid. I wrote to the NEMO community a few days ago regarding this rotation. You need to follow these steps if you want to rotate the u and v components from NEMO.

To correct the vectors, you need to follow this equation.

u_latlon_T = u_rot_T cos(alpha_T) - v_rot_T sin(alpha_T)
v_latlon_T = u_rot_T sin(alpha_T) + v_rot_T cos(alpha_T)

As you can see here, the u_latlon depends on both components. The real issue is to compute the alpha_T. You can find how to calculate this angle in this file geo2oce.F90 (look for angle) from NEMO.

PS: I leave you the link to the post here https://nemo-ocean.discourse.group/t/rotate-u-and-v-model-grid-to-regular-lat-lon-grid/384/2

Thanks so much Estanislao. The elephant is still in the room with respect to Arakawa u and v grid offsets. I keep waiting anyone to provide the proper tools for these transformations. I used to have a matlab script based on the NEMO fortran code, but that is not a realistic thing to ask of data end users IMHO.

Hi everyone,

thanks for your thoughts. As I said, we already use a series of cdo/nco commands with respect to what is done in geo2oce.F90, see the code below (the angle components gcost,gsint of our grid are already in our meshmask file)

# gridU to gridT
time cdo -P  $NCORE shiftx ${fileu_filled} ${fileu_shifted}
time cdo -P  $NCORE ensmean ${fileu_filled} ${fileu_shifted} ${fileUT}

# gridV to gridT 
time cdo -P  $NCORE shifty ${filev_filled} ${filev_shifted}
time cdo -P  $NCORE ensmean ${filev_filled} ${filev_shifted} ${fileVT}

# extract angle components
if [ ! -f angles.nc ] ; then
  ncks -v gcost,gsint /scratch/work/bourdaller/MESH_MASK/ORCA12_NEMO3.6_mesh_mask_nc4.nc angles.nc
fi

# merge all variable into one file to operate
time cdo -P  $NCORE merge ${fileUT} ${fileVT} angles.nc $file_full_rotate

# rotate the velocity components 
time cdo -P  $NCORE -f nc4 -expr,'sozocrtxT=sozocrtx*gcost-somecrty*gsint;somecrtyT=sozocrtx*gsint+somecrty*gcost'  $file_full_rotate ${fileuv}

It's works fine but it would be nicer if this could be done with only one command

Have gcost and gsint always been available in the NEMO mesh mask file? I can't recall.

Hi everyone,

By default, gcost/gsint aren't in the meshmask. We have added its.
I think the sens of the grid can be easly treated by considering -V, but the main problem for mrotuvb to be NEMO compatible is the -180/180.
I suppose there is a longitude difference somewhere in the code to compute alpha_T, and maybe a fix like:
"diff_lon=where(diff_lon > 360., diff_lon-360., diff_lon)" could be added in mrotuvb code ?

Regards,
Romain