Green Star daylight recipe

[max]

I’m doing a Green Star assessment for daylighting - specifically using their Daylight Autonomy approach. The existing LBT recipe doesn’t work for me because Green Star considers a point in space to have good daylighting if it exceeds 160lux for 80% of the nominated hours.

This means I can’t just take the DA output of the recipe, but need to do some custom data crunching on the raw lux values in post, which is inconvenient and requires extra runtime:

Would this be a case where I could embed that in a custom recipe with a GreenStar_DA output?

I would love to see that process - here is the definition with the post-processing:

unnamed.gh (45.4 KB)

[mostapha]

Thanks @Max! This is a great example. I will work on it later this week. A great case study on how to build on top of what is already available.

[devang]

This brings back memories. It would be so much fun to see a recipe do this. I spent 2 years doing exactly this for Dubai Municipality Green Building Code. I used green color for area that passes the threshold back then.

[max]

@devang in general, having a library of recipes to test all kinds of code compliance would be priceless…

[mostapha]

Hi @Max and @devang, I’m thinking to start working on this today. One question for you.

Is this fine that the results is not symmetrical for a symmetrical room facing north?

[max]

@Mostapha Yes should be ok. I think the reason is because the occupancy schedule doesn’t match the daylight hours, and probably also because it’s a yearly simulation so it may just be the case that the solar illuminance is different in the mornings as opposed to the evenings.

[mostapha]

I think I got my answer by plotting the values.

They are close to .8 and the values follow the same pattern on all the rows.

Now some recipe specific questions:

1. Do you want to keep the other outputs as part of this recipe or do we only want to get the green star outputs? I assume this recipe will not have the other outputs like DA, CDA, etc.
2. Would you output both the % and the pass/fail output or would you only be looking for pass/fail. I’m thinking to expose both of them so one can do some validation.

[max]

Yeah I was about to send this

[max]

@Mostapha regarding your other questions:

1. I think we’d want to make this one targeted for Green Star, so best not to confuse the user with the other outputs (they can use the generic recipe for that). Maybe just the raw results for debugging.
2. The threshold varies depending on building type and even space function, e.g.:

• For offices, 40% of the nominated floor area needs to be above 160lux for 80% of the “nominated hours”
• For underground train station entrances, 20% of the nominated floor area needs to be above 160lux for 80% of daylight hours
• For underground train station concourses, 20% of the nominated floor area needs to be above 80lux for 80% of daylight hours
• It’s again slightly different for overground stations, etc.

So I’m thinking, it’s probably best to only have the % as an output and force the user to apply the correct threshold in post to determine fail/pass.

Otherwise, if it’s in-built, then we would have to make a different recipe for each building/space type; or, add an input where the user specifies the building/space type.

[mostapha]

Thank you @Max! This is very helpful.

@Max

I think we’d want to make this one targeted for Green Star, so best not to confuse the user with the other outputs (they can use the generic recipe for that). Maybe just the raw results for debugging.

Agreed! Let’s keep it that way.

@Max

If it’s in-built, then we would have to make a different recipe for each building/space type, or, add an input where the user specifies the building/space type.

What if I expose the % area, illuminance threshold and % of time? Or do you think that’s so many inputs for a typical user? I’m fine with having a list of building/space types. I just need to know the list and what to do with post-processing. So far the list is:

• office
• underground train station entrance
• underground train station concourses
• overground stations - I don’t know the rules for this one

I can start with the first 3 and we take it from there.

@Max

Otherwise, if it’s in-built, then we would have to make a different recipe for each building/space type; or, add an input where the user specifies the building/space type.

I will provide the raw results for the user to play with if desired but I think we should provide the end result as a True/False for each grid for people who don’t want to bother doing the extra work - or want to keep everything on Pollination. It will still be one recipe with different space types. We should probably support a list if there will be grids with different types.

[max]

Thank you @Max! This is very helpful.

Right back at you @Mostapha!

I think the endgame would be to have the user specify the space type, and for the recipe to take care of the rest. So far I’ve only worked with offices and underground stations for Green Star so I’m not actually sure how long the list is - I will try to find out when I’m back at the office tomorrow!

In that case, the simple pass/fail output for each grid point would be sufficient (I would still include the raw results as you say). Would you also want to output a single metric saying how many Green Star points the whole building achieves? It might be too complex if it has mixed space types.

[max]

@Mostapha,

I’m fine with having a list of building/space types. I just need to know the list and what to do with post-processing.

I just asked around and it appears that the list is quite short:

• Residential (living areas vs. sleeping areas, kitchens excluded)
• Non-residential (only primary area, i.e. where people are expected to spend extended time periods)
• Overground Railway stations (entrance vs. concourse areas)
• Underground railway stations (entrance vs. concourse areas)

I will need to spend some time checking the exact metrics, unfortunately I won’t be able to do it today or tomorrow but will try ASAP. Of course if you only do part of it and share the script, I could try to add to it in future - probably an ideal exercise for learning how to create custom recipes.

[mostapha]

Thank you! Sounds like a plan. I didn’t get a chance to work on this yesterday after some work in the morning. I’ll try to get back to this today. I’ll keep you posted.

[max]

@Mostapha, here is the detailed breakdown for Green Star Daylighting assessment.

For most building types, Green Star - Design and As-Built applies (I am using v1.2 but for daylighting I believe the latest version 1.3 is identical). In this document, daylighting is discussed under Visual Comfort (Credit 12), under the sub-header Daylight (12.1):

Up to 2 points are available where a percentage of the nominated area receives high levels of daylight:

• For 40% of the nominated area – 1 point;
• For 60% of the nominated area – 2 points.

The “nominated area” in this case refers to all “primary spaces”:

Note that they allow you to pick from either of 3 methodologies to prove compliance:

• 12.1A Compliance using Manual Calculations
• 12.1B Compliance using Daylight Factor
• 12.1C Compliance using Daylight Autonomy

We are using the third option, since it is the most accurate and (at least in Australia) appears to be much easier to achieve than the Daylight Factor threshold. For the 12.1C method:

High levels of daylight are deemed to have at least 160 lux due to daylight during 80% of the nominated hours.
The “nominated hours” are to be defined by the project team.

I checked and they do not actually make a distinction between office and residential when using 12.1C (but they do for 12.1B).

---

Apart from the Design and As-Built standard, there are also Communities (for precincts), Interiors, Performance (for the operation of existing buildings), and Railway Stations.

---

The only other one that I have used is Railway Stations (v1.1). In this document, daylighting is discussed under Visual Comfort (Credit 16 in this case), under the sub-header Daylight (16.1). They allow for the same three methodologies as described above, but for the Daylight Autonomy approach (16.1C in this case) they distinguish:

Above ground stations
Up to 2 points are awarded as follows:

• 1 point is available where at least 50% of the total primary spaces (staff and patron areas) has a Daylighting Illuminance (DI) of at least 160 lux for 80% of the daylight hours.
• 1 point is available where at least 90% of the covered areas of platforms, concourses, pedestrian bridges, ramps, and star areas have a Daylight Illuminance (DI) of at least 400 lux for 80% of the daylight hours.

Underground stations
Up to 3 points are awarded as follows:

• 1 point is available where at least 20% of the total concourse area has a Daylighting Illuminance (DI) of at least 80 lux for 80% of the daylight hours.
• 1 point is available where at least 20% of the entrance areas to the station has a Daylight Illuminance (DI) of at least 160 lux for 80% of the daylight hours.
• 1 additional point is awarded if the above two criteria are fulfilled for 40% of the areas

Hope this helps!

[mostapha]

This is gold! Thank you so much for providing this information.

@Max

The “nominated hours” are to be defined by the project team.

How does one deal with this one? This should be accessible to user to change? Is this occupancy hours? Or daylight hours as referred to in the rest of the document?

[max]

@Mostapha for a lot of the credits, there is some wiggle room where you can argue your assumptions to the GBCA (e.g. you can have certain areas exempt from the analysis if you give them a good reason).

For the nominated hours, I think it is reasonable to assume occupied hours that are within the daylight hours.

As an example, for the office building that I’m currently working on, the architects weren’t able to provide me with an occupancy schedule (we’re in Reference Design stage). I looked at the National Construction Code of Australia’s template occupancy schedules, but they assume buildings to be occupied from early morning to late at night (albeit only 5 or 10% during those early and late hours). I ended up going with 9am-5pm since most would consider that “normal” working hours, and because they are always within daylight hours in Melbourne where the project is located.

Having said that, this is the first project I’ve had to do a Green Star assessment for; I’m not sure whether the GBCA will accept, however I did have a senior engineer browse through my report and she didn’t appear to find anything unreasonable.

[max]

Hi @Mostapha, I feel bad for hassling you for this but were you able to advance on the recipe? I have another Green Star project coming up where it would be really helpful!

Maybe if you give me your WIP I can finish it, in which case of course I’d be happy to share the end result.

[mostapha]

Hi @Max! It’s on me. I blocked later today and tomorrow for recipe development. You should hear back from me soon.

[max]

You’re a legend, thanks