UCUM Parser error

[wog48]

Starting to play around with systems.uom.ucum I found that it can occur that the UCUMFormat can parse its own created string. The following code give a systems.uom.ucum.internal.format.TokenException:

public class ConversionError {

  public static void main(String[] args) {

    UnitFormat ucumFormat = UCUMFormat.getInstance(Variant.CASE_SENSITIVE);
    Unit<?> glomerular = ucumFormat.parse("mL/min/((173/100).m2)");
     System.out.println(ucumFormat.format(glomerular));
    ucumFormat.parse(ucumFormat.format(glomerular));
  }
}

[keilw]

I tried to run the same string through a UCUM parser of Eclipse UOMo, but it did not work so far. The problem is, that the expression gets formatted mL.10^2/min/173/m2 or mL.10²/min/173/m2 (the latter is PRINT, not sure, why it has m2 without upper-score) so it is not exactly identical to the initial one. Did you check, if everything makes mathematical sense?

[wog48]

I'm trying to create some code that is able to parse a given uom and convert it into its UCUM representation to store this as a string on DB. Therefore it is imported for me that a created string representation can be parsed again. The example comes from Glomerular filtration rate (GFR). The usually given uom is mL/min/1.73m2. There is a ticked trying to discuss the "correct" UCOM representation: [FAQ] How to write "mL/min/1.73 m2"?, also describing why this is the correct uom.

Anyhow, for me it is important that the formatter is able to parse the string it has created.

I'll like to add the dependencies I'm using:

    <dependency>
      <groupId>systems.uom</groupId>
      <artifactId>systems-ucum-java8</artifactId>
      <version>0.7.2</version>
    </dependency>
    <dependency>
      <groupId>systems.uom</groupId>
      <artifactId>systems-quantity</artifactId>
      <version>0.7.2</version>
    </dependency>
    <dependency>
      <groupId>systems.uom</groupId>
      <artifactId>systems-common-java8</artifactId>
      <version>0.7.2</version>
    </dependency>

[keilw]

I'm afraid, your initial string "mL/min/((173/100).m2)" is not a correct UCUM expression. I built the current Eclipse UOMo 0.7 distro (https://github.com/eclipse/uomo/tree/0.7 will publish to update site soon, the current one is missing at least an XMLPull implementation) and installed it into a recent Eclipse IDE (Oxygen, Neon should also work, can't guarantee for older ones because of ICU4J etc.)

Running this small example:

public class UomoTest {
    public static void main(String[] args) {
        String message = "";
        try {
            InputStream stream = new FileInputStream("C:/temp/ucum-essence.xml");
            UcumService service = new UcumEssenceService(stream);
            //message = service.analyse("mL/min/((173/100).m2)");
            message = service.analyse("mL.10^2/min/173/m2");
            //message = service.analyse("mL/min/1.73m2");
        } catch (RuntimeException | FileNotFoundException ex) {
            message = ex.getMessage();
        }
        System.out.println(message);
    }
}

show, that the formatted output by the UCUMFormat "mL.10^2/min/ 173/m2" is a correct UCUM expression that can be parsed. All the other two variants including what you actually wanted to use are not and lead to UCUM errors like:

Error processing unit 'mL/min/((173/100).m2)': unexpected token looking for a symbol or a number' at position 7

As the UOMo UCUM bundle and parser were written by Graham Grieve who is an active UCUM and HL7 participant, I trust they are correct. This module also passes the UCUM functional test. It seems the JSR 363 UCUM parser has some issues based on the "native" UCUM bundle we shall investigate and address, but the formatters behave properly and produce a compliant UCUM string.

Sorry having to install UOMo via P2 repo. I hope maybe with help by @duckAsteroid or other committers we could get Maven to produce both a P2 repo and a more "traditional" Maven compatible one. If everything is on the classpath the simple demo app runs and it shows whether a UCUM string is valid or not.

So the parser has a problem, but unless UCUM accepts it the strings you used also don't seem UCUM compliant.