[Equest-users] eQuest Floor Multipliers & HVAC System(s)

Nicholas Caton Nicholas.Caton at schneider-electric.com
Wed Jul 11 12:36:22 PDT 2018

Hi Daric,

I do not know of any special output reports which divide the loads or capacities for spaces/zones/systems involving multipliers, but everything else you've written has my head nodding as expected behavior.

Speaking to "this feels screwy" (and bravo, by the way!  I think as a rule most energy modelers don't talk about their feelings nearly as much as they should):

  *   The nuances for working with multipliers are not always straightforward, but intelligently interpreting/dividing the resulting energy draws should feel comfortable as an approach, for the model-builder at a minimum.
  *   If it helps, consider a thought exercise going in the reverse direction:  What if you modeled ...

     *   A single-zone gym to your most stringent personal standards, and
     *   This gym has a single auto-sized AHU, and
     *   We then wanted to answer question: How big does this single system need to be if we want it to double the size of the gym for a planned future expansion.  You're to utilize the current model, we'll assert everything will be identical to the first gym, and we'll ignore the fact that there are probably real-world advantages to having 2 systems and duplicating the original design.
     *   Would you feel compelled to create an entirely separate copy of everything within your model (spaces, surfaces, zones, systems...), then assign to a common meter and add everything up to determine the new single system size... or could you also feel equally/more comfortable spending less time by leveraging a multiplier-based approach?
     *   There isn't a "right" answer (you can arrive at the same result either way), but hopefully this helps to illustrate the usefulness and comfort level we should be able to assign to the technique.

  *   Acknowledging:  It CAN seem screwy to other parties who you may not have the time/resources/patience to educate on the matter.  I empathize.
  *   Acknowledging:  I've completed a couple projects (2 to memory) under LEED involving multipliers in the final proposed and baseline case.  With that experience, I would avoid it if at all possible - there's just too much of a rats nest that develops in correctly and clearly determining/documenting baseline system inputs.
  *   If you need the final product to have no multipliers in sight, consider that it's very possible (with some time investment - this is a process) to develop a model WITH multipliers up to the last possible point (before building final documentation / prescriptive stuff, or before you need a pretty 3D picture for a report or something), then converting back to NO multipliers in detailed mode.  Here's a step-through:


     *   Save a separate copy - you can always start over or roll back!
     *   Create new floors/shells:
        *   Switch the multiplier at the floor input back to 1
[cid:image006.png at 01D41916.DE56C370]

        *   Set a user-default for window specification type to 'Composite'
[cid:image003.png at 01D41917.345317B0]

        *   Duplicate the entire floor and all of its components from the interface by right-clicking the floor in the component tree.  Tick only the first box.  Linking vs. copying will retain some of the benefits of multipliers, in keeping your input file much lighter in geometry-related inputs to load.  For sanity I like to advise always linking from the same original component - don't link from other linked copies.  :
[cid:image005.png at 01D41917.345317B0]

        *   Click OK in the following prompt listing the new stuff without renaming anything
        *   Take note of the Space number range corresponding to this floor on a notepad - you'll need this shortly.  In this example, I'd note Floor 4 = new Spaces 19 through 24:
[cid:image008.png at 01D41917.345317B0]

        *   Adjust the new floor Z-value to get the identical floor OFF the original - this isn't just for aesthetics, you're also avoiding self-shading issues with the windows by doing so.
        *   Rinse and repeat
        *   Do NOT rename anything at this stage, if you feel so-compelled.  Will make the later steps easier.
     *   Save:  At this stage the model will not simulate, as we need to create new systems/zones and make those associations.  I do recommend however making a new save as we're at another good "rollback" state if you should encounter any stability problems.
     *   Create new Systems/Zones
        *   In this case I recommend sticking to "Copy" vs Linking.  Linking systems/zones has caused me problems more often than not in personal experience, so I err towards avoiding them. Again note only the first tick box is checked:

[cid:image004.png at 01D4191A.B23C08F0]

        *   Click OK in the following prompt listing the new stuff without renaming anything
        *   You'll immediately be prompted to assign a SPACE to each new ZONE.  The dropdown will contain an abbreviated SPACE list containing only SPACEs which have no ZONE assignment.  NOT ticking the second box in the prior steps means that you will have as shown here a "Zone 19" to assign to "Space 19."

[cid:image007.png at 01D4191D.7E1CCE30]

        *   After finishing your first instance of this, cross-reference with aid of your "floor contains spaces X through Y" record, and make sure the zones and spaces are correctly sequenced.  If you need to adjust the pattern (because in development you revised the wizard-generated sequence in the INP file), you can map out for future systems what goes to what in sequence (i.e. assign the 2nd space to the 1st zone, etc.).
        *   It'll make sense at this stage to name the new HVAC system to something like "Floor 4 AHU"
        *   If applicable (depends on system type), assign a new control zone to the new system that's actually on the same floor.
        *   Rinse and Repeat
     *   Simulate to confirm everything is running.  Pat yourself on the back.
     *   If you must, now would be the time to rename everything... poor unfortunate soul!


[cid:image001.png at 01D41911.E5A45E80]
Nick Caton, P.E., BEMP
  Senior Energy Engineer
  Regional Energy Engineering Manager
  Energy and Sustainability Services
  Schneider Electric

D  913.564.6361
M  785.410.3317
F  913.564.6380
E  nicholas.caton at schneider-electric.com<mailto:nicholas.caton at schneider-electric.com>

15200 Santa Fe Trail Drive
Suite 204
Lenexa, KS 66219
United States

[cid:image002.png at 01D41911.E5A45E80]

From: Equest-users [mailto:equest-users-bounces at lists.onebuilding.org] On Behalf Of Daric Adair via Equest-users
Sent: Wednesday, July 11, 2018 9:12 AM
To: equest-users at lists.onebuilding.org
Subject: [Equest-users] eQuest Floor Multipliers & HVAC System(s)


Have a multistory building, hoping to use floor multipliers, but running into a issues understanding the HVAC simulation. For a 10 story building, with floor multipliers, I get a ground/bottom floor, top floor, and 8 middle floors. All good. With "system per floor" HVAC design I am getting 3 systems - bottom, top and a middle one that is far bigger than the other two.
If I disable the multipliers and model all 10 floors, also with system per floor, there are now 10 HVAC systems. The (auto-sized) total CFM, capacity, etc. are roughly, but not exactly, the same for the full building with the multipliers.

So, this leads me to believe that with multipliers eQuest is simulating 3 HVAC systems; without multipliers it is simulating 10. Can anyone validate?

I understand that the middle 8 floors will ideally have the same loads (no outside shading or other factors - ideal exercise here); and thus that the single large system is roughly the same as the 8 individual systems totaled. But explaining this to the untrained (and potentially stubborn...) leaves me wanting confirmation. Is there a detailed report that reports what a single middle floor HVAC system would need CFM/capacity wise? (SV-A for a single middle floor)

Which leads to a second question. If modeling Proposed/real systems with multipliers, should the air flow, capacity, etc of those to be summed before input to eQuest? This just 'feels' screwy.

Thanks in advance.

Mechanical Engineer, Energy Analyst

Henderson Engineers
8345 Lenexa Drive, Suite 300  |  Lenexa, KS 66214
Tel (913) 742-5530
daric.adair at hendersonengineers.com<mailto:daric.adair at hendersonengineers.com>


Licensed in KS

Sending me large files? Please use Henderson File Share<https://apps.hendersonengineers.com/FileShare/Upload?to=daric.adair@hendersonengineers.com> | TX ID #F-001236


This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. This communication represents the originator's personal views and opinions, which do not necessarily reflect those of Henderson Engineers, Inc. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately notify administrator at hendersonengineers.com<mailto:administrator at hendersonengineers.com>.

This email has been scanned by the Symantec Email Security.cloud service.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20180711/6e17d9c0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 255 bytes
Desc: image001.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20180711/6e17d9c0/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 8477 bytes
Desc: image002.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20180711/6e17d9c0/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oledata.mso
Type: application/octet-stream
Size: 7137 bytes
Desc: oledata.mso
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20180711/6e17d9c0/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 32556 bytes
Desc: image006.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20180711/6e17d9c0/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 53911 bytes
Desc: image003.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20180711/6e17d9c0/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 36145 bytes
Desc: image005.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20180711/6e17d9c0/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image008.png
Type: image/png
Size: 3520 bytes
Desc: image008.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20180711/6e17d9c0/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 34665 bytes
Desc: image004.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20180711/6e17d9c0/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.png
Type: image/png
Size: 19775 bytes
Desc: image007.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20180711/6e17d9c0/attachment-0007.png>

More information about the Equest-users mailing list