Allow ZoneHVAC:TerminalUnit:VariableRefrigerantFlow to be connected to AirloopHVAC and AirLoopHVAC:OutdoorAirSystem:EquipmentList #7605
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,229 @@ | ||
| Connecting Split DX AHU Components to VRF Refrigeration Loops | ||
| ================ | ||
|
|
||
| **Richard Raustad, Florida Solar Energy Center** | ||
|
|
||
| - 11/7/19 - Draft NFP | ||
| - 12/4/19 - several off-line design strategy discussions | ||
| - 12/4/19 - Design Document added at end of NFP | ||
| - 12/5/19 - New OO method of storing air system factory pointers has tentatively been implemented and the ZoneHVAC:TerminalUnit:VariableRefrigerantFlow objects has been added as a valid main air loop component. | ||
|
|
||
| ## Justification for New Feature ## | ||
|
|
||
| One of the recent developments in the variable refrigerant flow systems (VRF) field is the ability to connect terminal devices other than indoor split fan coils to a VRF refrigerant loop. These new terminal devices include DOAS AHUs and rooftop mounted split DX AHUs for space conditioning and ventilation. | ||
|
|
||
| Nearly all VRF applications need ventilation. Previously, ventilation had to be provided by separate packaged rooftop type DOAS equipment since VRF indoor units cannot handle raw outdoor air directly and VRF condensing units could not serve DOAS equipment. In addition, one of the energy efficiency limitations of VRF systems is the lack of an outdoor air economizer cycle. Both challenges have now been solved. | ||
|
|
||
| Multiple major manufacturers such as Daikin, Mitsubishi, LG, and Toshiba-Carrier offer the ability to connect split DX DOAS AHUs to VRF condensing units. In addition, Toshiba-Carrier condensing units can be connected to multiple rooftop-mounted split DX AHUs that provide space conditioning and ventilation and can offer outdoor air economizer cycles. These developments extend the application of VRF systems and the energy efficiency of these systems. | ||
|
|
||
| Currently, VRF systems in EnergyPlus only allow ZoneHVAC terminals to be connected to a VRF refrigerant loop. | ||
|
|
||
| ## E-mail and Conference Call Conclusions ## | ||
|
|
||
|
|
||
| ## Overview ## | ||
|
|
||
| This task will expand the capabilities of the VRF model to allow terminal devices such as split DX DOAS AHUs and split DX AHUs for space conditioning and ventilation to be connected to VRF refrigerant loops. The following figure is excerpt from the Eng. Ref. (Figure 16.51, pg 1163, V9.2) and modified to include VRF air loop and outdoor air equipment (red circle). | ||
|
|
||
| Figure 1:  Variable Refrigerant Flow Heat Pump (draw through fan placement) | ||
|
|
||
| ## Approach ## | ||
|
|
||
| The common connection of VRF TU's and the VRF condenser is the ZoneTerminalUnitList object. All ZoneHVAC:TerminalUnit:VariableRefrigerantFlow objects connected to a single VRF condenser (AirConditioner:VariableRefrigerantFlow or AirConditioner:VariableRefrigerantFlow:FluidTemperatureControl:\*) are listed in the ZoneTerminalUnitList object and this objects name is entered as an input in the VRF condenser object. | ||
|
|
||
| The most straight-forward approach appears to be allowing the ZoneHVAC:TerminalUnit:VariableRefrigerantFlow object to be connected as zone (existing), air loop and outdoor air system equipment. Using this methodology, limited changes to the AirConditioner:VariableRefrigerantFlow and AirConditioner:VariableRefrigerantFlow:FluidTemperatureControl:\* objects are anticipated. | ||
|
|
||
| ## Controls: | ||
| ZoneHVAC Equipment: no changes (currently load based control) | ||
| AirloopHVAC Equipment: requires thermostat control zone input, load based control | ||
| OutdoorAir Equipment: controlled to outlet node set point temperature (and humidity ratio?) | ||
|
|
||
| ## Testing/Validation/Data Sources ## | ||
|
|
||
| New test files will be created using VRF TUs in the air loop and outdoor air system. | ||
|
|
||
| ## Input Output Reference Documentation ## | ||
|
|
||
| IO Ref text will be updated to include these new capabilities. | ||
|
|
||
| ## Input Description ## | ||
|
|
||
| Changes to the IDD appear to be minimal as no new objects will be added to E+. The only changes to model inputs are the allowed location of the TU object and thermostat location for controlling air loop equipment. | ||
|
|
||
| ``` | ||
| ZoneHVAC:TerminalUnit:VariableRefrigerantFlow, | ||
| \memo Zone terminal unit with variable refrigerant flow (VRF) DX cooling and heating coils | ||
| \memo (air-to-air heat pump). The VRF terminal units are served by an | ||
| \memo AirConditioner:VariableRefrigerantFlow or | ||
| \memo AirConditioner:VariableRefrigerantFlow:FluidTemperatureControl:* system. | ||
| \min-fields 19 | ||
| A1 , \field Zone Terminal Unit Name | ||
| \required-field | ||
| \type alpha | ||
| \reference ZoneTerminalUnitNames | ||
| \reference DOAToZonalUnit | ||
| \reference ZoneEquipmentNames | ||
|
|
||
| -- new references as follows (not yet tested) -- | ||
| \reference-class-name validBranchEquipmentTypes | ||
| \reference validBranchEquipmentNames | ||
| \reference-class-name validOASysEquipmentTypes | ||
| \reference validOASysEquipmentNames | ||
|
|
||
| -- new field -- | ||
| A19; \field Controlling Zone or Thermostat Location | ||
| \note Used only for AirloopHVAC equipment on a main branch | ||
| \type object-list | ||
| \object-list ZoneNames | ||
| \note Zone name where thermostat is located. Required for control of air loop equipment. | ||
| ``` | ||
|
|
||
| ## Outputs Description ## | ||
|
|
||
| No new outputs are anticipated. | ||
|
|
||
| ## Engineering Reference ## | ||
|
|
||
| New schematic diagram (similar to above) and corresponding text description. | ||
|
|
||
| ## Example File and Transition Changes ## | ||
|
|
||
| New example file will be included. | ||
| No transition required. | ||
|
|
||
| ## References ## | ||
|
|
||
| Manufacturer Documentation | ||
| ------------ ------------------------------------------------------------------- | ||
| Daikin https://www.daikinac.com/content/commercial/ventillation-units/dvs-dedicated-outside-air-system | ||
| Mitsubishi https://www.mitsubishipro.com/products/city-multi-vrf/ventilation/premisys-dedicated-outdoor-air-systems | ||
| Mitsubishi http://meus1.mylinkdrive.com/item/PremiSys.html | ||
| LG https://lghvac.com/commercial/product-type/?productTypeId=a2x44000003XR0s&iscommercial=true | ||
| Carrier https://www.carrier.com/commercial/en/us/products/variable-refrigerant-flow/toshiba-carrier-vrf-products/toshiba-carrier-indoor-units/40qq/ | ||
|
|
||
|
|
||
| ## Design Documentation ## | ||
|
|
||
| Adding another air loop component, in this case ZoneHVAC:TerminalUnit:VariableRefrigerantFlow, perpetuates historical programming of individual component calls without regard to future code changes for air loop equipment and code maintenance. The Simulate call arguments for various air loop models use a CompIndex for array based access. The UnitarySystem was the first air loop model to use a pointer based Sim call, however, this pointer was not accessible to all air loop equipment (e.g. VRF, ChangeoverBypass). | ||
|
|
||
| The declaration of the pointer, used by upper level managers (i.e., Air loop equipment, OA systems, zone equipment), was specific to the UnitarySystem and this declaration is no longer adequate. | ||
|
|
||
| DataAirLoop.hh | ||
|
|
||
| struct OutsideAirSysProps | ||
| std::vector<UnitarySystems::UnitarySys *> compPointer; | ||
|
|
||
| DataAirSystems.hh | ||
|
|
||
| struct AirLoopCompData // data for an individual component | ||
| UnitarySys *compPointer; // pointer to UnitarySystem | ||
|
|
||
| DataZoneEquipment.hh | ||
|
|
||
| struct EquipList | ||
| std::vector<UnitarySystems::UnitarySys *> compPointer; | ||
|
|
||
| At the time that UnitarySystem was refactored to use the factory/pointer method, the set up for the air loop branch object changed from: | ||
|
|
||
| } else if (componentType == "AIRLOOPHVAC:UNITARYSYSTEM") { | ||
| PrimaryAirSystem(AirSysNum).Branch(BranchNum).Comp(CompNum).CompType_Num = UnitarySystem; | ||
|
|
||
| to: | ||
|
|
||
| } else if (componentType == "AIRLOOPHVAC:UNITARYSYSTEM") { | ||
| PrimaryAirSystem(AirSysNum).Branch(BranchNum).Comp(CompNum).CompType_Num = UnitarySystemModel; | ||
| UnitarySystems::UnitarySys thisSys; | ||
| PrimaryAirSystem(AirSysNum).Branch(BranchNum).Comp(CompNum).compPointer = thisSys.factory( | ||
| DataHVACGlobals::UnitarySys_AnyCoilType, PrimaryAirSystem(AirSysNum).Branch(BranchNum).Comp(CompNum).Name, false, 0); | ||
|
|
||
| And the Sim call was changed from this: | ||
|
|
||
| } else if (SELECT_CASE_var == UnitarySystem) { // 'AirLoopHVAC:UnitarySystem' | ||
| SimUnitarySystem(CompName, FirstHVACIteration, AirLoopNum, CompIndex, HeatingActive, CoolingActive); | ||
|
|
||
| to: | ||
|
|
||
| } else if (SELECT_CASE_var == UnitarySystemModel) { // 'AirLoopHVAC:UnitarySystem' | ||
| CompPointer->simulate(CompName, FirstHVACIteration, AirLoopNum, CompIndex, HeatingActive, CoolingActive, OAUnitNum, OAUCoilOutTemp, ZoneEquipFlag); | ||
|
|
||
| where: CompPointer = PrimaryAirSystem(AirSysNum).Branch(BranchNum).Comp(CompNum).compPointer as provided by the UnitarySystem factory. | ||
|
|
||
| As is done with plant equipment, a new class will be created such that a pointer can be declared in air systems managers for use by all types of air system equipment. This class is defined in a new header file, DataHVACSystems.hh. Virtual functions are included where this pointer is used to access model specific information from outside the scope of UnitarySystem (e.g., the Sim routine and get functions for air nodes used by air loop DOAS systems). Note that unit tests will need to be updated where this pointer is used to set or access object data and model functions. | ||
|
|
||
| ``` | ||
| #ifndef DataHVACSystems_hh_INCLUDED | ||
| #define DataHVACSystems_hh_INCLUDED | ||
|
|
||
| // C++ Headers | ||
| #include <string> | ||
|
|
||
| // EnergyPlus Headers | ||
| #include <EnergyPlus/EnergyPlus.hh> | ||
|
|
||
| namespace EnergyPlus { | ||
|
|
||
| // base class for all HVAC systems | ||
| class HVACSystemData | ||
| { | ||
|
|
||
| public: | ||
|
|
||
| // Default Constructor | ||
| HVACSystemData() | ||
| { | ||
| } | ||
|
|
||
| virtual void simulate(std::string const &Name, | ||
| bool const firstHVACIteration, | ||
| int const &AirLoopNum, | ||
| int &CompIndex, | ||
| bool &HeatActive, | ||
| bool &CoolActive, | ||
| int const OAUnitNum, // If the system is an equipment of OutdoorAirUnit | ||
| Real64 const OAUCoilOutTemp, // the coil inlet temperature of OutdoorAirUnit | ||
| bool const ZoneEquipment, // TRUE if called as zone equipment | ||
| Real64 &sysOutputProvided, // sensible output at supply air node | ||
| Real64 &latOutputProvided // latent output at supply air node | ||
| ) = 0; | ||
|
|
||
| virtual void sizeSystem(bool const FirstHVACIteration, int const AirLoopNum) = 0; | ||
| virtual int getAirInNode(std::string const &UnitarySysName, int const ZoneOAUnitNum) = 0; | ||
| virtual int getAirOutNode(std::string const &UnitarySysName, int const ZoneOAUnitNum) = 0; | ||
|
|
||
| }; | ||
|
|
||
|
|
||
| } // namespace EnergyPlus | ||
|
|
||
| #endif // DataHVACSystems_hh_INCLUDED | ||
| ``` | ||
|
|
||
| This class is inherited by the HVAC model where a factory call returns a pointer stored in a local array for later use. | ||
|
|
||
| UnitarySystems.hh | ||
|
|
||
| struct UnitarySys : HVACSystemData | ||
|
|
||
| and it's the HVACSystemData class that is used to declare the pointer array in various managers (instead of using the UnitarySys class). | ||
|
|
||
|
|
||
| DataAirLoop.hh | ||
|
|
||
| struct OutsideAirSysProps | ||
| std::vector<HVACSystemData *> compPointer; | ||
|
|
||
| DataAirSystems.hh | ||
|
|
||
| struct AirLoopCompData // data for an individual component | ||
| HVACSystemData *compPointer; // pointer to HVAC system | ||
|
|
||
| DataZoneEquipment.hh | ||
|
|
||
| struct EquipList | ||
| std::vector<HVACSystemData *> compPointer; | ||
|
|
||
| Instead of CompIndex being used on the call to the Sim function, the compPointer accesses that data and Sim function directly (as long as all model Sim functions are unified with the same arguments). Eventually, CompIndex will no longer be needed. | ||
|
|
||
| Now that the VRF terminal unit is allowed in the air loop, it should simply be a matter of inheriting the new class and storing the pointer in the same array previously used only for UnitarySystems. Similar changes to other HVAC equipment can now be made during ongoing refactoring efforts. The good news is that since the UnitarySystem can be used anywhere in the air simulation (i.e., air loops, OA systems, zone equipment, and zone OA units) this new OO method (with the help of reviewers updates) can be used with any HVAC equipment type. | ||
|
|
||
|
|
||
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It bothers me that we'll now have a "ZoneHVAC" object that's valid in airloops. We've already set the reverse precedent by allowing "AirloopHVAC:UnitarySystem" to be in airloops and in ZoneHVAC. Will any other components come along that are applicable in both places? Do we want two flavors "ZoneHVAC:TerminalUnit:VariableRefrigerantFlow" and "AirloopHVAC:TerminalUnit:VariableRefrigerantFlow". Or better yet, why not allow "Coil:Cooling:DX:VariableRefrigerantFlow" and Heating as valid coil type in AirloopHVAC:UnitarySystem? Then you don't need any new control logic etc. (Sorry this is a bit late in the game.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm all for changing the names of these objects to reflect system type instead of location. Instead of AirloopHVAC:UnitarySystem it should be just UnitarySystem or HVAC:UnitarySystem. Same for the ZoneHVAC VRF terminal unit. That's a different discussion.
Multiple flavors of any object is no longer acceptable. Although that is managed nicely in Furnaces.cc so it is possible if that's the route to take. It would be nice if JSON could handle that directly.
Furnaces::GetFurnaceInput
Regarding the VRF coils, the condensing unit connects to (via the TerminalUnitList) and talks to the terminal units (not the coils) to sum cooling/heating rates, limit coil capacity, to know when all TUs have been simulated, and maybe other parameters. If I remove the coils from the terminal unit I'll loose that connection (which means rethinking the whole VRF model communication).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I get all that. So, the terminal unit has inputs for an OA mixer - how will that play out when used in an airloop?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggested OAMixer flows are 0 and autosizing will create 0 flow. Same as ChangeoverBypass. This may mean a new object, one without an internal OA mixer, is not all that out of the question. And I suppose I could drop a VRF coil object on the main branch and create the TU in the background and add that TU to the correct TU list and everything would work the same as it does now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't get into making shadows object in the background. I thought maybe you'd let the OA mixer be active in the TU and then the user wouldn't need an OA system beyond what's in the VRF terminal unit. Would that work? Or let the OA mixer be optional and only require it when it's used as zone equipment. This may run into the same input processing/init checking problems that UnitarySystem has with its dual role.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree on shadow objects. For child components on the main branch, a parent has to control it (or that control is within the child model at a higher level). So let's assume the parent will be the TU for now. As for an internal OA mixer (w/o economizer) vs OA system mixer, I agree that it could be one or the other. But both would be a problem in sizing (unless of course that was somehow included in sizing). The subject of optional OA mixer came up with ChangeoverBypass and I don't recall right now how I left that (I think I tried doing a node copy from OA mixer inlet to outlet to avoid calling the mixer). And yes I am running into the same problem of zone equipment being called first for a dual role object (i.e., GetInput doesn't have all the info yet). It would be much easier for models that use the OO method of a "new" instance to avoid some of this "waiting for info" issue but that I think is a major rewrite. I'm trying to move in that direction but I should take these types of steps slowly and methodically.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the zone vs airloop input processing, I think if GetInput were to just populate an array of input data and save all the validation and cross-checking for an Init step, that should solve the issue of timing.