Question about modeling electrochromic glazing for SDA + ASE analysis

How would one go about modeling electrochromic glazing in a LEED v4 option 1 (SDA + ASE) simulation? Is this even possible?

Tags: daylightcredit, dynamic, electrochromic, leed

Views: 386

Reply to This

Replies to This Discussion

Hi Fabian,

There is a (completely undocumented) GH-only workflow for this, which involves creating an "electrochromic" material as an assembly of other glass materials (one per tint state).  The material must be assigned to a Window, not a Scene Object.  The list order must be clearest to darkest, and the lines should remain commented, to prevent other softwares -- including the Rhino toolbar -- from confusing it for a native Radiance declaration:

    void glass EC_Tint_58 0 0 3 0.632 0.632 0.632

    void glass EC_Tint_40 0 0 3 0.436 0.436 0.436

    void glass EC_Tint_10 0 0 3 0.109 0.109 0.109

    void glass EC_Tint_01 0 0 3 0.011 0.011 0.011

    # # EC glazing system tinted 58/40/10/1%
    # # custom dynamic material for DIVA for Grasshopper v4
    # # leave all lines commented (#)
    # void electrochromic EC_System_58_40_10_01
    # 4
    # EC_Tint_58
    # EC_Tint_40
    # EC_Tint_10
    # EC_Tint_01

When conducting an Annual Daylight run, DIVA will look for the clearest tint state that keeps direct normal irradiance below 50 W/m2 at the relevant sensor(s).  Otherwise the control options work the same as for shades (manual vs. auto).  sDA is reported for whatever control system you choose, while ASE is reported for the clearest state only.

Jon

Thank you Jon

Hi Jon,

I used this method yesterday and am getting confusing results as it seems there is no daylight over 300 lux in the space. Is there a way to create a schedule of when the glass is in different states?

Best,

Elliot

Yup, schedules can be grabbed from the Window Viewer, per usual.

(Schedule PNGs are also deposited in your run folder automatically.)

That is what I originally tried, but I wanted to check since the schedule outputted appears to be only the blue background. On further inspection, it looks like some of the sensors are located on top of the glass (some are inside the glass, I did not adjust the default). I am going to try adjusting the sensor locations and window groups and rerun. Perhaps it was just defaulting to the darkest color, unless you have any other thoughts.

 

The light blue is the clearest state, so that's a never-tinted schedule.  This suggests the sensor never gets direct sunlight in the auto sensor's field of view.  (Or that the clearest state is really dark, which I assume is not the case.)

As for sensor positioning, for EC glazing the sensors should be inside the glass (otherwise the sensor won't be able to tell the states apart).

Yeah then something is wrong because the results show no daylight in the area behind the glass, yet it seems from the schedule that it is never tinted. Here is my material definition, which I altered from yours to reflect the states of the Sage glass that is my basis of design: 

void glass EC_Tint_60 0 0 3 0.654 0.654 0.654
void glass EC_Tint_18 0 0 3 0.196 0.196 0.196
void glass EC_Tint_06 0 0 3 0.065 0.065 0.065
void glass EC_Tint_01 0 0 3 0.011 0.011 0.011
# # EC glazing system tinted 60/18/06/1%
# # custom dynamic material for DIVA for Grasshopper v4
# # leave all lines commented (#)
# void electrochromic EC_System_60_18_06_01
# 4
# EC_Tint_60
# EC_Tint_18
# EC_Tint_06
# EC_Tint_01

Additionally, adjusting the sensor offset parameter affects some of the sensor positions but not the ones that are for some reason outside of the glass:

> the results show no daylight in the area behind the glass, yet it seems from the schedule that it is never tinted

Well, both those observations are consistent with your sensors not getting any direct sun :).  I believe you'd get the same result for any old Tvis_60 window with an auto shade.

Yes, but that is very curious as this was run on a model where we previously did have autoshades and that results showed daylight behind the glass as expected. When I parse the hourly illumination values of this run, all the sensors always show 0 lux as if it were opaque. That is why I was wondering if you saw anything wrong with my altered material definition.

I will investigate the model further to see if there are any other reasons to explain the lack of daylight, but the issue of the sensors on some of the glass surfaces autogenerating on the exterior and not moving with the others when I adjust the offset parameter is extremely troubling. Any ideas what could be causing that?

Hmm, looks okay to me.  If you want to send over some geometry (and your material.rad) I can see what's up.  Sounds like auto sensor placement might be a little buggy -- though this doesn't explain the 0-lux results.

Reply to Discussion

RSS

© 2019   Created by jeff niemasz.   Powered by

Badges  |  Report an Issue  |  Terms of Service