Create Rule22-42.md #1520
Create Rule22-42.md #1520
Conversation
KarenWGard
requested review from
JasonGlazer,
supriyagoel,
weilixu,
claperle and
JacksonJ-KC
|
|
||
| ## Applicability Check: | ||
| - look at each chiller - only water-cooled chillers are applicable (ie chillers with a condensing_loop): `for chiller in B_RMD.chillers:` | ||
| - if the chiller has a condensing_loop, and the chiller energy source is electricity, continue to rule logic: `if chiller.consensing_loop != NULL and chiller.energy_source_type == "ELECTRICITY": CONTINUE TO RULE LOGIC` |
There was a problem hiding this comment.
should we include an applicability check for the baseline HVAC system type?
There was a problem hiding this comment.
I don't think so. It overcomplicates things here, and if the user has issues with the HVAC system type, they'll be notified elsewhere. If we do a check here, it just means that if a user is using the RCT to validate a model then they have to do an extra iteration.
docs/section22/Rule22-42.md
Outdated
| - convert the chiller rated capacity from watts to tons: `chiller_capacity_tons = rated_capacity * 0.000284345` | ||
| - check if the compressor type is CENTRIFUGAL: `if chiller.compressor_type == "CENTRIFUGAL":` | ||
| - if the capacity is less than 150 tons, the category is Z: `if chiller_capacity_tons < 150: curve_set = "Z"` | ||
| - else if the capacity is greater than or equal to 300 tons, the category is AB: `elif chiller_capacity_tons >= 300: curve_set = "AB"` |
There was a problem hiding this comment.
probably also need to add what the category is if the capacity = 150 tons, is that category AA or Z?
There was a problem hiding this comment.
this is covered in the following line. Anything that's not less < 150 and not >= 300 (ie 150 - 300, including 150, but not 300)
There was a problem hiding this comment.
The way you wrote it made me think twice about this too. Since the point of RDS is clear documentation I would recommend writing it so that the case where capacity = 150 tons is not implicitly covered by the else condition
docs/section22/Rule22-42.md
Outdated
| - create a list of the expected entering condenser temperatures for the condenser water temperature for the validation calculations - expected_ecwt_temps - units are (F). The values are selected to capture the minimum, maximum, rating condition and some points in between: `expected_ecwt_temps = [60,104,85,72.5,97.5]` | ||
|
|
||
| - get the coefficients for the EIR-f-T curve (IP units) using a table lookup for table J-6. This assumes that the lookup function will return a list with the coefficients in order (C1,C2,...): `eir_f_t_coefficients = table_J_2_lookup(curve_set,"EIR-f-T")` | ||
| - get the coefficients for the CAP-f-T curve (IP units) using a table lookup for table J-6. This assumes that the lookup function will return a list with the coefficients in order (C1,C2,...): `cap_f_t_coefficients = table_J_2_lookup(curve_set,"Cap-f-T")` |
There was a problem hiding this comment.
@weilixu do we need to create these lookup tables or do they exist for OS Standards?
There was a problem hiding this comment.
@supriyagoel We do not have plan to develop 2022 in OS Standards in FY25.
In the case that if we are developing this feature, it would be a look up table.
| - if the chiller has a condensing_loop, and the chiller energy source is electricity, continue to rule logic: `if chiller.consensing_loop != NULL and chiller.energy_source_type == "ELECTRICITY": CONTINUE TO RULE LOGIC` | ||
|
|
||
| ## Rule Logic: | ||
| - figure out the set of performance curves needed for the chiller - this should be V, X, Y, Z, AA or AB. Initialize a variable curve_set and set it to "NONE": `curve_set = "NONE"` |
There was a problem hiding this comment.
@weilixu I imagine that the actual implementation would use table lookups here. Is it clear enough from this RDS without using table lookups?
docs/section22/Rule22-42.md
Outdated
| - the following lines or logic do the power validation check: | ||
| - create a list of non-matching power validation points: `non_matching_power_validation_points = []` | ||
| - create a list of missing power validation points: `missing_power_validation_points = []` | ||
| - loop through the expected_cwt_temps: `for cwt in expected_cwt_temps:` |
There was a problem hiding this comment.
Based on above on line 34 I think this is supposed to be for chwt in expected_chwt_temps"
There was a problem hiding this comment.
everything has been updated to be ecwt and cwt
There was a problem hiding this comment.
The typical abbreviation for chilled water is CHW so I recommend that any variable that pertains to chilled water use CHW and any variable that represents condensing water be CW. Looks like they both use CW regardless of whether they are chilled or condenser water. This is a suggestion - feel free to ignore but I found it was a little confusing with CW for both. Maybe use the nomenclature in 90.1 with CHWT and ECT.
There was a problem hiding this comment.
ah, I see what you're looking for now. Using CHWT and ECT now
docs/section22/Rule22-42.md
Outdated
| - the following lines or logic do the capacity validation check: | ||
| - create a list of non-matching capacity validation points: `non_matching_capacity_validation_points = []` | ||
| - create a list of missing capacity validation points: `missing_capacity_validation_points = []` | ||
| - loop through the expected_chwt_temps: `for cwt in expected_cwt_temps:` |
There was a problem hiding this comment.
recommend updating "cwt" and "ect" to align with above to make it easier to follow
There was a problem hiding this comment.
The typical abbreviation for chilled water is CHW so I recommend that any variable that pertains to chilled water use CHW and any variable that represents condensing water be CW. Looks like they both use CW regardless of whether they are chilled or condenser water. This is a suggestion - feel free to ignore but I found it was a little confusing with CW for both. Maybe use the nomenclature in 90.1 with CHWT and ECT.
docs/section22/Rule22-42.md
Outdated
| - loop through the expected_chwt_temps: `for cwt in expected_cwt_temps:` | ||
| - loop through each expected_ecwt_temps: `for ect in expected_ecwt_temps:` | ||
| - look for the capacity validation point in capacity_validation_pts_dict: `if capacity_validation_pts_dict[[cwt, ect]]:` | ||
| - calculate the expected capacity by multiplying the result of the formula by the rated_capacity: `expected_capacity = (cap_f_t_coefficients[0] + cap_f_t_coefficients[1] * cwt + cap_f_t_coefficients[2] * cwt^2 + cap_f_t_coefficients[3] * ect + cap_f_t_coefficients[4] * ect^2 + cap_f_t_coefficients[5] * cwt * ect) * rated_capacity` |
There was a problem hiding this comment.
This formula looks correct cut recommend upsating ect and cwt nomenclature
There was a problem hiding this comment.
everything has been updated to be ecwt and cwt
There was a problem hiding this comment.
The typical abbreviation for chilled water is CHW so I recommend that any variable that pertains to chilled water use CHW and any variable that represents condensing water be CW. Looks like they both use CW regardless of whether they are chilled or condenser water. This is a suggestion - feel free to ignore but I found it was a little confusing with CW for both. Maybe use the nomenclature in 90.1 with CHWT and ECT.
| - look for the power validation points in power_validation_pts_dict: `if power_validation_pts_dict[[cwt, ect]]:` | ||
| - we are expecting to see multiple validation points aligning with the expected_validation_plr. Create a list of part load ratios that are given. Later we'll compare this with the expected list to make sure that all points are given: `given_plrs = []` | ||
| - look at each power validation point in the list: `for power_validation_point_result in power_validation_pts_dict[[cwt, ect]]:` | ||
| - get the load: `load = power_validation_point.load` |
There was a problem hiding this comment.
I may just be tired but I am not following how this load is getting retrieved from this. I don't think you are looping through power_validation_point objects at this point. Looks like you are looping through a list of power validation point results. I am thinking the loads also need to be included in the dictionary.
There was a problem hiding this comment.
load is a property of ChillerPowerValidationPoint
There was a problem hiding this comment.
Okay but I do not see how you are getting to this with the current logic. How are you able to reference the power_validation_point, you are not looping through them anywehre and there can be multiple associated with the chiller. power_validation_point is an object so I am not following how you are able to reference it here.
There was a problem hiding this comment.
you're right - I made changes also on line 50, so that power_validation_pts_dict[dict_key] references power_validation_points, not a list of power_validation_point results. Then we can get both the result and load on lines 75 and 76
docs/section22/Rule22-42.md
Outdated
| - get the load: `load = power_validation_point.load` | ||
| - get the given power: `given_power = power_validation_point_result` | ||
| - calculate the PLR by dividing the load by the given capacity at these operating conditions: `plr = load / given_capacities[[cwt, ect]]` | ||
| - check whether the plr is one of the plrs that we need to check: `if plr in expected_validation_plr:` |
There was a problem hiding this comment.
Can we allow some deviation? I can imagine the plr not being exactly 0.25 for example.
There was a problem hiding this comment.
yes. I added a note to the dev team to accept a deviation of 0.01 - which is based on the understanding that if a number is given to two decimal places, there is a deviation of 0.01 allowed (PLRs are 0.25, etc)
No description provided.