uom-systems icon indicating copy to clipboard operation
uom-systems copied to clipboard

Add missing UCUM units

Open keilw opened this issue 9 years ago • 22 comments

At the moment at least

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

are missing from the UCUM system.

keilw avatar Mar 14 '17 22:03 keilw

@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.

garretwilson avatar Mar 18 '17 01:03 garretwilson

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

keilw avatar Mar 18 '17 17:03 keilw

~~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.

magnonasc avatar Mar 20 '17 02:03 magnonasc

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

keilw avatar Mar 20 '17 11:03 keilw

Sure, thank you!

magnonasc avatar Mar 20 '17 13:03 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 avatar Mar 21 '17 11:03 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 avatar Mar 21 '17 11:03 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?

magnonasc avatar Mar 21 '17 12:03 magnonasc

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)

keilw avatar Mar 21 '17 12:03 keilw

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 avatar Mar 21 '17 12:03 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 avatar Mar 21 '17 13:03 magnonasc

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

magnonasc avatar Apr 08 '17 22:04 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.

magnonasc avatar Apr 08 '17 23:04 magnonasc

@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.

keilw avatar Apr 09 '17 14:04 keilw

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.

magnonasc avatar Apr 09 '17 17:04 magnonasc

@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.

keilw avatar Apr 24 '17 13:04 keilw

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.

frothga avatar May 27 '20 15:05 frothga

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?

alexanderkiel avatar Oct 21 '20 17:10 alexanderkiel

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 [email protected] 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

duckAsteroid avatar Oct 22 '20 07:10 duckAsteroid

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.

keilw avatar Oct 22 '20 10:10 keilw

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

somayaj avatar Jul 06 '22 15:07 somayaj

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

alexanderkiel avatar Oct 26 '23 12:10 alexanderkiel