When considering many atmospheric measurements it is important to know if it was made in 'ambient conditions' or 'standard temperature and pressure' conditions.

I've seen many ways these might be represented in the units of a measurement, for example: 'per std cc' or 'cm-3 at stp'. This information is included in a few CF standard names (e.g. 'number_concentration_of_aerosol_particles_at_stp_in_air'), but it's more general than that.

It would be great to be able to represent this consistently in the units, even if it's just in the form of a flag to indicate if the measurement represents ambient conditions or not.

Hi,

I found the ut_compare() function, as currently existing the the udunits2 library, to be too strict for my needs.

In particular, for some units, the comparison between the original unit and a back-and-forth transformation to text expression fails. In other words : for some values of unit, ut_compare(unit, (ut_parse(ut_format(unit))) != 0.

I know that a decimal textual representation of a real number cannot be exact, but I believe that we can safely assume that two units whose relative difference is less than 10^-8 or 10^-10 are identical. So, I wrote my own, more tolerant, ut_compare function (see attached source code).

My questions are :

• is this pernickety behaviour intended, or did someone just wrote the test "a==b" for floating-point values instead of the usual approximate test ?
• Am I the only one interested in a more lenient version of ut_compare() ? Would it be a good idea to add a ut_tolerant_compare() function to the udunits2 library ?

Regards,
Bruno.

Bruno Piguet
Météo-France
Équipe GMEI/TRAMM
CNRM/GAME, UMR3589 CNRS/Météo-France
Fixe : +33 561079659
Fax : +33 561079627
Postal : 42 Av. G. Coriolis
31057 Toulouse CEDEX 1

when attempting to install with the pacaur command or pamac GUI tool:

Preparing...

Building udunits...
Cloning into 'udunits'...
remote: Counting objects: 29, done.        
remote: Compressing objects: 100% (25/25), done.        
remote: Total 29 (delta 4), reused 29 (delta 4)        
Unpacking objects: 100% (29/29), done.
==> Making package: udunits 2.2.26-1 (Mon 18 Jun 2018 12:23:47 BST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Downloading udunits-2.2.26.tar.gz...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:05:02 --:--:--     0
curl: (56) response reading failed
==> ERROR: Failure while downloading ftp://ftp.unidata.ucar.edu/pub/udunits/udunits-2.2.26.tar.gz
    Aborting...

When attempting to install from the tar.gz file:

[oscarsouth@OS-ARC ~]$ pacaur -U $HOME/Downloads/udunits-2.2.26.tar.gz
loading packages...
error: missing package metadata in /home/oscarsouth/Downloads/udunits-2.2.26.tar.gz
error: '/home/oscarsouth/Downloads/udunits-2.2.26.tar.gz': invalid or corrupted package

Is there any way to install this on my system? There are a number or R packages I need which require udunits2 as a dependency.

Thanks,
Oscar

The publicised URLs for source code releases aren't stable - only the latest releases of each minor version exist in ftp://ftp.unidata.ucar.edu/pub/udunits/. It'd helpful if all the releases could be available in some form. The simplest way to acheive this would be to use git tags/GitHub releases.

A recently launched NASA EV satellite remote sensing mission known as Cyclone Global Navigation Satellite System (CYGNSS) is dependent upon fundamental GPS measurements from a remote sensing technique known as Global Navigation Satellite System Reflectometry (GNSS-R). It's similar to other radar-based spaceborne remote sensing techniques, however it depends on GPS-based specular reflection on the Earth's surface. There is likewise a receiver antenna on each of the CYGNSS platforms that requires the gain signal a prerequisite to perform science measurements. More can be read about CYGNSS here: https://podaac.jpl.nasa.gov/CYGNSS

As a result of reviewing the Level 1 metadata, it has come to our attention that the fundamental antenna gain unit, dBi, is not available in UDUNITS-2. As a representative of the CYGNSS Project, I would like to propose the following definition for dBi:

The gain of an antenna in dBi is the gain in the direction of maximum radiated intensity with respect to an antenna that emits the same total power uniformly in all directions (an isotropic antenna). If a given antenna at a given distance radiates at an intensity of I_a (power per unit area) in the direction of peak radiated intensity, then with respect to a theoretical lossless isotropic antenna radiating the same total power and an intensity I_i at the given distance, the gain of the antenna G in dBi is given by: G = 10*log 10 (I_a/I_i).

Please let me know if you need any additional information to process this request.

Hi,

I've successfully got UDUnits working within C# in Visual Studio and am trying to do a simple temperature conversion from Celsius to Fahrenheit and vice versa. I am running in to some rounding errors.

e.g 32.0 degF = 0.000000000000035527136788005009 degC

I tried debugging the udunits dll, but the only thing I could see is that the Galilean parameters for the conversion seemed to have a rounding error to start with. When doing 0.0 degC to degF, the fromProduct->Galilean->scale is 1.7999999999999998 and the fromProduct->Galilean->intercept is -459.67000000000002 (line 3635 in unitcore.c). I am unable to figure out exactly how these values are set so far.

Is this something that can be investigated and fixed?

Regards,
Mark

The unit "bit" was dropped in going from UDUNITS-1 to UDUNITS-2. Put it back if it doesn't cause problems.

The UDUNITS package incorrectly handles a "naked hour" specification in offset time units like "hours since 2014-03-02 06".

This must be fixed.

The new release of UDUNITS2 (as available at ftp://ftp.unidata.ucar.edu/pub/udunits/udunits-2.2.21.tar.gz) seems to be missing a couple of files that are needed by the Windows install process:

...

-- Configuring done

CMake Error at lib/CMakeLists.txt:62 (add_library):
  Cannot find source file:
    tsearch.c
  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx

CMake Error at prog/CMakeLists.txt:19 (add_executable):
  Cannot find source file:
    XGetOpt.c
  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx

...

We've encountered this in conda-forge/udunits2-feedstock#9 and SciTools/conda-recipes-scitools#227.

Assuming that the math functions are not in the standard C library, then a reference to the math library should be added to the build of the UDUNITS library so that the math library will automatically be included in builds of applications. See, for example, https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition for a description of this issue on Ubuntu systems.

It would be useful to support units of the form # s-1 where # is a dimensionless number. This can be present in some data sources e.g. aircraft readings. We are looking to implement this in the Python package cf_units (see SciTools/cf-units#88 & SciTools/cf-units#90). Is there any scope for supporting this?

cc @pelson @duncanwp

Could you add an option to link with static CRT

https://msdn.microsoft.com/en-us/library/abx4dbyh.aspx

this avoids shipping/dependency of Microsoft DLLs

this can be done in CMake with

#//////////////////////////
#compile as C++/static CRT on Visual Studio 
#//////////////////////////

set(MSVC_USE_STATIC_CRT off CACHE BOOL "Use MT flags when compiling in MSVC")
if (MSVC)
  if (MSVC_USE_STATIC_CRT)
     message("-- Using static CRT linking ${MSVC_USE_STATIC_CRT}")
     foreach(flag_var CMAKE_CXX_FLAGS_DEBUG CMAKE_CXX_FLAGS_RELEASE
                          CMAKE_CXX_FLAGS_MINSIZEREL CMAKE_CXX_FLAGS_RELWITHDEBINFO
                          CMAKE_C_FLAGS_DEBUG CMAKE_C_FLAGS_RELEASE
                          CMAKE_C_FLAGS_MINSIZEREL CMAKE_C_FLAGS_RELWITHDEBINFO)
       string(REPLACE "/MD" "/MT" ${flag_var} "${${flag_var}}")
     endforeach()
  endif()
endif()

an option of the package is to use static CRT

I set up a repository that lists all the dependencies

https://github.com/pedro-vicente/nco_bld

zlib
szip
hdf5
curl
netcdf
expat
udunits
gsl
antlr

for each one, the CMake support for static CRT varies from

non existing
existing as non default
existing as default ( for GSL)

if Microsoft includes static CRT as an option, the CMake scripts should allow us to choose also

the reason being the shipped final package with static CRT does not need any additional DLLs.
The end user of the software might or might not have those DLLs installed, we don't know.
If they don't, the package is broken

#include <stdio.h>
#include "udunits.h"

int main()
{
    ut_system* sys = ut_read_xml(NULL);
    ut_unit* u = ut_parse(sys, "mm2 day-2", UT_ASCII);

    u = ut_divide(u, u);

    char buf[128];
    ut_format(u, buf, 128, UT_ASCII);
    printf("%s\n", buf);
}

Output:

1 1

However, this unit doesn't compare equal to either "1" or "1 1" defined with:

ut_unit* one = ut_parse(sys, "1", UT_ASCII);
ut_unit* one_one = ut_parse(sys, "1 1", UT_ASCII);

udunits2 seems to parse and understand timezones:

$ udunits2 -H 'second since 1970-01-01 00:00:00 -1:00' -W 'second since 1970-01-01 00:00:00 -0'
    1 second since 1970-01-01 00:00:00 -1:00 = 3601 (second since 1970-01-01 00:00:00 -0)
    x/(second since 1970-01-01 00:00:00 -0) = (x/(second since 1970-01-01 00:00:00 -1:00)) + 3600

but it is unclear how to convert values using timezones:

$ udunits2 -H '86400 second since 1970-01-01 00:00:00 -1:00' -W 'second since 1970-01-01 00:00:00 -0'
udunits2: Units are not convertible
$ 

Is it possible? How?

In doing a little initial fuzzing of udunits I hit this assert of scale within seconds. Asserts should be for things that should never happen. My fix below probably isn't the best, but it at least lets me continue on with fuzzing.

static ut_unit*
galileanNew(
    double		scale,
    const ut_unit*	unit,
    double		offset)
{
    ut_unit*	newUnit = NULL;	/* failure */

    /* assert(scale != 0); */
    if (scale == 0) return NULL;

The fuzzer (which isn't particularly good for coverage):

#include <stddef.h>
#include <stdint.h>
#include <string>
#include <vector>

extern "C" int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
  const string data2(reinterpret_cast<const char *>(data), size);

  ut_set_error_message_handler(ut_ignore);

  ut_system *unit_system = ut_new_system();
  auto unit_system_cleaner =
      gtl::MakeCleanup([unit_system] { ut_free_system(unit_system); });

  ut_unit *unit = ut_parse(unit_system, data2.c_str(), UT_ASCII);
  auto unit_cleaner =
      gtl::MakeCleanup([unit] { ut_free(unit); });

  constexpr size_t kBufSize = 1000;
  std::vector<char> buf(kBufSize);
  CHECK_GE(static_cast<int>(kBufSize), ut_format(unit, &buf[0], kBufSize, 0));

  return 0;
}

Some of the inputs to ut_parse that trigger the assert include 360-191, 229991-091

@semmerson and @WardF I'm trying to build UDUNITS using CMAKE with Visual Studio 2008 (Visual Studio 9). From the Visual Studio 2008 Command Prompt, I typed:

cd c:\programs\udunits-2.2.16
mkdir build
cd build
../cmake

and I get back

c:\programs\udunits-2.2.16\build>cmake ..
DEFAULT_UDUNITS2_XML_PATH = "C:\Program Files\udunits\share\udunits\udunits2.xml
"
-- Could NOT find EXPAT (missing:  EXPAT_LIBRARY EXPAT_INCLUDE_DIR)
CMake Error at CMakeLists.txt:128 (MESSAGE):
  Unable to find an EXPAT library.

-- Configuring incomplete, errors occurred!

I tried installing expat for windows but that didn't help. Do I need to build it with CMAKE & same compiler?

David Robertson [email protected] via unidata.ucar.edu

to udunits
Hi,

With UDUNITS I can type something like "256996800 seconds since 2006-01-01 00:00:00" in the "You have:" and then just leave "You want:" blank and it will give me:

Definition: "256996800 seconds since 2006-01-01 00:00:00.0000 UTC"
"256996800 seconds since 2006-01-01 00:00:00" is 2014-02-22 12:00:0 UTC

However, with UDUNITS2 it just replies "256996800 s" which is pretty useless in my situation. I am interested in the "is 2014-02-22 12:00:0 UTC" portion of the answer. Is there a way to get UDUNITS2 to behave in the old way? Preferably using the -H and -W flags.

Thanks,
Dave

When performing a static build XML_STATIC must be #defined before expat.h is included.

This can be achieved by adding

ifndef DLL_UDUNITS2

define XML_STATIC

endif

Where DLL_UDUNITS2 is a pre-processor definition added by CMake for dynamic builds only.

When Unicode encoding is set on Windows there are some compiler warnings about casting TCHAR* to char*. Running udunits2 gives garbage, presumably because the encodings are all wrong.

We've hit an issue where the "units" of salinity are tripping over some code of ours, we've documented this a little better at PCMDI/pcmdi_metrics#162

It would be helpful for a number of software packages (noted above and also CMOR: PCMDI/cmor#12) if UDUNITS-2 could deal with salinity equivalence.

How can we get some better coverage of salinity "units" into a future release of UDUNITS-2?

Currently, udunits2 (version 2.2) uses "ua" as symbol for the astronomical unit, and 1 ua is equal to 149,598,000,000 m

$ udunits2 -H ua -W m
    1 ua = 1.49598e+11 m
    x/m = 1.49598e+11*(x/ua)

$ udunits2 -H au -W m
udunits2: Units are not convertible

However, according to this resolution of the XXVIIIe General Assembly of International Astronomy Union (2012), the symbol should now be "au" and 1 au should be equal to 149,597,870,700 m exactly.

On Windows, UDUNITS-2 fails if you try and use it on a drive that is not the one it is installed to. Below is a trace from the Windows command-line that demonstrates this. In this trace I have UDUNITS-2 installed to C: but it does not work if I try to use it from U::

[cubebrowser] U:\>udunits2 --help
Usage:
    udunits2 -h
    udunits2 [-A|-L|-U] [-r] [-H have] [-W want] [XML_file]

where:
    -A         Use ASCII encoding (default).
    -L         Use ISO-8859-1 (ISO Latin-1) encoding.
    -U         Use UTF-8 encoding.
    -h         Help.  Print this message.
    -r         Reveal any problems in the database.
    -H have    Use "have" unit for conversion. Default is reply to prompt.
    -W want    Use "want" unit for conversion. Empty string requests
               definition of "have" unit. Default is reply to prompt.
    XML_file   XML database file. Default is "C:\Users\peter.killick\App\Miniconda\envs\cubebrowser\Library\share\udunits\udunits2.xml".

[cubebrowser] U:\>udunits2
udunits2: Character encoding not specified and not settable from environment variables LC_ALL, LC_CTYPE, or LANG. Assuming ASCII encoding.
udunits2: Couldn't initialize unit-system from database "C:\Users\peter.killick\App\Miniconda\envs\cubebrowser\Library\share\udunits\udunits2.xml": No such file or directory

[cubebrowser] U:\>c:

[cubebrowser] C:\Users\peter.killick>udunits2
udunits2: Character encoding not specified and not settable from environment variables LC_ALL, LC_CTYPE, or LANG. Assuming ASCII encoding.
You have: K
You want:

This happens whether using UDUNITS-2 from the command-line (as above) or calling UDUNITS-2 within another application. The latter of these is tripping us up in the cf_units conda recipe for Windows.

Hello,

I have two suggestions for changes to Unidata's UDUNITS web pages.

1.  Fix an apparent mistake in the page describing Unit Grammar, at
   

http://www.unidata.ucar.edu/software/udunits/udunits-2.0.4/udunits2lib.html#Grammar.

This text defines Timestamp:

 Timestamp: one of
         DATE
         DATE CLOCK
         DATE CLOCK CLOCK
         DATE CLOCK INT
         DATE CLOCK ID
         TIMESTAMP
         TIMESTAMP INT
         TIMESTAMP ID

I think an explicit is needed before each 'CLOCK'. I am assuming that, for instance, 'DATE CLOCK' means a string formatted like '2014-04-28 23:59:59'.

2.  Place a link to the Unit Syntax documentation in a prominent place on a page close to the Home page.
   

Many times I have unsuccessfully searched for a definition of UDUNITS syntax on this website. I recently stumbled on what I sought as Section 6 'Unit Syntax' of the page on the UDUNITS-2 C API, at www.unidata.ucar.edu/software/udunits/udunits-2.0.4/udunits2lib.html#Syntax. Having no interest in the C API, I had never thought to navigate to this page. While I understand that UDUNITS[-2] is first of all a software package, the adoption of the UDUNITS time format by the CF Conventions means that there is a large set of users who need just the syntax itself. A good place for a link might be on the page at
http://www.unidata.ucar.edu/software/udunits/udunits-2.2.19/doc/udunits/udunits2.html

Regards,
Ian

Ian Grant | Satellite Specialist

Use the XSLT file from John Graybeal.

@WardF , I tried building UDUNITS2 with CMAKE following your directions:

$ cd c:\programs\udunits-2-master
$ mkdir build
$ cd build
$ cmake .. -DCMAKE_PREFIX_PATH=c:\programs\expat32_2.1.0  -G"Visual Studio 9 2008"
$ cmake --build . --config Release --target libudunits2
$ cmake --build . --config Release --target udunits2

but got back:

c:\RPS\UDUNITS-2-master\build>cmake .. -DCMAKE_PREFIX_PATH=c:\programs\expat32_2
.1.0 -G"Visual Studio 9 2008"
-- Building Windows DLL: ON
DEFAULT_UDUNITS2_XML_PATH = "C:\\Program Files (x86)\\udunits\\share\\udunits\\u
dunits2.xml"
-- Could NOT find EXPAT (missing:  EXPAT_LIBRARY EXPAT_INCLUDE_DIR)
CMake Error at CMakeLists.txt:161 (MESSAGE):
  Unable to find an EXPAT library.

It would be nice if the udunits source has a configure script ready to go. Not all systems have autotools properly installed.

For instance, Apple doesn't deliver autotools with the compilers for OS-X.

It's common practice for source distributions to have autotools already run, so you can just do:

./configure && make && make install

A Python API would be awesome. I could find some discussion about this at http://www.unidata.ucar.edu/support/help/MailArchives/udunits/msg00661.html; however, the link you provided in that email doesn't seem to work. Is that work something similar available anywhere?

In the FTP repository, so that scripts can auto-download the latest release.

Create binary yum(1) and apt-get(1) repositories for the package and incorporate them into the continuous-delivery pipeline.

The UDUNITS-2 package needs a Fortran API. The easiest/best way to do it, I think, would be to use the Fortran 2003 mechanism for calling C functions by creating an interface module.

Apparently, it's missing.

Having the "..." element both in and out of the "aliases" element apparently results in a segmentation fault.

In the course of answering a question re: UDUNITS-2 Issue #16, I've discovered that the latest code in master fails to compile on Windows with Visual Studio. The culprit is the auto-generated file scanner.c, which has introduced a dependency on unistd.h. This issue is clearly known on other platforms, as a lack of unistd.h has been mitigated in autotools-based builds.

The fix should be fairly simple; I forked and took a quick pass, but the fix I added didn't work as expected. I will pursue as best I can, although my focus right now is on some netcdf-c issues.

Hi udunits-2 devs!

In the unidata webpage we have links for releases 2.2.18 2.1.24, 2.0.4, and even 1.12.10. And in the GitHub release page we have from 2.2.0 to 2.2.17, but no 2.2.18. That is a little confusing. It would be nice to have at least one place with all the releases, legacy and latest alike.

Also, 2.2.18 release seems to be missing tsearch.c, which is crucial for windows builds. See ioos/conda-recipes#143.

Was this intentional? Is there a chance to get a 2.2.18 GitHub release with the full source that we can compile on Windows?

I was updating the conda-forge build of udunits to 2.2.26 and found that stdbool.h is not available in Visual Studio 9 (but is for v14). This essentially means that it is not possible to build udunit 2.2.26 for Windows and Python 2.

The relevant PR on conda-forge was conda-forge/udunits2-feedstock#16. With output at https://ci.appveyor.com/project/conda-forge/udunits2-feedstock/build/1.0.52. Specifically:

[ 62%] Building C object lib/CMakeFiles/libudunits2.dir/unitcore.c.obj
unitcore.c
C:\bld\udunits2_1515645928472\work\UDUNITS-2-2.2.26\lib\unitcore.c(65) : fatal error C1083: Cannot open include file: 'stdbool.h': No such file or directory
NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1.0\VC\bin\cl.exe' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
Traceback (most recent call last):
  File "C:\Miniconda\Scripts\conda-build-script.py", line 5, in <module>
    sys.exit(conda_build.cli.main_build.main())
  File "C:\Miniconda\lib\site-packages\conda_build\cli\main_build.py", line 342, in main
    execute(sys.argv[1:])
  File "C:\Miniconda\lib\site-packages\conda_build\cli\main_build.py", line 333, in execute
    noverify=args.no_verify)
  File "C:\Miniconda\lib\site-packages\conda_build\api.py", line 97, in build
    need_source_download=need_source_download, config=config)
  File "C:\Miniconda\lib\site-packages\conda_build\build.py", line 1524, in build_tree
    config=config)
  File "C:\Miniconda\lib\site-packages\conda_build\build.py", line 1114, in build
    windows.build(m, build_file, config=config)
  File "C:\Miniconda\lib\site-packages\conda_build\windows.py", line 232, in build
    check_call_env(cmd, cwd=src_dir)
  File "C:\Miniconda\lib\site-packages\conda_build\utils.py", line 628, in check_call_env
    return _func_defaulting_env_to_os_environ(subprocess.check_call, *popenargs, **kwargs)
  File "C:\Miniconda\lib\site-packages\conda_build\utils.py", line 624, in _func_defaulting_env_to_os_environ
    return func(_args, **kwargs)
  File "C:\Miniconda\lib\subprocess.py", line 186, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['cmd.exe', '/c', 'bld.bat']' returned non-zero exit status 1
Command exited with code 1

Given how simple it might be to work around (creating a stdbool along the lines of https://stackoverflow.com/a/17249460/741316) I was wondering what the perefered solution was? I could stub in the necessaries on conda-forge, but would personally prefer to fix them here.

The relevant commit is 9335848, which specifically cites AppVeyor CI testing (Windows). This raises the possibility that I've either completely messed up, or the AppVeyor is missing this config (VC9).

Thanks in advance.

In the documentation, it says:

If you use ut_read_xml(), then you should not normally need to add any new prefixes to a unit-system.

I can't seem to figure out something as simple as conversion from kilometer to meter. I get a NULL ut_type * return when asking for kilometer, although I can prefix kilo to e.g. gram and get a valid type, so I'm assuming the prefixes have loaded correctly. Color me confused.

Please see this example:

#include <stdio.h>

#include "udunits2.h"

int main(int argc, char const *argv[])
{
  ut_system *system = ut_read_xml(NULL);
  ut_unit *from, * to;
  cv_converter *converter;
  double result;

  // kilograms -> grams
  from = ut_get_unit_by_name(system, "kilogram");
  to = ut_get_unit_by_name(system, "gram");
  converter = ut_get_converter(from, to);
  printf("from: %p, to: %p\n", from, to);
  result = cv_convert_double(converter, 12.34);
  printf("kg -> g: %f\n", result);
  cv_free(converter);

  // kilometer -> meter
  from = ut_get_unit_by_name(system, "kilometer");
  to = ut_get_unit_by_name(system, "meter");
  printf("from: %p, to: %p\n", from, to);
  converter = ut_get_converter(from, to);
  result = cv_convert_double(converter, 12.34);
  printf("km -> m: %f\n", result);
  cv_free(converter);

  ut_free_system(system);

  return 0;
}

Which produces the following output:

$ UDUNITS2_XML_PATH=`pwd`/udunits-2-build/share/doc/udunits/udunits2.xml DYLD_LIBRARY_PATH=`pwd`/udunits-2-build/lib ./a.out
Definition of "au" in "/Users/rene/Code/UDUNITS-2/udunits-2-build/share/doc/udunits/udunits2-accepted.xml", line 123, overrides prefixed-unit "1.6605402e-45 kilogram"
Definition of "kt" in "/Users/rene/Code/UDUNITS-2/udunits-2-build/share/doc/udunits/udunits2-common.xml", line 105, overrides prefixed-unit "1000000 kilogram"
Definition of "microns" in "/Users/rene/Code/UDUNITS-2/udunits-2-build/share/doc/udunits/udunits2-common.xml", line 411, overrides prefixed-unit "1e-15 second"
Definition of "ft" in "/Users/rene/Code/UDUNITS-2/udunits-2-build/share/doc/udunits/udunits2-common.xml", line 522, overrides prefixed-unit "1e-12 kilogram"
Definition of "yd" in "/Users/rene/Code/UDUNITS-2/udunits-2-build/share/doc/udunits/udunits2-common.xml", line 531, overrides prefixed-unit "8.64e-20 second"
Definition of "pt" in "/Users/rene/Code/UDUNITS-2/udunits-2-build/share/doc/udunits/udunits2-common.xml", line 785, overrides prefixed-unit "1e-09 kilogram"
Definition of "at" in "/Users/rene/Code/UDUNITS-2/udunits-2-build/share/doc/udunits/udunits2-common.xml", line 1250, overrides prefixed-unit "1e-15 kilogram"
Definition of "ph" in "/Users/rene/Code/UDUNITS-2/udunits-2-build/share/doc/udunits/udunits2-common.xml", line 1880, overrides prefixed-unit "3.6e-09 second"
Definition of "nt" in "/Users/rene/Code/UDUNITS-2/udunits-2-build/share/doc/udunits/udunits2-common.xml", line 1889, overrides prefixed-unit "1e-06 kilogram"
from: 0x7fb36f800600, to: 0x7fb36f800b80
kg -> g: 12340.000000
from: 0x0, to: 0x7fb36f800c70
ut_get_converter(): NULL unit argument
Segmentation fault: 11

I'm assuming this is not a bug, so what am I doing wrong?

Currently, there's no configure(1) script in the source distribution.

Add a configure(1)-based build to the acceptance testing.

It looks like the unit with def '0.9 arc_degree' (in the Plane Angle section of udunits2-common.xml) is mistakenly given the alias 'grade'. Various web sources indicate this should be 'grad', aka gon.

Since the traditional LICENSE file has been changed to COPYRIGHT in 2.2.0, Github doesn't provide the easy overview as usual. Furthermore I can't seem to find any wording on "licensing" in general on the support site, which leaves me unsure of the exact terms.

By the look of it, it seems to most resemble the BSD 4-clause license, albeit with slight alterations.

According to https://tldrlegal.com/license/4-clause-bsd, besides copyright and license inclusion in any derivative work, there's also an attribution clause. Is that likewise the case for UDUNITS-2?

Also, is usage of UDUNITS-2 allowed for use in commercial software as well? Given the above provisions are met of course.

From Charlie Zender at UCI:

Now I understand what you mean by saying "1" and "8" can be used now.
However that workaround is a dead-end for user-friendliness, as
evidenced by my confusion as to the meaning of your suggestion.
And it does not accrue the UDUnits benefits of automagically
converting plain English prefixes to the numeric values, e.g.,
megabytes = 1000000 * bytes. No one wants to ask NCO to hyperslab
all data rates between 1.234e6 8's and 5.678e6 8's, nor
1.234 mega8's and 5.678e6 mega8's. That would be silly.

So. The case for including "bits" and "bytes" really makes itself.
Users would benefit if these common units of measurement were
integrated into UDUnits. Our case is an instrument that will fly on
a NASA satellite (ICESat2) and the Level1 datasets archive sensor
information and disk information like "bits per second" and "bytes per
second". Would be great if UDUnits-enable software could automatically
translate that into "megabytes per fortnight" and "decabits per day".

The ambiguity of whether byte should mean 8 bits (commonly accepted)
or should be reserved for the smallest addressable size on a given
architecture is worth noting. Octet does mean 8 bits, so that is
unambiguous. Nevertheless, people who deal with non-8-bit bytes
already know that the rest of the world thinks a bit is 8 bytes.
So byte = 8 bits is unlikely to adversely impact anyone.
Adopting this definition into UDUnits will help broaden its utility
in fields like electrical engineering, and computer science.

I looked into the Decimal vs. Binary (1000 vs. 1024) issue.
Seems pretty clear that Decimal is the way to go so mega means the
same for information as for SI units. "kibi"/"mebi" and friends
could be added for completeness.

I don't understand the following:

$ udunits2 
You have: degree C
You want: degree_C
udunits2: Units are not convertible
You have: degree_C
You want: degrees_C
    1 degree_C = 1 degrees_C
    x/degrees_C = (x/degree_C)
You have: degree C
You want: degrees C
    1 degree C = 1 (degrees C)
    x/(degrees C) = (x/(degree C))

Hello

The CF community would like to explore the additon of a new 'unit' to udunits, that of
'no_unit'

We would like this to be an accepted string for a unit according to udunits, with the same behaviour as a unit of
''
That is, that it will not operate or compare with any other unit, it is not a unit. This is important for capturing categorical entities, where no unit of measure is to be used. The syntax of
unit = ''
is deemed unclear by the community, who would prefer an explicit and human readable version
unit = 'no_unit'

For a long time in CF a lack of a units string has been equivalent to a unit of '1' which has markedly different behaviour, so we cannot just omit the unit in these cases.

As CF defers to udunits for 'what is a valid unit' it would be very helpful if this could be included.

I have looked into the xml files to see if I could add this, but I cannot see how to define the null behaviour we get if we have a unit of
''

thank you
mark

Basically I want to parse a string like “days since 1895-01-01”, then convert a value to date and a date to value

When the udunits2(1) utility is invoked with the "-v" option, it should print the version string (e.g., "2.2.1") and exist. This will allow users to determine what version of the package they're using, even if installed from a binary distribution.

When I try to compile, using

autoconf
./configure

I see:

edzer@gin-edzer:/tmp/UDUNITS-2$ autoconf 
edzer@gin-edzer:/tmp/UDUNITS-2$ ./configure
configure: error: cannot find install-sh, install.sh, or shtool in build-aux "."/build-aux

What did I overlook?

Various data producers in the NASA earth remote sensing community are requesting a standard unit to represent Decibels (dB) for Radar data, such as for scatterometers, altimeters, and synthetic aperture radars. Having these units available in the standardized Udunits database would provide a significant contribution toward data provenance and would likewise help meet CF compliance standards, which many NASA data producers are making significant efforts to achieve.

More details in defining this unit can be provided as needed.

This request corresponds to Unidata ticket #VZX-973749.

Hi, according to Units and Symbols Found in the UDUNITS2 Database, an acre is

unit of area in the US Customary System, used in land and sea floor measurement, equal to 43560 square feet (exact).

If that is true, then the following is incorrect:

library(units)

ad <- with(ud_units, 1 * acre)

ad
1 acre


units(ad) <- with(ud_units, ft^2)

ad
43560.17 ft^2

If the current definition of acres is incorrect within units, then will you correct it then?

Thank you.

Irucka Embry

The unistd.h file does not exist on a windows system - from the comments in scanner.c it is not necessary and its use can be removed by #defining YY_NO_UNISTD_H. Adding

ifdef WIN32

define YY_NO_UNISTD_H

endif

just before the #include allows libudunits2 to build