[Equest-users] Fwd: Overload problems.. again.

[DongEun Kim]

Thank you  Nick for your insights.

Please anyone feel free to add comments, further questions regarding this
subject!

---------- Forwarded message ----------
From: Nick Caton <ncaton at smithboucher.com>
Date: 2013/7/18
Subject: RE: [Equest-users] Overload problems.. again.
To: DongEun Kim <equested at gmail.com>


 **1.       **Every model is a different circumstance, but I can share that
I have not had problems with auto-sized chillers/boilers in relation to
their capacity and what’s required of the secondary loop.  As explained,
more often than not it’s totally fine for the non-coincident secondary loop
sums to total higher than the primary capacity sums.  If you’ve bumped up
capacities as you’ve described and still observe 200+ unmet hours, it’s
pretty clear the source of the remaining unmet hours is elsewhere in your
model.  ****

**2.       **While I think it’s possible to do what you’re proposing and
stay in the spirit of 90.1’s requirements, if at all possible I would avoid
it as it’s a stretch to interpret things that way.  Proposed should
represent actual equipment capacities and baseline capacities should
autosize (with oversizing factors as prescribed).  ****

** **

All told, I suspect you need to take a step back from these (probably
erroneous) loop warnings:  If you have to inflate *proposed* equipment
capacities beyond their designed values to deal with unmet hours exceeding
90.1’s thresholds, that’s a sign something else is wrong in one or both
models with respect to envelope, internals, or equipment sizing.  If it
were me, I would probably next review the model’s loads & scheduling
against those of the designer sizing the equipment for any large
discrepancies.  ****

** **

~Nick****

[image: cid:489575314 at 22072009-0ABB]**

* *

*NICK CATON, P.E.*

SENIOR ENGINEER****

** **

Smith & Boucher Engineers****

25501 west valley parkway, suite 200****

olathe, ks 66061****

direct 913.344.0036****

fax 913.345.0617****

www.smithboucher.com* *****

** **

*From:* DongEun Kim [mailto:equested at gmail.com]
*Sent:* Tuesday, July 16, 2013 10:51 PM
*To:* Nick Caton
*Subject:* Re: [Equest-users] Overload problems.. again.****

** **

Dear  Nick and Rosie,****

 ****

Your comments have helped me tremendously. Thank you!****

 ****

I guess the key problem was that  I trusted the program's autosizing
ability too much.****

 ****

I mean, even though I let both the air-side  and water-side system to be
autosized, I manually put capacities matching the loop peak load, and ****

 ****

the PS-D overloads were all gone. And, the energy increase was trivial.****

 ****

(I had my air-side systems to have sizing option of "Coincident", so the
secondary peak demand exceeding the primary capacity may not****

have been an issue. And, my report showed unmet hours to be less than 200
hrs, so insufficient cooling/heating level may have been in an allowable
range.)****

 ****

But, I can't help feeling disappointed about unstable autosizing capability
of eQuest. I mean, why the peak load in the PS-D doesn't match the peak
load in PS-V when being autosized?****

 ****

I have two more questions..****

*1. should I still be so caught up with the overload problem even when the
model has reasonable amount of unmet hours?*****

*2. Can I size the water-side plant for the Baseline(for the LEED project)
 with the same way (input the plant capacity to match the peak load in
PS-D) I used for proposed? Or, Is there some sort of rule for the baseline
model capacity to be left untouched?*****

2013/7/17 Nick Caton <ncaton at smithboucher.com>****

All,****

 ****

I’ve seen this topic come and go many times as well and have hesitated in
the past to share my thoughts, but having spent enough time pondering this
I figure I may as well share my opinions to further the discussion:  ****

 ****

My understanding is that loop capacity warnings often fall in the category
of attention messages that can easily be checked and dismissed as
erroneous.  ****

 ****

It’s my understanding one of two things is the usually case when you get
one of these warnings:  ****

1.       Your primary hydronic heating/cooling equipment is actually of
insufficient capacity to keep up with the highest demand incident on the
loop, in which case you have a real problem that will likely manifest as
significant block of unmet heating/cooling hours, assuming typical
thermostat inputs.  One way to check appropriate equipment sizing is to
check the PEAK load for the loop/equipment of concern in the PS-C/PS-D
reports against a tallied sum of the CAPACITY for all associated equipment,
as reported in the PV-A report.  Be mindful units are typically of
different magnitude between these reports.****

2.       More commonly, the program has calculated a secondary capacity
which exceeds the primary equipment capacities *in sum*.  This secondary
capacity is a “sum of maximum capacities” (i.e. the most each
heating/cooling coil can do, as autosized/specified, in sum), and can
easily be well in excess of the maximum hourly load incident on the primary
equipment during the simulation.  Another way to put it is there’s no
“whole-building” diversity worked into the secondary capacity figure that
shows up in the ATTN report.  In such cases, the primary capacity as
autosized/specified can in fact be just fine.  ****

 ****

The designer sizing the primary equipment should be able to speak to what
degree of diversity (if any) is intended for the whole building heating and
cooling loads for determining equipment capacities.  Different systems will
have different ranges of “normal” for whole-building diversity, and it
isn’t uncommon for hydronic cooling vs. heating systems to be designed with
different capacity diversities for the same project.****

 ****

I’d be interested to hear if others have a similar perspective or further
insight as to when such cautions can be disregarded and when they’re cause
for real concern.****

 ****

Hope this helps you in the meantime Kim!****

 ****

~Nick****

[image: cid:489575314 at 22072009-0ABB]****

* *****

*NICK CATON, P.E.*****

SENIOR ENGINEER****

 ****

Smith & Boucher Engineers****

25501 west valley parkway, suite 200****

olathe, ks 66061****

direct 913.344.0036****

fax 913.345.0617****

www.smithboucher.com* *****

 ****

*From:* equest-users-bounces at lists.onebuilding.org [mailto:
equest-users-bounces at lists.onebuilding.org] *On Behalf Of *DongEun Kim
*Sent:* Monday, July 15, 2013 7:22 PM
*To:* equest-users at lists.onebuilding.org
*Subject:* [Equest-users] Overload problems.. again.****

 ****

Hi All~****

 ****

I've been posting about loop overload problem  and still haven't got any
responses.****

 ****

In the archive, some equesters had cast questions regarding overload
problems, but they don't seem to get answers either.****

 ****

It it really that, no one knows how to fix it, or no one had experienced
overload problems but us who question about it.****

 ****

I just want to know why the over load is being shown in the loop
report(PS-D),****

and any possible approach to fix the overload. ****

 ****

Any advice or a mere comment will be a great help!****

 ****

Thank you!****

 ****

Kim****

 ****

** **
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20130718/567735ac/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1459 bytes
Desc: not available
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20130718/567735ac/attachment-0002.jpeg>