I'm working through a daylight study to set the early concept / massing for a natatorium.  As part of this, I'm looking at both daylight autonomy (at 50fc) and the amount that the lights will be off for the occupied time (7 am to 9 pm M - F).  Because the project is in such an early stage of design, we don't want to compare lighting energy usage yet.

 

I've run into a discrepancy that I'm not sure is wrong, but doesn't seem quite right.  Basically, the example I'll show is a box that is 100' x 110' oriented so it is elongated along the E - W axis.  It has two windows, one on the south and one on the north, with some shading devices on the south, and a large grove of trees about 110' tall to the south, so there is no direct sunlight coming in the south window.

 

I've run daylight autonomy, and the mean for the space is 25%. (image 1).

 

I set up a lighting schedule - continuous dimming with occupancy on / off @ 537 lux (image 2).  This resulted in the schedule (image 3). I then went through the CSV file and summed the column "lighting [0=off...1=full on]" and divided it by the sum of the occupied hours to get the percent of occupied hours that the lights are on (41%).  This means the lights are off 59% of the occupied time.

 

This jump from a DA 50fc of 20% (at the lighting sensor nodes) to lights being off 59% of the occupied time, seems like a large jump, though I don't think it is incorrect - the average continuous daylight autonomy for the space is 55%. 

 

Essentially, I have two questions:

 1.) Is the workflow to get to the metric: % of occupied time the lights are off valid?  Or is there something incorrect with the assumptions I am supplying in the lighting control group input?

 2.) Are there plans to implement a lighting control group with stepped dimming?  The continuous dimming control group seems like it will always be way beyond what is achievable in projects.  Also, specifying the manual on/off switch lighting control was not feasible for this project because it is set up for an office space and turns off lighting at around 250 lx. (Aside: the link to the Lightswitch Study is broken).

 

Thanks for your thoughts!

 

Jeffrey

Tags: autonomy, control, daylight, lighting

Views: 839

Attachments:

Reply to This

Replies to This Discussion

Hi Jeff,

First, thanks for the detailed description of the problem and the images to support your query!

 1.) Is the workflow to get to the metric: % of occupied time the lights are off valid? Or is there something incorrect with the assumptions I am supplying in the lighting control group input?

Your workflow seems perfectly sound. The one thing you have to consider is that with the dimming sensor you are using, your lights are not just on or off, but they float in between. Daylight Autonomy only counts the hours when the lighting levels are completely above 50 fc. In this case, using Continuous Daylight Autonomy to make the comparison - as you suggest - makes a lot of sense. In your parsing of the CSV file, you could always take the ceiling of each value (0 if the lights are completely off, 1 if they are dimmed), and I suspect you will get a number closer to your daylight autonomy percentage.

 2.) Are there plans to implement a lighting control group with stepped dimming? The continuous dimming control group seems like it will always be way beyond what is achievable in projects. Also, specifying the manual on/off switch lighting control was not feasible for this project because it is set up for an office space and turns off lighting at around 250 lx. (Aside: the link to the Lightswitch Study is broken).

Thanks for pointing out the broken link. I fixed it, and you can read the study here if you'd like. Manual on/off is indeed lacking because its based on observed human behavior in a rather 'green' office building, and you can't specify the lighting requirement. 

As for stepped dimming, I'd like to see it as well. If DAYSIM ever supports it, we will definitely add it to DIVA. 

Best,
Alstan

Thanks Alstan!

Reply to Discussion

RSS

© 2020   Created by jeff niemasz.   Powered by

Badges  |  Report an Issue  |  Terms of Service