Open nealkruis opened 7 years ago
The limits are there to protect the user from operating a DX system out of range on flow rate and is based on review of manufacturers data. Without warnings the user could operate a coil at air flow so low it freezes the coil (which there is also a warning for). Since this is a simulation, we could allow operation at very low or high flow rate ratios, but then how would you warn the typical user there might be something wrong with their inputs? At -25C, the coil would be a solid block of ice, yet you would still get air flow through the coil and the nominal capacity, does that sound right? I don't completely disagree on the engine vs UI argument on warnings reporting.
@rraustad, good point. We should have a warning (maybe an error?) when the ADP is below freezing instead.
The limits we currently impose are based on a sampling of units, and not the potential range of DX coil designs. In reality there is no real upper limit (just higher than normal supply temperatures), and the lower limit can be handled with the warning on the ADP temperature.
@rraustad do you agree that we can replace these errors with a warning when the ADP is below freezing?
There is already a warning for SA temperature below 2C here. I don't think ADP < 0C is much different and would probably be redundant. One could argue what the limit should be (i.e., 2C or 0C). Also, the only reason for the warning is that the DX cooling coil does not have a defrost model.
It seems ADP is a better indicator of freezing, but I don't have a strong preference. So we either leave the SA warning or move it to ADP? Either way, we can remove the flow per capacity severe error, right?
ValidateADP is only used during sizing. A warning for ADP < 0 is OK by me since it would make the user think about their inputs if and when they saw that message. During the simulation, the SA<2C would show up as necessary. I'm unsure about removing the flow per capacity severe error. If the flow ratio was way out of bounds how would users know? I would accept a >20% out of bounds or something like that but I think we still need to be sure the model doesn't allow unrealistic inputs.
I think the underlying ADP bypass factor modeling method from HVAC toolkit just hasn't been proved to be okay outside the range. Maybe it is but the academic investigation needs to happen.
A severe without a fatal is not policy these days so changing to a warning is fine with me.
I asked Mike Brandemuehl (author of the HVAC toolkit) about this. Here is his response:
Yeah, a "severe error” might be a bit extreme - a warning might be more appropriate. I have several responses and general comments:
- I could imagine some scenarios when a DX coil could be designed outside the range of 300-450 cfm per ton. One case would be the design of a dedicated outdoor air coil or dual-path system where the design conditions could expect a large air temperature drop from, say, outdoor air at 105 F with a discharge air at 50 F. In such a scenario, the airflow may be below 200 cfm/ton at design conditions. Similarly, for a dry coil with only a 20 F air temperature drop, the airflow could be as much as 550 cfm/ton.
- The ADP/BF approach should work fine. However, it only applies to wet coils, but I would expect the EnergyPlus would make that check. The only other wrinkle arises when the entering air is very humid and the ADP is very low. In this scenario, the slope of the line between the entering air and the ADP is so steep that it intersects the saturation curve and produces supersaturated air.
- There are really two limitations on design. The first is definitely coil freezing, which limits the minimum airflow rate. The second is condensate blow-off. If the air velocity is greater than about 600 fpm, the air will blow droplets of condensate off the coil, which can then wet the duct insulation and cause other corrosion problems.
@rraustad @EnergyArchmage How do we feel about changing these severe errors when cfm/ton is outside of (300-450) to warnings when outside of (200-550)?
The numbers Mike used are very close to what EnergyPlus uses now. The question here is if users have available the data needed to create the performance curves for the rated DX coil. Meaning, there is a rated air flow rate range, and an operating air flow rate range. The curves need to be created for a coil within the rated range of air flow. The CapfFlow and EIRfFlow account for operation outside this rated range (where a user gets this curve is beyond me). So what would the user do if the data provided is for the coil that operates outside this range?
I could agree to lowering the min rated vol flow for regular DX coils to 250 cfm/ton, this would match the upper limit of DOAS coils and possibly increasing the MaxCoolVol* for regular coils to 550. But then that brings in the question of the rated vol flow range of 300-450, the data needs to be available in this range to create the performance curves and I am not sure if that is true (i.e., a unit coil with special operating characteristics may have data for 250 cfm/ton and how would a user translate that data back to 300 cfm/ton to create the performance curves).
// Airflow per total capacity range (Regular DX coils)
Real64 const MaxRatedVolFlowPerRatedTotCap1( 0.00006041 ); // m3/s per watt = 450 cfm/ton
Real64 const MinRatedVolFlowPerRatedTotCap1( 0.00004027 ); // m3/s per watt = 300 cfm/ton
Real64 const MaxHeatVolFlowPerRatedTotCap1( 0.00008056 ); // m3/s per watt = 600 cfm/ton
Real64 const MaxCoolVolFlowPerRatedTotCap1( 0.00006713 ); // m3/s per watt = 500 cfm/ton
Real64 const MinOperVolFlowPerRatedTotCap1( 0.00002684 ); // m3/s per watt = 200 cfm/ton
// 100% DOAS DX coils Airflow per total capacity ratio
Real64 const MaxRatedVolFlowPerRatedTotCap2( 0.00003355 ); // m3/s per watt = 250 cfm/ton
Real64 const MinRatedVolFlowPerRatedTotCap2( 0.00001677 ); // m3/s per watt = 125 cfm/ton
Real64 const MaxHeatVolFlowPerRatedTotCap2( 0.00004026 ); // m3/s per watt = 300 cfm/ton
Real64 const MaxCoolVolFlowPerRatedTotCap2( 0.00004026 ); // m3/s per watt = 300 cfm/ton
Real64 const MinOperVolFlowPerRatedTotCap2( 0.00001342 ); // m3/s per watt = 100 cfm/ton
@rraustad The CapfFlow and EIRfFlow curves are a separate issue. Most users are running rubber-band coils where the rated inputs are meant to represent the coil with the assumption that once a real coil is selected the airflow will match the coil. If I am following this thread correctly, the proposal here is only to expand the range for the rated performance (either user-input or autosized). Operating the coil at a flow rate other than rated is not part of this issue.
@nealkruis As a side note, remember that expanding this range will do more than change the error message. It will also expand the clipping range where sizing alter that coil capacity vs the design coil load in order to keep it within this range.
@nealkruis I used to fight this same battle, to try and widen the range, so I am sympathetic. If I recall correctly what finally caused me to retreat was that the HVAC Toolkit document has the 300 - 450 cfm/ton range in the model description (I no longer have that reference though so I can't verify now). It is hard to go beyond what the model's reference has in it, and I am not sure a casual email from the reference author is sufficient. I think it takes testing and comparison to something, and then adding such content to the engineering reference to show that the ADP method was found to be able to handle blaa blaaa. It must break down at some point but guessing at the range is hard for a pedant to accept.
@rraustad I agree with @mjwitte regarding the curves being a separate issue.
@mjwitte Great point regarding the clipping. There will certainly be some expected diffs if we remove the limits.
@EnergyArchmage I don't believe the original HVAC Toolkit reference (Thermal Environmental Engineering, 3rd Edition) imposes any range of validity (though I also don't have that reference handy to double check).
Overall, I feel that these DX range errors are some of the most common and frustrating errors our users face. Even as a warning, I feel they would still be more alarming than needed and cause more confusion than they are worth. Often, my advice is "you can safely ignore these messages"--not exactly a satisfying resolution for the user.
This GitHub issue originally came up because a company was taking ratings directly from a PTAC manufacturer's catalogue that were outside this range. They were understandably frustrated with the number of errors/warnings and that their input was being adjusted internally by the clipping routine.
My position is that, as a calculation engine, EnergyPlus should only impose warnings and errors where physical limits exist. You never know when someone wants to explore a creative application of a DX coil that exercises the physical model beyond its typical application, but still within its physical limits. There are countless places where we could add sanity checks to EnergyPlus input (e.g., LPD > 5 W/m2?), but that is the role of an interface and not the calculation engine.
@nealkruis I don't think we can remove the limits completely, especially on sizing. The way that airflow and coil load sizing are somewhat independent could lead to ridiculous system with very high or very low cfm/ton. Perhaps the best solution would be to make these limits be user inputs so the defaults can be overridden.
@mjwitte Are you referring to sizing differences between ventilation and cooling airflow requirements?
That's part of it, but there are so many things that can result in a big discrepancy between the supply airflow and the coil capacity. Other cases are high ventilation loads, heating-dominated climate, inconsistent supply temps for sizing, etc. Many of the problems arise because the default sizing method relies specifying the supply temp which may be relevant for a built-up DXVAV system serving many zone, but isn't the way a single-zone rooftop unit is sized. Unless the user specifies FlowPerCoolingCapacity, most DX systems don't end up sizing the way they should. Part of the solution here is to use the available sizing options to get a well-balanced piece of equipment. And we may need additional options to do it right. High outdoor air coils are another issue which is why the 100%OA coil options was added, but most users don't know about it and it's limited in usefulness.
I'll just throw in here that LG has provided input data for their VRF units to NREL's TPEX (and BCL) which include terminals with flow/capacity ranges outside the EnergyPlus limits. In their accompanying guide (pdf link) for modeling these systems they recommend overriding their inputs (page 20) to avoid hitting the limits (which are fatal errors for Coil:Cooling:DX:VariableRefrigerantFlow at least as of v8.6).
@eringold What are the highest/lowest values you see in that data?
@mjwitte the linked guide has a table of each unit and corresponding input parameters. Looks like the highest is ceiling cassette model ARNU053TRC2 with 605 CFM/ton (0.00008125 m3/s/W).
@mjwitte
We can get started on the four more straightforward tasks and address the actual ranges after we've looked into it a bit more.
@nealkruis There are some warnings/fatals in the detailed chilled water coil when the air velocity across the coil is very high. Kind of similar, and they were added because the calculations blew up and the cause traced back to this (if I remember correctly).
@mjwitte It appears the warning was added to inform an excess of design guidelines (with a safety factor of 2.0) and the error was added due to numerical limitations (at ~20x typical velocities).
Maybe we need a warning when the rated flow per capacity causes a freezing ADP or greater than, say, 650 cfm/ton that suggests the user check their sizing method for the coil. Then the user is aware of the potential problem and points them to the DesignSpecification:ZoneHVAC:Sizing object the can use if they want to use a more realistic approach. I think the whole clipping approach is a bit opaque and worrisome. With the DesignSpecification object, we enable the users to make those decisions rather than making them for them. Like you said, maybe we need more options in that object to provide adequate flexibility.
Any other ideas?
@nealkruis @mjwitte, Back to the idea of making the range values an input, I was also thinking of new inputs for the range to use for clipping during autosizing. So there would be two ranges, a wider one for model validity and a narrower one for what to use as normal for sizing. But it should be general for DX coils used in AirLoopHVAC as well as ZoneHVAC, so I am not sure DesignSpecification:ZoneHVAC:Sizing is the right place.
I like that idea. Do we need a DesignSpecification:Coil:Cooling:DX object that allows you to apply limits to specific coils (or maybe a list of coils)?
If possible, I'd rather fit it into existing objects, Sizing:System, and DesignSpecification:ZoneHVAC:Sizing which both already have inputs related to flow/capacity and other related sizing inputs.
The errors for "Rated air volume flow rate per watt of rated total cooling capacity is out of range" (e.g., here), appear frequently in projects.
As far as I can tell, this has always been a severe (or fatal) error with no real justification for the imposed limits.
I recognize these limits as somewhat typical bounds of DX coil design, but coils are sometimes designed for specific purposes outside this range. The only real physical limit is the saturated vapor temperature of the refrigerant at atmospheric pressure (i.e., the theoretical limit of the apparatus dew point temperature).
At a minimum, the "severe" errors should be reduced to a warning (they don't even trigger a fatal error). Though, I suggest we replace them with a warning when the apparatus dew point is calculated to be less than -25 C (saturation of R134a at 1 atm). Interfaces can run their own QA checks on flow rate per capacity values if they'd like, but it seems heavy-handed for them to be imposed by the engine.
Related to #6113.
Tasks
Checklist