Internal Wall Problems with Wizard

12 posts / 0 new
Last post

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, 

Omer Moltay's picture
Offline
Joined: 2011-09-30
Reputation: 0

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?

Omer Moltay, LEED AP BD+C, ASHRAE BEMP, CPMP, BREEAM Assessor

Omer Moltay's picture
Offline
Joined: 2011-09-30
Reputation: 0

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:
[image: Inline image 1]

Hope that helps.

Robby Oylear, PE, LEED AP

Robby Oylear's picture
Offline
Joined: 2011-09-30
Reputation: 202

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

Robby Oylear's picture
Offline
Joined: 2011-09-30
Reputation: 202

An HTML attachment was scrubbed...
URL:

Bruce Easterbrook's picture
Joined: 2011-09-30
Reputation: 0

Hi Robby,

Thanks a lot. Learned something very important today.

Another problem that I am having with internal walls: There are internal
walls missing in some zones and I have no clue as to why. You will see
these in the attached images as thin lines. The walls are missing from
the selected zone (grayed), but the neighboring zone has walls in the
same place.

In 01.jpg, all three internal walls of the smaller zone are missing.

In 02.jpg, some internal walls are missing and some are not.

This floor has been recreated according to your advice with additional
vertices.

I think there is more to internal walls in Wizard that I do not know.

Best regards,

Omer Moltay, LEED AP BD+C, ASHRAE BEMP, CPMP, BREEAM Assessor

Omer Moltay's picture
Offline
Joined: 2011-09-30
Reputation: 0

Regarding the comment about not trusting eQUEST's snaps, I find it helps to
turn all snaps except "Polygon" off when defining zones. Thus the only way
it's snapping is directly onto an existing vertex. I use this every time
and don't have any issues with interior walls.

Omer-
I believe what you're experiencing is that when defined properly, eQUEST
only defines ONE interior wall. Since an interior wall is used to define a
relationship between two spaces, there is only need for one wall. The zone
that own's the wall is rather arbitrary, because either way they are linked
through the NEXT-TO command. If two walls are created by eQUEST, it's
likely that they'll both be ADIABATIC and this is a symptom of not defining
the wall geometry correctly. One wall per zone interface is what you
should be shooting for.

-Robby

Robby Oylear's picture
Offline
Joined: 2011-09-30
Reputation: 202

To further clarify, if you look at the walls you highlighted as ?missing? in
Image 1 (when you select the smaller space), you will see that they appear
in Image 2, meaning as Robby indicated, they are a child component of the
larger space that surrounds the smaller space. You should be able to select
them and verify that the NEXT-TO field is properly entered.

Also, I thought that the space that gets ?possession? of an interior wall
has something to do with the order that you draw them in the wizard, but it
has been a long time since I cared to check on that.

Nathan Miller, PE, LEED AP BD+C

Nathan Miller's picture
Offline
Joined: 2011-09-30
Reputation: 200

An HTML attachment was scrubbed...
URL:

Bruce Easterbrook's picture
Joined: 2011-09-30
Reputation: 0

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.

Nick-Caton's picture
Offline
Joined: 2011-09-30
Reputation: 805

Nick,

It's the "might" that makes it worthwhile to define your vertices exactly
in the same location if you want an interior partition created between the
two. eQUEST does have some capability for approximating your intent of two
vertices being adjacent, however I have not been able to determine where
the tipping point is between "close enough" and "ADIABATIC".

As mentioned above, the same can go for exterior walls where sometimes
eQUEST does pick up on the fact that your single vertex on an exterior
floor line should result in an exterior wall, however I've witnessed plenty
of cases where an interior wall gets created on an exterior exposure.

-Robby

Robby Oylear's picture
Offline
Joined: 2011-09-30
Reputation: 202

I agree completely Robby - I do not mean to discount defining all vertices possible as a practice. I oftentimes do the same whenever zoning is not perfectly orthogonal =).

The point I mean to drive home is the reasons for doing so are to eliminate user-error-based issues, and not due to some mysterious or unknowable flaw of the program/interface.

For what it's worth and to join the chorus, locking to vertices wherever possible is always a good idea. Defining additional vertices is never a bad idea (in moderation). When defining geometries, rather than toe the line of "close enough" I have found it easiest to follow the slightly slower, more deliberate path of "exactly right."

To Omer's recent query: floor-to-floor thermal ties are generated automatically by the wizards if you define multi-story shells, but not otherwise. IIRC, NEXT-TO thermal ties between shells always require some degree of detailed mode editing, though it is not uncommon to conclude such transfers can be safely omitted from a model (further discussion in the archives). In any case, this is one of many reasons to prioritize minimizing the quantity of shells, within reason.

Best of luck!

~Nick

[cid:489575314 at 22072009-0ABB]

NICK CATON, P.E.

Nick-Caton's picture
Offline
Joined: 2011-09-30
Reputation: 805