Closed adamchengtkc closed 4 months ago
Thanks for raising this issue Adam. As it stands, resqpy is built for RESQML v2.0.1 and its units of measure internal dictionary is auto generated from Energistics_Unit_of_Measure_Dictionary_V1.0.xml. We can explore whether using a more recent version of the Energistics dictionary within resqpy would lead to any adverse side effects. I think we might get away with moving the resqpy uom basis to a more recent version.
Hi @andy-beer thanks for the quick reply. We have no problem on the UOM front. We are creating PropertyKind where Density, thermal conductivity and fluid volume are in RESQML spec 2.0.1
These propertyKind also appears in resqpy https://github.com/bp/resqpy/blob/fa1903136cf4412ee61f20b6d6fb2014eb9a57d5/resqpy/olio/data/properties.json#L21063
Thanks for the clarification Adam – I had misunderstood where the issue is. This is now a bug fix rather than an enhancement (which is what I had first thought).
Hello Adam, I am now closing this issue as I believe it resolved by pull request #804, which is included in release v4.16.0. Please let me know if that release does not resolve things for you. Thanks again for taking the time to raise the issue, and apologies for the defect.
We are using the following PropertyKinds that are in RESQML spec 2.1
Density, thermal conductivity and fluid volume are not recognised by resqpy as StandardPropertyKind.
If these property is created by resqpy, it will create a LocalProepertyKind.
These are the StandardPropertyKind we generated using
xsdata
and used in our ETP library