PHOTOCELL-CTRL Idea/Suggestion

3 posts / 0 new
Last post

Hey all!

Something new occurred to me recently triggered by a photocell
scheduling question.

To ground and set up this idea - first check out this interesting online
visual explaining how annual day/night hours vary based on latitude...
play around a bit with the bars to see how daylight hours vary based on
latitude and time of year:
http://astro.unl.edu/classaction/animations/coordsmotion/daylighthoursex
plorer.html

Note that regardless of location, the yearly average on a daily basis
always works out to 12 hours.

Now take the typical case of a simple ON/OFF photocell control for
exterior lighting. From an exterior lighting control standpoint, the
model linked above is simplified from reality in that the effects of
cloud cover/weather are not accounted for. While the sun on a given
day may officially set at 6PM, for example, overcast cloud cover, rain,
smog, fog and similar conditions may cause a photocell to turn on the
exterior lights hours earlier, by reducing the daylight illumination
reaching the photocell/ground.

Based on some explorations - the current PHOTOCELL-CTRL schedule appears
to demonstrate something like a "simplified" model per the above link,
assuming clear skies. I'm observing approximately 12 hrs of photocell
operation per day averaged over the year for different locations' TMY
weather files (slightly less, actually... ~11.95). I would assume by
extension it's using a function based on the location's latitude or
perhaps referencing something like the "sun up flag" in the weather
files. Does this jive with what anyone knows to be going on under the
hood?

If my understanding is correct, I would like to suggest a few
improvements for present discussion and future development:

1) First I think it's worthwhile to retain the "clear sky"
PHOTOCELL-CTRL function as it currently exists - I can conceive
applications where a simplified "on when the sun sets" model could be
both desirable & useful, such as in comparing output with simple
daylight simulation models. It could also perhaps be more specifically
named "ASTRONOMICAL-CTRL" in reference to mechanical/digital
astronomical timeclocks which calculate daily on/off times very much
like the animated model linked above.

2) An improved PHOTOCELL-CTRL scheduling function could be defined
working around the following:

a. It's my understanding that weather files may contain hourly
measured illuminance readings that inherently account for cloud cover
and other weather conditions.

b. Actual photocell systems will turn on and off at prescribed,
sometimes different levels. For example, here's a link to a product
which turns fixtures on at 3fc and off at 8fc, with a nominal delay to
minimize nuisance cycling: LINK
. The equipment literature I've checked cite values
from 1fc to 10fc.

c. Per the above, an improved PHOTOCELL-CTRL scheduling option
could accept inputs for one (possibly two) exterior footcandle levels to
define on/off behavior. Hourly ON/OFF behavior could then be determined
directly referencing the exterior hourly horizontal ground illuminance
measurement from the weather file used, switching lights when the
appropriate threshold is crossed.

d. Such a scheduling option could more accurately gauge the full
impact of exterior lighting retrofit and controls upgrades. This is
often relatively low-hanging fruit, in my experience.

A related query for the weather gurus: I'm uncertain whether TMY
weather files, representing averaged data over many years, would be
particularly constructive or not for representing the effects of cloud
cover and so forth... Growing up in FL, I recall a definite
"rain-season" mid-summer which I expect would be captured in the
daylight measurements of any FL weather station... but where
weather/cloud cover is much less regular (such as here in KS), perhaps
the effects would be lost in averaging?

Thoughts?

~Nick

NICK CATON, P.E.

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

Hi Nick,

Interesting findings on your part. I can offer some info regarding the
integrity of the weather files that might be useful for understanding.

My experience shows that the majority of the weather files that are still
being referenced by default in eQuest are typically a TMY file ( for the
North American locations). TMY files were the fist set of bin files
available for use with DOE-2. The data sets in these files include weather
data collected from 1952-1975. Which makes the weather info in the pretty
old by comparason to the weather phenomena that we have experienced in the
present (..at least going back to the mid 1990s.)

The next version (or updated weather data sets) are referred to as TMY2
files, and this data was collected from 1961-1990. The latest version of
data sets is referrenced as TMY3 files which was collected from 1991-2005
(note*** a consideralbly short set of data complied into bins for us --14
years compared to 29 years for TMY2 and 23 years for TMY.)

Also, when the TMY3 versions became available they were available for
hundreds more cities in North America than before. For example, the small
town that I live in (population less than 10,000) actually has a TMY3 data
set available because we have an airport here with collectable weather
data. Without the TMY3 file being available if I were to simulate the
energy usage on my house or business building I would have to reference a
TMY file for either Omaha or Denver, but either of these weather choices is
not even close to being like the weather micro-climate characteristics that
we have in our rural area. The TMY2 version of data does bring another
option for a city about 60-90 miles away from my town. This is doable,
but with the new technology and the amount of data that is available via
internet resources and a multitude of weather stations, I was delighted to
see that a TMY3 existed for such a small place 'in the middle of nowhere'
which is how we are considered by so many people/visitors to our town.

The statement to take away from this knowledge is two-fold: a) the
majority of weather files still being referrenced by default in eQuest is
mostly TMY and/or TMY2 files; and b) the older sets of weather data were
more limited on the type of climate data that was collected during the
specific time periods noted. THEREFORE; in some cases you might be
experiencing a weather file/data set that is absent of the clear-ness
factors that you might be looking for & trying to reference in your
model(s). It is also known that some weather files completely lack any
solar-type data, ground water temp data, daylighting variable factors and
such, simply due to the fact that it wasn't available in the area that
weather info was being collected for some cities.

Now recognizing that TMY-type files are only for North American locations
and more specifically USA locations, there are other types of weather files
available for other Non-USA locations. For example; the CWEC type files
are noting Canadian locations; WYEC files which is an acronym for "weather
year for energy calculations" are representative of many other
international locations, but are typically based on the collection years
anywhere between the TMY and TMY2 eras.

Once energy-plus came about in its development it was also a new
opportunity in time to reference more updated weather files especially
since we (the world) started experienencing more significant weather
phenomena in the past 20 years. The EPW weather files are data sets
collected more recently (I can't verify the time period from the DOE
website though), and this is what was stated about these sets of weather
data:

Weather data for more than 2100 locations are now available in EnergyPlus
weather format ? 1042 locations in the USA, 71 locations in Canada, and
more than 1000 locations in 100 other countries throughout the world. The
weather data are arranged by World Meteorological Organization region and
Country.

- Africa(WMO
Region 1)
- Asia(WMO
Region 2)
- South America(WMO
Region 3)
- North and Central
America(WMO
Region 4)
- Southwest Pacific(WMO
Region 5)
- Europe(WMO
Region 6)
- Antarctica(WMO
Region 7)

This is probably WAY more information than you hoped to consider, but it is
imperative to be aware of the integrity of your weather data in your
models, because sometimes we can observe interesting anomolies in our
energy models due to the lack of incorrect or missing weather information
from which we base our energy calculations on.

ALSO--on a side note, other energy modelers might be thinking----" that
doesn't seem right, when I select my location in eQuest wizard I can select
my specific city in the Wizard screens." Yes, you can select your
specific city/town in the wizard screens of eQuest, but it may actually be
referrencing a more 'regional' weather file for the largest city/airport
location near your actual project site. Don't be fooled by what you see
in the user interface, you will have to dig into files deeper to
specifically confirm the default weather file that is being used in your
models. You can do this by going into DDedit mode and clicking on your
Project Name at the top of the navigation tree and then referencing the
actual .bin file name that is being used in your energy calculations.

Don't believe everything you see in your user interfaces---always go into
DOE-2 itself to confirm what is actually being used. An additional
example of this would be using TRACE700 for Underfloor air system
simulations---I actually had a Mech Designer tell me, "TRACE can simulated
UFA systems! I can choose the system type in the program." I told them
no it can't specifically model these systems, they are applying
work-arounds and modified algorithms to "Represent" the sytem operation,
but TRACE700 and other sim programs including eQuest/DOE-2 do not
specifically stratify loads in the conditioned spaces to actually represent
these types of systems. I believe that EnergyPlus is the closest
simulation software that can most accurately represent UFA & TDV systems,
and all others are fooling us by using work-a-round strategies.

Cheers,
Pasha

Pasha Korber-Gonzalez's picture
Joined: 2011-09-30
Reputation: 600

Nick,

I just came across the same question recently, here's what I've discovered.
In my case, I was looking at the difference between using photosensors or
simply using the BAS to control exterior lighting.

This was part of a larger eQUEST project, but I also created a spreadsheet
to look at the difference between operational hours. For the BAS, we were
assuming monthly schedules, but these could actually be different by each
day. A simple algorithm can be created on an hourly basis to calculate
sunrise and sunset, but the BAS works on an hourly resolution. This means
that if sunrise is at 5:30, you'll have to leave the lights on until 6:00.
In addition, to be conservative for safety sake, we let the BAS keep the
lights on shortly through sunrise and before sunset. The spreadsheet shows
that using a photocell can reduce hours vs an average-ly programmed BAS.

In the spreadsheet, I assumed a horizontal flat plate collector surface for
the photosensor, which I believe is also what eQUEST assumes.
Consequently, there's no need to worry about cloud data or any
other miscellaneous solar data, which are only used to calculate the
irradiation on a tilted surface given the irradiation on a horizontal one.
Global horizontal radiation (diffuse plus beam) and diffuse horizontal
radiation are actually measured at the TMY3 stations. It's also important
to remember that the TMY files are not averaged data, but each month is a
"typical" month, and two of the primary parameters in determining a typical
month are global horizontal and diffuse horizontal radiation. So the solar
radiation data in TMY file should pick up regularities such as "June Gloom"
in Southern California for instance.

The major weakness in the spreadsheet is how to determine the efficacy
(Lumens/watt) of sunlight. In fact, I resorted to using 93 Lumens/Watt for
direct sunlight, which I got from Wikipedia. For the diffuse radiation, I
assumed 10% the efficacy of direct radiation. I have no idea if this is
close to valid, but I'm fairly certain that the atmosphere reflects/absorbs
visible light at a higher proportion to IR radiation. The efficacy of beam
radiation should be fairly constant, but the efficacy of the diffuse
radiation gets very complicated. In theory, it should depend on the
particulate properties of the atmosphere. At best, I think we could hope
for an efficacy model which depends on solar geometry and cloud cover.
This wouldn't be able to account for things such as smog in a dense city.

Anyway, if you were to do an hourly report in eQUEST with global horizontal
radiation and an on/off flag for the photosensor, I think you'll see that
it's simply on and off with this value. According to the spreadsheet
attachment, this misses approximately 163 hours of operation in Memphis,
which you may or may not consider significant.

Interestingly, the product that was chosen for the final design included a
photosensor/motion sensor combination. The lights were to remain off for
all hours unless it was night time and motion was detected. The lights
will remain on for 15 min after motion is detected. Now, tell me how you
would model this with hundreds of lights across a campus? I thought about
using a probability distribution to model motion detection at different
areas and finally decided that the eQUEST PHOTOCELL-CTRL is good enough!!

Aaron

--
Sent from my DynaTAC 8000x

Hey all!

Something new occurred to me recently triggered by a photocell scheduling
question.

To ground and set up this idea ? first check out this interesting online
visual explaining how annual day/night hours vary based on latitude? play
around a bit with the bars to see how daylight hours vary based on latitude
and time of year:
http://astro.unl.edu/classaction/animations/coordsmotion/daylighthoursexplorer.html
Note that regardless of location, the yearly average on a daily basis
always works out to 12 hours.

Now take the typical case of a simple ON/OFF photocell control for exterior
lighting. From an exterior lighting control standpoint, the model linked
above is simplified from reality in that the effects of cloud cover/weather
are not accounted for. While the sun on a given day may officially set at
6PM, for example, overcast cloud cover, rain, smog, fog and similar
conditions may cause a photocell to turn on the exterior lights hours
earlier, by reducing the daylight illumination reaching the
photocell/ground.

Based on some explorations ? the current PHOTOCELL-CTRL schedule appears to
demonstrate something like a ?simplified? model per the above link,
assuming clear skies. I?m observing approximately 12 hrs of photocell
operation per day averaged over the year for different locations? TMY
weather files (slightly less, actually? ~11.95). I would assume by
extension it?s using a function based on the location?s latitude or perhaps
referencing something like the ?sun up flag? in the weather files. Does
this jive with what anyone knows to be going on under the hood?

If my understanding is correct, I would like to suggest a few improvements
for present discussion and future development:
1) First I think it?s worthwhile to retain the ?clear sky?
PHOTOCELL-CTRL function as it currently exists ? I can conceive
applications where a simplified ?on when the sun sets? model could be both
desirable & useful, such as in comparing output with simple daylight
simulation models. It could also perhaps be more specifically named
?ASTRONOMICAL-CTRL? in reference to mechanical/digital astronomical
timeclocks which calculate daily on/off times very much like the animated
model linked above.
2) An improved PHOTOCELL-CTRL scheduling function could be defined
working around the following:
a. It?s my understanding that weather files may contain hourly
measured illuminance readings that inherently account for cloud cover and
other weather conditions.
b. Actual photocell systems will turn on and off at prescribed,
sometimes different levels. For example, here?s a link to a product which
turns fixtures on at 3fc and off at 8fc, with a nominal delay to minimize
nuisance cycling: LINK. The equipment literature I?ve checked cite values
from 1fc to 10fc.
c. Per the above, an improved PHOTOCELL-CTRL scheduling option could
accept inputs for one (possibly two) exterior footcandle levels to define
on/off behavior. Hourly ON/OFF behavior could then be determined directly
referencing the exterior hourly horizontal ground illuminance measurement
from the weather file used, switching lights when the appropriate threshold
is crossed.
d. Such a scheduling option could more accurately gauge the full
impact of exterior lighting retrofit and controls upgrades. This is often
relatively low-hanging fruit, in my experience.

A related query for the weather gurus: I?m uncertain whether TMY weather
files, representing averaged data over many years, would be particularly
constructive or not for representing the effects of cloud cover and so
forth? Growing up in FL, I recall a definite ?rain-season? mid-summer which
I expect would be captured in the daylight measurements of any FL weather
station? but where weather/cloud cover is much less regular (such as here
in KS), perhaps the effects would be lost in averaging?

Thoughts?

~Nick

NICK CATON, P.E.

Aaron Powers2's picture
Offline
Joined: 2011-09-30
Reputation: 0