Missing, updated UDUNITS

[rschmunk]

I submitted an update to UnitsManagerDB (master) in #1003 to handle a dataset provided by a user who wanted to convert moles to molecules. The Units parser has been treating "molecule" as meaning "milli-olecule" and "molec" as "milli-olec", which was good for a laugh but not much else.

Looking through the UDUNITS 2 release notes, I see some other units that have been added or whose definitions have been re-defined and so either are not in or else don't match what is in UnitsManagerDB. For example, "potential_vorticity_unit" is missing and "dram" has been redefined. I could try to resolve some of that, but perhaps it's best addressed by the the UDUNITS 2 developer(s)?

[lesserwhirls]

The UDUNITS module in the THREDDS project is...interesting. Some of the code is generated by JavaCC. I am not sure of the version of UDUNITS codebase that was used in the generation, and I have been unable to find the grammar file used for the generation. Basically, this means there are parts of this codebase in which debugging and fixing things is nearly impossible (due to the generated code being unintelligible), and given the missing grammar file, we can't regenerate things to pick up fixes to the C library.

Now, perhaps extending the various DB classes can take us far in getting up to date with the unit support in UDUNITS2. My only three thoughts are:

1. tests
2. tests
3. tests

For sure this package needs some love.

Currently, the UDUNITS2 developer is @semmerson, or at least some tiny fraction of him. If we're just talking making the unit support in the various DB files match the level supported in UDUNITS2, I can look at that for sure. However, it won't be until after the 5.0 beta release of the TDS (by the end of February).

[DennisHeimbigner]

Is this in a separate repository? It is possible that either I can reverse
engineer the grammar or perhaps use the C version to get the grammar.

[lesserwhirls]

@DennisHeimbigner - this is just one of the modules in our main THREDDS repo udunits. However, it might be worth breaking this out into its own repo. It has no dependencies on netCDF-Java or the TDS, so it should be easy to break out. What do you think, @cwardgar?

[DennisHeimbigner]

I agree, in fact it should probably be part of the existing UDUNITS 2 repo.

[lesserwhirls]

Not sure how @semmerson would feel about having java code hanging out in the Unidata/UDUNITS-2 repo, especially since we don't know what the generated java code was based off of. It might be easier to have a UDUNITS-java repo until we clear that up and get the java code on the same level of functionality.

[cwardgar]

I think that UDUNITS is an excellent candidate to be broken off into its own repo.