standard_name for U,V current components

[flcastej]

Dear all,

I have uploaded my ROMS model output to a ncWMS server and it works without problems, so I am able to visualize my output perfectly. The only problem is that ncWMS, in order to plot vectors, looks for the word "eastward or northward" in the standard_name to recognize this variable as vectors. I have tried with u_eastward and v_northward but ncWMS vector plots only works if there is a "standard_name". I have tried to change the varinfo.dat file, but although I have been reading the wiki and forum I am not pretty sure about how to do it. Now, I have been able to resolve the problem using:

ncatted -a standard_name,u,c,c,eastward_component output_his.nc

But I will like to know if there is an easiest way to do so without any postprocessing.

Thanks a lot for your help.

-Francisco

[rsignell]

So you must be using the flags to write out rotated velocity at grid cell centers, right?
For example:

Code: Select all

 Hout(idu3dE) == T       ! u_eastward         3D U-eastward  at RHO-points
 Hout(idv3dN) == T       ! v_northward        3D V-northward at RHO-points 

For sure these should be using standard_name values from the official list here: http://cfconventions.org/standard-names.html

Hernan has addressed this here:
https://www.myroms.org/projects/src/ticket/703

[arango]

Nope, this cannot be done in varinfo.dat. I have thought about this in the past but we have so many variables. However, I can see how this is important for velocity components and third-party potting tools. It is very easy to add the standard_name to the variables in def_avg.F and def_his.F. We just need to provide the standard_name value in Vinfo(21) when defining these variables.

I updated the code to include this attribute. Please check the following ticket and update. Thank you for bringing this to my attention.

[flcastej]

Richard, thanks a lot for your suggestion about the use of standard names. Hernan thanks a lot for updating the code with this change I am very glad to be able to help a little to the ROMs community.

[rduran]

I guess it could be understood from the context but just to be clear, it seems that vertically averaged was intended instead of vertically integrated:

Code: Select all

float ubar_eastward(ocean_time, eta_rho, xi_rho) ;
                ubar_eastward:long_name = "eastward vertically integrated momentum component at RHO-points" ;
                ubar_eastward:units = "meter second-1" ;

Code: Select all

 float vbar_northward(ocean_time, eta_rho, xi_rho) ;
                vbar_northward:long_name = "northward vertically integrated momentum component at RHO-points" ;
                vbar_northward:units = "meter second-1" ;

[arango]

Nope. It is not a vertical sum divided by the number of levels. It is a matter of semantics here. Perhaps, depth-averaged will be more appropriate. The shallow water equations are obtained by vertically integrating momentum and continuity equations in flux form. In curvilinear coordinates (xi, eta) we have the following definitions:



where H are the vertical level thicknesses, D is the total thickness of the water column, and Z is the terrain-following vertical coordinate. All are time-dependent quantities.

[rduran]

Hi Hernan,
Depth integrated is m2/s and is consistent with the definition you give; in that case this is what may need revising:

Code: Select all

units = "meter second-1"

Edit: however if both sides are divided by D before writing to netcdf then the units are correct and that would be depth-averaged by definition.