Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implementation of new daylight metric in accordance with European standard #237

Open
TobySkov opened this issue Jul 16, 2018 · 6 comments
Open

Comments

@TobySkov
Copy link

TobySkov commented Jul 16, 2018

Leading up to the Danish ladybug tools workshop there is a very relevant daylight metric that could be nice to implement:

The new European standard prEN 17037 prescribes a new metric for documenting sufficient amounts of daylight in buildings. The metric (with no official name) is very similar to sDA only deviating by looking at "daylight hours" instead of occupancy hours.
Daylight hours are defined as the 4380 hours of the year with the most diffuse horizontal illuminance.

This new metric has been implemented in the new danish building regulation, allowing for the first time in history, the use of CBDM to document sufficient amounts of daylight (as opposed to previous days with WFR and DF only). However the problem is that no "easy to use" software can compute this metric.
In relation to my recently completed thesis I wrote a cPython script computing the metric from HB+ results and I am very happy to contribute making it available as default in HB+. This would greatly benefit architectural and enginnering companies in Denmark and possibly in Europe when prEN 17037 starts being implemented more places.

@TobySkov
Copy link
Author

So far I have a somewhat temporary solution for grasshopper, that can be used for the danish workshop and that displays the workflow:
workflow

workflow2

schedule

@chriswmackey
Copy link
Member

@TobySkov ,

The grasshopper plugin is generally in need of a "values to schedule" component, which is essentially all that is needed to make your workflow complete. I'll add this to the Grasshopper plugin before the Denmark workshop assuming it's ok with the other devs:
ladybug-tools/honeybee-grasshopper#20

I am going to close out this issue here as it's not really a feature that is needed on the honeybee core and it belongs under the GH plugin repo.

I would also say that you don't necessarily need a python component to generate that list of 0's and 1's (you can use the native GH "smallerthan" components to make it) but that is one way to do it.

@TobySkov
Copy link
Author

TobySkov commented Jul 18, 2018

@chriswmackey

Yes you are right that the above is lacking a component to create the schedule (assumed initially that the sDA component could read the binary list) and nice that there is already a component for it!

I don't see the "smallerthan" component doing the job since selecting the highest 4380 values will have different cutoffs depending on the .epw file.

Was suggested by Mostapha to post this here when signing up for the workshop, likely to discuss a more integrated approach

@chriswmackey
Copy link
Member

@TobySkov ,

Here's the way to do it with native grasshopper components and the Honeybee Occupancy schedule component:
image

Example fie is here:
https://drive.google.com/open?id=1uqr7feIv34UsUHSpveknyyekVSijwVzw

@mostaphaRoudsari
Copy link
Member

Selecting the highest n values from a list and returning the values and indexes can be implemented as a method to DataCollection class. I can see other use cases for this approach. I'm going to Reopen this issue to add it to DataCollection at some point.

@AntoineDao
Copy link
Member

It seems like the datacollection issue has been resolved. I'm assuming this issue has not been resolved however so I'll leave it open and add it to Hacktoberfest for those keen to get their hands dirty with daylight metrics 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Development

No branches or pull requests

4 participants