Vertical position of grid points

[jo.irisson]

Hello to everyone,

I am using ROMS to provide the flow field for a biological application. The biological grid is a regular, non terrain following one, so I have to interpolate the output of ROMS. As far as I known, ROMS does not store the layers' depths in the netCDF output file, so I compute them with ROMS tools in MATLAB (get_depths.m, zlevs.m, etc.).

However, at this point I am not entirely sure of what to do for the vertical velocities:

- On one hand, ROMS is said to use an Arakawa-C grid, and this is compatible with the lengths of the dimensions s_rho and s_w in the output file: length(s_w)=length(s_rho)+1 i.e. there is one more w point that there are rho points. This is also in agreement with the output of get_depths which gives me a matrix of size (xi_rho, eta_rho, z_w) for the position of w points. This is how I picture ROMS grid.

- On the other hand, w in the netCDF output has the dimensions [xi_rho, eta_rho, s_rho, time] (and not s_w as I would have expected). My interpretation is that w at the bottom is always 0 according to the vertical boundary conditions (bottom of the page) and that, to save disk space, it is not stored in the output file. w should therefore have the the size [xi_rho, eta_rho, s_w-1, time] since w speeds are at s_w points and the last layer is skipped, and that just happens to be equal to [xi_rho, eta_rho, s_rho, time].

Therefore I should extract the w field until length(s_rho) but I should interpolate it based on the vertical coordinates s_w[2:length(s_w)] (since s_w[1] is the bottom).
Am I right or am I completely mistaken? I would help me a lot to have confirmation on this.

Thank you in advance. Sincerely,
Jean-Olivier Irisson

[wilkin]

ROMS output optionally gives the s-coordinate vertical velocity "omega" (defined at https://www.myroms.org/wiki/index.php/V ... oordinates) or the actual vertical "w" (in the z-direction). These outputs are requested in ocean.in via the logical flags:

Code: Select all

Hout(idWvel) == T                          ! 3D W-velocity
Hout(idOvel) == T                          ! omega vertical velocity 

My ROMS code (updated in the last few days) has both "omega" and "w" output dimensioned "s_w" in the vertical, in contradiction to your comments (you say they are s_rho):

Code: Select all

        float w(ocean_time, s_w, eta_rho, xi_rho) ;
                w:long_name = "averaged vertical momentum component" ;
                w:units = "meter second-1" ;
                w:time = "ocean_time" ;
                w:coordinates = "lat_rho lon_rho" ;
                w:field = "w-velocity, scalar, series" ;

Perhaps you need to reconcile these differences. You are correct that the s_w points are staggered with respect to the tracer points at s_rho, and that this gives one more s_w point than s_rho points. The first s_w point corresponds to z=-h, and the last corresponds to z=zeta (the free surface).

It may be that the Matlab codes you have "get_depths.m, zlevs.m, etc." have misled you.

John.

[jo.irisson]

Thank you for your answer. Indeed I am outputing w in the netCDF file and this is what I am interested in interpolating (together with u and v of course). From you answer I gather that the code in MATAB gives the correct dimensions and those are also correct in the dimensions part of the netCDF file. The issue is therefore probably with my ROMS code, which is a bit old, and which outputs w on s_rho points while it should be on s_w points.
I took this particular application as-is from someone who ran it before, so I will try to update this part of the code first, and then I guess I am in for a big diffing/merging party.

Thanks again.

[wilkin]

Perhaps you are using the IRD ROMS code? That could explain everything.

If so, you should probably make this clear in future posts otherwise advice you get here might be irrelevant or confusing.

The s-coordinate information reported in netcdf files written by version 3 of ROMS distributed on this myroms.org service includes the data and attributes for the CF standard "ocean s coordinate". Working with an agreed standard for describing ROMS s-coordinate helps with interoperability with other data, model output and utilities.

[jo.irisson]

I am working with the a UCLA version of the code which appears less clean (in my humble opinion) than the version 3 distributed through myroms (I cannot find a version number or anything like this in my source currently it may be quite old. The config was presented two years ago in the Ocean Science Meeting in Hawaii). We tried to run the same configuration with the AGRIF version too but never succeeded. I am not in charge (and not capable actually) of configuring ROMS for this problem, I am just using its output for the biological part, but your remarks make me think that I should motivate my colleagues in physical oceanography to update their code.

Thanks.