Re: NetCDF Digest - Vol 1 : Issue 278

• To: netcdfgroup@xxxxxxxxxxxxxxxx
• Subject: Re: NetCDF Digest - Vol 1 : Issue 278
• From: Harvey DAVIES <hld@xxxxxxxxxxxx>
• Date: Thu, 3 Aug 1995 20:14:11 +1000 (EST)

Steve,

Re your comments in NetCDF Digest [Volume 1 Issue 278]
on my proposed new units for the units database file 'udunits.dat'

> Subject: 19950728 Re: Suggested new units for udunits.dat 
> From:    Steve Emmerson <steve@xxxxxxxxxxxxxxxx>
> To:      netcdfgroup@xxxxxxxxxxxxxxxx
> Date:    Fri, 28 Jul 1995 13:19:40 MDT

> > ppt                     S 1.0e-3                # parts per thousand
> > ppm                     S 1.0e-6                # parts per million
> > ppb                     S 1.0e-9                # parts per billion
> > ppt                     S 1.0e-12               # parts per trillion
> 
> `ppt' in the above is ambiguous.  But I can add `ppm' and `ppb'.

The fact that I made this mistake proves 'ppt' is a bad idea!
My face is red with embarrassment  :-(

> > billion                 P 1.0e9
> > trillion                P 1.0e12
> 
> Don't the British use `billion' to mean 1.0e12 (i.e. isn't the British
> `billion' the USA's `trillion')?

The old British billion & trillion were more logical -- 1st 2 letters (bi or
tri) represented the power of million, giving 1e12 & 1e18.  In Australia the
meanings have clearly changed (over the last 20 years or so) from these to the
USA usage.  I seem to remember a news item a year or so ago to the effect that
the British had officially adopted (I can't remember how) the USA billion (& I
guess trillion).  Perhaps some UK reader would like to clarify this.

If there is still real ambiguity, then I guess we can live without billion &
trillion in udunits.dat.  However 'ppb' is common & should be included.

> I'm wary of adding too many 2-character abbreviations but will if
> pressed.  What do you think?

I see your point and agree.

> > month                   P year/12               # mean calendar month
> 
> I'll add this -- even though a month isn't a twelfth of a year.  I
> suppose it might be convenient.

I assure you it will be most useful.  

> > sidereal_month          P 27.321661 day
> > tropical_month          P 27.321582 day
> 
> I don't have a reference handy and the above aren't 1/12 of the
> corresponding years.  Are you certain about the coefficients?

I have checked these in another reference book & it gave exactly the same
values.  They relate to the moon, so they are not 1/12 of corr. year.

I had not realised that you defined 'year' as 3.153600e7 second = 365 days:
year                    P 3.153600e7 second     # exact

It would be clearer if it was expressed in days:
year                    P 365 day               # exact

I suggest also including:
leap_year               P 366 day               # exact
Julian_year             P 365.25 day            # exact
mean_calendar_year      P 365.2425 day          # exact

Mean calendar year is based on fact that in every 400 years there are 
303 ordinary years of 365 days:  303*365 = 110595 days
97      leap years of 366 days:   97*366 =  35502 days
                                   total = 146097 days
Thus mean calendar year = 146097/400 = 365.2425 days

I guess one could argue about definition of 'year' and 'month', but I think
year = 365 days, month = 1/12 year are reasonable.  For example, our climate
modelling output netCDF files have units 'year', 'month' and 'day' & we
commonly want year = 12 months = 365 days (although it is often necessary to
take into account the number of days in each month).

Harvey Davies,                              Home: +61 3 9772 5199
CSIRO Division of Atmospheric Research,     Work: +61 3 9586 7574
Private Bag No. 1, Mordialloc,               Fax: +61 3 9586 7600
Victoria 3195,  Australia                 E-mail: hld@xxxxxxxxxxxx