search

kbenne / cbecc

Automatically exported from code.google.com/p/cbecc
0 stars 0 forks source link

IES - table lookups #786

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Can you help with the table lookup errors as shown in the attached file please, 
as well as some other errors. Model in the link below.

http://upload.iesve.com/uploads/staff/7151/Westwood912_NoUndergroundAdjacency.ca
b

Original issue reported on code.google.com by f.le...@gmail.com on 15 Sep 2014 at 11:15

Attachments:

GoogleCodeExporter commented 9 years ago 
Sorry it’s taken so long to respond.  There are a number of issues with this 
model.  Some of the table lookup errors were due to having user inputs for 
lighting power in unoccupied spaces, even though the values were zero.  When I 
restore the defaults for those spaces, those errors do not reoccur.  

The other table lookup errors were due to a bug in the demising floor rules.  
This has been fixed and the fix will be in v3b.  I don’t have a workaround on 
this.  I’m not sure that these errors are causing the run to fail.  

When I ran the model in the development version of v3, which includes the fix 
for the demising floors, I got errors because having multiple pumps assigned to 
plant equipment or to fluid segments is not supported.  I removed the pumps 
labeled “standby” to resolve this.  

Finally, I was getting EnergyPlus errors: “GetSurfaceData: There are 2 
degenerate surfaces; Degenerate surfaces are those with number of sides < 3.” 
 I didn’t have a simple means of identifying these surfaces, so I wasn’t 
able to remove them.  There were subsequent EnergyPlus errors, the first of 
which are due to these two surfaces, and others which may also be due to these 
surfaces, although I can’t be sure without fixing the surface errors.

Original comment by rhedr...@archenergy.com on 8 Oct 2014 at 7:04

GoogleCodeExporter commented 9 years ago 
Dan, I thought we had added code to the translator to remove "Degenerate 
surfaces are those with number of sides < 3"  Can you check on this?  

Luke, once that is resolved, can you check on the daylighting reference point 
being too close to the glass?

Original comment by rhedr...@archenergy.com on 8 Oct 2014 at 7:08

Attachments:

GoogleCodeExporter commented 9 years ago 
The problem surfaces here are these two.  They have 4 vertices but they are 
very small (area is 0.01 m^2).  This is just above OpenStudio's threshold for 
declaring this a degenerate surface but apparently below EnergyPlus's

Surface=BS000000_W20 REVERSED, in Zone=ZN ADJACENT BUILDING
Surface=BS000000_W20, in Zone=ZN BASEMENT - B100 - STORAGE

  0.3048, 17.9832, 0.0012701016,          !- X,Y,Z Vertex 1 {m}
  8.9916, 17.9832, 0.0012701016,          !- X,Y,Z Vertex 2 {m}
  8.9916, 17.9832, 0,                     !- X,Y,Z Vertex 3 {m}
  0.3048, 17.9832, 0;                     !- X,Y,Z Vertex 4 {m}

Original comment by dan.macu...@gmail.com on 5 Nov 2014 at 11:56

GoogleCodeExporter commented 9 years ago 
When opening this file in the SketchUp plug-in I also get this warning:

Error:  GR000018_W3-W1
This sub surface's base surface 'GR000018_W34' has less than 3 points, it 
cannot be drawn.

This was odd because the base surface was fine.  However, the window 
GR000018_W3-W0 extended all the way to the bottom of the base surface.  I think 
this was causing a SketchUp entity swap which somehow confused GR000018_W3-W1.  
Changing GR000018_W3-W0 to the following resolved this issue (which never 
affected simulation):

<Win>
  <Name>GR000018_W3-W0</Name>
  <FenConsRef>Westwood External Window (West)</FenConsRef>
  <PolyLp>
    <CartesianPt><Coord>1</Coord><Coord>58.7851</Coord><Coord>0.104167</Coord></CartesianPt>
    <CartesianPt><Coord>1</Coord><Coord>20.2149</Coord><Coord>0.104167</Coord></CartesianPt>
    <CartesianPt><Coord>1</Coord><Coord>20.2149</Coord><Coord>12.1391</Coord></CartesianPt>
    <CartesianPt><Coord>1</Coord><Coord>58.7851</Coord><Coord>12.1391</Coord></CartesianPt>
  </PolyLp>
</Win>

Original comment by dan.macu...@gmail.com on 6 Nov 2014 at 4:27

GoogleCodeExporter commented 9 years ago 
Roger, I'm turning back to you, basically the issue is that there was a surface 
that Openstudio thought was ok but EnergyPlus did not.  I could try to align 
the checks between OpenStudio and EnergyPlus but don't think there is a 
guarantee these can be perfectly synched.  Do you know how this model was 
constructed?

Original comment by dan.macu...@gmail.com on 6 Nov 2014 at 4:30

GoogleCodeExporter commented 9 years ago 
Yes, this is a model that came from IES, so I assume that the IES interface was 
used in creating the geometry.  I am not familiar with their interface, so I 
can't speak to the details of geometry creation.  However, we have had a number 
of issues related to IES created geometry, so we need to trap geometry errors 
before they cause hard to diagnose errors. 

I don't think it is necessary that the OS and E+ checks be perfectly synched, 
just that the OS checks prevent passing geometry that E+ can't deal with.  If 
we end up slightly more restrictive than strictly necessary, so be it.

Original comment by rhedr...@archenergy.com on 6 Nov 2014 at 10:00

GoogleCodeExporter commented 9 years ago 
Roger is this important enough that I should go ahead and try to fix this?  If 
so just re-assign to me

Original comment by dan.macu...@gmail.com on 13 Nov 2014 at 9:43

GoogleCodeExporter commented 9 years ago 
Yes, I think so.

Original comment by rhedr...@archenergy.com on 13 Nov 2014 at 9:46