CBECC-Com Issue - Unexpected Crash

[GoogleCodeExporter]

Version = 2013_3a_687   (ComplianceManager)

Category = Unexpected Crash

From IES customer (Buro Happold):

I created a small two-room sample building, with simple air systems to see if I 
could simply first simulate and generate a report. After some error fixing, I 
was successful in this. Then, I created a more geometrically complex section of 
our building, using the same systems.
Upon trying to run this, the simulation wouldn’t work. Receiving the message 
below:
My guess was that because the building is very curved, it was not running 
because there were so many different wall surfaces (see attached). 

Do you know if there is a limitation to the # of surfaces per room or model 
imposed by CBECC-COM?

Original issue reported on code.google.com by f.le...@gmail.com on 19 Dec 2014 at 8:58

Attachments:

• 4.rar

[GoogleCodeExporter]

As soon as I opened your model in versions 2b, 3 or 3a of CBECC, CBECC 
immediately crashed.  I am not sure what is causing this.  Perhaps Scott can 
look at this.  

In looking at the file, the first polyloop I saw (for space South Perimeter 
Gallery_TR000001) had something like 148 points.  The roof and floor were 
similar.    I am not aware of any limit on the number of surfaces, nor of a 
limit on the number of sides on a polyloop.  However, 148 points seems like it 
may be a source of trouble.  

I would recommend representing the curves with fewer straight segments as a 
starting point for attempting to resolve the problems here.  But, as I am not 
sure what exactly is causing the problems, I cannot say that this will solve 
the problem.  

Original comment by rhedr...@archenergy.com on 30 Dec 2014 at 6:55

• Changed state: Discussion

[GoogleCodeExporter]

Uncertain presently as to the problem here.
Initial PolyLp defaulting is successful, but the program bombs during daylit 
area calculations.  The space geometry however is too complex to track down the 
bug in any timely manor.  This model doesn't load into the Sketchup plugin 
either - it bombs as well, further indicating a problem with this file.

I believe that EnergyPlus limits the number of surface polygon vertices to 120. 
 This should be confirmed and we should also check whether OpenStudio includes 
the same restriction.
We should then incorporate a limit into CBECC-Com - identifying all PolyLp 
objects in the model with greater than 120 vertices, reporting their and their 
parent space/surface names and prevent any further defaulting or analysis.

This project file includes four spaces that exceed 120 vertices.  Each of these 
spaces include a floor and roof with the same number of vertices, for a total 
of 12 PolyLp objects w/ > 120 vertices.  They are:
Spc  South Perimeter Gallery_TR000001   148 vertices
Spc  North Perimeter Gallery_TR000000   311 vertices
Spc  Mechanical Core_TR000005           344 vertices
Spc  Inner Gallery_TR000007             186 vertices

Advice passed along to the user - greatly simplify space geometry, well below 
120 vertices, and try performing analysis on that model.

Original comment by scriswel...@gmail.com on 14 Jan 2015 at 6:09