[Equest-users] dd wizard - invalid argument

Bruce Easterbrook bruce5 at bellnet.ca
Tue Jun 15 15:53:05 PDT 2010


I just came on it by chance late one night.  I had a few BDL errors that 
I fixed, tried to run the sim and it wouldn't run it, said I still had 
the errors in the BDL file.  Totally frustrated I saved the file and 
went to bed.  Got up and opened it in the morning, eQuest initialized 
the cad file, ran through the BDL error free, I ran the sim and 
everything worked.  As for exactly why, I do not know for sure, 
everything else in my comments was speculation.  I have used the 
re-evaluate components, doesn't always do much.  Seems to depend on what 
you have been changing.  I think the program just starts from scratch 
and rebuilds the BDL file, the line processing order is reset.  When you 
open the program and a project the program always processes (compiles?) 
a file, and I assume creates a new BDL file.  All the information is 
saved in the INP file, which is processed to create the BDL file?  But I 
have noticed that a lot of errors which eQuest said I had, which I had 
worked on to correct, do not disappear until you force the program to 
redo the initial launch process.  When I think of all the hours I have 
previously spent trying to fix an error, probably fixed it and threw the 
fix away and then got into even more obscure ideas for a fix.  It only 
seems to apply to certain errors as well.  Some fixes will get the 
simulation to run.  It is hard to track it when I don't use eQuest every 
day.  Sometimes I will not use it for weeks.  For the time it takes I 
just close the program and reopen it, 8 errors go to 3, you do the 3 
restart, and away you go, no getting lead down the garden path by a flag 
which might or might not reset.  This is probably why working right in 
the INP file is so effective, you are fixing the error right at the 
point it happens, not having something added at the end by the wizard?  
I do this as well but prefer to use the wizard interface as much as I 
can.  Older files are handy for this as well if you delete something you 
later find out is important, just go back to the old INP file, copy what 
you need and put it back in the newer file.  This is something I have 
noticed in the INP file, the order is very important.  You can fix some 
errors just by changing the line order.  This also had something to do 
with my speculation.  I had changed an item, can't remember what, the 
sim wouldn't run.  The error referred to the change I had just made, I 
went into the INP file and saw my change further down, after the program 
was making the call for the information, I grabbed the section, moved it 
up before the call and the simulation ran.  That is about all the light 
I can shed on the subject, just an observation about an inconsistency.
Bruce

On 15/06/2010 11:18 AM, Nick Caton wrote:
>
> Bruce,
>
> Your "reinitialization breakthrough" has my eyebrows at attention!  
> I've previously dug to figure out what the "reevaluate components" and 
> various "reinit... " options under the 'Tools' menu are supposed to 
> do, and have until now come up empty-handed...
>
> Are you saying these functions perform something of a "cleaning 
> duty"?  If anyone can offer a complete explanation of these tools (or 
> point me to a help file / search term), that'd be one less thing on my 
> "huh?" list =).
>
> Aaron,
>
> Bruce has already said most of what I'd contribute to your situation 
> -- I might only add that I now make a conscious point to do a bit of 
> rounding (to the first decimal place) whenever I define vertical (z) 
> coordinates and floor-to-floor heights for different shells.  It can 
> really streamline things and make it easier to get the geometries 
> right on the first go.  Recently I've thrown together fairly complex 
> geometries for a 5-level, 5-shell school, and I found making a quick 
> reference riser in my notepad margin for each floor's z-coordinates 
> streamlined the process perfectly.
>
> I'll be very curious to hear whether the "reinit" or "reevaluate" 
> options help your situation -- if you do have pitched roofs to model, 
> I'll share that I've had nothing but inconsistent troubles in the past 
> using the wizard-generated pitched roofs -- If so, I might encourage 
> you or anyone else to consider whether a wizard-generated flat roof, 
> mildly edited later in detailed mode (adding tilt and/or breaking into 
> 2 pieces), might give a fair thermal approximation.
>
> Pasha and Bruce are right -- a lot of people in the industry make 
> energy modeling out to be unrealistically complex and accurate --the 
> end-users (I'm raising my hand) are occasionally the worst culprit! 
>  When you go to the hardware store to buy a hammer, would you pay for 
> a gold-interlaced hammer with pretty tassels, matching fashionable 
> holster, built-in compass, and aerodynamic spoilers?  Not to hammer 
> things with...  You'd simply buy a hammer.  With eQuest, and indeed 
> any energy modeling software, we're tasked with building a tool (the 
> model) to ultimately perform a simple task.  If a nail ultimately gets 
> driven into the wood straight, only hammer-connoisseurs might ever 
> care how complex of a hammer put it there.
>
> ~Nick
>
> PS: If anyone actually owns a hammer like that -- yes, I am making fun 
> of you =).
>
> cid:489575314 at 22072009-0ABB**
>
> * *
>
> *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 
> *Bruce Easterbrook
> *Sent:* Tuesday, June 15, 2010 2:21 AM
> *To:* Pasha Korber-Gonzalez
> *Cc:* equest-users at lists.onebuilding.org
> *Subject:* Re: [Equest-users] dd wizard - invalid argument
>
> Thanks Pasha, positive feedback is nice.  I'm on a roll after a 60 
> hour project.  Not big, but complex.  As it is fresh in my mind I have 
> been able to share a few new tidbits I have learned off the top of my 
> head.  Unfortunately a few were learned the hard way, again.  The 
> reinitialization about the BDL file seems to be major, to me anyway.  
> It seems before I was chasing a few phantom errors which I had 
> actually fixed but didn't realize were fixed.  Leading me down a path 
> to never never land thinking my fix was no good.  The current building 
> had multiple intersecting cottage roofs on top and multiple flat roofs 
> on lower levels.  Didn't even go there, the model has all flat roofs.  
> Thermo wise it will be close.  That is another thing for new users, 
> your 3D model does not have to look like the architects pretty 
> rendering.  eQuest is a thermodynamic idealization.  There are limits 
> on how much your client wants to pay to get to get a good mechanical 
> system.  Sorry architects, but I do find it encouraging some of you 
> are dabbling with eQuest.  Understanding the total project and systems 
> is the key to a great building and maybe a little more appreciation 
> when your project lands on my desk, lol.  I'm also a Joe Lstiburek fan 
> like Nick.  Another point I would like to make is about reality on the 
> building site.  When the plumbing contractor drops a drain from a 
> toilet that got moved right where your main supply duct was supposed 
> to go, the sheet metal contractor uses 4 short 90's to avoid it, 
> worrying about your AHU ESP of 2.55 " WC or 2.6 " WC is crazy.  Real 
> life HVAC is not accurate to .01, except the eQuest geometry.  Besides 
> my up to date ASHRAE manuals my next most valued quick reference is 
> the fifth edition of Fan Engineering by the Buffalo Forge Company, 
> copyright 1949.  There are very few current HVAC applications not 
> covered in this manual and with a psych chart (included) and a slide 
> rule you are in the ball park with most of todays systems at least as 
> far as they actually get installed.  Buffalo Forge was Willis 
> Carrier's first engineering job after graduating from Cornell (1901), 
> in an "experimental department", the future "father of the AC 
> industry".   I have been in one old building with a cast BF fan system 
> still running like the day it was installed, and the occupants still 
> satisfied after 70? years.  My point, we have better tools, computers, 
> eQuest, HAP, Trace, infinitely better control systems and sensors, 
> hi-efficiency motors, etc, but the basic engineering is many decades 
> old.   We are still re-inventing the wheel with new twists to deal 
> with the current reality.  Calculating to .0001 is still, in reality, 
> irrelevant in HVAC.  The key is to simplify the model so it reflects 
> the building reality reasonably close, have the model flexible enough 
> to be able to test different ideas, configurations and use your 
> computing horsepower to run simulations to test the different 
> hypotheses.  The model is the key, once it is running reliably and 
> accurately, a new scenario is a dozen or 2 key strokes and a press of 
> the sim button.  The other defining reality is how much your customer 
> wants to pay for this information, somewhere between as little as 
> possible and not much, lol.
> Time to get some sleep!
> Bruce
>
>
> On 15/06/2010 12:10 AM, Pasha Korber-Gonzalez wrote:
>
> Bruce-you've been comin' in pretty heavy yourself on this forum and I 
> concur with your explanations & comments/advice to Aaron and other new 
> users of eQuest.  Put very well and sincere.  Bruce stated the reality 
> of the need for accuracy & efficiency in setting up any energy model.  
> After foolishly having faith in my eQuest files' ability to run 
> smoothly from start to finish, I have adopted the "Save As" approach 
> for all of my project files, and like Bruce stated, "Never get 30 
> hours in without testing and running it many times on the path...the 
> simulation at this point is for confirmation your model is running and 
> [free of errors.]"
>
> Aaron-you might want to send us your .pd2 & .inp files so we can see 
> the error(s) you are experiencing.  I think Bruce is on the right 
> track that it might be an external surface.  Do you have a pitched 
> roof on your model?
>
> Pasha
>
> On Mon, Jun 14, 2010 at 7:50 PM, Bruce Easterbrook <bruce5 at bellnet.ca 
> <mailto:bruce5 at bellnet.ca>> wrote:
>
>     You did have an error in your electric rate but obviously if it is 
> not now involved it probably is not the main problem.  That leaves the 
> roof.  If you have several custom floors when you create them in the 
> DD wizard they will all have roofs.  If they are stacked you will have 
> embedded roofs if you have not gone in and removed them which you 
> can't do in the DD wizard.  They will only effect floor to floor heat 
> transfer and maybe eQuest will give them a solar load I don't know.  
> eQuest will run with them if they are technically (geometrically) 
> correct.  The problem is you can't see them in the 3D view if they are 
> covered by other floors and easy visual check to see if they are 
> geometrically correct is not possible.  That will cause eQuest to 
> crash.  You may be able to cheat a little.  eQuest will show external 
> surfaces in a red outline in the 3D view.  If this is may be your 
> problem go to the building shell tab to one of the floors and 
> highlight the roof in tree pane.  Switch to your 3D view and hold your 
> control key and with your left mouse held down rotate the 3D model.  
> It will switch to wire frame and the roof surface will be highlighted 
> in red.  I can't remember how to turn on the wire frame view but that 
> is possible to do as well.  Maybe someone monitoring this will refresh 
> my memory.  I think you have a roof geometry problem and geometry 
> problems are a pain in the ass.
>     The other thing I have noticed and I'm not sure quite why but if 
> there was an error and you have corrected it, the program may have not 
> actually accommodated the change yet.  My guess is, the program runs 
> in a linear fashion start to finish.  A change will probably get added 
> to the end of the program as a addition or change.  When the program 
> is run again it is using the original file and then the additions, but 
> the error is still there and the program hits it first and crashes.  I 
> have found when doing major changes it is best just to save the file, 
> close it and re-open it.  eQuest will then reorder the file and it 
> probably won't crash if you did correct the error.  Run a simulation 
> and you will get much better error messages as to what the problem 
> is.  I have adjusted my trouble shooting technique to this method in 
> the last few weeks and have seen many errors disappear once the file 
> is reinitialized.  It has saved many hours of banging my head on the wall.
>     This is not specifically for you Aaron, just a general observation 
> (tangent).  I have noticed a few guides in the last week or so to help 
> new comers but no one has mentioned reinitializing the project.  It 
> may be an obscure point but I think it saved me about 30% of my hours 
> on my latest project.  One of the biggest things with eQuest is to get 
> it running and keep it running as you build your model.  Start simple, 
> initially, heat transfer surfaces are important, zones are important, 
> windows are not, schedules are not, utilities are not, constructions 
> are not, layers are not, HVAC systems and their zones are not.  
> Geometry is CRITICAL.  eQuest will choke with a vertex error of .01, 
> Carol(e) is "anal on this point", lol, but she knows what she is 
> talking about.  She and Pasha both agree and no doubt will add wisdom 
> if they have any pointers to add.  I should add a plug for Nick as 
> well, another heavy hauler on this site with major experience beyond 
> his years.  Start simple, get the box(es), and surfaces correct.  
> Zones initially can be artificial with the future HVAC system in mind 
> _but also_ to assist with the geometry.  Specifically, in dealing with 
> other floors and roofs.  An un-named eQuest instructor will attest to 
> this, it is easier to manipulate your zoning to assist in your 
> geometry problems and put them together later to accommodate your HVAC 
> model than create the surfaces on the fly in detailed edit. Especially 
> with 40 students watching!  eQuest can be humbling even for experts.  
> NEVER get 30 hours in without testing and running it many times on the 
> path.  Lots of saves, build your files as well as the model.  The 
> simulation at this point is for confirmation your model is running and 
> for error messages.  A tiny error in geometry will crash the file.  
> There is no point doing anything but the bare minimum until the 
> geometry is correct.  It will crash your project with minimal error 
> messages, maybe none, eQuest will just freeze.  Once the geometry is 
> correct keep adding to the complexity one step at a time, test and 
> confirm, fix errors, save, then the next step.  I know it sounds 
> plodding, it is.  Methodical is a much classier word.  Efficient is 
> more to the point.  I contract so when everything blows up I don't get 
> paid.  I eat the hours for my mistakes.  In the end it is all similar, 
> whether it is the boss pounding on the door or the client, the 
> deadline has arrived, eQuest is not cooperating and you are ready to 
> toss the computer out the window, your name is mud.  Plodding is smart.
>     Sorry for the digression Aaron, the Voodoo thread was interesting 
> and I didn't get to add my 2 cents worth.  I was in a swamp with 
> alligators at the time.  On the other hand I did learn a lesson about 
> reinitialization.  You learn by doing and making mistakes.
> Bruce
>
>
>
> On 14/06/2010 06:43 PM, Dahlstrom, Aaron wrote:
>
> Bruce --
>
> The error shows up when I attempt to "finish" the DD wizard.
>
> When I look through the PD2 file and the INP file in Notepad, neither 
> have any explicit errors in them.
>
> The PD2 file does have -
>
> 1) RoofZoneErrorCode = 4
>
> 2) TOUPeriodErrSeas1 = " "
>
> I can get */into /*the wizard just fine, and all the data appears 
> correct. The problem is that when I "finish" the program crashes.
>
> I just experimented with removing the TOU electric rate, and again, 
> when I hit "finish" it crashes eQUEST with the error noted below.
>
> Thanks for trying!
>
> Any other suggestions?
>
> *Aaron Dahlstrom , PE, LEED® AP*
>
> *In P**o**sse* -- A subsidiary of *AKF*| 1500 Walnut Street, Suite 
> 1414, Philadelphia, PA 19102
>
> d: 215-282-6753| m: 267-507-5470| In Posse: 215-282-6800| AKF: 
> 215-735-7290
>
> e: ADahlstrom at in-posse.com <mailto:ADahlstrom at in-posse.com> | in posse 
> web: www.in-posse.com <http://www.in-posse.com/> | akf web: 
> www.akfgroup.com <http://www.akfgroup.com/>
>
> *From:* Bruce Easterbrook [mailto:bruce5 at bellnet.ca]
> *Sent:* Monday, June 14, 2010 5:21 PM
> *To:* Dahlstrom, Aaron
> *Cc:* equest-users at lists.onebuilding.org 
> <mailto:equest-users at lists.onebuilding.org>
> *Subject:* Re: [Equest-users] dd wizard - invalid argument
>
> It depends where you are in the process.  If you are getting a 
> detailed sim report it should open to the errors part of the report.  
> If you aren't that far open the project BDL or INP files with 
> notepad.  They will list warnings and errors as they are processed.  
> The error will be at the end, there may be contributing errors 
> before.  All it really does is tell you where it kicked out, but it 
> does provide clues.  When you run your simulation make sure the boxes 
> are checked so it will run through errors and warnings.  You get 
> better hints this way.
> Bruce Easterbrook P.Eng.
> Abode Engineering
>
> On 14/06/2010 04:56 PM, Dahlstrom, Aaron wrote:
>
> Folks:
>
> I have gotten the following error several times on the same project.
>
> I have rebuilt the file from scratch already once, and I'm wondering 
> if there is another way to fix this error.
>
> Any idea if there are reports or INIs that I can view / modify to find 
> out where exactly this "invalid argument" is located?
>
> Thanks!
>
> *Aaron Dahlstrom , PE, LEED® AP*
>
> *In P**o**sse* -- A subsidiary of *AKF*| 1500 Walnut Street, Suite 
> 1414, Philadelphia, PA 19102
>
> d: 215-282-6753| m: 267-507-5470| In Posse: 215-282-6800| AKF: 
> 215-735-7290
>
> e: ADahlstrom at in-posse.com <mailto:ADahlstrom at in-posse.com> | in posse 
> web: www.in-posse.com <http://www.in-posse.com/> | akf web: 
> www.akfgroup.com <http://www.akfgroup.com/>
>
>
> This e-mail may contain information that is confidential, privileged 
> or otherwise protected from disclosure. If you are not an intended 
> recipient of this e-mail, do not duplicate or redistribute it by any 
> means. Please delete it and any attachments and notify the sender that 
> you have received it in error. Unintended recipients are prohibited 
> from taking action on the basis of information in this e-mail. E-mail 
> messages may contain computer viruses or other defects, may not be 
> accurately replicated on other systems, or may be intercepted, deleted 
> or interfered without the knowledge of the sender or the intended 
> recipient. If you are not comfortable with the risks associated with 
> e-mail messages, you may decide not to use e-mail to communicate with 
> In Posse.
>
>   
>   
> _______________________________________________
> Equest-users mailing list
> http://lists.onebuilding.org/listinfo.cgi/equest-users-onebuilding.org
> To unsubscribe from this mailing list send  a blank message toEQUEST-USERS-UNSUBSCRIBE at ONEBUILDING.ORG  <mailto:EQUEST-USERS-UNSUBSCRIBE at ONEBUILDING.ORG>
>    
>
>
> This e-mail may contain information that is confidential, privileged 
> or otherwise protected from disclosure. If you are not an intended 
> recipient of this e-mail, do not duplicate or redistribute it by any 
> means. Please delete it and any attachments and notify the sender that 
> you have received it in error. Unintended recipients are prohibited 
> from taking action on the basis of information in this e-mail. E-mail 
> messages may contain computer viruses or other defects, may not be 
> accurately replicated on other systems, or may be intercepted, deleted 
> or interfered without the knowledge of the sender or the intended 
> recipient. If you are not comfortable with the risks associated with 
> e-mail messages, you may decide not to use e-mail to communicate with 
> In Posse.
>
>
> _______________________________________________
> 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 
> <mailto:EQUEST-USERS-UNSUBSCRIBE at ONEBUILDING.ORG>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20100615/f5e2399b/attachment-0002.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/20100615/f5e2399b/attachment-0002.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 6773 bytes
Desc: not available
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20100615/f5e2399b/attachment-0002.png>


More information about the Equest-users mailing list