CF-1.0 Compliance

[crode1968]

Some visualization softwares are only able to handle ROMS netcdf output files, when attributes for some variables are added. These attributes describe the relations between real world and model model coordinate systems and are in compliance with the CF-1.0 standard.

I suggest to introduce the coordinates attribute, like

h:coordinates = "lon_rho lat_rho" ;
u:coordinates = "lon_u lat_u";

I do not know if software packages in general can use the standard_name for the rho, u, v and psi points in parallel. Therefore, I would suggest to set this attribute only for the rho points, because most variables are defined on this points.

lon_rho:standard_name = "longitude" ;

In addition, I would like that the attribute positive is added to describe the orientation of vertical axes.

h:positive = "down";

This attribute allows to interpret the orientation of an axis. In the example the software might realize, that the deep is getting deeper for higher numbers. Unfortunately, some software packets do not evaluated this attribute.

To prevent problems by introducing the additional parameters, I suggest to introduce a FLAG, which is not set in the standard case. Since ferret, for example, gives a warning message when data containing the coordinates attribute are loaded, these might cause a flood of trouble tickets and long discussions in the wiki. This might be preventable by setting undef FLAG.

[arango]

Yes, thank you. I added the positive attribute to h. I also added the standard_name to lon_rho and lat_rho. That's a good suggestion.

I also modified various enumeration attributes with flag_values and flag_meanings.

Already, ROMS has the coordinates attribute. We never have problems in the past when using various post-processing NetCDF packages. I rechecked again compliace with the web ​interface. ROMS output files passes compliance for CF 1.0 to 1.4. However, I left the global attribute as CF 1.0.

I think that the problem is in Ferret and it should be fixed to be CF compliant. I have never used Ferret before so I don't know what are the problems. I don't think that adding a CPP option in ROMS to remove compliance is a good idea. Nowadays, the CF compliance is ROMS is strict. This was done to facilitate parallel I/O.

I alsp corrected a typo in metrics.F and normalization.F.

[rsignell]

Actually, the "positive" attribute is for use with vertical coordinate variables. "h" is not a coordinate variable, so "positive" should not be set. "positive" could be set to "up" for the vertical coordinate variables (currently "s_rho" and "s_w", which identify "ocean_s_coordinate" as the vertical coordinate transformation) but since this is the default, it is unnecessary.

Software packages do not use "standard_name=longitude" to identify coordinate axes but also there is no harm in having more than one variable identified with a particular "standard_name" in a file. If we are going to add "standard_name=longitude" for lon_rho and lat_rho, we should add it for the others (e.g. "lon_u, lat_u, lon_v...") as well. Does this mean we going to start using the CF standard_name in ROMS output (for potential temperature, salinity, etc)? I suppose this should be done eventually, and this would help identify the need for new standard_name entries to support the types of data ROMS produces. The CF standard name table is at: ​http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standard-name-table/current/standard-name-table/

-Rich

[arango]

Yes, thank you for your clarification. I assume that we eventually will do that for basic fields. Currently, we don't have a full standard_name table for ocean fields. The ​link that you gave us is pretty much for atmospheric fields. However, there are few that can be used:

zeta => sea_surface_height
u => x_sea_water_velocity
v => y_sea_water_velocity
temp => sea_water_potential_temperature
salt => sea_water_salinity

I will add this in the future.

Rich further adds in an e-mail:

Clients may use standard_name to identify different types of functionality. For example, if the client ncWMS finds variables that have the standard names eastward_sea_water_velocity and northward_sea_water_velocity, it plots vectors on the map.