[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[UDUNITS #ZNC-874842]: Outputting UDUnits Slope and Intercept from the API

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: [UDUNITS #ZNC-874842]: Outputting UDUnits Slope and Intercept from the API
  • Date: Thu, 30 Jul 2009 12:02:37 -0600
Peter,

> Thanks for the warning. I was guilty of making that assumption.
> 
> My question came from the fact that in ESMF we may have huge datasets
> over domains that may have been decomposed to run on different sets of
> processors.  The ESMF software already has a sparse matrix multiply
> mechanism built into it to perform operations on such datasets and I
> was thinking of using these routines to carry out physical unit
> conversions.   Consequently, I would need to pass unit conversion
> slope and intercept to these existing routines.
> 
> ESMF already has a class for metadata (the "Attribute" class) that
> includes a string for units.  I was planning to use ut_parse on these
> attribute strings, then testing the resultant ut_units with
> ut_are_convertible, then return the appropriate slope/intercept for
> the conversion, assuming ut_are_convertible returned UT_SUCCESS.
> Would this approach work, or is it headed toward brittle code?

Whether or not the code is brittle will depend on whether or not someone, 
somewhere, uses a non-linear unit.  I'm not aware of any such units being used 
in atmospheric and oceanic numerical models, but I wouldn't know.

> My example problem is from coupling an atmospheric model to an ocean
> model.  We want to be able to do this without having to modify the
> individual model codes.  If, for example, the ocean model outputs SST
> in Celsius but the atmos. model imports SST in Kelvin, we would like
> ESMF to detect this discrepancy (based on Attributes) and perform the
> unit conversion itself, as part of its coupling routine.  The SST-
> Kelvin conversion is a easy test case, but we'd like the coupler to be
> able to handle generic unit conversions.

If you wan't to go that route, then I suggest that you create a function that 
will test whether or not two units are related via a Gallilean transformation 
(by testing for compatibility, getting the coefficients, and then testing at 
another point).  This will ensure that your assumption holds before proceding.

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: ZNC-874842
Department: Support UDUNITS
Priority: Normal
Status: Closed