Grasshopper

algorithmic modeling for Rhino

I was just experimenting with the Set EP Zone Thresholds component and found that the Daylight Threshold input overrides the lighting power rather than setting a daylight threshold.  Screenshots of the HB component and associated IDF:

Views: 775

Replies are closed for this discussion.

Replies to This Discussion

This question definitely seems to be one for Mostapha.  I know that he put that daylightThreshold_ input there but I never asked him what exactly it was meant to do.  I imagine that it is probably not supposed to override the lighting power like that.  Burin, do you know of a place in the IDF where such a daylightThreshold should go?  If so, I can probably change it to do that.

-Chris

EnergyPlus has a daylighting engine.  It's not as accurate as Radiance, but it's much faster.  I would guess that the Daylight Threshold should be connected to daylight dimming of the electric lighting load.  The simplest way to do this is with the DAYLIGHTING:CONTROLS class.  You can find the description of it on page 391 of the I/O Reference.  I'm copying the variables for this class below for your reference.  It really only requires a minimum of two inputs from the user: a point (x,y,z) where the daylight sensor should be placed and the illuminance threshold.

Hope this helps...

!- =========== ALL OBJECTS IN CLASS: DAYLIGHTING:CONTROLS ===========

Daylighting:Controls,
Zone 1, !- Zone Name
1, !- Total Daylighting Reference Points
0.441765, !- X-Coordinate of First Reference Point {m}
5.133972, !- Y-Coordinate of First Reference Point {m}
0.762000, !- Z-Coordinate of First Reference Point {m}
, !- X-Coordinate of Second Reference Point {m}
, !- Y-Coordinate of Second Reference Point {m}
, !- Z-Coordinate of Second Reference Point {m}
1.0, !- Fraction of Zone Controlled by First Reference Point
0.0, !- Fraction of Zone Controlled by Second Reference Point
300, !- Illuminance Setpoint at First Reference Point {lux}
, !- Illuminance Setpoint at Second Reference Point {lux}
1, !- Lighting Control Type
0.0, !- Glare Calculation Azimuth Angle of View Direction Clockwise from Zone y-Axis {deg}
22.0, !- Maximum Allowable Discomfort Glare Index
0.3, !- Minimum Input Power Fraction for Continuous Dimming Control
0.2, !- Minimum Light Output Fraction for Continuous Dimming Control
1, !- Number of Stepped Control Steps
1.0; !- Probability Lighting will be Reset When Needed in Manual Stepped Control

Hi,

I agree that there is some confussion with this definition and how E+ allows light load definitions. In the Light section there is an option Design Level Calculation Method where you can define loads per area, Light level and more. The Light level is the sum of Watts of the lights in the zone (crazy way of defining things, but possible). So Mostapha's interpretation of the component input is to define the lights with this "crazy" way, instead of using it as a light desired level.

Burin is right in showing the Object Class needed, but i'm afraid it overlaps in some amount with this discussion (shading controls)... which seems difficult to implement right now. I'm willing to work with you Chris on the workflow and maybe even more.

-A.

Ok. I finally managed to get to this discussion. :) That's my mistake. Burin is right and I added the threshold to set illuminance setpoints for daylight controls assuming I will implement it before the release but I never get the chance to do it (https://github.com/mostaphaRoudsari/Honeybee/issues/118)

Overwriting the value for LPD was a bug. For now I removed the input form the component (https://github.com/mostaphaRoudsari/Honeybee/commit/ad8e31b342058fb...) and I will add it back once we have daylight control object.

Cheers,

Mostapha

RSS

About

Translate

Search

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service