[Equest-users] Overload problems.. again.

[Nick Caton]

PS:  Looks like you may have accidentally replied only to me and not the group - feel free to forward this continuing conversation on to the group if you are comfortable doing so.  I will be unavailable for some time personally!

Regards,

~Nick

[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: Nick Caton
Sent: Wednesday, July 17, 2013 12:09 PM
To: 'DongEun Kim'
Subject: RE: [Equest-users] Overload problems.. again.


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
[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<mailto: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
[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<http://www.smithboucher.com/>

From: equest-users-bounces at lists.onebuilding.org<mailto:equest-users-bounces at lists.onebuilding.org> [mailto: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<mailto: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/20130717/e3be464d/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1459 bytes
Desc: image001.jpg
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20130717/e3be464d/attachment-0002.jpg>