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
Comments
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: 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. |
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 |
Here's the way to do it with native grasshopper components and the Honeybee Occupancy schedule component: Example fie is here: |
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. |
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 😄 |
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.
The text was updated successfully, but these errors were encountered: