Roof monitor "Open to Below"

9 posts / 0 new
Last post

Hello E-quest group,

I am working on ways to implement Equest in my workflow for the purpose
of daylighting design evaluation, and I am having trouble implementing a
roof monitor. I have read the help files that describe the limitations
of Equest to perform daylighting calculations, but I have also seen that
some people have been able to implement multilevel atriums and I have
seen one application of a roof monitor. Anyways I want to give it a go
before I start programming in Daylight Factors.

Attached is an example building I would like to be able to evaluate. My
evaluation goal is to put a light meter on the bottom zone under the
monitor and see what results pop out in the detailed daylighting summary
reports (LS-G, LS-J, ect.) I would like to compare Equest results to the
results of other software/calculations/measurements I am investigating,
however it seems that no light from the roof monitor is making it to the
bottom zone.

The bottom shell is all one zone and the top is all one zone. I have
found that it is necessary that the bottom zone have windows or else no
daylighting dialog screen shows up in the DD wizard, and that means no
light meter. At first I tried to make the top zone "open to below" and
then in the detailed edit mode moved the light meter under the monitor,
but the results do not indicate any light is making it from the roof
monitor to the bottom zone.

I was hoping some of you might have some suggestions to help implement
this roof monitor setup.


Aaron Smith

Smith, Aaron Matthew's picture
Joined: 2011-09-30
Reputation: 0

If you wouldn't mind sharing your model with the group, maybe we could
help better.

A starting point could be to make the monitor a part of the zone you
want to daylight so that the monitor glazing can
contribute to that zone. In your case, the monitor should be
contributing to its zone only, which is the top zone. You can verify
this by placing a
sensor in the top zone.

Umesh Atre's picture
Joined: 2011-09-30
Reputation: 0

Hello Umesh,

Attached are the project file and input file for the groups review.



Smith, Aaron Matthew's picture
Joined: 2011-09-30
Reputation: 0

Thanks Nick, this looks exactly like what I want to accomplish. I will
look up the "cutting lines" strategy and see if I can implement it.

Also thank you for sharing the images of your nice looking model.



Smith, Aaron Matthew's picture
Joined: 2011-09-30
Reputation: 0

Happy to help - I'll point out further that the important thing when
modeling varying roof heights / monitors using the "cutting method" (and
that is a term I just made up so don't search for that explicitly), to
save yourself some time, is to match vertices when defining the separate
shells. In doing so, eQuest will recognize two planes are on top of
each other and default each to be adiabatic or partially adiabatic.

This is good because on one level you won't accidentally end up with a
lot more exterior wall than you should have. On a further level, it
will save you some time later in identifying which walls need to be tied
to adjacent zones (the adiabatic walls will stand out in spreadsheet
view), if you decide you want to more accurately account for thermal
behavior between the monitor zone(s) and the surroundings by defining
"Next to Space...".

Also, flattery will get you nowhere, but thanks for the model compliment



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

I think you've identified the root of your problem - I'm unsure that
there's any way to get light in one shell to transmit to another.

Attached and below is an example of a project with a lot of roof
monitors that does successfully measure and account for daylighting in
those spaces. A picture speaks a thousand words, so see if this
matches what you were thinking to accomplish.

Each monitor is a single zone and shell (i.e. no plenum zone). Sensors
are located either on the floor or at a desk height, as appropriate to
the space usage. Creating the shell that "wraps" around the monitors is
done by using "cutting lines" in the footprint/zoning pattern - you can
read up on that strategy by searching the archives for how courtyards
are modeled.

I'll point out, in terms of accuracy, I have the impression that
eQuest's daylight sensors do not accurately realize the full amount of
light that should be encountered with light shelves, light tubes, or
other means of interreflected daylight, based on my comparative daylight
analyses using AGI32 (which I've learned to use accurately for daylight
modeling). The DOE2 help files I think also allude to this - It's
something to keep in mind if you have a lot of monitor overhangs, again
as with the example below.


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

An HTML attachment was scrubbed...

Scott Criswell2's picture
Joined: 2011-09-30
Reputation: 0

Hi All,

Does anyone know if eQUEST is planning to develop a means for modeling VRF
systems? To the best of my knowledge, only EnergyPro and recently, Trane
Trace, are able to capture the performance characteristics of these system


Jeffrey G Ross-Bain, PE, LEED

Jeff Ross-Bain2's picture
Joined: 2011-09-30
Reputation: 0

Previous posts have indicated that it?s in development, but the release forecast is to be determined. Speculation ranges from Q4 2009 to Q4 2010, so we?ll have to wait and see. The two major roadblocks I see for VRF getting into public software are:

1) Lack of a rating system for all capacities: ARI-210/240 was not expanded to rate low-capacity VRF systems until 2008, and it is my understanding that an ARI standard for larger-capacity (over 6 tons) VRF systems is still pending. I don?t see the DOE granting money for simulation development without a recognized rating system. Once one is approved, I would expect the development and testing to take the better part of a year, possibly longer.

2) Funding: the manufacturers seem willing to pay for development, but in the interest of neutrality, developers of public software seem reluctant to accept.

For what it?s worth, we recently purchased EnergyPro specifically for VRF systems, and I was fortunate enough to attend a training session at Daikin with several of their sales engineers. The word was that Daikin (and I would assume Mitsubishi) is aggressively trying to get its products incorporated into various modeling packages. In fact, it?s a major hurdle they need to overcome in order to grow their market share. The proprietary software developers have been much more receptive to working with the VRF manufacturers and accepting financial support for the development costs. Daikin has produced several libraries of performance curves for their products, so much of the legwork has been done from a data-gathering perspective. In fact, if you want to approximate a Daikin product in eQUEST, the info needed to create custom curves is readily available. I would recommend that route over purchasing proprietary software. If you?re considering EnergyPro and want a full opinion, feel free to contact me directly.



Dakota Kelley's picture
Joined: 2011-09-30
Reputation: 1