I am testing Diva4 components, especially sDA&ASE output. And I notice some abnormal results when I rotate my testing space/window towards the range from East (90 degree) to South (180 degree). Within this range, sDA&ASE are sort of underestimated. But if I rotate the space to other orientations beyond this range, the results look reasonable to me. I've attached test files for your verification. I also run Diva4 in Rhino to double-check and notice the results generated within Rhino are reasonable.  

I'd also like to know, in Grasshopper, how I can trigger sDA Conceptual shading control. 

Views: 1305

Attachments:

Reply to This

Replies to This Discussion

Hi Cheney,

The Grasshopper components do not use conceptual shading -- but rather an actual mechoshade-type surface just inside the window.

The reason your sDA numbers are low in the SE orientation is that shade is closed most of the time.  This is somewhat inevitable given Vancouver's sun path and the tall window head height (4.7 m!).  As for ASE, it's normal for that to be low... it just means the shade is doing its job.

You're also on the "Lowest" quality setting (-ab 1), which gives not-so-realistic results (switching to the "Low" setting increases sDA in your example from 18 to 31%).

To convince yourself of the results (or not!), try setting the Grid Viewer preview to Illuminance (scrub hourly data).  This lets you slide hour by hour through the year, showing when the shade is down.  The data look reasonable to me...

(As an aside, you should not set the Rh input to true, since you are already bringing the geometry in through Grasshopper.  I don't think this affected your results, however.)

Jon

Hi Jon, 

Awesome, I reduced my window/room size and notice the changes. Thanks a lot for your help! 

Best Regards, 

Cheney 

Jon Sargent said:

Hi Cheney,

The Grasshopper components do not use conceptual shading -- but rather an actual mechoshade-type surface just inside the window.

The reason your sDA numbers are low in the SE orientation is that shade is closed most of the time.  This is somewhat inevitable given Vancouver's sun path and the tall window head height (4.7 m!).  As for ASE, it's normal for that to be low... it just means the shade is doing its job.

You're also on the "Lowest" quality setting (-ab 1), which gives not-so-realistic results (switching to the "Low" setting increases sDA in your example from 18 to 31%).

To convince yourself of the results (or not!), try setting the Grid Viewer preview to Illuminance (scrub hourly data).  This lets you slide hour by hour through the year, showing when the shade is down.  The data look reasonable to me...

Hi Jon,

Just a note here, but ASE should always be the unshaded ASE and not account for dynamic shades.

Alstan

Alstan is right about this -- ASE should ignore the dynamic shade, so those ASE values should be higher (and remain unaffected by the shading schedule).  The correction is reflected in the latest DIVA auto-update (v4.0.2.11).

Jon

Hi Alstan and Jon, 

I am developing an early stage tool in which octopus is used to optimize room depth, shades dimensions, etc. in order to achieve both sDA>55% (or 75%) and ASE<10%. I am doing it orientation by orientation so that I am able to understand, with current window dimensions, how deep the daylight can be introduced without too much direct sunlight at each every orientation.

From your experience, is it easy to fulfill LEED v4 requirement, I mean both sDA and ASE? Is there any successful design can prove it? Until now, I have not seen a successful case and my concern is the current sDA and ASE requirements they are contradicting each other and make it impossible to achieve both. Your thoughts will be greatly appreciated.

Regards, Cheney     



Jon Sargent said:

Alstan is right about this -- ASE should ignore the dynamic shade, so those ASE values should be higher (and remain unaffected by the shading schedule).  The correction is reflected in the latest DIVA auto-update (v4.0.2.11).

Jon

Hi Jon, 

So I update DIVA4 to 4.0.2.11 and notice the window shading schedule has been ignored by ASE calculation. However, I am not sure whether the shading schedule has also been ignored by sDA calculation in this manner. I notice my window is always 100% exposed without any internal shading. Please clarify. Many thanks! Cheney   

Jon Sargent said:

Alstan is right about this -- ASE should ignore the dynamic shade, so those ASE values should be higher (and remain unaffected by the shading schedule).  The correction is reflected in the latest DIVA auto-update (v4.0.2.11).

Jon

Hi Cheney,

The ASE calculation doesn't affect the window schedules.  E.g., with the model you originally posted, I get this:

It looks like your new definition actually has multiple windows.  Check that you can see shading sensors on your grid, that you haven't turned off the shade on the Window component, and that you actually expect the shade to be active based on the sensor locations, window orientation, and static shading objects.

Jon

Achieving LEED v4 daylighting credits can be quite difficult.  You typically need a deep static shading system (louvers, light shelves, thick punched openings, etc.) to minimize direct sun penetration and keep ASE below 10%.  And once you've done this, you may find your sDA value is below the 55 or 75% target.  Keep in mind, however, that the lower Quality settings systematically underestimate reflected light.

For instance, taking the example file 02_AnnualDaylight_B_OpenOfficeWithShading.gh (in C:\DIVA\ExampleFiles\Grasshopper\Daylight), I added horizontal louvers on the S, E, and W facades to block direct sun  (0.8 m depth, 0.5 m spacing).  The louvers brought ASE down to 8.7%.  On the "Lowest" quality preset, which only accounts for a single ambient bouce (-ab 1), I got an sDA of 24.4%; but on the "Medium" setting (-ab 4), sDA shot up to 89.4%.  You need at least four bounces -- and probably more -- to properly account for light reflected through a shading system and deep into a floor plate.  

"Lowest" (-ab 1): rays can't escape!

"Medium" (-ab 4): Much better

I should note that this model is unrealistic for other reasons (an open floor with no interior partitions or furniture?), but you get the idea -- the Radiance parameters matter.  Of course, you pay a heavy price in simulation time.  At 60cm sensor spacing (the max allowable under LM-83), the Medium run above took 10 hours to complete :/.

Jon

It's also important to remember that sDA often has a discontinuous relationship  

Cheney said:

Hi Alstan and Jon, 

I am developing an early stage tool in which octopus is used to optimize room depth, shades dimensions, etc. in order to achieve both sDA>55% (or 75%) and ASE<10%. I am doing it orientation by orientation so that I am able to understand, with current window dimensions, how deep the daylight can be introduced without too much direct sunlight at each every orientation.

From your experience, is it easy to fulfill LEED v4 requirement, I mean both sDA and ASE? Is there any successful design can prove it? Until now, I have not seen a successful case and my concern is the current sDA and ASE requirements they are contradicting each other and make it impossible to achieve both. Your thoughts will be greatly appreciated.

Regards, Cheney     



Jon Sargent said:

Alstan is right about this -- ASE should ignore the dynamic shade, so those ASE values should be higher (and remain unaffected by the shading schedule).  The correction is reflected in the latest DIVA auto-update (v4.0.2.11).

Jon

Hi Jon, 

Thanks a lot! Would you mind elaborating a little more about how to make sure the right shading sensors on the grid? I guess certain parameters should be defined within the window component? I'd also like to check with you, as per LM-83, whether I am allowed to use Automated shades option rather than manual one for my sDA calculation? And I believe Automated shades is independent of the location of shading sensors on the grid? I notice I can get better sDA (without shading the window too often) by triggering automated shades. Regards, Cheney 

  

Jon Sargent said:

Hi Cheney,

The ASE calculation doesn't affect the window schedules.  E.g., with the model you originally posted, I get this:

It looks like your new definition actually has multiple windows.  Check that you can see shading sensors on your grid, that you haven't turned off the shade on the Window component, and that you actually expect the shade to be active based on the sensor locations, window orientation, and static shading objects.

Jon

Hi Jon, 

Actually I do not quite understand the shading schedule map generated from the sample DIVA4 project: 

1. By using manual shades, the shades mostly closed at daytime and night time but totally open from Apr to Aug? Is it because the low sun in winter and higher sun in summer (south orientation)? I understand manual control means when someone sitting near to the window has potential glare issue and trigger manual shades, it will not be open again for the rest time of the day until next morning? But how can I interpret the shades will never be closed during shoulder and summer months below? 

2. By Auto, it makes more sense. Nighttime will be open, daytime will be closed when get direct sunlight

 I guess my question is, under what circumstance, we have to use manual control? For your sample sDA/ASE simulaiton with overhangs, does it trigger manual shades in the calculation and still be able to achieve  sDA=89.4%?  

Automated shades are allowable under LM-83, but only if they are specified in the design or construction documents.  In this case, technically, you'd also need to use the manufacturer's blind control protocol when eventually applying for the credit.  But yes, mechanical blinds are a legitimate way to increase sDA -- and a good strategy(!) if you can get your client to pay for them :)

Reply to Discussion

RSS

© 2019   Created by jeff niemasz.   Powered by

Badges  |  Report an Issue  |  Terms of Service