[{Object}, Reference] in SWH

[KarenWGard]

Allowing both an ServiceWaterHeatingUse and References in the BuildingSegment.service_water_heating_uses and Space.service_water_heating_uses adds a layer of complexity without signficiant benefit.

We would like to suggest some limitations to the [{Object}, Reference] approach with regards to service water heating uses

First, some background

In order to evaluate many of the rules, we need to evaluate the amount of energy required to heat each ServiceWaterHeatingUse. In order to do this calculation there are some conventions that have been established regarding the applicability and meaning of the service water heating uses when those service water heating uses are assigned at the building segment level. These convetions for ServiceWaterHeatingUses assigned at the Building Segment level are:

1. A ServiceWaterHeatingUse that has one of the following unit types: [POWER_PER_PERSON, POWER_PER_AREA, VOLUME_PER_PERSON, VOLUME PER AREA] AND has not been explicitly referenced by any spaces is assumed to apply to each space in the building segment.

2. A ServiceWaterHeatingUse that is referenced by one or more spaces will be applied only to those spaces.

3. A ServiceWaterHeatingUse with units POWER, VOLUME, or OTHER will be applied only once to the entire building segment.

This function (get_energy_required_to_heat_swh_use) is used by 3 other functions, is directly used by one rule and is either directly or indirectly used in all section 11 rules.

Under the old structure, the function only needs a ServiceWaterHeatingUse and an RMD as inputs in order to complete the calculation. All of the work of figuring out which spaces to apply the ServiceWaterHeatingUse is done in a single function.

With the current [{Object}, Reference] structure, it is impossible for get_energy_required_to_heat_swh_use to know which building segment or spaces that reference the ServiceWaterHeatingUse are intended. The only way to remedy this without modifying the schema is to externalize and duplicate a lot of the work that is currently cleanly encapsulated in get_energy_required_to_heat_swh_use. This is an achievable development task, but it leaves a lot of room for future errors and misinterpretation both on the development side and from UI developper and end-user perspective.

We suggest the following changes:

1. BuildingSegment.service_water_heating_uses - allow only ServiceWaterHeatingUse, and not References.
2. Update the description for BuildingSegment.service_water_heating_uses to include the following text from Test swap to pipenv #1, Update schema #2, & Thermal blocks is missing a name/ID #3, above.
3. Space.service_water_heating_uses - allow [{ServiceWaterHeatingUse}, Reference], but with the following restrictions

• References must refer to a ServiceWaterHeatingUse at the BuildingSegment level and that BuildingSegment must be the BuildingSegment to which this space belongs
• ServiceWaterHeatingUses stored at the space level may only be used for this space and may not be referenced by other spaces.

These changes would vastly improve quality, efficiency and accuracy.

Thanks.

[DavidHollman]

Questions...

(1) Why does the schema support relative unit types: [POWER_PER_PERSON, POWER_PER_AREA, VOLUME_PER_PERSON, VOLUME PER AREA] ? What would be the consequence for rules checking of simplifying it to only allow whole units (power or volume)? ( BEM tools would have to output in whole units only, and if its own definitions were in relative terms then it would have to do those conversions first). Or is there the potential that rules might require relative units for various reasons?

(2) @KarenWGard in your point 1, why make the assumption that non-referenced ServiceWaterHeatingUse objects apply to all spaces? Would it be simpler to mandate that all uses of ServiceWaterHeatingUse are explicit and have fewer assumptions?

(3) If there are rules such as:

References must refer to a ServiceWaterHeatingUse at the BuildingSegment level and that BuildingSegment must be the BuildingSegment to which this space belongs
ServiceWaterHeatingUses stored at the space level may only be used for this space and may not be referenced by other spaces.

what happens if those rules are broken? Does the ruleset checking tool preform a validation step to decide if the JSON is valid or invalid? If it decided it was invalid that seems like it would be due to a bug in the BEM tool, not a user-input problem that the user of the BEM tool would be able to do anything about.

If its possible to avoid rules like that altogether by making the schema self-validating by design it seems simpler.

(4) When the schema presents a choice of how to represent something - such as reference OR object - I wonder if that is really necessary. As a BEM tool developer I would probably pick one of the two methods only and disregard the other; this just makes the software development task simpler. I've been wondering whether the schema would be better if only one method were made available. I think it could be argued that if a given type of object (like ServiceWaterHeatingUse ) is used in more than one place, then it should only be provided by reference.

[JasonGlazer]

@KarenWGard I made the changes you recommended, which will appear in the 0.1.5 update.

@DavidHollman I'm closing the issue, but I think that @KarenWGard can still answer your questions (1) and (2)

Concerning (3), I don't know the answer to that.

Concerning (4), part of the reason to provide referencing to other instances of data groups was to cut down on redundancy. I guess we did not discuss and consider just having references only.

[KarenWGard]

@JasonGlazer - thank you.

@DavidHollman - thanks for the questions.

I wasn't involved in creating the schema, but I'll answer your questions based on my experience working on the RDS team.

(2) - this approach

Questions...

(1) Why does the schema support relative unit types: [POWER_PER_PERSON, POWER_PER_AREA, VOLUME_PER_PERSON, VOLUME PER AREA] ? What would be the consequence for rules checking of simplifying it to only allow whole units (power or volume)? ( BEM tools would have to output in whole units only, and if its own definitions were in relative terms then it would have to do those conversions first). Or is there the potential that rules might require relative units for various reasons?

the schema is designed to support multiple rulesets and simulation programs. There may be a ruleset in the future that uses the schema where other units are desired. Also, the easier we make it for UI developpers to create input files for the schema the better.... even if in this case it's a small improvement.

(2) @KarenWGard in your point 1, why make the assumption that non-referenced ServiceWaterHeatingUse objects apply to all spaces? Would it be simpler to mandate that all uses of ServiceWaterHeatingUse are explicit and have fewer assumptions?

This is actually the approach I originally suggested, but the schema working group went with the [{Object}, Reference]. It wasn't until I got into the weeds with it that I realized how complicated it made things.

(3) If there are rules such as:

References must refer to a ServiceWaterHeatingUse at the BuildingSegment level and that BuildingSegment must be the BuildingSegment to which this space belongs
ServiceWaterHeatingUses stored at the space level may only be used for this space and may not be referenced by other spaces.

what happens if those rules are broken? Does the ruleset checking tool preform a validation step to decide if the JSON is valid or invalid? If it decided it was invalid that seems like it would be due to a bug in the BEM tool, not a user-input problem that the user of the BEM tool would be able to do anything about.

If its possible to avoid rules like that altogether by making the schema self-validating by design it seems simpler.

There is a validation step in the RCT

(4) When the schema presents a choice of how to represent something - such as reference OR object - I wonder if that is really necessary. As a BEM tool developer I would probably pick one of the two methods only and disregard the other; this just makes the software development task simpler. I've been wondering whether the schema would be better if only one method were made available. I think it could be argued that if a given type of object (like ServiceWaterHeatingUse ) is used in more than one place, then it should only be provided by reference.

I agree! I think the options are more so some developers can do things one way and others another way.