FluidSystem - TwoPipe

[GoogleCodeExporter]

What SDD Object:Property(s) are relevant to this issue?
FluidSystem:Type

Explanation of addition, revision, or clarification:
Based on a review of E+ I/O reference, two-pipe hydronic systems are modeled as 
separate hot water and chilled water loops that are scheduled to not operate at 
the same time.  

DOE-2.2 supports describing two-pipe systems, however, depending on control 
requirements, I have often modeled these as separate heating/cooling loops 
(similar to the E+ convention) to have more flexibility on loop temperature 
control.  

A few questions/items for discussion:
1) Kyle, please confirm that this is indeed how two-pipe systems are modeled in 
OS/E+
2) If true, then we need to identify how to describe this system in the SDD.  
Here are some proposed ideas:

Concept #1 (similar to how two-pipe systems can be described in DOE-2.2)
- Add enum to FluidSys:Type = TwoPipeWater.  This System type could have both 
Boiler and Chiller primary equipment defined on the same Primary FluidSeg.
- Add a property FluidSys:TwoPipeSnapTemperature.  This would define the OA 
temperature at which the primary heating/cooling equipment would be allowed to 
operate.  Another property, FluidSys:TwoPipeSnapDeadband would define the 
deadband around the SnapTemp to ensure that the loop does not switch abruptly 
from htg/clg for hours immediately around the snap temp.
- Add a new object call CoilTwoPipe, which users would define in their 
Air/ZnSystems, and be connected to the FluidSegs of the FluidSys = TwoPipeWater
- The OS translator would see that FluidSys:Type = TwoPipeWater and create the 
two plants and separate htg/clg coils systems with the relevant system 
availability controls.

Concept #2 (similar to how two-pipe systems are described in E+, I think)
- User defines separate HotWater/ChilledWater FluidSystems.
- Add control properties that allow user to specify when the two systems can be 
enabled.
- User would still specify CoilHtg/CoilClg objects in thier Air/ZnSystems, same 
as they would a four-pipe system.

Concept #1 is more representative of what systems look like in real life.  
However, Concept #2 would seem to be less translation effort.  Both approaches 
require adding properties, but Concept #2 entails adding an additional Coil 
object to the SDD, though this could be mitigated by still requiring 
Air/ZnSystems be described with separate coils; they could just be connected to 
the same FluidSegs of the FluidSys:Type = TwoPipeWater 

Proposed resolution:
For release 1 and near future, I suggest we stick with Concept #2, but want to 
get thoughts on this before moving forward with the necessary changes.  

Please provide any additional information below.

Original issue reported on code.google.com by da...@360-analytics.com on 1 May 2013 at 6:22

[GoogleCodeExporter]

Discussed this system with Kyle, and although some testing needs to be done, it 
is likely that representing the two-pipe system per Concept #1 should be fine; 
below is an updated description.  

Before we make this any more of a priority, I reviewed the ACM and did not find 
two-pipe systems listed in the ACM.  I've added John to this issue, but since 
it is not in the ACM, this suggests that this is not a Release 1 priority?  
Roger/John, can you confirm before we add this to the SDD updates/instances? 

Two-pipe systems
SDD description:
ZoneSystem:Type = TPFC (two-pipe fan coil)
FluidSystem:Type = TwoPipeWater.  Would assign both chiller and boiler to the 
Primary FluidSegs of this System
ZnSys has both CoilHtg and CoilClg children, connected to the same 
FluidSegments of the two-pipe fluid system.
FluidSystem includes new properties: ChangeOverTemperature and 
ChangeOverDeadband. 
Clg/Htg availabilty schedules would also be added to FluidSystem to allow for 
defining seasonal availability as well.

OS/E+ description:
- ZoneHVAC:FourPipeFanCoil would represent the air-side
- A single PlantLoop with both Chiller and Boiler objects to the Primary 
FluidSegs of this System
- OA reset setpoint controller would be used to controller the change-over 
behavior.  The control inputs would be generated from the ChangeOverTemperature 
and ChangeOverDeadband properties

Kyle - will add OA reset setpoint controller for two-pipe changeover control 
and test configuration
Dave - Add necessary properties to FluidSystem and ZoneSystem and create SDD 
instance file

Original comment by da...@360-analytics.com on 6 May 2013 at 9:48

[GoogleCodeExporter]

Changing priority to Low. This is not a baseline system and is not explicitly 
required to be modeled by the current ACM. I don't think this should be 
required in the Version 1 CBECC release.

Original comment by JohnJArent on 6 May 2013 at 10:16

• Added labels: Priority-Low
• Removed labels: Priority-High

[GoogleCodeExporter]

OA Reset has been added.

Original comment by kbe...@gmail.com on 6 May 2013 at 10:18

[GoogleCodeExporter]

Well, we needed OA reset anyways for hot/chilled water loops (see prototype 
00400), so no lost time there.  Roger, can you confirm with Martha that this 
change is acceptable?    

Original comment by da...@360-analytics.com on 6 May 2013 at 10:23

[GoogleCodeExporter]

I'll confirm with Martha. 

Original comment by rhedr...@archenergy.com on 6 May 2013 at 11:31

• Changed state: Discussion

[GoogleCodeExporter]

Original comment by rhedr...@archenergy.com on 9 Dec 2014 at 9:19

• Changed state: WontFix