[Equest-users] Strange errors in file- HELP!

[John Aulbach]

Thank God a weekend is coming up. Everyone stop simulations and visit their 
families.

The .INP file is the raw data entry in DOE-2.,2 that the eQuest .PD2 recognizes 
to formulate a run. The .BDL file is the "digested" input information after 
DOE-2.2 (the engine) error checks the input. The core program actually uses the 
.BDL file for its input.

I suppose you could change the .BDL file. But the eQuest front end (.PD2) 
displays what is sees in the .INP files NOT the .PD2 file.

It is finished....




________________________________
From: Bruce Easterbrook <bruce5 at bellnet.ca>
To: Nick Caton <ncaton at smithboucher.com>
Cc: equest-users at lists.onebuilding.org
Sent: Fri, July 9, 2010 3:59:34 PM
Subject: Re: [Equest-users] Strange errors in file- HELP!

I guess my question has opened a can of worms but that was why I asked the 
question.  Maybe the eQuest code writers will have to answer this one.  Maybe I 
was delirious after 16 hours on the computer when I made my observations.  I 
noticed that wizard changes were inserted at the end of the INP file when you 
press finish.  If you then press simulate, eQuest will do another run of the (a) 
BDL file.  It does not seem to be a new BDL file, possibly a modified one based 
on the current INP file ie changes tacked onto the end, maybe just the old BDL 
file.  Certain line based errors don't seem to get updated unless the program is 
shutdown, opened and recompiled.  My new simulation was kicking out on the same 
line error as before.  Maybe I adjusted the BDL file by mistake, but I don't 
think I did, I adjusted the INP file.  Finally in frustration I closed the 
project and went to bed.  Opened the same file in the morning, it compiled 
perfect, pressed simulate and that ran too.  So the new question is what is 
different between doing a save in the program, simulating, and shutting down, 
restarting and simulating?  When does the line order in the INP file get 
updated?  Maybe this is why Carol likes editing in the INP file so much, she 
fixes the error at the line it occurred at, rather than the wizard fix which 
seems to append the INP file.  I did do a INP fix where I noticed the call for a 
change I had make had caused the run to fail.  I just grabbed the change from 
the end of the INP file, moved it up to before the call, saved it and then the 
simulation ran.
Contradicting Nick, it seems to me the INP file is the active file for making 
changes and the BDL file is the compiled result from the INP file that is used 
to run the simulation.  If you change the BDL file then it will be 
over-written.  But on the other hand Nick does know the program extremely well 
and has had success changing the BDL file.  All this seems to support my 
contention that there is a difference in how eQuest treats a full shutdown and 
recompile verses one in the program with just a save.  Dating myself here, I 
haven't written and compiled code since the days of card readers.  For the 
program to run you have to compile the whole program.  You can have discrete 
programs making up the whole, they can be compiled and test run separately, but 
in the end, you have to compile the whole program at once.  Thoughts?
Bruce

On 09/07/2010 04:22 PM, Nick Caton wrote: 
Let me take a crack at the piñata too!
> 
>-          eQuest Wizard information is stored in the pd2 file.
>-          When you hit the “Finish” button in the wizards, an .inp file is 
>generated based on the Wizard inputs (which are in the pd2)
>-          Whenever you run a simulation, whether in detailed or wizard mode, 
>eQuest will first “evaluate” everything in the current .inp file.  The generated 
>report is the .bdl file.
> 
>As a result of the above, changing anything in the .bdl file will do nothing for 
>you – treat it simply as a report and make changes to the .inp file.
> 
>Additionally, if you are ever trying to copy/paste information into a 
>wizard-level project, you will never get anywhere pasting into the .inp because 
>that .inp will get overwritten (a new one is generated) every time you “finish” 
>your wizard screens.
> 
>~Nick
> 
> 
> 
>NICK CATON, E.I.T.
>PROJECT ENGINEER
>25501 west valley parkway
>olathe ks 66061
>direct 913 344.0036
>fax 913 345.0617
>Check out our new web-site @ www.smithboucher.com
> 
>From:equest-users-bounces at lists.onebuilding.org 
>[mailto:equest-users-bounces at lists.onebuilding.org] On Behalf Of Demba Ndiaye
>Sent: Friday, July 09, 2010 3:18 PM
>To: Bruce Easterbrook; Patrick J. O'Leary, Jr.; cmg750 at gmail.com
>Cc: equest-users at lists.onebuilding.org
>Subject: Re: [Equest-users] Strange errors in file- HELP!
> 
>Bruce, 
> 
>To your question (My question is does eQuest take the INP file and create a new 
>BDL file on opening the project?  I'm referring to the initial run (compile) 
>eQuest does on opening, is it creating a new BDL file?), answer is YES.
> 
>____________
>Demba NDIAYE
> 
>From:equest-users-bounces at lists.onebuilding.org 
>[mailto:equest-users-bounces at lists.onebuilding.org] On Behalf Of Bruce 
>Easterbrook
>Sent: Friday, July 09, 2010 3:40 PM
>To: Patrick J. O'Leary, Jr.; cmg750 at gmail.com
>Cc: equest-users at lists.onebuilding.org
>Subject: Re: [Equest-users] Strange errors in file- HELP!
> 
>I have a question, partly due to my ramble a few weeks ago on the wizards and 
>how I use them.  After a long series of adjustments I shutdown and re-initialize 
>the program.  My question is does eQuest take the INP file and create a new BDL 
>file on opening the project?  I'm referring to the initial run (compile) eQuest 
>does on opening, is it creating a new BDL file?
>To second what everyone else is saying, certain errors are easier fixed in the 
>INP file, like these ones.  The main thing to remember is to always have a 
>backup copy.  The most important one is your last one before you leave the 
>wizards.  Then go for it, if you crash it, copy your copy and try and other 
>tack.
>Bruce
>Abode Eng.
>
>On 09/07/2010 02:48 PM, Patrick J. O'Leary, Jr. wrote: 
>one thing you can do is make changes to the .pd2 and .inp files using notepad 
>once you've figured out what you need to change.   for example, if your EL3 East 
>Perim Plnm (G.E6) was referenced but is no longer defined, you have a plenum 
>space that belonged to a space that changed names during a zoning change.  look 
>at the .inp file line number, find out which space the EL3 East Perim Plnm 
>(G.E6) is supposed to correlate to and change the name accordingly - in the .inp 
>file.  once these references are corrected the simulation should run fine. 
>
>
>you're probably looking at changing EL3 East Perim Plnm (G.E6) to whatever the 
>new space name is (checking what comes before line 14898 can put you in the 
>right direction on finding the correct name to change to.
>
>and when you have a working simulation always backup your .pd2 (wizard mode) 
>and/or .inp (detailed mode) files even if you just copy them in the same 
>directory.
>*ERROR****************************************************************************************
>
>*ERROR*****EL3 East Perim Plnm (G.E6) was referenced on line 14898 but never
>            defined.
>*ERROR****************************************************************************************
>
>*ERROR*****EL3 West Perim Spc (G.W4) was referenced on line 15237 but never
>            defined.
>*ERROR****************************************************************************************
>
>*ERROR*****EL3 WNW Perim Plnm (G.WNW7) was referenced on line 15377 but never
>            defined.
>
>
>On 7/9/10 11:23 AM, Carol Gardner wrote: 
>Hmm. Well I'm not sure I understand exactly what you are asking, but here are my 
>recommendations. Finish what you need to do in DDWizard and get out of it. I 
>wouldn't even try to make the changes you are trying to make while in the 
>Wizard.
>
>Don't fear DD edit. You can do things in it just as easily as in the Wizard, and 
>if you get stuck we'll help. Like I said earlier, the easiest way to see what 
>and where the error is, is to open up the .bdl and .inp files. That might be 
>even scarier to you than DD edit, and that's okay, you should be scared. You can 
>mess up in a hurry but with careful work you won't. 
>
>
>Take a deep breath and get out of the Wizard!!
>
>Cheers,
>Carol
>On Fri, Jul 9, 2010 at 11:11 AM, Paul Brooks <equestpaul at yahoo.com> wrote:
>Carol, Dave, and Mtt:
> 
>Thank you for the replies.  I did look in the BDL file, but did not realize I 
>had to update the inp.
> 
>That being said, am I safe in assuming that, if I stay in the DDwizard (not 
>quite ready to leave yet), every time i add information and compile, I will have 
>the same error.  The root cause of the error is in the interface, correct?  If 
>that is the case, then the reality is it just cannot be fixed unless i change 
>the inp file after compiling?
> 
>Thank you again!
> 
> 
> 
>
________________________________

>From:Carol Gardner <cmg750 at gmail.com>
>To: Paul Brooks <equestpaul at yahoo.com>
>Cc: eQuest user forum <equest-users at lists.onebuilding.org>
>Sent: Fri, July 9, 2010 1:32:58 PM
>Subject: Re: [Equest-users] Strange errors in file- HELP!
>
>Hi Paul,
>
>Here's my strategy when this happens to me. I open the .inp file and the .bdl 
>file in Word. I then use the Edit, Find feature and search on ERROR in the .bdl 
>file. When I find the line that the error is occurring in I then fix it in the 
>.inp file. Repeat until all errors gone. You probably have an existing space 
>that shared an interior wall with your now deleted space and is trying to 
>reference it using" NEXT-TO". Be sure to fix the error in the .inp file not the 
>.bdl file, which I have done a few times. This is one example of why it is good 
>to familiarize yourself with the Building Descriptive Language (BDL): you can 
>make these sorts of fixes much easier in your input deck using than trying to 
>figure it out in DD edit. Just be sure not to delete any delimiters (..) 
>
>
>Let me know how you do..
>
>Carol
>On Fri, Jul 9, 2010 at 8:33 AM, Paul Brooks <equestpaul at yahoo.com> wrote:
>I am modeling an addition to an existing building.  I originally did the 
>shell/zoning using just the original building.  I then, after saving a back up 
>copy of the base building, i went back to the shell and zone drawing screens in 
>the DD wizard and expanded the shell to account for the addition, and then went 
>into the zone creation and adjusted my zones.  I was sure to follow the rules 
>about matching verticies, etc.
> 
>Now i am getting errors concerning the zone and plenum.  It appears that the 
>program is still seeing plenums and walls that are now non-existent.  The 
>program says that plenums are being referenced but are not defined (see error 
>message below).
> 
>Anyone got any ideas on how to clear this?
> 
> 
> 
>*ERROR****************************************************************************************
>
>*ERROR*****EL3 East Perim Plnm (G.E6) was referenced on line 14898 but never
>            defined.
>*ERROR****************************************************************************************
>
>*ERROR*****EL3 West Perim Spc (G.W4) was referenced on line 15237 but never
>            defined.
>*ERROR****************************************************************************************
>
>*ERROR*****EL3 WNW Perim Plnm (G.WNW7) was referenced on line 15377 but never
>            defined.
> 
> 
>****************************************    5 ERRORS
>****************************************    2 WARNINGS
>****************************************  103 CAUTIONS
>     *20195* COMPUTE ..
>     *20196* STOP ..
>****************************************    5 ABORT-LEVEL DIAGNOSTICS 
>  
> 
> 
> 
> 
> 
>  
>  
>_______________________________________________
>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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20100709/0c789d85/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1459 bytes
Desc: not available
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20100709/0c789d85/attachment.jpeg>