[Equest-users] Internal Wall Problems with Wizard

[Nick Caton]

Sorry my reply is coming late to the party...

Robby's illustration is helpful and the point is well taken as a 'best practice' to avoid user-errors during geometry defnition, but I think I can dispel the "next-to" concerns here and show this is simpler than it may seem...

I recreated your illustration with a quick dummy model and confirmed the quantity of vertices (4 vs. 6) for "zone 1" has zero effect on the quantity of internal partitions created/assigned.  In any case I try to define it, the model is generated with all appropriate partitions and next-to inputs (I cannot recreate Omer's issue as described with spaces not being tied together or adiabatic partitions being created).

[cid:image003.png at 01CD5E90.04B86F70]

The only thing I can think of for Omer's situation is that (1) it's worth noting the model should be making only one partition for any two adjacent spaces (it will be a child component of one or the other), and (2) partitions might go missing/adiabatic if the spaces' vertices aren't being defined accurately enough and there's actually a small gap between the spaces.  To that end maybe Robby's suggestion to define each vertex possible is a good housekeeping approach to avoid such issues of definition.  The only remaining ways you will end up with adiabatic internal partitions is if you actually define them as such in the footprint map where you define zoning patterns and/or in the subsequent wizard shell screens.

[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 Robby Oylear
Sent: Tuesday, July 10, 2012 10:54 AM
To: omoltay at mimtarch.com
Cc: eQUEST Users List
Subject: Re: [Equest-users] Internal Wall Problems with Wizard

I should probably clarify that the vertices shown in the sketch belong to Zone 1.  It is not enough to just define those vertices in Zones 2-4.

-Robby
On Tue, Jul 10, 2012 at 8:52 AM, Robby Oylear <robbyoylear at gmail.com<mailto:robbyoylear at gmail.com>> wrote:
Omer,

The simplest way to ensure that eQUEST defines the NEXT-TO property correctly is to make sure that each interior wall only interfaces with one other interior wall.

In the situation you describe where you have an interior wall that is adjacent to more than one zone, I would typically split that interior wall into two or three walls by adding vertices at each of the intersections between the zones and the interior wall that spans them.

Here's a sketch of what I'm describing:
[Inline image 1]

Hope that helps.

Robby Oylear, PE, LEED AP
Mechanical Engineer
Senior Energy Analyst

D 206-788-4571<tel:206-788-4571>
www.rushingco.com<http://www.rushingco.com/>

On Tue, Jul 10, 2012 at 8:45 AM, Ömer Moltay <omoltay at mimtarch.com<mailto:omoltay at mimtarch.com>> wrote:
Dear All,

I have realized that while creating the model after Wizard entries, eQuest will fail to determine the NEXT-TO property for interior walls that are adjacent to more than one zone and all those interior walls will be defined as ADIABATIC.

Also, I see that interior walls are missing from zones where another zone has an ADIABATIC wall in the same place.

I see no way of having a model with all interior walls correctly defined without fixing all these problems after the Wizard. Does everybody have the same experience or am I missing something?

Ömer Moltay, LEED AP BD+C, ASHRAE BEMP, CPMP, BREEAM Assessor
Mimta EcoYapi
Hekimsuyu Cad. 559. Sk. No:39
34255 Kucukkoy Istanbul Turkey
Tel: 90-212-617-2296
Fax: 90-212-617-2297
www.ekoyapi.net<http://www.ekoyapi.net>
www.mimtasolar.com<http://www.mimtasolar.com>
www.mimtarch.com<http://www.mimtarch.com>


_______________________________________________
Equest-users mailing list
http://lists.onebuilding.org/listinfo.cgi/equest-users-onebuilding.org
To unsubscribe from this mailing list send  a blank message to EQUEST-USERS-UNSUBSCRIBE at ONEBUILDING.ORG<mailto:EQUEST-USERS-UNSUBSCRIBE at ONEBUILDING.ORG>
_______________________________________________
Equest-users mailing list
http://lists.onebuilding.org/listinfo.cgi/equest-users-onebuilding.org
To unsubscribe from this mailing list send  a blank message to EQUEST-USERS-UNSUBSCRIBE at ONEBUILDING.ORG<mailto:EQUEST-USERS-UNSUBSCRIBE at ONEBUILDING.ORG>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20120710/726a0688/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/20120710/726a0688/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 10321 bytes
Desc: image002.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20120710/726a0688/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 69673 bytes
Desc: image003.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20120710/726a0688/attachment-0005.png>