[Equest-users] 答复: Some discuss about the Calculation Method of thesoftware

Varkie C Thomas thomasv at iit.edu
Fri Feb 3 15:10:41 PST 2012


1,100 feet height is a tall building. The eQUEST default for infiltration is 0.038 cfm per sqft of envelope area. You can break the building into 3 or more shells and assign different infiltration rates. You can download my attempt at dealing with this problem from http://bepan.info/engg-calcs and open 4b - Bldg Stack Effect, Wind Press + Envel Leakg Calcs Varkie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20120203/98d085b3/attachment.htm>
-------------- next part --------------
Dear Nick, Karen, Javed and Sami:

Thank you so much, I will try to confirm your light. Your suggestions make me more sure about my result. I make a summary about the 3 questions:

1.       For the 1st situation, I make the 2nd floor higher than before, now it is  1112ft higher than the first floor. The result show no different. So the elevation(in this project situation) didn’t influence the result. I think maybe the software can’t simulate the wind speed changes when the Z-value difference.

  

2.        Now I understand the hole and the default boundary condition tings. Below you said is very clear.

3.       The software should make an adjacent judgment of spaces by the internal wall “next to “option like below.

 

Thanks again.

 

Joey

 

发件人: Nick Caton [mailto:ncaton at smithboucher.com] 
发送时间: 2012年1月31日 2:07
收件人: Karen Walkerman; Jiao, Joey
抄送: Equest-users at lists.onebuilding.org
主题: RE: [Equest-users] Some discuss about the Calculation Method of thesoftware

 

Vikram and Karen’s response are right on � I can fill in a few gaps as well:

 

-          Elevation of a building can have an effect on eQuest’s infiltration calculations, depending on the method you choose to use for defining infiltration.  Much to read on the topic in the help files if you’re interested, but FYI the default coming out of the wizards is not elevation-sensitive (AIR-CHANGE à INF-FLOW/AREA).

-          To help clarify the first example:  Moving spaces away from each other does not break the “adjacency ties” that existed (or not) prior.  I would not expect any changes of the first example, because you have the flexibility to move the spaces all over the place.  If you intend to separate the floors, you should simultaneously re-assign the “next to” property or or removing the interior surfaces that joined them to begin with.  Note coming out of the wizards, you may not actually find there to be a surface defining that connection, depending on how you defined the shell(s).

-          I can confirm to my understanding that eQuest does not recognize “holes” in any sense.  eQuest does recognize the relative XYZ coordinates of exterior surfaces and of building shades when determining solar loads incident on exterior walls, roofs, and windows.  You should be able to confirm this by moving the wall in the 2nd example right next to another (and keeping the ‘self-shading’ property on for all exterior surfaces). 

 

~Nick

 

 

 

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 Karen Walkerman
Sent: Monday, January 30, 2012 8:24 AM
To: Jiao, Joey
Cc: Equest-users at lists.onebuilding.org
Subject: Re: [Equest-users] Some discuss about the Calculation Method of thesoftware

 

Hi Joey,

 

Your observations are based on the fact that the underlying simulation engine for eQuest (DOE2) has little actual understanding of 3 dimensional space.  I think it's easiest to start with your second example when you move the wall out of the space.  The program itself doesn't understand that the original space bounded by the floor, ceiling and 4 walls consisted of a volume.  Therefore, when the wall is moved it doesn't understand that there is a hole.  The wall is still in the program, it is still facing the same cardinal direction, it is still assigned by the same zone, and in both cases, it is not shaded by any other objects, so the program will model model conduction through the wall and solar gain through the windows.  The program does not understand the hole.

 

When you delete the wall, the program no longer models conduction through the wall or solar gain through the windows.  Basically, there is no longer a boundary there, although it's easier to think of it as an adiabatic boundary with no mass.  This effect can be advantageous because if you need to create custom geometry in detailed mode and need to change the polygons, it can be difficult to get all walls to match exactly.  Having a small gap or small hole is acceptable and doesn't lead the program to model natural ventilation.  If you want to model natural ventilation, I believe you do this in detail mode under the "Internal Loads" tab.

 

Your first example is the only one that should show a tiny amount of difference in the result - this is because I believe that the elevation of the building is accounted for in the calculation.  However, the internal ceiling of the first floor is still internal and is still specified as being adjacent to the internal floor of the second floor.

 

Regarding space adjacency - when you enter spaces into the wizard, it does a decent job of figuring out which spaces are adjacent.  If it knows a space is adjacent to another space, it will set that wall to interior.  If the space is not adjacent, it will set the wall to exterior.  Be careful and double check in detailed mode that everything you expect to be interior and exterior actually came through that way.  When you make a change in detailed mode, you need to make sure everything agrees.

 

--

Karen

 

 

From: equest-users-bounces at lists.onebuilding.org [mailto:equest-users-bounces at lists.onebuilding.org] On Behalf Of Sami, Vikram
Sent: Monday, January 30, 2012 8:19 AM
To: Jiao, Joey; Equest-users at lists.onebuilding.org
Subject: Re: [Equest-users] Some discuss about the Calculation Method ofthe software

 

1.  Absolutely from the 1st situation, we can see that the software can’t  judge if the two space are adjacent from the coordinate, is that right? Further , how should the software judge if two spaces adjacent? The software judges adjacent spaces by the surface that separates them. In interior spaces you have to specify an adjacent space that it shares the space with. 

2.  If there is a hole on the wall, I don't think the software should deal with it as natural ventilation, so , how should the software to deal with it?

3.   If some wall been deleted as 3rd situation, the software still can be run, so I think there should be some default boundary conditions, and which should be the default boundary condition?

 

The software doesn’t (as far as I know) calculate holes. It will calculate heat transfer through a surface. In terms of boundary � it calculates heat transfer to a space from exterior conditions through an exterior wall, and from adjacent spaces through interior walls. The absence of a surface (I think) makes that area adiabatic � no heat transfer, mass, or any exchanges. It also means there is no daylight coming into the space from that wall. As far as natural ventilation goes � I think the way to model that is as an infiltration with a schedule.  

 

Hope this helps

 

 

Vikram Sami, LEED AP BD+C

Sustainable Design Analyst

1315 Peachtree St. NE, Atlanta, GA 30309

t: 404-443-7462    f: 404.892.5823       e: vikram.sami at perkinswill.com   www.perkinswill.com <http://www.perkinswill.com/> 

Perkins+Will.  Ideas + buildings that honor the broader goals of society

 

 

From: equest-users-bounces at lists.onebuilding.org [mailto:equest-users-bounces at lists.onebuilding.org] On Behalf Of Jiao, Joey
Sent: Sunday, January 29, 2012 10:04 PM
To: Equest-users at lists.onebuilding.org
Subject: [Equest-users] Some discuss about the Calculation Method of the software

 

Hi all:

Below are some situations always puzzle me:

1.  If you modify the Floor’s Z-axis coordinate like this , you will find the 2 floors has been separated, but the calculation result didn’t show any different.

                                   

2.  As above, you can also move some wall like this, there is still no different.

                                 

3.  But , if you directly delete this wall, the result show different.

                 

                  

 

The questions are :

1.  Absolutely from the 1st situation, we can see that the software can’t  judge if the two space are adjacent from the coordinate, is that right? Further , how should the software judge if two spaces adjacent?

2.  If there is a hole on the wall, I don't think the software should deal with it as natural ventilation, so , how should the software to deal with it?

3.  If some wall been deleted as 3rd situation, the software still can be run, so I think there should be some default boundary conditions, and which should be the default boundary condition?

 

I have used this software half of one year,  but I can’t sure if my calculation result is right, I think I need a higher level to understand this software.

Any suggestions would be appreciated.

I have learn a lot from you guys ,Thank you.

 

Joey

---------------------------------------------------------------------------

Joey Jiao

Graduate Engineer
Shanghai WSP Consulting Ltd. (Shenzhen Branch)

Room 406, Wan Tong Da Sha, 3002 Sun Gang Road East, Luo Hu, Shenzhen, 518023, PRC 

Tel:  +86 755 25860686 

Fax: +86 755 25860680 
Website: www.wspgroup.hk


We are WSP. United by our difference.

WSP is one of the world's fastest-growing design, engineering and management consultancies. Specialising in property, transport and environmental projects, we work with clients to create built and natural environments for the future.

CONFIDENTIAL
This e-mail is confidential to the named recipient. If you have received a copy in error, please destroy it. You may not use or disclose the contents of this e-mail to anyone, nor take copies of it. The only copies permitted are (1) by the named recipient and (2) for the purposes of completing successful electronic transmission to the named recipient and then only on the condition that these copies, with this notice attached, are kept confidential until destruction. 

 


This email and any files transmitted with it are confidential and intended solely for the addressee. If you are not the named addressee you should not disseminate, distribute, copy, or alter this email.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20120203/98d085b3/attachment-0001.htm>
-------------- next part --------------
_______________________________________________
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: thomasv.vcf
Type: text/x-vcard
Size: 308 bytes
Desc: Card for Varkie C Thomas <thomasv at iit.edu>
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20120203/98d085b3/attachment.vcf>


More information about the Equest-users mailing list