Location of ServiceWaterHeatingUse

[KarenWGard]

the location of ServiceWaterHeatingUse as a child object of Space is awkward for 90.1 as well as for many modeling tools (eQuest for sure, and while EnergyPlus can have uses assigned at the space level they often don't).

It seems that for Title 24, ServiceWaterHeatingUses may need to be connected to spaces, however, I suggest the following change to make the system simpler for modeling tools:

1. Define ServiceWaterHeatingUses at the BuildingSegment level (BuildingSegment.service_water_heating_uses & BuildingSegment.service_water_heating_building_area_type)
2. At the Space level, allow a list of references to ServiceWaterHeatingUses that are in the space (Space.service_water_heating_uses)
3. Consider removing Zone.served_by_service_water_heating_system, which seems to be redundant
4. If no spaces reference a ServiceWaterHeatingUse, the power or volume is calculated based on ALL Spaces in the BuildingSegment
5. If one or more spaces reference a ServiceWaterHeatingUse, the power or volume is calculated based on just the spaces that reference it.

[KarenWGard]

Some more information about this request:

The RCT team has been developing the logic for the Service Water Heating section of ASHRAE 90.1 Appendix G. We are requesting a change to the schema that we believe will benefit users.

Currently, the service water heating systems are connected as follows:

You'll notice that ServiceWaterHeatingUses are child objects of spaces. This is an issue because not all modeling programs link the use of service water heating with spaces (eQuest / DOE2). Many projects model service water heating use as a peak flow rate (with a schedule) as one number applied to the service water heating system, and some service water heating loads are not connected to spaces at all. For these projects, the translation to the schema would require arbitrarily assigning the service water heating use to a space.

In addition, under Zone there is a data element: served_by_service_water_heating_system which seems to be redundant.

We propose making the following changes:

Most significantly, the proposed change moves ServiceWaterHeatingUses so that they are now children of BuildingSegment. Spaces still have a list of ServiceWaterHeatingUse IDs, but this is optional. This maintains the link between ServiceWaterHeatingUses and Spaces, should a connection be required for a different ruleset, or to calculate service water heating use when the use_units are linked to space attributes (gallons / person, for example). However, this gives more flexibility and more direct translation for models and software that do not have ServiceWaterHeatingUse directly linked to spaces.