[Bldg-sim] [Equest-users] BEST PRACTICES: Wild Coils

Chris Yates chris.malcolm.yates at gmail.com
Mon Jun 24 01:43:16 PDT 2019


There are a number of non-linearities in this kind of control. We (UK) term
the pressure related non-linearity "valve authority". This can be quite
extreme. However, with the advent of 2-port control with Pressure
Independent Control Valves (PICV) and Differential Pressure Control Valves
(DPCV) this has helped ease the issue. Previously, with 3-port control and
constant speed pumping the agreed method to limit valve authority problems
was to design a low-pressure drop system (typically 200 Pascal/metre).
There can also be transitions between laminar and turbulent flow in the
coil itself - this affects heat transfer. I don't know enough about the
various software's models to understand if either of these phenomena can be
represented.

I think Michael Wetter's work is very relevant to the problem. I also think
there could be some success with IES VE, possibly using their ERGON
software to replicate actual building variables. The latter can also define
network airflow rather than scheduled infiltration rates. Another contender
is IDA ICE. This similarly has network airflow (IDA *has* to model network
airflow), and the ASHRAE HVAC toolkit model of heating and cooling coils
can be modeled. I have little experience of this, but it appears to model
water temperature and valve position explicitly (don't ask me anything more
detailed). There is a benefit in modeling network airflow, and I think this
gives the commercial tools an advantage.
[image: ashrae_tk_coil.png]

I seem to recall this interactive web-based training software used to let
you play with valve problems: http://www.learnhvac.org/index.php

A final note is that this is entering the realms of stochastic problems, so
the work done with Annex 66 <https://annex66.org/>could be relevant.

On Sat, Jun 22, 2019 at 3:42 PM Timothy Moore via Bldg-sim <
bldg-sim at lists.onebuilding.org> wrote:

> Nick and all,
>
>
>
> Perhaps I can answer your question regarding what Cory has described for
> the IES VE, and perhaps take that a little further, as I imagine Cory might
> have gone home for the day by this time. J
>
>
>
> Firstly, indeed, if a runaway source of heat can be sufficiently described
> as a scheduled internal gain, then most all of the simulation tools
> discussed here ought to be able to do that quite readily. If, however, the
> behavior or output at any given time for the “wild” coil, radiator,
> baseboard, unit, etc. is tied to the characteristics of the of which it is
> a part, it may be preferable to model this as a system or terminal unit
> that includes a component that has just that behavior…
>
>
>
> For example, depending upon the type of “rogue”, “wild”, or “runaway”
> device, there are likely to be contextual influences at one or more of five
> different levels:
>
> 1)     *Room*—*e.g*., air and/or radiant temperature of the space, and
> thus the delta-T seen by the rogue device, which will influence the amount
> of unintentional heating or cooling it does (if it is a “room unit” that is
> directly exposed to the room conditions) ;
>
> 2)     *Component*—*e.g*., design vs. off-design output at reduced or
> increased delta-T with respect to the space or airflow path that it is
> located within;
>
> 3)     *Terminal unit*—*e.g*., interactions with FCU fan, OA path, etc.
> operation, volume flow rate, and entering air temperatures;
>
> 4)     *System*—*e.g*., primary airflow operation, volume, and air
> temperature;
>
> 5)     *Plant*: HWL or CHWL operation, supply temperature, and flow rate.
>
>
>
> The output of a rogue Radiator with a stuck valve would, for example, be
> influenced to one or another degree by 1, 2, and 5 above.
>
> The output for an FCU coil with a stuck valve, for example, be influenced
> to one or another degree by 2, 3, 4, and 5 above.
>
>
>
> In the IES Virtual Environment ––specifically within the ApacheHVAC module
> of the VE–– the following are relevant specifics regarding control and
> modeling of heating and cooling coils and “room units” (e.g., hydronic
> radiators, convective baseboard units, radiant heating panels, or embedded
> hydronic floor/ceiling slab heating loops, as well as the corresponding
> hydronic cooling panels and loops) if you are interested in modeling one or
> another form of “runaway” or “wild” source of heating/cooling in the
> context of the system or zone-level terminal unit that it is attached to.
> These attributes would allow you to account for any combination of
> contextual influences 1­–5 listed above:
>
> ·        *Coils*: In addition to the usual controlled variables for a
> coil (leaving air DBT and, for cooling coils, leaving air DPT), a coil can
> be controlled to transfer a given amount of heat to the airstream passing
> over the coil (or from the airstream for the case of a cooling coil). This
> is different than simply modeling a scheduled process load or internal gain
> in the space, as the heating (or cooling) done by the coil will reach the
> space only to the extent that the air passing over the coil goes to that
> space.
>
> o   If the airflow is modulated (*e.g.,* as in a fan-coil with
> multi-speed or variable-speed fan, or for a re-heat coil in a fan-powered
> or basic VAV box) a given controlled heat transfer rate will determine how
> much heat is dumped into that airstream, and thus the temperature of the
> air as the combined outcome of heat transfer and volume airflow. If the
> airflow modulates to a very small flowrate and the heat transfer remains
> fixed, the result may be a small quantity of very warm (or very cool) air.
>
> o   If the advanced coil model is used, the amount of heat transferred to
> the air will be also constrained by the delta-T between the coil and the
> air, using a counter-flow model of the water in the coil relative to the
> airflow (i.e., for heating, the entering air will initially encounter the
> coolest water that is exiting the coil, and will lastly be heated by the
> hottest water entering the coil, and vice versa for a cooling coil). Thus
> the heat transfer will be limited to that which can be physically
> transferred between the water loop and air loop, given the temperatures and
> flow rates on both sides of this counter-flow arrangement, as well as the
> coil description in terms of capacity, contact factor, etc.
>
> o   The ‘simple coil’, which is really intended mainly for modeling thing
> other than coils on water loops, has fewer constraints, as it does not
> attempt to account for all aspects of air and water flows and temperatures.
> There are some feasibility constraints in VE2018, and there is a move to
> improve upon this in the new future.
>
> o   Regardless of the coil model used, if the airflow over the coil is
> shut off completely, the heat transfer from (or to) the coil will cease.
>
> §  In the case of a Fan-Coil Unit, this will depend upon the
> configuration modeled: If the ventilation air to the space is modeled as
> passing through the FCU, the airflow over the coil will persist so long as
> the system (e.g., DOAS for ventilation) is operating; If the ventilation
> air path to the space is modeled as separate from the FCU, the airflow over
> the coil will be present only when the FCU fan is operating.
>
> §  VRF Indoor Unit coils are treated the same as FCU coils in this regard.
>
> §  Parallel fan-powered boxes can likewise be modeled with the heating
> coil either within the combined primary + secondary airstream or just on
> the secondary airflow path.
>
> §  Active Chilled/Heated Beams are similar: The coil can be modeled as
> seeing only the induced airflow (typical active beam config) or both the
> primary + induce airflow. While there is no local fan, and thus airflow is
> determined at the system level, the airflow path is relevant as this
> determines the total volume of air seen by the coil and thus the amount of
> heat transfer that is possible (given temperature and flow rates for both
> the water and air loops).
>
> o   Heat transfer to/from the air flowing over the coil will also be
> constrained or controlled by (all of which are optional):
>
> §  Schedules (consistent with the scheduled internal gain that Nick
> suggested). This could be set to ‘on continuously’ for a coil that is
> making or removing heat all the time, could use the HVAC system operating
> schedule if it does this whenever the system is operating, or could use the
> HVAC schedule with a seasonal availability constraint for cases wherein the
> coil is on a seasonal change-over system. The schedule profile can also
> incorporate a simple formula referencing variables such as the outdoor air
> temperature, etc. if this is the basis for the change-over operation.
>
> §  On/off control and hysteresis (deadband) with respect to a setpoint
> and sensed variables;
>
> §  On/off control as a function of logical AND/OR connections to other
> controllers.
>
> §  Proportional control of the heat transfer amount with respect to a
> setpoint, control bandwidth, and sensed variables. Both the setpoint and
> the control signal values at min & max sensed variable can also be varied
> according to a profile.
>
> ·        *Room unit or zone/room-level hydronic loop*: These include
> hydronic radiators, convective baseboard units, radiant heating panels, or
> embedded hydronic floor/ceiling slab heating loops, as well as the
> corresponding hydronic cooling panels and loops
>
> o   Heating/cooling output for all of these components is constrained by
> the following:
>
> §  SWT and flow rate of the water loop (HWL or CHWL) to which the
> zone-level component is attached;
>
> §  Design max water flow rate for the component;
>
> §  Design capacity at design conditions (design room air temperature and
> design room radiant temperature), and thus reduced or increased capacity at
> *off*-*design* conditions as a function of lesser or greater delta-T.
>
> o   Controllers for these types of heating and cooling components include
> all of the following (optional) controls:
>
> §  Schedules, as described above for coil controls––*e.g., *could be
> scheduled as always on with HVAC system.
>
> §  On-Off setpoint control, as described above for coil controls.
>
> §  On-Off as a function of logical AND/OR connections with other
> controllers, as described above for coil controls.
>
> §  Proportional flow control, as described above for coil controls, but
> specifically for water flow control.
>
> §  Proportional temperature control, as described above for coil
> controls, but specifically for water temperature control.
>
> o   Surface temperature in the space: Because room units are, unlike
> coils, located within the room, they are exposed to room
> conditions—including mean radiant temperature for the space—that influence
> their output. Furthermore, all of the above On/Off and Proportional
> controls have access to one additional sensed variable:
>
> §  Floor, ceiling, or wall temperature for any one tagged surface within
> the room. And, as there is radiant exchange between surfaces, convective
> heat transfer with the air, and conductive heat transfer with adjacent
> spaces or exterior environments, this surface temperature is an integral
> part of the thermo-physical model of the room.
>
> §  This sensed surface temperature is normally used for the control of an
> embedded hydronic loop; however, in the case of a “rogue” radiator or
> similar device that might be mounted directly on an exterior wall, this
> sensed variable could be used to “control’ the “rogue” radiator output in
> relation to the interior surface temperature of the exterior wall. Thus,
> especially for an older building with poorly insulated walls, the model
> could be configured to estimate the output and resulting comfort and energy
> implications of a radiator adjacent to this externally cooled surface—
> *I.e.,* increasing the heat output of the radiator as a result of the
> potentially high delta-T in that location.
>
> o   Zonal subdivisions: If you want a better estimate of how much heat
> from a rogue radiator is being lost through the exterior wall it’s mounted
> upon, it may be useful to divide the room into core and perimeter zones,
> with a rather thin perimeter zone being separated only by an ‘air barrier’
> (simply a division between ‘fully mixed’ thermal zones in the model, but
> having no partition of any kind preventing either radiative or conductive
> heat transfer. And, if you wanted to take this further, you could firstly
> turn on MacroFlo to account for air transfer between the ‘fully mixed’
> perimeter and core thermal zones, as driven by bulk-airflow modeling of
> airflow driven both by temperature differences and other airflow inputs and
> outputs (infiltration, exfiltration, operable windows, window crack flow
> coefficients, airflow from adjacent rooms, and any HVAC airflow inlets or
> extract).
>
> ·        *Direct-acting Heater/Coolers*: Lastly, and perhaps truly least
> of all, there is also within ApacheHVAC a component called a Direct-acting
> Heater/Cooler that can be added to any space. This simpler ‘room unit’
> component can be used for both heating and cooling. It is like a radiator
> or other room unit in terms of the controls and sensed variables, but there
> is no relationship to any hydronic loops and there are no detailed inputs
> to describe design vs. off-design output. It just does what you tell it to
> do, as constrained only by the controller inputs.
>
>
>
> That was kind of fun to write! Hope you enjoyed it.
>
>
>
> Cheers,
>
> Timothy
>
>
>
> [image: IES-email2014] <http://www.iesve.com/>
>
> *Timothy Moore*
> *Senior Product Manager*
>
> C:
>
>   +1 (415) 810-2495
>
> T:
>
>   +1 (404) 806-2018
>
> T:
>
>   +1 (617) 502-2085
>
> Internal IP ext. 8549
>
> http://www.iesve.com
>
> Integrated Environmental Solutions Limited. Registered in Scotland No.
> SC151456
> Registered Office - Helix Building, West Of Scotland Science Park, Glasgow
> G20 0SP
>
> Email Disclaimer <http://www.iesve.com/disclaimer.html>
>
>
>
>
>
> *From:* Bldg-sim <bldg-sim-bounces at lists.onebuilding.org> *On Behalf Of *Nicholas
> Caton via Bldg-sim
> *Sent:* Friday, June 21, 2019 3:14 PM
> *To:* Duggin, Cory <Cory.Duggin at tlc-eng.com>; Jim Dirkes <Jim at fsmgmt.co>;
> Julien Marrec <julien.marrec at gmail.com>
> *Cc:* equest-users at lists.onebuilding.org; bldg-sim at onebuilding.org
> *Subject:* Re: [Bldg-sim] [Equest-users] BEST PRACTICES: Wild Coils
>
>
>
> Hey Cory!
>
>
>
> I’m thinking of the case for a fan-powered box with a reheat coil (and a
> stuck open valve):
>
>
>
> What you’re describing (to my doe2-tuned mind & terminology) sounds *in
> effect* a lot like a scheduled internal process/heat load, pushing a
> specified amount of heat into the space for all hours the loop would be
> active.  A shortcoming (at least in doe2/eQuest) for this approach stems
> from the following:
>
>
>
> You have asserted (or maybe just inferred?) that in VE, the specified heat
> transfer can be tied to the activity of the associated hydronic loop.  How
> might you supplement this approach to also capture the relatively different
> (perhaps not binary) amount of heat dumped into a space between states when
> the local fan is in operation vs. not?  Is there a way to tie these
> operations together within the simulation that doesn’t require processing
> of interval/hourly data outside of the model and feeding that back in via
> customized scheduling?
>
>
>
> For shared context, the issue of a “changeover” situation such as with
> 2-pipe systems and/or seasonal scheduling is easily enough addressed on the
> doe2/eQuest side of things by specifying hydronic loop availability and/or
> operational states over on the hydronic tab (of the eQ interface).  Happy
> to help anyone struggling with that over in the [equest-users] community
> ;-).
>
>
>
> *@ Everyone: * I do, by the way, *very very much* appreciate this flood
> of contributions so late on a Friday with the weekend beckoning us to go
> out and enjoy life!  It’s very encouraging to find validation in our shared
> worries and solution-paths through other’s experiences and approaches, and
> I’m certain I’m not the only one who feels that gratitude.
>
>
>
> ~Nick
>
>
>
> [image: cid:image005.png at 01D515A3.47EDD880]
>
> *Nick Caton, P.E., BEMP*
>
>   Senior Energy Engineer
>   Regional Energy Engineering Manager
>
>   Energy and Sustainability Services
>   Energy Performance Contracting
>
> D
> M
> F
> E
>
> 913 . 564 . 6361
>
> 785 . 410 . 3317
>
> 913 . 564 . 6380
>
> *nicholas.caton at se.com <nicholas.caton at se.com>*
>
> 15200 Santa Fe Trail Drive
> Suite 204
> Lenexa, KS 66219
> United States
>
> [image: cid:image006.png at 01D515A3.47EDD880]
>
>
>
>
>
> *From:* Duggin, Cory <Cory.Duggin at tlc-eng.com>
> *Sent:* Friday, June 21, 2019 4:39 PM
> *To:* Jim Dirkes <Jim at fsmgmt.co>; Nicholas Caton <Nicholas.Caton at se.com>;
> Julien Marrec <julien.marrec at gmail.com>
> *Cc:* bldg-sim at onebuilding.org
> *Subject:* RE: [Equest-users] BEST PRACTICES: Wild Coils
> ------------------------------
>
>
>
> In the VE you could do it a couple different ways.  Assuming the valve is
> stuck open, I would modify the heating coil control to control heat
> transfer, so it would always be providing the amount of heat the coil is
> designed to at that flow and water temp as long as HHW is available.  Make
> sure to use their advanced coil model though so the available coil capacity
> will vary depending on the HHW temperature.  If it is a changeover system,
> you would need to create an availability profile to put on the “wild” coil
> to limit when it can go wild.
>
>
>
> *Cory Duggin, PE, LEED AP BD+C, BEMP*
> *Principal* | *PEAK Institute*
> cory.duggin at tlc-eng.com
> *TLC* *ENGINEERING* *SOLUTIONS*
> 12 Cadillac Dr., Ste 150
> Brentwood, TN 37027
> *Main: *615.297.4554
> *Office: *615.346.1939
> *Cell: *931.273.8396
>
> *www.tlc-engineers.com*
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.tlc-engineers.com&data=02%7C01%7CNicholas.Caton%40se.com%7Cb2eb2075524f4ae3308d08d6f690fab1%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636967499884389344&sdata=3g65vor0T9XYvseiYSArRkz3p%2BYyK7wxfrja5eeea1s%3D&reserved=0>
> USGBC MidTN Branch Leadership Group Co-chair
>
>
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.tlc-engineers.com&data=02%7C01%7CNicholas.Caton%40se.com%7Cb2eb2075524f4ae3308d08d6f690fab1%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636967499884389344&sdata=3g65vor0T9XYvseiYSArRkz3p%2BYyK7wxfrja5eeea1s%3D&reserved=0>
>
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fcompany%2Ftlcengineeringsolutions&data=02%7C01%7CNicholas.Caton%40se.com%7Cb2eb2075524f4ae3308d08d6f690fab1%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636967499884399338&sdata=nr3ijW6bfe%2FG4YGsInWNEF%2FRJpnF9qQN75pbCjCbiZ8%3D&reserved=0%20>
>
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.facebook.com%2FTLCengineeringsolutions&data=02%7C01%7CNicholas.Caton%40se.com%7Cb2eb2075524f4ae3308d08d6f690fab1%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636967499884399338&sdata=Ci2Lp1Ckb9ZD%2B4gNDvXpxYVudAVDxYB1XYayFybYutQ%3D&reserved=0>
>
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FTLC_Engineering&data=02%7C01%7CNicholas.Caton%40se.com%7Cb2eb2075524f4ae3308d08d6f690fab1%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636967499884399338&sdata=WxC177HSx3aIDwrgJi8fm16eOsQG%2FknJI5mDPOw1wAc%3D&reserved=0>
>
> *From:* Bldg-sim [mailto:bldg-sim-bounces at lists.onebuilding.org
> <bldg-sim-bounces at lists.onebuilding.org>] *On Behalf Of *Jim Dirkes via
> Bldg-sim
> *Sent:* Friday, June 21, 2019 3:17 PM
> *To:* Nicholas Caton <Nicholas.Caton at se.com>; Julien Marrec <
> julien.marrec at gmail.com>
> *Cc:* bldg-sim at onebuilding.org
> *Subject:* Re: [Bldg-sim] [Equest-users] BEST PRACTICES: Wild Coils
>
>
>
> ..and since you people are distracting me enough to get me thinking about
> a problem that I have rarely seen...
>
>
>
> In the EnergyPlus world:
>
>    1. As Julien suggests, we could "play" with infiltration. the
>    ZoneInfiltration:EffectiveLeakageArea object can be scheduled, perhaps,
>    with higher rates in colder weather for opened windows
>    2. I think we could also create zones in such a way as to represent
>    our understanding of the wild coil areas and assign a fictitious zone
>    temperature setpoint of, say, 90F. At the same time, we could schedule the
>    boiler's operation for cold weather only (which is likely to be the case
>    anyway or people would be screaming at the building operator in the warmer
>    months)
>    3. Alternatively, some zones could have their heating setpoint
>    overridden by an EMS routine based on certain weather conditions. We could
>    do the same for infiltration.
>    4. Another possibility that comes to mind is to "schedule" boiler
>    efficiency via EMS to be lower during colder weather. This would be a
>    "catchall" value that would be used to calibrate the model (with brute
>    force) to utility bill actual values.
>
> ps, This sort of issue demonstrates the power of the modeling community to
> share experience and creativity - so that everyone becomes smarter and
> better able to provide real solutions! Let's wring it out.
>
>
>
> pps, Cory, can you share more details for the IES users?
>
>
>
> ppps, Funny to hear someone who lives in France write "y'all" 🙂😊. Your
> time in NYC changed you! (But you must have traveled South to hear that
> term very often)
>
>
>
> James V Dirkes II, PE, BEMP, BCxP
>
> Team Lead - Building Performance
>
> 616 450 8653
>
> Foresight Management
>
> *https://fsmgmt.co/
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__fsmgmt.co_%26d%3DDwMGaQ%26c%3Dzhb2MdLBGZ6ylyn5KhRKTw%26r%3DiwVYMKvZX3FI6Ym25lTBWNH494rPH7s_jKjOu5kPxlg%26m%3DxXWJQmy9S39j_tJORR005fLSyZZslnNwOsYJ2u9x0aE%26s%3DSfXPWqS-xRDGCRC3VaMRoBSYzWcYD_3Q2uCKljpMtfQ%26e%3D&data=02%7C01%7CNicholas.Caton%40se.com%7Cb2eb2075524f4ae3308d08d6f690fab1%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636967499884399338&sdata=iCq3FxVzB3MmwAU8QGxYChxyaeLELscpTD%2FVM2JlXDA%3D&reserved=0>*
>
>
>
> *Coffee Conversation:*
>
> But to handle human lives with no agreement as to *what human beings are*
> or *what the purpose of life is * - that is a formula for chaos.
> ------------------------------
>
> *From:* Bldg-sim <bldg-sim-bounces at lists.onebuilding.org> on behalf of
> Julien Marrec via Bldg-sim <bldg-sim at lists.onebuilding.org>
> *Sent:* Friday, June 21, 2019 2:56 PM
> *To:* Nicholas Caton
> *Cc:* Nicholas Caton via Equest-users; bldg-sim at onebuilding.org
> *Subject:* Re: [Bldg-sim] [Equest-users] BEST PRACTICES: Wild Coils
>
>
>
> Hey Nick,
>
> TL;DR I usually play on the infiltration rate, bumping it higher as needed.
>
> Something I've encountered a lot while working on Multifamily existing
> buildings in NYC, where you'll encounter most often than not steam systems,
> one or two pipe. The "wild" coil situation is exacerbated to unreal levels,
> because these systems are very old, out of tune, hard to balance, and the
> ancient knowledge of steam systems is getting lost.
>
> Part of our audit checklist in the winter involved walking around the
> building to map the windows (usually no building plans exists...) and flag
> the ones that  were opened (you could get in the 30% easily even a deadly
> cold winter day. I've personally lived on a run down building when i first
> got to nyc and on a well below freezing point our windows were opened to
> avoid sweating to death: the good old "double-hung zone valve" was the only
> option we had).
>
> We'd take space temperature readings (and ideally install sensors for a
> couple of weeks), to set the thermostat setpoints accordingly, and play
> with infiltration to match our understanding of how people reacted.
>
> The opposite is true too though, I've seen people run their gas stoves
> with the door open as a supplemental space heater because it was too damn
> cold. The cooking gas account is more often than not separated from the
> boiler room one in nyc thankfully, so if you find a huge spike in the
> cooking gas bill in the winter (a HDD correlated component of your bill
> when you run a regression) it probably can't be explained by "people don't
> go out as much and stay in to cook".
>
> Just my two cents/a rant, but i hope this sparks a conversation anyway :)
>
> Y'all enjoy the weekend!
>
> Best,
>
> Julien
>
> --
>
> Sent from a mobile device, please excuse the brevity.
>
> Julien Marrec, EBCP, BPI MFBA
>
> Owner
>
> Direct: +33 6 95 14 42 13
>
> Website: www.effibem.com
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__www.effibem.com%26d%3DDwMGaQ%26c%3Dzhb2MdLBGZ6ylyn5KhRKTw%26r%3DiwVYMKvZX3FI6Ym25lTBWNH494rPH7s_jKjOu5kPxlg%26m%3DxXWJQmy9S39j_tJORR005fLSyZZslnNwOsYJ2u9x0aE%26s%3DV8rPtDKWYRI1grDNKMBmiq1hbD85zHOgKI9hv12ry7g%26e%3D&data=02%7C01%7CNicholas.Caton%40se.com%7Cb2eb2075524f4ae3308d08d6f690fab1%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636967499884409332&sdata=vKE%2BTavRZ8DAA45XzjEtq2wjwJasXKsseijmyIwR%2B8U%3D&reserved=0>
>
> LinkedIn (en
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.linkedin.com_in_julienmarrec%26d%3DDwMGaQ%26c%3Dzhb2MdLBGZ6ylyn5KhRKTw%26r%3DiwVYMKvZX3FI6Ym25lTBWNH494rPH7s_jKjOu5kPxlg%26m%3DxXWJQmy9S39j_tJORR005fLSyZZslnNwOsYJ2u9x0aE%26s%3Dt8QuP0gLDfCvA1FNpepay_amJjHxX-HXV9Kcp5Aw0Yg%26e%3D&data=02%7C01%7CNicholas.Caton%40se.com%7Cb2eb2075524f4ae3308d08d6f690fab1%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636967499884409332&sdata=4qAReHncbVPrgRlrletZ%2FLr8ofiyerbDZprDZVbhMCY%3D&reserved=0>)
> | (fr
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__fr.linkedin.com_in_julienmarrec_fr%26d%3DDwMGaQ%26c%3Dzhb2MdLBGZ6ylyn5KhRKTw%26r%3DiwVYMKvZX3FI6Ym25lTBWNH494rPH7s_jKjOu5kPxlg%26m%3DxXWJQmy9S39j_tJORR005fLSyZZslnNwOsYJ2u9x0aE%26s%3DTJna9Rp7ZhuwyxZXJ84h6NdVsyzg4iTvXkjmUjkbSlc%26e%3D&data=02%7C01%7CNicholas.Caton%40se.com%7Cb2eb2075524f4ae3308d08d6f690fab1%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636967499884419327&sdata=S5YuPj6FFzm%2FojgO2zpZ4m9dn4Lsn8gbEGRlEZ85VPM%3D&reserved=0>
> )
>
> On Jun 21, 2019, at 19:37, Nicholas Caton via Equest-users <
> equest-users at lists.onebuilding.org> wrote:
>
> Apologies for the cross-post, however I wanted to ask this question from 2
> angles and I feel both communities may benefit from the discussion (if I
> can spark one).
>
>
>
> A common reality I’ve observed with “real-world” hydronic systems is that
> system coils and baseboard/radiator loops fall into a state coined *wild
> coils*.  Rather than modulating flow to maintain a measured supply air or
> room temperature setpoint, flow is *uncontrolled*.  A heating or reheat
> coil for example will end up dumping heat at all times the associated
> circulation loop is active, independent of its associated system’s fan
> operation, cooling coil activity, or thermostat signals requesting
> more/less heating.  Occupants in response to wild coils, when they cay,
> will end up using windows, propping open doorways, plugging in local space
> heaters / circ fans, and generally suffering in terms of comfort.  In just
> about every case, this scenario presents a win-win in terms of improved
> occupant comfort potential in parallel with energy savings potential for
> whoever is paying the bills.
>
>
>
> Causes for this situation I’ve encountered more than once include:
>
>    - Manual Control valves left in an open state, with dusty cobwebs
>    suggesting their presence is unknown to the occupants/building operators
>    - Automated valves (electric or pneumatic) which have become
>    mechanically stuck in an open, or partially open position
>    - Automated valves (electric or pneumatic) which are otherwise busted
>    due to upstream pneumatic line/system issues or mechanical failures of the
>    moving parts at the valve
>    - A valve was never designed and/or installed and/or wired up for
>    control in the first place
>
>
>
> For all of this however, I have always struggled in approximating the
> energy and comfort impacts of “wild” coils in my building energy
> simulations.  Quantifying this impact with some degree of confidence is
> difficult, but desirable in cases where I am calibrating to existing
> utility bills (read: always) and/or asserting the utility savings and
> comfort improvement impact for fixing/addressing such situations.
>
>
>
> *For the [bldg-sim] family:*  Are there any 3rd party tools, models, or
> other energy simulation platforms with explicit options for evaluating the
> comfort and energy impacts of wild coil situations?  Is there any research
> I could be pointed towards exploring this topic?
>
>
>
> *For the [eQuest-users] crowd:*  Can anyone share a best practice or
> recommendation for simulating this sort of problem-state within a
> doe2/eQuest model?  As far as I know, the native input options are
> essentially limited to a pair of “working” coil modulation states: TWO-WAY
> and THREE-WAY.  Here’s an example doe2 reference entry, with language that
> repeats a couple times over for different scenarios:
>
> I personally have taken different approaches, with none being particularly
> satisfactory.  These have included introducing process loads onto the loops
> concurrently with “free” internal energy source definitions to get those
> losses dumped into the spaces experiencing discomfort.  I have also played
> with artificially bumping the thermostat schedules around to reflect
> measured, uncomfortable temperature states…
>
>
>
> Any solutions/experiences/shared-commiseration would be very welcome!
>
>
>
> ~Nick
>
>
>
> [image: cid:image005.png at 01D515A3.47EDD880]
>
> *Nick Caton, P.E., BEMP*
>
>   Senior Energy Engineer
>   Regional Energy Engineering Manager
>
>   Energy and Sustainability Services
>   Energy Performance Contracting
>
> D
> M
> F
> E
>
> 913 . 564 . 6361
>
> 785 . 410 . 3317
>
> 913 . 564 . 6380
>
> *nicholas.caton at se.com <nicholas.caton at se.com>*
>
> 15200 Santa Fe Trail Drive
> Suite 204
> Lenexa, KS 66219
> United States
>
> [image: cid:image006.png at 01D515A3.47EDD880]
>
>
>
>
>
> ------------------------------
>
>
> Equest-users mailing list
> http://lists.onebuilding.org/listinfo.cgi/equest-users-onebuilding.org <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lists.onebuilding.org_listinfo.cgi_equest-2Dusers-2Donebuilding.org%26d%3DDwMGaQ%26c%3Dzhb2MdLBGZ6ylyn5KhRKTw%26r%3DiwVYMKvZX3FI6Ym25lTBWNH494rPH7s_jKjOu5kPxlg%26m%3DxXWJQmy9S39j_tJORR005fLSyZZslnNwOsYJ2u9x0aE%26s%3DyWWKJ2r_f4IZD5Jrt5xzMDGsQKtrxtFyr_UHcSdNwCg%26e%3D&data=02%7C01%7CNicholas.Caton%40se.com%7Cb2eb2075524f4ae3308d08d6f690fab1%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636967499884419327&sdata=80gkjTiDZS8qJ26475VYajd4cwkeWeDeKQrTydAjxYI%3D&reserved=0>
> To unsubscribe from this mailing list send  a blank message to EQUEST-USERS-UNSUBSCRIBE at ONEBUILDING.ORG
>
>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> ______________________________________________________________________
> _______________________________________________
> Bldg-sim mailing list
> http://lists.onebuilding.org/listinfo.cgi/bldg-sim-onebuilding.org
> To unsubscribe from this mailing list send  a blank message to
> BLDG-SIM-UNSUBSCRIBE at ONEBUILDING.ORG
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/bldg-sim-onebuilding.org/attachments/20190624/03d9765a/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 6298 bytes
Desc: not available
URL: <http://lists.onebuilding.org/pipermail/bldg-sim-onebuilding.org/attachments/20190624/03d9765a/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image009.png
Type: image/png
Size: 255 bytes
Desc: not available
URL: <http://lists.onebuilding.org/pipermail/bldg-sim-onebuilding.org/attachments/20190624/03d9765a/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image010.png
Type: image/png
Size: 8477 bytes
Desc: not available
URL: <http://lists.onebuilding.org/pipermail/bldg-sim-onebuilding.org/attachments/20190624/03d9765a/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ashrae_tk_coil.png
Type: image/png
Size: 33454 bytes
Desc: not available
URL: <http://lists.onebuilding.org/pipermail/bldg-sim-onebuilding.org/attachments/20190624/03d9765a/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image012.png
Type: image/png
Size: 455 bytes
Desc: not available
URL: <http://lists.onebuilding.org/pipermail/bldg-sim-onebuilding.org/attachments/20190624/03d9765a/attachment-0011.png>


More information about the Bldg-sim mailing list