Add missing UCUM units

[keilw]

At the moment at least

SECTIONS §41-§43 skipped; implement later if needed

are missing from the UCUMsystem.

[garretwilson]

@keilw , I want to introduce you to a GlobalMentor developer @magnonasc. I'm going over the UCUM tasks right now. If you want you can assign this issue to him.

[keilw]

@garretwilson @magnonasc Thanks y lot for helping out with this.

[magnonasc]

Although there are a lot of UCUM units that are missing, there are a lot of types that still doesn't exist in the api, such as the units for fluid resistance, or refraction of a lens, or slope, so I'll add what I can, but I'll leave the ones that we don't have a type for when they're created in the api... It might be an issue for unit-api aswell. Nevermind, you have dimensionless that might be enough.

[keilw]

Please feel free to add quantities you are feel better suited than Dimensionless to https://github.com/unitsofmeasurement/uom-systems/tree/master/quantity

[magnonasc]

Sure, thank you!

[magnonasc]

I think it's better to use this same issue to implement the units correctly than creating another issue for that i.e., bring the comment blocks into functional code.

[magnonasc]

Heey @keilw, is it possible to add units for numbers from 1 to 10? It would help in cases like: 2lg(2 10*-5.Pa) where we need to use the base unit ONE and multiply it for whatever we want

[magnonasc]

Nevermind, I found that using this: PASCAL.divide(1E5).multiply(2).transform(new LogConverter(10)).multiply(2).asType(Level.class) might be enough, do you think it's okay?

[keilw]

The compiler will tell, as long as the build won't break, it should be OK. Runs on Java SE 8, hopefully a recent enough version, so as long as Java 9 won't mess up the type system, it's OK (not on CI, but locally I hope to test this soon for UoM-SE)

[magnonasc]

Some tests are failing.. It can't convert from mol/m3 to Dimensionless on PH, which is considered a Dimensionless by UCUM, any idea of what to do here?

public static final Unit<Dimensionless> PH = addUnit(MOLE.divide(LITER).transform(new LogConverter(10)).multiply(-1).asType(Dimensionless.class));

This is how I'm converting it.

[magnonasc]

There's a pull request ready to be made for this issue, but I messed up with it a little while checking out the branches and to not cause any conflict it will be made after #77 be merged, if approved

[magnonasc]

It's time to make the units in block of comments work

[magnonasc]

@keilw, in some units there's a quantity that's only used by one of them, so what do you think we should do with them? We could create each one of the quantities or find another category for the units (but they need to be proper).

examples:

peripheral vascular resistance unit - fluid resistance 
diopter - refraction of a lens
prism diopter - refraction of a prism

What do I think? I think that they should be created to match the UCUM specification, BUT, if you want to put them in one like Dimensionless, it's up to you.

@garretwilson, your opinion is welcome aswell.

[keilw]

@magnonasc @garretwilson I am not sure, if 2 specific refraction quantities are justified. https://en.wikipedia.org/wiki/Refraction talks about one Refraction and there are even others e.g. of sound. I think adding one and pointing to the Wikipedia page is what we also did for others. Same for https://en.wikipedia.org/wiki/Drag_(physics), which I would stick to Wikipedia having the most common physical term there as well.

[magnonasc]

yeeah, about Refraction I added just one.. We don't need to create them as the name of the unit will say what's the type of the refraction that we want.

[keilw]

@magnonasc How many of these are still missing? If it is a lot of them, maybe breaking both adding new units and creating JUnit tests for them (or aspects like formatting) into smaller pieces like "UCUM table 17" could be better. We are not monitored by a board or corporate management on how long issues are open, but it's still better to process them in a timely manner.

[frothga]

The UCUM parser did not recognize "wk" as week (7 days). WEEK is defined in UCUM.java, but seems to be missing from the UCUMFormat_*.properties files.

[alexanderkiel]

I use the UCUM system in the context of FHIR which is a standard for health care data exchange. FHIR defines a ValueSet of UCUM units which are used in the medical domain. Not all of this units are parseable by this implementation. Today I had especially the request for 10*3/uL (https://github.com/samply/blaze/issues/232) with is defined as "Thousands Per MicroLiter". Is the form 10*3 really defined in UCUM? I'm not sure.

What can I do to get more of the units in FHIR interest into this implementation?

[duckAsteroid]

Back in August I was experimenting with the UCUM implementation and found that the UCUM [drp] "drop" (a volume) was also not supported.

However, this was not one of a group of units just commented out in the implementation, I think it was missing completely.

There is a set of functional tests for UCUM that we could look to validate against? https://ucum.org/trac/wiki/FunctionalTests

On Wed, 21 Oct 2020 at 18:13, Alexander Kiel notifications@github.com wrote:

I use the UCUM system in the context of FHIR https://www.hl7.org/fhir/index.html which is a standard for health care data exchange. FHIR defines a ValueSet of UCUM units https://www.hl7.org/fhir/valueset-ucum-units.html which are used in the medical domain. Not all of this units are parseable by this implementation. Today I had especially the request for 103/uL (samply/blaze#232 https://github.com/samply/blaze/issues/232) with is defined as "Thousands Per MicroLiter". Is the form 103 really defined in UCUM? I'm not sure.

What can I do to get more of the units in FHIR interest into this implementation?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/unitsofmeasurement/uom-systems/issues/59#issuecomment-713725947, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHE4YD63Q5QRJLZHC2Y7ELSL4JD3ANCNFSM4DDU6NIA .

-- Regards,

Chris

[keilw]

Thanks for the input, we also had #173 but there was no feedback about retesting it after many units have been added to the latest SNAPSHOT already. Maybe you could give it a try instead. For very healthcare specific units that are not covered by UCUM we could use the Domain Health module and define what's necessary there.

[somayaj]

Hi, be willing to contribute if someone can give a rundown of what needs to be added? thx

[alexanderkiel]

I like to have [arb'U]. This is properly related to #174.