help with macros?

6 posts / 0 new
Last post

I'm just getting started playing around with macros, and had a quick

I current have a macro defined in my .inp file as follows:

##def GHTclassify

EL1 Bldg Occup Sch - Office


I entered this directly after the first "INPUT .." line of the .inp
file. Is this the correct place to define macros? Does it matter?

Further down when I describe a space, I have the following:

"EL1 South Perim Spc (G.S1) - Office" = SPACE




//lots of info on lighting, equipment, infiltration, etc

POLYGON = "EL1 Space Polygon 1"



The "EL1 Bldg Occup Sch - Office" is a valid annual schedule.

However, I'm getting an error that basically says GHTclassify was never

Any idea what I'm doing wrong? I thought I copied this perfectly out of
the DOE2 Topic section.

Thanks in advance!

James Hansen, PE, LEED AP

James Hansen's picture
Joined: 2011-09-30
Reputation: 200

Doug and Brian,

Thanks for your recommendations - unfortunately neither of them worked
(using ##set1 and removing quotes).

Here is the "example" directly from the DOE2 pdf:

I made a very similar macro, except defined:

##def GHTclassify


PEOPLE-SCHEDULE = "EL1 Bldg Occup Sch - Office"


And used the command line

ZONE-TYPE = GHTclassify[]

With the thought that the result should be equivalent to:


PEOPLE-SCHEDULE = "EL1 Bldg Occup Sch - Office"

Just like in the example. But unfortunately, when I open the BDL file,
it shows the translated command as:

*1502 * "EL1 South Perim Spc (G.S1) - Office" = SPACE


*1504 * ZONE-TYPE = GHTclassify[]

.1* 9 * PEOPLE-SCHEDULE = "EL1 Bldg Occup Sch -

.1* 10 *

*1505 * LIGHTING-SCHEDUL = ( "EL1 Bldg InsLt Sch" )

In other words, it's not pulling the "CONDITIONED" in to the zone-type
line as in the example, but it IS pulling in the People schedule. Makes
no sense to me!

The only thing different in my case is I don't have the ".." in the
##def because I don't want this to end the space definition.

Any thoughts?

James Hansen, PE, LEED AP

James Hansen's picture
Joined: 2011-09-30
Reputation: 200

I'm sorry to spam the board with my macro questions, but if anyone has a
spare minute, would they mind inserting this command into a test INP
file of theirs (right after the INPUT ..) line, and run it, and tell me
if it crashes eQuest?

##set1 dumb_macros "not working"

No matter what I name the macro name ("dumb_macros" in this case), and
no matter what I have as the value (text, number, etc), whenever I open
the project file from eQuest, it goes thru the entire loading of the BDL
with no errors, but then simply terminates the program without any error
messages or anything.

I've tried the ##set1, ##def, and ##def1 commands, and none seem to

I don't even have to reference the macro name in the body of the input
file for it to crash - simply defining it does that.

I've tried with v3.63 and v3.61, and it crashes in both versions.

Am I defining the macros in the wrong location?

James Hansen's picture
Joined: 2011-09-30
Reputation: 200

Just an update since the responses I received were only to me:

Apparently eQuest can't really handle macros - that was a DOE2 function
that wasn't incorporated into eQuest, even though it shows up in the
help file.

I would love to be corrected otherwise, but that was the response I get
from several people (thanks by the way!).

However, my whole purpose for wanting macros to work was to simplify
input. I suppose it's possible that I could take the .inp file created
by eQuest, run it thru the DOS-based DOE2 processor to run the macros,
and then reopen with eQuest (and repeat every time I want to process
something). Not ideal, but it might make things easier for jobs where I
have 300+ spaces.

James Hansen's picture
Joined: 2011-09-30
Reputation: 200

I am modeling a building with 2-3 floors depending on where in the building you are. Each of the floors are somewhat different so I created 3 models and stacked them on top of each other. Once I got into the detailed mode I find that the program put a roof on each floor. I had incorrectly assumed that if I put one floor on top of another, then the program would recognize that it's "roof" is adjacent to another floor and make it adiabatic while overhangs and extended roofs would keep their "roof label". Do I now need to go through and delete all the roofs from the 1st and part of the 2nd floor? Or does eQuest not take them in on the calculation because it knows that it should be adiabatic since it has a floor above it?

[cid:image003.jpg at 01CA8DDF.0E99BBE0]


jwendel's picture
Joined: 2010-10-05
Reputation: 0

Text editors are your friend. If you need to change the people schedule
for 300 spaces then just do a find/replace in a text editor. However to
really do anything remotely complicated like replacing all people
schedules (with different names per shell like eQUEST likes to create) you
need a text editor that can handle macros. I use Boxer Text Editor and
it can do some pretty impressive stuff with the macro functions.

Robby Oylear, LEEDR AP

RobbyO's picture
Joined: 2010-11-03
Reputation: 0