Martin, thanks for a well stated summation of this problem.
My opinion is there are good reasons for prohibiting numeric scale and
offset in the units string, as indicated in section 3.1. (Decimal prefixes
are fine, as always.) Therefore I agree with Karl's #1 and #3, keep the
prohibition and do not change 3.1.
The CMIP6 data request itself is a problem because it actually violates CF
3.1. Best remedy would be to get CMIP6 authority to agree to alternate
units that do not use numeric scale factors. I would modify Karl's #2 like
this:
2) Replace the scaled units in the CMIP6 data request with unscaled units
and equivalent decimal prefix (e.g., replace "1e6 J" with "MJ"). However,
if the result is deemed not user friendly in some way, then decide on some
user friendly unscaled units, e.g. "J", and consumers will need to re-scale
data later, for some purposes.
Does anyone know why CMIP6 requested units in violation of CF 3.1?
--Dave
On Thu, Nov 1, 2018 at 10:58 AM, Taylor, Karl E. <taylor13 at llnl.gov> wrote:
> Hi Martin,
>
> I think the main point of the relevant paragraph in section 3.1, which
> reads
>
> "The Udunits syntax that allows scale factors and offsets to be applied to
> a unit is not supported by this standard. The application of any scale
> factors or offsets to data should be indicated by the *scale_factor* and
> *add_offset* attributes. Use of these attributes for data packing, which
> is their most important application, is discussed in detail in Section
> 8.1, "Packed Data"
> <http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/cf-conventions.html#packed-data>
> ."
>
> is that if you want to pack the data, the proper way to do that is through
> scale_factor and add_offset, not through the scale and offset options
> allowed by udunits in the units attribute. In general I find the
> "scale_factor" and "add_offset" attributes much easier to interpret than
> the scale and offset udunits options. I would therefore:
>
> 1) continue to forbid (or strongly discourage?) use of offset and scale in
> the units attribute (and modify the conformance document to be consistent
> with this).
>
> 2) replace the scaled units in the CMIP6 data request with units that
> might be less user friendly, but include equivalent prefix (e.g., replace
> "1e6 J" with "MJ")
>
> 3) replace in the standard names table all non-conforming units with
> conforming units. I don't think the new units need to be identical to the
> old (e.g., I would replace "1e-3 kg m-2" with "kg m-2", not "g m-2").
>
> Regarding this last point, note that the so-called "Canonical units" in
> the standard names table are there to provide guidance on what the quantity
> represents (e.g., W m-2 indicates the quantity is a flux density, not a
> flux). CF does not recommend a particular unit among all equivalent (e.g.,
> "kg" might appear in the canonical units, but "g" would be just as
> acceptable).
>
> Do others have opinions about this?
>
> best regards,
> Karl
>
>
> On 10/29/18 7:45 AM, Martin Juckes - UKRI STFC wrote:
>
> Hello Karl, Alison,
>
> As part of a separate discussion on 'months since' and 'years since' in time units<http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020648.html> <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020648.html>, Klaus pointed out the use of numerical scale factors in units strings, although allowed by Udunits, is prohibited by the CF convention in section 3.1. I'm raising this here because there are 3 standard names which make use of such scale factors in their canonical units, and a number of CMIP6 variables. The CF conformance document diverges from the standard and allows any string which is accepted by Udunits, and hence accepts such factors. The CF checker implements the version according to the conformance document, as does the cf-python code (and hence checks on the CMIP6 variables using cf-python didn't detect this problem).
>
>
> The CF standard names are:
>
> integral_wrt_depth_of_product_of_sea_water_density_and_salinity : 1e-3 kg m-2
>
> ocean_salt_x_transport, ocean_salt_y_transport: 1e-3 kg s-1
>
>
> In the CMIP6 data request, we have:
>
> 1.e6 J m-1 s-1 for atmospheric energy transport (intuadse, intvadse);
>
> 1e-3 kg m-2 for integral wrt depth of density and salinity (somint);
>
> 1e-6 m s-1 for saturated hydraulic conductivity;
>
> 1e3 km3 for sea ice volumes (sivoln, sivols);
>
> 1e6 km2 for sea ice areas (siarean, siareas, siextentn, siextents);
>
>
> Should we stick to the statement in the standards document ... and bring the conformance document etc into line, or could the standards document be interpreted more loosely?
>
>
> These scale factors could be replaced by prefixes, but I think there is some loss of legibility in some cases:
>
> 1e-3 kg --> g
>
> 1e6 J --> MJ
>
> 1e-6 m --> um
>
> 1e3 km3 --> hm3
>
> 1e6 km2 --> Mm2
>
>
> (here "um" is a micrometer, "hm" a hectometer and "Mm" a megameter).
>
>
> regards,
>
> Martin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20181101/fcacfc2a/attachment-0001.html>
Received on Thu Nov 01 2018 - 12:03:10 GMT
