Numeric precision

[atomczak]

I see the current examples have varying numeric precision:

• six:
  https://github.com/buildingSMART/IFC5-development/blob/828ee54fcfa56db3c2ca9c55d1e505f5532e3dcd/examples/Hello%20Wall/hello-wall.ifcx#L1457C15-L1457C23
• seven:
  https://github.com/buildingSMART/IFC5-development/blob/828ee54fcfa56db3c2ca9c55d1e505f5532e3dcd/examples/Hello%20Wall/hello-wall.ifcx#L1185C12-L1185C24
• or even scientific notation:
  

  IFC5-development/examples/Hello Wall/hello-wall.ifcx

  Line 1458 in 828ee54

  -2.3841858e-08,

• In some examples, I also see 12-digit precision (that's 1/50th of a hydrogen atom), significantly increasing the file size

It would be good to establish a general number precision for IFCX. To start with, how about 6 digits after the comma? For length, that's 1 millionth of a meter - micrometre, which is a 1/50th of a human hair diameter. More than needed for AEC purposes, but enough to not have issues with rounded object geometry or conversion loss. Because we agreed to use the metric system for length (and SI for most of the quantity kinds), even if the project is in metres, the precision would remain.

Less than the agreed precision should also be allowed, for example, full numbers or single digits:

IFC5-development/examples/Hello Wall/hello-wall.ifcx

Line 1056 in 828ee54

0.1,

Alternatively, we could establish separate rounding per quantity kinds, for example, four digits for length (0.0001 m - thickness of a coarse hair), but seven digits for angles (for example, geographic latitude).

TODO:

• add the agreed solution to the documentation

[aothms]

Alternatively, we could establish separate rounding per quantity kinds, for example, four digits for length

This has been discussed as part of the IDS project. One issue is that with SI units for volume or area without prefix this does not work in all cases, such as square meters for cable cross section e.g 0.000001 $m^2$ vs square meters for land area e.g 10000000.000000 $m^2$. So there we have opted for absolute + relative precision.

But I think we have a great starting point with our schema-based property definitions to make this a little bit richer. I've been meaning to come up with a proposal and implementation for this, but how about something like this.

| prop.ifcx |

"bsi::ifc::prop::CableCrossSectionArea": {
  "value": {
    "dataType": "Real",
    "quantityKind": "Area"
  }
}

| model.ifcx |

@import prop.ifcx

schemas: {
  "bsi::ifc::prop::CableCrossSectionArea": {
    "value": {
      "unit": {
        "name": "sqmm",
        "si_equivalent": 1e-06,
        "tolerance": ...
      }
    }
  }
},
data: [ ... ]

So, schema specifies quantityKind, data layers can further specify units (respecting quantityKind). Unit is just a string with an SI-equivalent so complexity is bounded by one scalar multiplication to support units.

Why I like this:

• Units fully optional on write: you could still use as is, don't specify a unit, model uses SI unit for quantityKind in schema
• Implementation complexity is minimal, you have the SI equivalent (not sure if we need an enum for names si_equivalent is all that matters), we could also add symbols or whatever so that presentation in viewer is easy
• Retains full freedom like we have now in IFC4 for measure-less units, e.g "hamburgers_per_inch" (courtesy of @tomvandig I think), because we have nothing now for Counts and Ratios.
• Retains flexibility in how to handle this in implementation, you can pre-apply unit conversion pre-composition (viewer only renders SI) or you can "box" values as measure-with-unit-pairs and retain those during composition (viewer uses locally defined unit which can be different based on originating layer).
• Efficient, uses the existing schema-based definitions so no linear increase with number of prop instances.

[atomczak]

Is the value in your proposal still stored in SI (m2) and the unit (mm2) is just to inform the viewer what they should convert it to? Or is it already stored in mm2? In Budapest, we agreed that it is better to store everything in same unit (m2), and perhaps optionally add information about the desired unit (mm2).

[janbrouwer]

I like the idea to limit the number of decimals in the core schema based on usage.
Especially storing mesh coordinates with limited precision (taking into account the base use case of everyone able to view the model) and those not being multiplied by transformations or dimensions.

[aothms]

I like the idea to limit the number of decimals in the core schema based on usage. Especially storing mesh coordinates with limited precision ...

I'm not so sure. So indeed in USD you have for example more float types to choose from. Express has only unbounded machine agnostic Real, and usd has float64 / double, float32 (and maybe half (16bit) not sure sometimes used in shaders / normals). But that works well because it has a binary serialisation format. Storage, text-based serialisation and schema are not really the same thing. I'm in particular a bit worried whether all common JSON libraries have support for truncating precision on serialisation. I'd rather search for efficiency on the storage layer, because it's not only file size, but also parse time that's a concern with JSON. Instead, at some point we should look into binary serialization + compute friendly compression (e.g even simple gzip level 5 is typically faster to decompress than disk speed, so is performance wise net positive). And there are other tricks you can do in binary serialisation such as the equivalent of HDF5 shuffle filter where you transpose tabular data so that similar bits get contiguously grouped to make compression even more effective.

So that's actually two directions:

• Which format are we? on the Express side with machine agnostic number types or on the USD side with concrete machine native types?
• Aim for performance with schema measures or serialisation measures or both?

Is the value in your proposal still stored in SI (m2) and the unit (mm2) is just to inform the viewer what they should convert it to? Or is it already stored in mm2?

I think actually both are possible, but if we go this amount of trouble I have a slight preference for storing in the original unit. (a) for precision: Just so that 1ft remains exactly 1 feet (b) to facilitate your proposal of number of decimals-based tolerance. If we store measures in SI, it's probably better to make it just a viewer property on how users want to display that rather than forcing the intent from the originating system. But regardless the question remains still on the counts, what do you count: pieces, boxes or trucks full of screws? You can add it to the property name, but then on a schema level you define how to count and you have less type safety.

[Airy59]

I'd advocate sticking to IFC4 and EXPRESS principles

• unbounded, machine agnostic real
• explicit representation of uncertainties and tolerances
• explicit representation of quantities and units

because domain engineers will agree and disagree on that basis.
There is then ample room for

• endless discussion about default choices (use-case dependent?...)
• re-using existing conventions when they are well established (USD may be such an example)

but first things first, I'd like to see the first three bullet points in the alpha schema :)

[atomczak]

@Airy59, the current HelloWall example has unbounded real numbers. Is that how you would like it to stay?

We also discussed (mainly at the Implementers Assembly in Budapest earlier this year) and came to the conclusion that apart from data types (real, int, string...) we want quantity kinds (volume, area, power...), and that those should have fixed storage units (mostly SI). This offers a balance between ease of reading and supports unit conversion etc. You can see the preliminary assumptions in here: https://github.com/buildingSMART/IFC5-development/blob/main/web/quantity-kinds.md#list-of-ifc-quantity-kinds and review the history here: #19.

explicit representation of uncertainties and tolerances

User-defined uncertainties and tolerances? What for? That adds a lot to the complexity. How about following the general approach, based on the good practice established in the IDS group: https://github.com/buildingSMART/IDS/blob/development/Documentation/ImplementersDocumentation/tolerance.md?

[atomczak]

... I have a slight preference for storing in the original unit. (...)

I have a slight preference for storing in SI, as it would simplify implementation and calcs. I've seen it working very well in practice in: https://github.com/BHoM/documentation/blob/main/docs/BHoM_oM/BHoM-Units-conventions.md

But regardless the question remains still on the counts, what do you count: pieces, boxes or trucks full of screws? You can add it to the property name, but then on a schema level you define how to count and you have less type safety.

Count is measureless, I would just treat it as non-convertible integer and wouldn't assign it a quantity kind.

[aothms]

Count is measureless, I would just treat it as non-convertible integer and wouldn't assign it a quantity kind.

Yes but people still do arithmetic on them. You don't want 1 box + 1 truck = 2 ....

[Airy59]

@aothms

• Unbounded real numbers (e.g. in HelloWall example): fine.
• Explicit quantities and units: thanks for the links to the history, which I'll investigate. Concerning the current state, no remarks except that I'd prefer the reference to QUDT appearing in the schema rather than the documentation.
• User-defined (and predefined) uncertainties and tolerances: again, thanks for the link, which I understand proposes a way to define equality in the field, rather than by bitwise coincidence (here again, IFC is ahead of some other models). But:

1. In the context of wider usage of IFC data, agnostic of the destination, or usage of "foreign" data by IFC, specifying a confidence range for scalar data, and matching the data with (toleranced) specifications where relevant, remains fundamental even though most of the time it is not an issue, thanks to some agreements on data quality or manufacturing standards. Of course, HelloWall is not too much concerned by the window fitting in the hole or not, but I might ask "is my rolling stock / platform edge interface going to fulfill the legal gap requirements for accessibility" and that is a different story.
2. the current IFC4 description of uncertainties and tolerances is at the same time limited to civil engineering concerns (only space dimensions and geometry) and indeed complex; maybe a more generic & adaptable scheme would help its adoption.

On that subject (under header "metrology") there are quite a few standards but I've never found them generically translated into models or schemes. Not all hope is lost as, for instance, IFC did a good job in translating the complex, generic ISO19148 "linear referencing" standard into something usable.

If that's a subject for you or somebody you know, let us work on it.