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?
[cid:image001.png at 01CB0BE2.78F66840]
Thanks!
Aaron Dahlstrom , PE, LEED(r) AP
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.
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(r) AP
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
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
I have been there more times than I like to admit. I think you may have
a geometry problem. Shells above each other normally cause more
problems than side by side. I would think you are looking for a
geometry conflict, ie shells intersecting, or bad vertices's. A 3D view
should confirm if you have an intersection problem horizontally.
Actually eQuest doesn't care if shells are spread out improperly, just
not intersecting. Make a copy and go back into the building creation
wizard, actions tab, building creation tab. This could dump a lot of
information you have input, like custom windows and locations, the
reason I never input this stuff right away or much else. You will be in
the Project Navigator. Get to page 2 of 25. Also, print a copy of your
building footprint from your cad file in the cad program. Get into the
custom foot print and start checking and itemizing major vertices's on
the footprint. Go to the zones and check as well. One other thing to
check is on screen 1 of 25, the box, "specify exact site coordinates"
must be checked and your adjacent and vertical shells must be exactly in
the correct spot. I normally start with 0,0,0. Everything has to be
correct to 2 decimal places or eQuest will not run. If a vertex is
wrong you can double click on the incorrect coordinate and eQuest will
allow you to edit it. If you have vertical shells things have to line
up vertically too. In the custom building footprint screen you will see
a tab, little book with a P on the cover in the top left corner. Click
on that and make sure your cad units correspond with the eQuest units
and the cad origin is the same as in eQuest (0,0). If that is all good
then you are "just" checking, looking for a vertex error. On a simple
model maybe 500 points, lol. Not funny when you have this problem
though, even worse when you have thousands of points. Snap in this
screen is unreliable. NEVER use snap to grid, always have this turned
off. Snap to cad first, snap to polygon second. I always do this
screen with a cad printout with vertices's marked on it and check as I
go. You would be amazed how often your snap point is incorrect. There
is no such thing as close enough in this screen. I will say it once
more, _if any point is out by .01 your model is toast!_ Any gap or
overlap in any direction in the geometry will fry eQuest. You have to
watch your Z coordinate as well going vertically. Hence Carol(e)'s anal
remark. Screens 1 and 2 are the most important screens to your sanity
and your model running! I ignore everything else in eQuest, ie all
defaults apply, until the model will run after these 2 screens. Any
other work is probably going to be wasted. Do one shell at a time, make
sure it runs and so on. Then you can proceed to the Air System Types.
Leave custom windows to the VERY last, this is a time trap. You will
have to go back to the navigator a few times, maybe many times, so there
is no point inputing anything you will lose. Good luck.
Bruce
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
Going back to the original point about the error. I have been getting the error too at my new work computer. It only happens with the wizard. I'm not sure, but I think it has to do with the way it was installed and the permissions on the computer. I'm pretty sure it's not got anything to do with the input values - it happens when I run through the wizard without touching anything.
Pasha & Bruce - I don't think you will see the errors in the inp file if it's a problem with the installation/ system that it's on.
I would be curious if anyone else has similar issues. And I would LOVE to know what the fix is.
Vikram Sami, LEED AP
I have also had the same error. I have never been able to get it fixed, but based on previous posts I believe that it may have something to do with running Equest on a 64-bit machine.
Luke
Luke,
You might be right - my old machine was 32 bit and this one is 64 bit. Is there a fix?
Vikram Sami, LEED AP
No one was ever able to help me with this one. Sorry.
Luke
I have a version running on win7, and the problem does seem to be
permissions. I didn't have exactly the error problem you all have
described, mine was eQuest or win7 asking for a password. The fix which
worked for me was to reinstall it as a single user, just me, can't
exactly remember, go into the compatibility screen and set it to run as
XP compatible. Find the equest.exe file, right click on it and the
screen will open if it doesn't come up in the installation.
Bruce
I am running on XP. I have tried reinstalling Equest and also playing around with the compatibility, but none of that helped with my errors.
Luke
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 =).
NICK CATON, E.I.T.
My two cents,
I think the 64-bit installation is a valid argument. I had to uninstall all
my programs from 64-bit because REVIT was giving me problems, MAX had some
issues, etc. They only seemed to show up every now and then. I think 64-bit
machines have a 32-bit emulator but that is still an emulator. I would make
a suggestion that no one uses 64-bit until it's been on the market a little
longer. Programmers still have to update all their code to allow for a
64-bit interface, IE:- lots of man hours and money. There are 64-bit patches
but I would still wait. Give it another year or 2, unless you are an IT
person and you're using it for networking or video games. The gaming
industry is always a step ahead because it is a large market and typically
drives the graphic interfaces. Also remember that the game and movie
developers have 64-bit machines that cost around $54,000 for their base
machine.
I had the permissions error with MAX.
REVIT had graphics card interface error.
I now run 32-bit and have no issues with my software.
Thanks,
PETER HILLERMANN
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