search

kbenne / cbecc

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

CBECC-Com Crashes on calculation #394

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Software Version: CBECC-Com 2013-1d (521)

Now that I have been able to complete a model the software has been shutting 
down almost immediately after trying to calculate.  What I am working on is a 
small 20 unit apartment building that is 5 stories tall.  The one thing I am 
unsure of is modeling multiple HVAC systems of the same type.  All 20 units use 
the same 2 ton heat pump and when I try to put the unit count at 20 there is an 
error saying it needs to be less than 10.  So I broke it into 5 systems with a 
unit count of 4, essentially 1 system per floor.  
Is this the proper way to model this situation?  
Could this be the cause of the software not calculating?  

I have attached the model for your review.  

Also, will we have the capability in the future to have a unit count greater 
than 10?  We work on a lot of high-rise multi-family projects and 

I can have hundreds of units that all use the same size system and it would 
make modeling faster if they can all be grouped under one HVAC entry with a 
multiplier.

Original issue reported on code.google.com by nka...@archenergy.com on 22 Jan 2014 at 10:05

Attachments:

GoogleCodeExporter commented 9 years ago 
Additional files and screenshots after CEC did some initial fixes.

Original comment by nka...@archenergy.com on 22 Jan 2014 at 10:11

Attachments:

GoogleCodeExporter commented 9 years ago 
Martha: Never mind what I said about CBEC-Com crashing – I was using a 
version downloaded from svn (probably not correctly) – when I used v521, the 
error trapping that I expected is there.

So far, it looks like the model is UNDER specified, to put it nicely.

Original comment by rhedr...@archenergy.com on 23 Jan 2014 at 7:40

Attachments:

GoogleCodeExporter commented 9 years ago 
Scott: That's good.  It is important that we jump on any situations where the 
system actually does crash.

In terms of the model being UNDER specified - there has not been much in terms 
of user/usability testing on CBECC-Com, so I would expect there to be a fairly 
substantial number of "required" inputs or inputs out of reasonable ranges that 
might not be getting checked.  I actually do not really know - so kind of 
unfair for me to suggest it...
In any case, if time/availability permits between now and our next release 
(1/29), it would probably be a good use of time to examine the few models we do 
have for model completeness or areas where inputs aren't internally consistent 
and improve either ruleset CHECK* reporting and/or UI... to improve the overall 
system.
If it is found that rules in a given area are lacking CHECK* logic, then those 
rule developers should perhaps set aside some time to fill those in - which 
will also help in terms of usability.

Original comment by rhedr...@archenergy.com on 23 Jan 2014 at 7:41

GoogleCodeExporter commented 9 years ago 
Martha: Here is a history of what I’ve done with this user file.  I’m sure 
there are problems with the mechanical system, since I threw something in there 
quickly, so I am only sending you this because you wanted to know when the 
program aborts rather than error traps.

This can be combined with the user issue once it is in the tracking 
spreadsheet…

Original comment by rhedr...@archenergy.com on 23 Jan 2014 at 7:44

GoogleCodeExporter commented 9 years ago 
Martha to user: Hi XXXX,  We are still debugging this, but for starters there 
are several things missing in this file:

1.  Space Function and Schedule Group assignments
2.  Surface Construction and/or Fenestration assignments
3.  Thermal Zone assignments
4.  HVAC details for each Thermal Zone
5.  Lighting specifications for each Space

Thanks, Martha

PS  We have self-paced CBECC-Com how-to videos here: 
http://bees.archenergy.com/faq.html

Original comment by rhedr...@archenergy.com on 23 Jan 2014 at 7:49

GoogleCodeExporter commented 9 years ago 
Scott: Digging more into this model and was finding that there were problems in 
wall & window Z coordinates.  First thing that popped out was window 
coordinates exceeding it's parent wall and after further investigation found 
other problems.

I have copied some others on this message, because in reviewing it I toggled on 
an old CCP feature we had not been using to date - the ability to append onto 
each object in the component tree the contents of one of that object's 
properties.
Some examples that we may want to toggle on for users include:
- ConsAssm:CompatibleSurfaceType

- AirSys:Type

- ThrmlZn:Type

... and we could expand this to include properties for other objects.  These 
can all be specified in the CBECC-Com13.INI file.
Let me know your thoughts on that.

Back to the task at hand - reviewing Z-level of parent/child objects.
I implemented a new PolyLp property "ZRngMessage" and am now populating that 
inside the routine that initializes the PolyLp data.  Then plugged it into the 
INI file to view to the right of each PolyLp - and now see this:
For surfaces associated w/ the Unit 2A 5216 space, most conform to the expected 
Z range of 9-18 (highlighted in green) but some seem to have geometry more 
consistent w/ the floor above (in red):

... and the same goes for space Unit 2A 5217
There are these plus additional problems w/ space Unit 2A 5218 - the space 
PolyLp is inline w/ the space ceiling rather than floor (purple highlight) and 
one window protrudes down below its parent wall (in ):

... and there are similar problems w/ spaces/surfaces on floors 3 & 4...

Martha - are you wanting to continue to communicate w/ Vincent re: this input 
file.  If so, then two things that should be added to the list you already 
provided him are:
    - fixes to geometry issues (all surfaces located withing the Z range of it's parent object)
    - addition of non-recirculating or recirculating DHW systems, assigned to each Space with a residential function type
 and if not, who would you like to follow-up on this.

All - let me know if you have thoughts/suggestions re: the above functionality 
and keep in mind that the Z range labeling shown above won't be available until 
I update the EXEs on the SVN site (which I was not planning on doing for 
another 1-2 days, so let me know if you want it sooner).

Original comment by rhedr...@archenergy.com on 23 Jan 2014 at 7:50

GoogleCodeExporter commented 9 years ago 
For more re comment 6, including graphics, see email from Scott on 1/22/14 at 
17:22

Original comment by rhedr...@archenergy.com on 23 Jan 2014 at 7:52

GoogleCodeExporter commented 9 years ago 
Martha: Thanks Scott, this is very helpful.  I like your suggestion to add more 
object information in the tree diagrams.  The Polyloop coordinate info is 
especially helpful.

Original comment by rhedr...@archenergy.com on 23 Jan 2014 at 7:53

GoogleCodeExporter commented 9 years ago 
Martha: One more thing – since the reason I sent you the original note is 
about the fatal error, are you working with the rule authors to prevent the 
crash exemplified in this project?

The last line in this log file concerns me, because it looks like a missing 
file needed for the rules, not a user error.

Original comment by rhedr...@archenergy.com on 23 Jan 2014 at 7:53

GoogleCodeExporter commented 9 years ago 
Additional info FYI & perhaps inclusion to the QSG -
The version of Vinny's project (from Martha) caused the analysis to bomb the 
program.  This bomb was occurring during OpenStudio loading the simulation SDD 
XML file.  I made some changes to help catch these errors within the compliance 
manager and report them w/out having the program bomb, but some errors (this 
one in particular) cannot be caught without change being made inside 
OpenStudio.  I have made Kyle & Dan aware of this and we will be talking about 
how to address these issues in upcoming Fri AM calls.
Ultimately - each of these errors is caused by some anomaly in the user's 
input.  What we have to do is to be more proactive by checking for and 
reporting these issues via CHECKCODE or CHECKSIM rules, so that they can get 
caught and reported before being passed on to OpenStudio.  This not only can 
help to minimize the occurrences of these situations, but it (the ruleset) is 
also the best place to provide meaningful error messages that the user can act 
on to fix the problem.  When errors like this get passed through the analysis 
mechanism and into OpenStudio, the likelihood of getting an error message out 
that the user can understand sufficiently to fix the problem is pretty slim.

In addition to catching and reporting these problems - we have also talked 
about making changes/additions to the ruleset library and adding some UI 
features to help facilitate the importation of HVAC systems into user models.  
This should help to minimize the number of HVAC definition issues in user 
models by filling in details and forming the (default) object relationships 
w/out the user having to construct the systems from scratch.

Lots can be done across the board, from ruleset library and input error 
checking to reporting of errors and guiding users to solutions by the software 
to catching and preventing program aborts within E+ and OpenStudio...

Original comment by rhedr...@archenergy.com on 23 Jan 2014 at 7:55

GoogleCodeExporter commented 9 years ago 
Luke: The last line in the log file does indeed correspond to a rule/table 
format error.  While we performed extensive testing of glazing rules prior to 
the December public release, there are a very large number of potential input 
permutations, and we did not test this one.  This particular error has been 
corrected.  Unfortunately, I expect we'll see a few more like this as the 
public continues to put the software through it's paces...

Original comment by rhedr...@archenergy.com on 23 Jan 2014 at 7:56

GoogleCodeExporter commented 9 years ago 
Martha: So, if I use the svn version of CBECC-Com, I should be able to continue 
debugging this file?

Original comment by rhedr...@archenergy.com on 23 Jan 2014 at 7:58

GoogleCodeExporter commented 9 years ago 
Scott: ALSO - if you do pursue this project further, you might want to start 
from where I left off (attached).
The attached file has modified inputs that fix a few of the problems that 
existed in the version you circulated - mainly adjustments to Z dimensions 
throughout the geometry, a FenCons addition and perhaps some other mods.
The HVAC is totally different, so you might want to blast that and put 
something together more along the lines of the user's intended system(s)...

Original comment by rhedr...@archenergy.com on 23 Jan 2014 at 8:03

GoogleCodeExporter commented 9 years ago 
Scott to user: Hi XXXX,

Scott XXXX here - one of the CBECC-Com developers.
I reviewed your model yesterday and found a couple of other things that require 
your attention -
1.  Assuming one or more of your Space Function inputs will be residential in 
nature, you will need to define at least one DHW system (either recirculating 
or non-recirculating) and assign that to each Space in your model that has a 
water heating load, and
2.  Fixes to the building's geometry.  There are a number of surfaces that have 
Z dimensions inconsistent with the floor that they are defined on. For example, 
the second story includes spaces and surfaces w/ Z dimensions of 9 (bottom) 
thru 18 (top).  Within that floor is space 'Unit 2A 5216' (with consistent Z 
dimensions) which has a child exterior wall 'Surface 76' whose dimensions, and 
those if its child windows, fall in the Z range of 18-27.
There are similar problems on each of the floors 2-5.
CBECC-Com does not yet allow users to edit geometric inputs within the UI, so 
these changes would have to occur either using whatever tool was used to 
generate the geometric inputs in the first place, or via manual edits to the 
CBECC project file.
As Martha mentioned, we encourage you to visit the online FAQ page and from 
there view the tutorial videos, one of which includes the process of defining 
DHW systems and assigning them to spaces.

Original comment by rhedr...@archenergy.com on 23 Jan 2014 at 8:05

GoogleCodeExporter commented 9 years ago 
Adding comments sent via email on 1/23/14 @ 19:53 to issue, as well as adding 
Kyle and SDD XML files for review. In testing some other, I believe unrelated 
CBECC updates, I was able to recreate the same issue with our current 010212 
model in the repo.  The last time I successfully ran this model was via batch 
mode on 1/18/14 @ r1432.  Don't see anything significant in the recent CBECC 
repo commits that would cause this issue. With regards to HVAC, on common trait 
is both models have a PTAC system in them.  I ran the 0200 model this morning, 
which does not have a PTAC system, and it ran fine.  

Kyle, interested to know if you find any issues when you run through your 
methods.

--------------- Email on 1/23/14 @ 19:53 -----------------
Finally had a chance to look at this model:
CMVIIPod14-CBECC mjb-sac3.cibd

I found that running the model through CBECC-Com, the program stalls and the 
last item listed in the log file is:

2014-Jan-23 19:36:15 -     OSWrap - Loading SDD model into reverse translator...

However, I did find that the -p xml model created by CBECC will successfully 
(reverse) translate and simulate using the most recent OS package Kyle built on 
1/17/13 (1.2.2.3153fc9) :

https://drive.google.com/file/d/0B6AYyX2ggNyBRUQ5NExSVW15bk0/edit?usp=sharing

I thumbed through inputs, and the only item I noted with regards to HVAC is

Spc   "Unit 2A 5315", ThrmlZnRef should be "ThermalZone 3", not "ThermalZone 2"

Another observation is that there is no lighting energy use since there is none 
defined for any of the user's spaces

With this current definition the ThermalZone is comprised of Spaces that span 
BuildingStorys.  This seems to be fine with OS, but it is a no-no in CBECC, 
mainly because schedules are assigned by floors, and if the baseline design is 
a flr-by-flr system, this checking ensures all the zones served by the system 
have the same schedule.

I had already been planning to add a CHECKSIM rule that checks for this, so I 
will move this up the list.  We should also check that the user has lighting 
defined.

Original comment by da...@360-analytics.com on 24 Jan 2014 at 6:50

Attachments:

GoogleCodeExporter commented 9 years ago 
A few more testing notes:
- Ran the current 010112 model as well, which is basically the same as 010212 
except it does not have ZnSys and related objects; it does not have this issue. 

- Ran the current 070012 model, which as a mix of AirSys and ZnSys, but all 
ZnSys:Type FPFC (i.e. no PTAC or PTHP ZnSys); it does not have this issue.  

- Ran the 010212 model that I referenced in comment #15, but changed the PTAC 
system to PTHP (SAC's version of the user's model had PTAC).  Still, the -p 
model stalls at OS translation.

I could replace the user's HVAC with another type, or alternatively remove all 
ZnSys from the 0102 model for further testing.  However, interested to have 
Kyle indicate what he finds before going through that effort.

Original comment by da...@360-analytics.com on 24 Jan 2014 at 7:56

GoogleCodeExporter commented 9 years ago 
Hey Kyle, 
Just checking into see if you had a chance to review running these files on 
your end?  It would be ideal to resolve before our next beta release, which is 
planned for 1/29.

Original comment by da...@360-analytics.com on 25 Jan 2014 at 2:52

GoogleCodeExporter commented 9 years ago 
Unfortunately I just simulated the two models attached in #15 and they 
completed successfully.

Original comment by kbe...@gmail.com on 25 Jan 2014 at 3:44

GoogleCodeExporter commented 9 years ago 
Although I cannot reproduce this issue on my system, I have a feeling this 
might be related to blow through fans.  I have made a bug fix that might 
address your problem.  Building a package for you now to test.

Original comment by kbe...@gmail.com on 25 Jan 2014 at 3:50

GoogleCodeExporter commented 9 years ago 
Kyle,
Initial testing suggests the change you made fixes the issue with CBECC 
stalling on reverse translation of the .  Just curious to understand how your 
very minor change may have fixed this, especially since the PTAC systems have 
an uneditable default of DrawThrough fans and that we didn't see this in the 
last batch test I ran about 1 wk ago...

Original comment by da...@360-analytics.com on 26 Jan 2014 at 1:02

GoogleCodeExporter commented 9 years ago 
In response to #20, let me try to explain a little technical detail.

The translator gets a vector (c++ term for array) of all of the supply nodes.  
It is getting ready to drop a setpoint manager on each node.  Before it adds 
setpoint managers it is designed to drop the last node because that is the 
supply outlet node, which should already have an SPM.  As you can see on github 
It did this with something like  nodes.erase(nodes.end()).  I made an error 
because nodes.end() is one element past where we want to erase.  The c++ 
standard says this is undefined behavior.  My compiler seems to be tolerant of 
this mistake but you definitely can't count on it and you can't count on 
getting the same result every time.  You might have observed it working one 
moment and not the next.

Original comment by kbe...@gmail.com on 28 Jan 2014 at 5:49

GoogleCodeExporter commented 9 years ago 
Thanks for the description Kyle.  However, I think I confused some changes 
Scott made to eliminate the stall on OS translation with this issue being 
fixed; I am still experiencing a consistent translator failure with the 
attached CBECC model when reverse translating to OS via CBECC, but not when 
reverse translating via SketchUp plugin. 

I turned on the logging in the SketchUp plugin; attached is the log file 
created when the file is imported into OS via SketchUp. I've also attached a 
few messages output to the Ruby console during import (these don't appear to 
show up in the log file).

I suspect this issue has something to do with geometry since the CBECC->OS 
translation fails for all models (-p, -bz, and -b, all included).  If you view 
the geometry in SketchUp, the building is shifted far from the origin.  I can't 
imagine this would be an issue, but perhaps this is an indication that there 
are some other funky issues lurking in this model.

Original comment by da...@360-analytics.com on 29 Jan 2014 at 12:57

Attachments:

GoogleCodeExporter commented 9 years ago 
Following up on comment #22, there are some specific items in the log file that 
jumped out at me:

In SketchUpPlugin (SUP) log:
[boost.ublas] <-1> boost::numeric::ublas::lu_substitute threw exception 
'internal logic'

In Ruby console log:
Surface.create_entity:  fixed swap for #<Sketchup::Face:0xeab5aa0>

Adding Dan to this issue as I thought her might have some ideas.

Original comment by da...@360-analytics.com on 29 Jan 2014 at 6:50

GoogleCodeExporter commented 9 years ago 
This warning is expected:

[boost.ublas] <-1> boost::numeric::ublas::lu_substitute threw exception 
'internal logic'

This should only affect the model when opening in SketchUp, won't matter when 
running programatically:

Surface.create_entity:  fixed swap for #<Sketchup::Face:0xeab5aa0>

Original comment by dan.macu...@gmail.com on 29 Jan 2014 at 7:08

GoogleCodeExporter commented 9 years ago 
Uploading updated archive of files that were originally included in comment 
#22, but this archive includes the OSM for the model that was created when SDD 
-p model was import into OS via SUP.  The log files included in the archive 
correspond to this model, so UID object names in log correspond to the UIDs in 
the OSM. Thought this might be useful for debugging.

Original comment by da...@360-analytics.com on 30 Jan 2014 at 7:40

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by rhedr...@archenergy.com on 31 Jan 2014 at 5:32

GoogleCodeExporter commented 9 years ago 
I can't reproduce this in the SketchUp plug-in or using CBECC myself.  Scott, 
can you set a break point here:

https://github.com/NREL/OpenStudio/blob/develop/openstudiocore/src/model/PlanarS
urface.cpp#L287

That will allow you to get a full stack trace.  Also, you might be able to go 
up into the call stack to find the SDD translation routine this is coming from. 
 That might allow you to get an xml element id or something useful for you.

Original comment by dan.macu...@gmail.com on 31 Jan 2014 at 7:19

GoogleCodeExporter commented 9 years ago 
Making progress in isolating the problem, but still not sure the source of the 
problem. Tracing through the reverse translation I identified the object that 
throws the exception - the door (Dr) named "Sub Surface 7".  The root cause of 
the exception is that that object's PolyLp has no vertices found when 
getNewallVector() is called during the process of computing the outward normal.
Deleting that one object (and it's child PolyLp) causes the run to process fine.
Have looked at this object many times and can't see a problem.  It is clearly 
in the same plane as it's parent wall, PolyLp looks fine...
Attached are the two proposed XML files (before & after deletion of Sub Surface 
7) and a graphic showing their only difference.

Kyle/Dan - Any thoughts what might be causing this particular object from 
translating properly?

Original comment by scriswel...@gmail.com on 1 Feb 2014 at 1:55

Attachments:

GoogleCodeExporter commented 9 years ago 
More experimentation -
If I shift the door 0.01 of a foot toward the X-axis, it runs.
Door is in exact same plane and in all cases it fits inside the wall.
Both the attached XML files run fine, w/ the only difference being this slight 
shift in door location.
Perhaps some unusual math or unit conversion issue??
Thoughts?

Original comment by scriswel...@gmail.com on 1 Feb 2014 at 2:22

Attachments:

GoogleCodeExporter commented 9 years ago 
Could it be something to do with the coordinates being on the edge of the wall. 
Shouldn't make a difference but you never know.

Original comment by nka...@archenergy.com on 1 Feb 2014 at 2:26

GoogleCodeExporter commented 9 years ago 
Thanks Scott, this is really useful.  It seems that the vertices are getting 
removed somewhere along the way.  However, I can't think of where this would 
be.  When you said "PolyLp has no vertices" does that mean the the XML element 
has no vertices when the translation happens?  It is possible that the xml file 
has vertices but the translator is somehow modifying the QXmlDocument to remove 
it.  When the translator gets to that sub surface and goes to create the 
surface, how many vertex elements are returned?  If the problem is not in the 
xml elements, then something in the OpenStudio must be removing those elements. 
 If there is anyway to get a debug build or source code to me I can help debug 
this more.

Original comment by dan.macu...@gmail.com on 1 Feb 2014 at 3:14

GoogleCodeExporter commented 9 years ago 
Here is a link to debug executables:
https://drive.google.com/file/d/0B3jyVDPkSD_DdGhfbFI0OElWaG8/edit?usp=sharing
They were compiled against Kyle's latest OpenStudio commit w/ the mod to remove 
the LCC objects from IDF files - branch: 64950006-LCC_Disable
Let me know if you need any other files (PDB/Lib/ILK/etc.)

Vertices are not present by the time getNewallVector() is called, right before 
the exception is thrown.  The fact that minor tweaks to the vertices Y values 
works and the original values don't seem to imply that something specific to 
the Y values themselves is causing the vertices to get blasted.
I did not trace into the code QDom code that initially reads/parses the 
cartesian coordinates out of the XML file, but I sure don't see any problem on 
the XML side.
Let me know if any other files/info can help.
THANKS for the continued focus!

Original comment by scriswel...@gmail.com on 1 Feb 2014 at 5:33

GoogleCodeExporter commented 9 years ago 
Scott, I believe I have a fix for this issue and am testing it out now (I'll 
just commit to the same branch Kyle did the no LCC option on).  However, we 
still need to figure out the desired behavior of the translator for bad input 
(e.g. non-planar vertices).  Non-planar vertices would be hard for you to check 
for but might occur in a file.  The translator could continue to throw an 
exception; it could trap the exception, issue an error, and halt translation 
(returning false); or it could issue a warning and continue translating the 
rest of the model.  What is your preference?  Kyle do you have any convention 
you are following?

Original comment by dan.macu...@gmail.com on 2 Feb 2014 at 6:57

GoogleCodeExporter commented 9 years ago 
A fix for this issue is in this commit on the 64950006-LCC_Disable branch:

https://github.com/NREL/OpenStudio/commit/f18cdf75077999c0bdd989b7be680ea0873e2a
72

Original comment by dan.macu...@gmail.com on 3 Feb 2014 at 4:48

GoogleCodeExporter commented 9 years ago 
Fix confirmed in wrap of CBECC-Com 2013 version 1e (538)

Original comment by scriswel...@gmail.com on 3 Feb 2014 at 10:06