Questions on quantity kind and units

40 views
Skip to first unread message

Brett Leida

unread,
Jun 19, 2024, 2:27:13 PMJun 19
to Brick User Forum (Unified Building Metadata Schema)
Hi,
I am working with Sarah MacDougall on some Brick modeling projects and have some questions on how to fill in missing classes.

1. Multiple QuantityKinds on a Brick class
Following up on Sarah's question, we want to confirm that it is acceptable to define multiple QuantityKinds on a Brick class in order to add support for additional units. I understand that this is ok so long as the QuantityKinds have the same DimensionVector. I don't see any shacl rules to prevent this.

Please confirm that this is acceptable.

2. Measuring humidity in g/kg
I understand that this unit represents specific humidity (not absolute humidity, https://www.weather.gov/lmk/humidity).

The unit exists in QUDT (unit:GM-PER-KiloGM), but it is not associated with any quantity kind related to humidity. One such QK is quantitykind:MassRatio.

Does it make more sense to use something like quantitykind:MassRatio or create our own QK?

If we add our own QK, do you advise to add a brick:Quantity class or a qudt:QuantityKind? It's not obvious to me when to use which class as a base class.

3. Specific Fan Power
We will need to add a sensor for SFPv, e.g., Specific_Fan_Power_Validation_Sensor, a quantity kind and a unit.

The unit is the ratio of fan power to volume of air per time, e.g., W/(m3/s).

Can someone advise on a quantity kind and unit? I presume we'll have to define our own.

Given that the unit has a fraction in the denominator, what it the best way to represent this in QUDT? Something like W-SEC-PER-M3?

4. klux
We will need to add qudt:KiloLUX as a unit and add it to quantitykind:Illuminance. Just pointing out a missing unit.

5. PM4
We will need to add brick:PM4_Concentration and associated sensor class. We'll base it on others such as brick:PM10_Concentration. Just pointing out a missing and useful Brick class.

Thanks in advance for any direction on these questions.
BR,
Brett

Gabe Fierro

unread,
Jun 20, 2024, 10:09:27 AMJun 20
to Brett Leida, Brick User Forum (Unified Building Metadata Schema)

Hi Brett:

 

Thanks for reaching out!

 

  1. You are correct that there are no rules preventing the definition of multiple quantity kinds on a brick class, however, I’m worried that this would be confusing for some of the rules that check that the units on an entity are appropriate for the associated quantity kind. Are the examples of the rest of your email the ones that you’re thinking of? I think the better solution is to figure out the right quantity kind for the sensor, rather than try to associate multiple. I’m more than happy to help you do this!
  2. Because specific humidity is a different quantity time than relative humidity, we probably need to add a new brick sensor class that has a quantity kind supporting specific humidity, such as MassRatio.

 

In general, we should be using the QUDT quantity wherever possible. If it’s necessary to add one, we can do so either in Brick or in QUDT. Things are specific to buildings should be done in brick, and quantity kinds that are generally useful outside of the buildings context should be put in QUDT.

 

  1. For your question on specific fan power, I would recommend filing an issue on the QUDT GitHub to ask for their guidance. In my experience, they’ve been very responsive!
  2. Same here – either file an issue or submit a PR on QUDT, and I can merge the latest QUDT into brick when that is ready.
  3. For the missing PM4 sensor, I’d happily review a pull request if you want to submit one, or I can try to get around implement to get myself if you file an issue.

 

Let me know if you have any other questions!

 

Best,

Gabe

 

--
You received this message because you are subscribed to the Google Groups "Brick User Forum (Unified Building Metadata Schema)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brickschema...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/33429614-ad56-4a72-b080-9fb096c47d0en%40googlegroups.com.

Steve Ray

unread,
Jun 20, 2024, 10:30:16 AMJun 20
to Brick User Forum (Unified Building Metadata Schema)
I will speak only to what is allowable in QUDT, just in case Brick needs to make any exceptions.

1. Definitely, a qudt:Unit can have many qudt:hasQuantityKind references, and it must have at least one. As you state, they must all reference the same qudt:QuantityKindDimensionVector. 

I should point out that the relations qudt:hasQuantityKind and the derived relation qudt:applicableUnit,  relating Units and QuantityKinds, are intended as suggestions, but not intended as limiting constraints. So as long as they share the same dimension vector, it is valid to relate any Unit and QuantityKind. (For more information on qudt:applicableUnit, see this.)

2. unit:GM-PER-KiloGM reveals that NASA was the original sponsor for creating QUDT—most interested in rockets and propulsion! It would be great if you could propose additional quantity kinds for this and other units. You don't need to maintain them yourself—just submit a pull request to https://github.com/qudt/qudt-public-repo, and the next time Brick updates its import, they will be present. The process to do this is documented here.

3. If my math is correct, the dimension vector for your unit is qkdv:A0E0L-1I0M1H0T-2D0, with one of the referencing quantity kinds being EnergyDensity. We already have unit:W-HR-PER-M3 as one of the applicableUnit values for EnergyDensity, but we don't have unit:W-SEC-PER-M3. So my recommendation is to use EnergyDensity as the quantity kind, and either unit:W-HR-PER-M3 or unit:W-SEC-PER-M3 as your unit, but you would need to submit a pull request for the new unit:W-SEC-PER-M3 to QUDT. As you noted, you suggested the correct (and unambiguous) way of handling fractions in the denominator.

4. We welcome more pull requests!



Steve

Brett Leida

unread,
Jun 20, 2024, 5:26:25 PMJun 20
to Brick User Forum (Unified Building Metadata Schema)
Hi Gabe and Steve,
Thanks for your quick replies. They're appreciated. Please see my comments below per respective question.

1. There are several scenarios where we want to add a second quantity kind to a class b/c of a missing unit, but one that we think is still relevant for that class.

Angle_Sensor: qudtqk:Angle (existing), qudtqk:DimensionlessRatio (new for PERCENT)
Humidity_Setpoint: qudtqk:PressureRatio (existing), qudtqk:RelativeHumidity (new for PERCENT_RH)
Fan_Speed_Command: qudtqk:Dimensionless (new for UNITLESS), qudtqk:DimensionlessRatio (new for PERCENT)

For Fan_Speed_Command, we have a need to represent PERCENT. But it seems to make sense to add a second qk in the scenario where one wants to set the speed to an enum value, like Low, Med, High. It would be UNITLESS in this case.

Hopefully, this use of a Command class is legitimate.

2. I will propose a new qk for SpecificHumiity and submit a PR to QUDT. I may have some follow-up questions on creating a qk as I work through those details.

Once QUDT has been updated, presumably with a new version, how is this updated in Brick? Is it only pulled into the master branch (which will be 1.4), and 1.3 is not updated? I just want to understand so that we know how to manage the updates on our end.

3 and 4. I'll include these changes in the same PR to QUDT.

5. I'll submit a PR to Brick for the PM4 sensor and quantity.

BR,
Brett
Reply all
Reply to author
Forward
0 new messages