Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rds/kjw/rule 11 3 #1337

Open
wants to merge 21 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
86 changes: 0 additions & 86 deletions .gitignore

This file was deleted.

69 changes: 69 additions & 0 deletions docs/section11/11-3.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
# Service_Water_Heating - Rule 11-3
**Schema Version:** 0.0.37

**Mandatory Rule:** TRUE

**Rule ID:** 11-3

**Rule Description:** "Where no service water-heating system exists or has been designed and submitted with design documents but the building will have service water-heating loads, a service water-heating system shall be modeled that matches the system type in the baseline building design"

**Rule Assertion:** Options are PASS/FAIL

**Appendix G Section Reference:** Table G3.1 #11, proposed column, c
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Table G3.1(11) Proposed Building Performance (c)


**Evaluation Context:** Each SWH distribution system either in the P-RMD and / or B-RMD
**Data Lookup:**
**Function Call:**
- **get_component_by_id**
- **compare_context_pair** - there is no RDS for this function, but it is a function developed for Rule 1-6 that compares two elements
- **get_SWH_equipment_associated_with_each_swh_distribution_system**

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add get_SWH_equipment_associated_with_each_swh_distribution_system

**Applicability Checks:**
- check that the SHW BAT in the P_RMD has SHW loads

## Applicability Checks:
- projects without SWH in the user model are expected to have a baseline SWH system in the proposed model. If there is SWH in the user model, we assume there is a SWH system designed, and instead rule 11-1 Applies and P_RMD matches U_RMD.
- use the function get_SWH_equipment_associated_with_each_swh_distribution_system to get a dictionary of SWH equipment associated with each Distribution System for the Proposed model (pumps, tanks, SWH use, distribution system, etc): `p_swh_system_and_equip_dict = get_SWH_equipment_associated_with_each_swh_distribution_system(P_RMD)`
- create a list of the distribution ids that have been checked: `checked_dist_ids = []`
- for each distribution system: `for distribution_id in p_swh_system_and_equip_dict:`
- get the distribution system: `p_distribution = get_component_by_id(P_RMD, distribution_id)`
- for each swh use in the dictionary, check to see that the swh use exists in the user model: `for swh_use_id in p_swh_system_and_equip_dict[distribution_id]["USES"]:`
- get the user swh_use: `u_swh_use = get_component_by_id(U_RMD, swh_use_id)`
- if the u_swh_use exists, this rule is not applicable and 11-1 applies: `if(u_swh_use): NOT_APPLICABLE`
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest that we check equipment instead of the uses in the user model. Because some could model the uses when there is no equipment designed, right? I think this rule applies when there will be SHW loads in the user model but no system has been designed. I am concerned by looking at uses instead of User model equipment we maybe skip something when it should not be skipped.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see your concern, however the architecture of the schema makes a ServiceWaterHeatingUse without a distribution_system problematic. On the last call (5/29/2024), we discussed (and agreed to) making ServiceWaterHeatingUse.served_by_distribution_system a required field, which would allow this logic.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes the rule not applicable if even 1 ServiceWaterHeatingUse is defined in the User model. What is supposed to happen if there are just certain spaces where the ServiceWaterHeatingUse is not defined?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if this rule is not applicable, rule 11-1 is applicable. This logic just checks whether the SWH use that exists in the proposed model exists in the user model. It allows for spaces without SWH uses

- if the program reaches this line without being not applicable first continue to rule logic for this distribution system: `CONTINUE TO RULE LOGIC`
- we also need to look at the distribution systems in the baseline model and ensure that all of them have been covered by the above checks. If any exist (and have SWH use), but do not exist in the proposed model, then there is an issue: `for distribution_id in b_swh_system_and_equip_dict:`
- check whether there are SWH uses connected to the distribution system: `if len(b_swh_system_and_equip_dict[distribution_id]["USES"]) > ):`
- continue if the distribution_id is not the id of a system that has already been checked: `if !distribution_id in? checked_dist_ids:`
- if uses exist, continue to rule logic #2: `CONTINUE TO RULE LOGIC #2`
- if the program reaches this line without going to the rule logic, the project is not applicable for this SWH heating distribution system id: `NOT_APPLICABLE`

## Rule Logic #1:
- create a list that the compare_context_pair function will use to send errors back tot he rule: `errors = []`
- create the compare context string: `compare_context_str = "AppG 11-1 P_RMD Equals B_RMD"`
- get a dictionary of all SWH equipment in the proposed model (pumps, distribution, tanks, SWH use, etc): `p_swh_equipment_dict = p_swh_system_and_equip_dict[distribution_id]`
- get a dictionary of all SHW equipment connected to the SHW distribution system in the baseline model: `b_shw_equipment_dict = get_SWH_equipment_associated_with_each_swh_distribution_system(B_RMD)[distribution_id]`
- Compare the distribution in the proposed and baseline models using the function compare_context_pair. compare_context_pair is recursive, so by sending the function the distribution systems, it is also checking the tanks and piping that are child objects of the distribution systems. The boolean all_match is created and set to the result of the function: `all_match = compare_context_pair(distribution_id, distribution_id, $, extra_schema_for_SWH_comparison.json, true, compare_context_str, error_str)`
- there's equipment that's part of the service water heating distribution system that are not direct child objects of the distribution system. We need to check these objects.
- first, check ServiceWaterHeatingEquipment - when we execute compare_context_pair, this will also check any child objects that exist (SolarThermal and SWH validation point). Start by checking if there are the same number of objects in the proposed and user models. We need to do the length check here because it's not checked implicitly as part of compare_context_pair. For example, if there are more pieces of equipment in the user model than the proposed, comparing each item found in the proposed model could return a false positive: `if len(p_swh_equipment_dict["SWHHeatingEq"]) == len(b_swh_equipment_dict["SWHHeatingEq"]):`
- look at each SWHEquipment in the proposed model: `for swh_eq_id in p_swh_equipment_dict["SWHHeatingEq"]:`
- compare the two SWH equipment using compare_context_pair, if the result is false, set all_match equal to false. We won't exit early if all_match is false as we allow the function to keep running so errors is fully populated and available to the user: `if !compare_context_pair(swh_eq_id, swh_eq_id, $, extra_schema_for_SWH_comparison.json, true, compare_context_str, error_str): all_match = false`
- next, check Pumps - this will also recursively check PumpOutputValidationPointPumpOutputValidationPoint: `if len(p_swh_equipment_dict["Pumps"]) == len(b_swh_equipment_dict["Pumps"]):`
- look at each SWHEquipment in the proposed model: `for pump_id in p_swh_equipment_dict["Pumps"]:`
- compare the two pumps using compare_context_pair, if the result is false, set all_match equal to false. We won't exit early if all_match is false as we allow the function to keep running so errors is fully populated and available to the user: `if !compare_context_pair(pump_id, pump_id, $, extra_schema_for_SWH_comparison.json, true, compare_context_str, error_str): all_match = false`

## Rule Logic #2:
- The equipment exists in the baseline model, but not in the proposed model, all match is false: `all_match = false`

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Defer to Weili due to complex, novel structure.


## Rule Assertion:
- Case1: all elements are equal: PASS: `if all_match: PASS`
- Case2: all elements don't match, FAIL: `if !all_match: FAIL`




**Notes:**
1. is there a situation where some of the equipment shouldn't be equal? Solar hot water, for example?
2. extra_schema_for_SHW_comparison.json is the json file created from SHW comparison fields.yaml

**[Back](../_toc.md)**
Loading