[Equest-users] Multithreading

[Anthony Hardman]

I'm no software engineer but I thought that's how processors were supposed
to work (one application per thread).  I've ran into the same problem on
larger complex projects.  If that's true, a higher clock speed may be the
only solution.

 

Anthony Hardman, PE

LEED AP BD&C

Building Performance Analyst

 

THE GREEN ENGINEER, LLP

Sustainable Design Consulting - Energy Modeling - LEED Project Management 

50 Beharrell St

Concord, MA 01742

O: 978/610-2801

C: 720/840-7862

 

 <http://www.greenengineer.com/> Description: TGE Logo
<http://www.linkedin.com/in/ahardman81> Description: images5
<http://twitter.com/#!/a_Hardman> Description: t4

 

 

From: equest-users-bounces at lists.onebuilding.org
[mailto:equest-users-bounces at lists.onebuilding.org] On Behalf Of Jeremy
McClanathan
Sent: Thursday, May 19, 2011 12:45 PM
To: 'Brian Tysoe'; equest-users at lists.onebuilding.org
Subject: Re: [Equest-users] Multithreading

 

I had the same problem and our IT guy did a similar analysis and came to the
same conclusion.  The CPU was the bottleneck.  I upgraded to a Dell
Precision T3500 and it reduced my open time on a large hospital project from
10 minutes to 1.5 minutes.

 

___________________________________________

Jeremy McClanathan, LEEDR AP BD+C

CDi_Engineers_logo_color.jpg

4200 194th St SW, Ste 200, Lynnwood, WA 98036

P 425-672-1071 | F 425-778-8769 

P Please consider the environment before printing this email.

 

From: Brian Tysoe [mailto:BTysoe at mcw.com] 
Sent: Thursday, May 19, 2011 11:06 AM
To: equest-users at lists.onebuilding.org
Subject: [Equest-users] Multithreading

 

Hello equest-users,

 

Does anyone out there know if the next release of eQuest (based on a new
version of DOE 2 I believe) will be able to make use of processor
multithreading?

 

We are running into problems modelling large buildings with eQuest 3.64.
Files are taking upwards of 5 minutes to open and once they are open it
takes about 8 seconds to modify any single field. If you want to change the
flow rate of an AHU you enter your number and then wait for 8 seconds while
the software thinks about it.

 

We have done some monitoring and found that the software is running on one
processor core at 100% and that is the bottleneck.

 

Exhibit A: Loading the model

 

Description: cid:image001.png at 01CC1628.DD97AE70

 

In this graph (taken while loading the model) you can see that eQUEST's CPU
usage is constant. It is only using one of the available CPU cores and it is
using that core to the max. Compare this to the Disk usage and you can see
that the Disk usage spikes up several times but those spikes are relatively
low.

 

Exhibit B: Changing values

 

Description: cid:image002.png at 01CC1628.DD97AE70

 

In this graph you can see the CPU usage spike up when I made a change in
eQUEST and then dip down several seconds after. The Disk usage is still
sporadic and low.

 

We have concluded that adding RAM will not speed things up. The best
solution is a faster processor.

 

Has anyone else done any similar benchmarking and want to share their
findings?

 

Thanks,

 

 

Brian Tysoe M.A.Sc., P.Eng., LEED AP 

Mechanical Engineer 

 

 <http://www.mcw.com> MCW Consultants Ltd. 

600-156 Front Street West 
Toronto, ON M5J 2L6 
Phone 416-598-2920 
Fax 416-598-5394 

 

This e-mail may be privileged and confidential. Any unauthorized use is
strictly prohibited. If you received this e-mail in error, please contact
the sender directly. 

 

This email message, including any attachments, is for the sole use of the
intended recipient and may contain confidential, proprietary, and/or
privileged information, as well as content subject to copyright and other
intellectual laws.  If you are not the intended recipient, you may not
disclose, use, copy, or distribute the email message or its attachments.  If
you believe you have received this email message in error, please contact
the sender by reply email, immediately delete this email and destroy copies.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20110519/b4c177e2/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1364 bytes
Desc: not available
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20110519/b4c177e2/attachment-0008.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1997 bytes
Desc: not available
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20110519/b4c177e2/attachment-0009.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1971 bytes
Desc: not available
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20110519/b4c177e2/attachment-0010.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1232 bytes
Desc: not available
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20110519/b4c177e2/attachment-0011.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 119343 bytes
Desc: not available
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20110519/b4c177e2/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 321398 bytes
Desc: not available
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20110519/b4c177e2/attachment-0005.png>