CF compliant units attributes in Varinfo.dat

[nacholibre]

I have recently started working on creating ISO metadata files for our model outputs and started to realize the challenges. One of them is linking to a units vocabulary for units definition. For example white spaces the units attribute with are problematic for automatically populating the units link. Consider the variable rain with the units attribute 'kilogram meter-2 second-1':

Code: Select all

'rain'                                             ! Input
  'rain fall rate'
  'kilogram meter-2 second-1'                      ! [kg m2/s]
  'rain, scalar, series'
  'rain_time'
  'idrain'
  'r2dvar'
  1.0d0

In this case wouldn't be more suitable to have something that is more like a standard name, which uses underscores? e.g. 'kilogram_meter-2_second-1'. This way ithe link can be directly created in the metadata as follows:

Code: Select all

<gmd:units xlink:href="https://raw.githubusercontent.com/Unidata/UDUNITS-2/master/lib/udunits2-common.xml#meter_second-1"/>

Also is there any update plans for ROMS metadata? Do the Udunits community get informed if there is any request for additional unit definitions from modeling community? Here's a related discussion here. For example I don't think it is possible to provide a link for the definition of units in ISO metadata for velocity because I believe none of the units databases define meters_second-1...
Thanks
Zafer

[arango]

Thank you. The ROMS metadata file varinfo.dat is a user file and can be edited in any way that the user feels is necessary. You can even change the language. Some users in France wanted some of the attribute values to be in French. I haven't read the documentation about the UDUNITS-2 package. I look older version several years ago. I believe that you are providing the correct information about changes in the convention. It will be an easy change to make. However, I will have to check the ROMS code since I use the units attribute when processing input NetCDF data. Adding underscores may complicate matters in the decoding of time units of the form:

Code: Select all

        double ocean_time(ocean_time) ;
                ocean_time:long_name = "time since initialization" ;
                ocean_time:units = "seconds since 1900-01-01 00:00:00" ;
                ocean_time:calendar = "proleptic_gregorian" ;

What you will do in this case? Are you suggesting that we need to replace all the blanks with underscores in this units attribute? That will be weird. I understand the issue of creating links. I only use standard_name in coupling metadata that will be released in the future. Dictionaries are difficult because some of the standard_name out there are not precise. Why should we use unprecise values for these attributes? There is a lot to consider like physics, numerical discretization, vertical coordinates, etc. We cannot even agree with what surface is in a particular context.

One of the problems that I need to check with the suggested change is backward compatibility with older versions of ROMS if we change varinfo.dat. I need to think about this one.

[nacholibre]

Thank you Hernan. This is helpful and those are very good points. My example was just for demonstration purposes. Surely there is no easy fix because the challenge of defining standard names spans across different disciplines, communities, applications etc... I appreciate your effort and future plans to stick with standard names. I will be on the lookout for any useful information and will add to the conversation when it is worthwhile.

[nacholibre]

Adding underscores may complicate matters in the decoding of time units of the form:

Code: Select all

        double ocean_time(ocean_time) ;
                ocean_time:long_name = "time since initialization" ;
                ocean_time:units = "seconds since 1900-01-01 00:00:00" ;
                ocean_time:calendar = "proleptic_gregorian" ;

What you will do in this case? Are you suggesting that we need to replace all the blanks with underscores in this units attribute?

Looks like we will be able to handle all other units somewhat automatically, but this notation is very nonstandard and will be problematic in any case. It is actually not correct, would you not agree? It is a combination of units and a variable. The units should be "seconds" only, and the reference date should be handled through another variable or a separate attribute most probably. For example:

Code: Select all

        double ocean_time(ocean_time) ;
                ocean_time:long_name = "time since initialization" ;
                ocean_time:units = "seconds" ;
                ocean_time:start_date = "1900-01-01 00:00:00" ;
                ocean_time:calendar = "proleptic_gregorian" ;

Just wanted to flag this for your consideration in case you decide to make any updates to this part of the code in the future.
Thanks
Z

[wilkin]

Do not separate the units "seconds" from the reference date. Read the CF Conventions standard:

http://cfconventions.org/cf-conventions ... coordinate

[arango]

I agree with John. This part is not desirable. We and others have been using this standard for years. There are lots of datasets out there that follow this nomenclature. I am sympathetic with the issue of the links but some of the changes suggested are radical.

[nacholibre]

CF recommends UDUNITS, which recommends "using a true calendar package rather than the UDUNITS-2 package".
https://www.unidata.ucar.edu/software/u ... .html#Time

10 The Handling of Time
You should use a true calendar package rather than the UDUNITS-2 package to handle time. Having said that, many people use the time-handling capabilities of the UDUNITS-2 package because it supports "units" like "seconds since 1970-01-01". You should be aware, however, that the hybrid Gregorian/Julian calendar used by the UDUNITS-2 package cannot be changed. Dates on or after 1582-10-15 are assumed to be Gregorian dates; dates before that are assumed to be Julian dates. In particular, the year 1 BCE is immediately followed by the year 1 CE.

I understand the legacy requirements and the backward compatibility challenges with this issue. I surely do not want to impose any expectations for such a change by ROMS community unilaterally. But I am learning a lot along the way. Thank you John and Hernan for your replies.

[arango]

ROMS has nowadays a very robust calendar. See the routine ROMS/Utility/dateclock.F for more details. It is consistently internally and can handle different reference date (epoch) for each forcing field from NetCDF files regardless of what we choose in the ROMS input parameter TIME_REF. I have to rewrite it because of my current work with multimodel coupling using the ESMF/NUOPC library. We also have equivalent functions written the Perl to aid us in complex submit job scripts. See ROMS/Bin/dates and dates_test.bash and friends. Therefore, we really don't need to use third party software like UDUNITS to manage and decode calendars and time inside ROMS. The default calendar in ROMS is proleptic_gregorian.

It seems to me that your real problem is your parser to HTML and what to do with white spaces in the link. You could use any replacement function to replace the blank spaces with underscores on the fly. I use PERL a lot for any text editing because it can be used in any scripting language.

The metadata model should be flexible and not so narrow to not allow blank spaces. Good luck.