Rds/kjw/rule 11 1 #843
Rds/kjw/rule 11 1 #843
Conversation
KarenWGard
requested review from
JasonGlazer,
supriyagoel,
weilixu and
mkarpman
docs/section11/Rule_11-1.md
Outdated
|
|
||
| **Appendix G Section Reference:** Table G3.1 #11, proposed column, a & b | ||
|
|
||
| **Evaluation Context:** P-RMD each SHW type |
There was a problem hiding this comment.
Should this have a different context? Maybe P-RMD each ServiceWaterHeatingEquipment. I am not following why it would be evaluated for each type as opposed to system.
There was a problem hiding this comment.
I am struggling with the same thing
There was a problem hiding this comment.
After going through I see Karen means each SWH building area type
There was a problem hiding this comment.
Can SWH systems serve more than one SWH building area type? Is that accounted for already?
There was a problem hiding this comment.
I think it could certainly be the case that a SHW system could serve more than one building area type in the proposed design. I think because of this maybe there should be a function that returns {"SHWHeatingEq":{"SHWDistribution":["shwd1","shwd2"], "Building area types served":["Dormitory","Multifamlily"], "Pumps":["p1"], "Tanks":["t1"], "Piping":["piping1"], "SolarThermal":[]}} so all this information would be returned for each SHWHeatingEq ID.
Alternatively it may be better to do by ServiceWaterHeatingDistributionSystem since this would encompass a SHW system as opposed to SHWHeatingEq where there could be mulitple SHWHeatingEq IDs per system. So it would be {"ServiceWaterHeatingDistributionSystem":{"SHWHeatingEq":["shwe1","shwe2"], "Building area types served":["Dormitory","Multifamlily"], "Pumps":["p1"], "Tanks":["t1"], "Piping":["piping1"], "SolarThermal":[], "Service_water_heating_uses":["swhuse1","shwuse2"]}} so all this information would be returned for each SHWHeatingEq ID.
I think this change would be helpful for checking the baseline, that there is one system per BAT. I think it would also avoid checking things multiple times in this RDS.
There was a problem hiding this comment.
I created a new function get_SWH_equipment_associated_with_each_swh_distribution_system, which gives a dictionary based on the swh distribution system. 11-1 now relies on this function to evaluate the rule so that the context is each swh distribution system.
update BuildingSegment to reflect proposed changes here: open229/ruleset-model-description-schema#264
| - next, check Pumps - this will also recursively check PumpOutputValidationPointPumpOutputValidationPoint: `if len(p_swh_equipment_dict["Pumps"]) == len(u_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` | ||
|
|
There was a problem hiding this comment.
I defer to Weili on this one since it uses a complex, novel approach.
change piping_losses_modeled to are_thermal_losses_modeled
updates to address Jackson's question about catching systems that are in the user model, but not in the proposed model
docs/section11/Rule_11-1.md
Outdated
| - compare the proposed and user models using the function compare_swh_dist_systems_and_components. This function returns a list of errors. If the list of errors has a length of 0, then the comparison encountered no issues: `user_proposed_comparison = compare_swh_dist_systems_and_components(P_RMD,U_RMD,user_proposed_str,swh_dist_system_id)` | ||
| - from here, go directly to the rule assertion: `GO TO RULE ASSERTION` | ||
|
|
||
| - if we got to this line without going to the rule assertion, it means that there is no equivalent system in the user model, or that the user model does not have SWH use. Compare the proposed and baseline models using the function compare_swh_dist_systems_and_components. This function returns a list of errors. If the list of errors has a length of 0, then the comparison encountered no issues: `user_baseline_comparison = compare_swh_dist_systems_and_components(P_RMD,B_RMD,user_proposed_str,swh_dist_system_id)` |
There was a problem hiding this comment.
i may be missing something but couldn't it be an error and there was supposed to be a corresponding system in the user model when there is not one? Like in the case that there are SWH load? It is not clear to me that this would be caught.
There was a problem hiding this comment.
this is caught in lines 29 and 32 of the function: compare_swh_dist_systems_and_components, but the error returned is not as descriptive as it could be. A check and a specific error is added here.
No description provided.