Standard File writing error

4 posts / 0 new
Last post

When I try to simulate building performance in version 3.64, I get "Error:
1 standard file writing errors occurred".

How do I go about getting around this problem? There should be no reason I
can think of that the program can't write to disk.

This does not happen if I start a new project, accept all the defaults, and
simulate it, as a simple test.

The project in question was opened from a thumb drive, and then "save as"
to the hard drive. Is there some other secret component that has to be
copied to make this work?

I'm running windows 7 if that makes any difference.

lawrence Lile's picture
Joined: 2011-09-30
Reputation: 0

In my experience this is a message about writing to the BDL file, after
eQuest reads the .inp file. It is possible to create an .inp file that has
logical errors, such as a system with no thermal zone or a thermal zone with
no system. But when eQuest tries to process this input and write a BDL file,
the logical errors will stop the process, and that error message will be

Usually you can see the cause of the error in the "ATTN Simulation Messages
For Review" report in the .sim file or by clicking Tools > Check Building

Sometimes the way to find the error is to open the .BDL file with a text
editor and search for the word "error".

Hope this helps,

Rob Rosen, LEED AP BD+C

Rob Rosen's picture
Joined: 2011-09-30
Reputation: 0

Hi eQuesters,

I have about 20,000sf studio space near Los Angeles, CA with huge roll up metal door (15x20ft) that goes up/down on unknown schedule (a lot, year round).
PSZ is 100%OA, no return due to noise issues/request by client.

I'm trying to simulate the energy savings of putting a time switch on the metal door so if the door is up for more than 2 min, the AC would turn off.
How would one approach to simulate savings via eQuest? Anyone worked on similar task please share your thoughts.


Nikola Kravik3's picture
Joined: 2011-11-12
Reputation: 0

I'll toss an idea into the ring:

Your controls as described ultimately affect the amount of hours the
system is "on."

If you can first estimate an annual factor that differentiates how much
"on" time is clipped off as a result of this measure, you could clip a
corresponding number of "on" hours from your system fan schedule.
Consider the effects of your night setback settings and tstat schedules,
and modify if/as necessary.

This sort of measure can cause/justify a certain quantity of unmet hours
as the system is made to "catch up" once the doors close again.

You may already be on top of this, but I'd expect both runs to have
infiltration scheduling defined in coordination with the time you
considering as "door open" and the above scheduling edits.

Haven't done this study myself - but there's my initial brainstorm!



Nick-Caton's picture
Joined: 2011-09-30
Reputation: 805