I have several questions regarding the daylight and light simulation, and I hope you could help.

- Is there a way to set up a custom Lighting Control System? In the grid component I can set several behaviors and that is fantastic, but in the case I am working I have a private house of 2 people. What I need is that the behavior takes into consideration that the lights are off, say, from 22 to 6. What I did was to set up a LCS (Manual On Off Switch) and then I modified the output and create a custom schedule (see picture 1). This schedule I can use it with archsim, but is it possible to use it in the grid component as a light control system?

- In the case I have a canopy or tent that is being used  just for the summer, how can I translate this into Radiance/Daysim? The idea is that the canopy is set up for just 3-4 months on the house terrace. Is it possible to set up something like this for the daylight simulation? In archsim I can apply a schedule to an object, but I cannot do it for the daylight/light.

- in diva4rhino I could set up 2 or more shadings for a window. Is it possible in grasshopper? Also in diva4rhino I could just pick up the sensors I want from the grid, but it seems not in grasshopper. Is there a way to do this?

Thanks very much,


Views: 683


Reply to This

Replies to This Discussion

Hi Federico,

1) The function of the Annual Daylight component is, among other things, to calculate lighting schedules based on occupancy and available daylight.  If you know the lighting schedule a priori, there's no need to include it in the annual daylight run.  Simply pass the schedule to Archsim, as you are doing.

2) For dynamic geometry, you'll need to run each state separately, and then merge the hourly results after the fact using your schedule.  (Unlike EnergyPlus, Radiance and Daysim do not perform serial timestep calculations.  Each geometric state requires a completely separate raytrace.)

3) Only one shade state per window in GH at the moment.  For automated shades, you can put sensors wherever you want (using the Window component's (hidden) sensor override input).  For manual shades, you have to use the 'region of influence' parameters, as described in example file 02_AnnualDaylight_C_WindowsAndShades.gh.  (C:\DIVA\ExampleFiles\Grasshopper\Daylight\)


Hi Jon,

thanks very much for the help.

I have some follow up comments though, and I hope you still can help me with these:

2) I tried the system you suggested, but I could not really get how to do it.

I did like in the picture I attached, but it is just for one sensor and with the result I get, I cannot feed it into, say, the grid component to have the DA values calculated, am I right?

3) Ok for one shade per window, thanks for the info.

Regarding the sensors, I used a simple model and check the behaviors.

What I found is that the "region of influence" method and the "Sensor override" one, work beautifully with manual shades.

For automated shades no one of the methods is working at all.

Thanks very much,




2) This is true -- you'll have to calculate DA on your own.  I suppose some sort of grid merging component would be helpful here.

3) Sensor override should work for auto shades.  If you post a non-functioning example I can take a look...


Hi Jon,

thanks again for the help.

2) Ok, I will try to see how to do it. thanks

3) I have uploaded the test file I am working on. A part of the problem of the automated shades, I cannot set up vertical sensors for the shades. It seems like the shades are working just with horizontal sensors. For avoiding glare, I was trying to set up the sensors on the walls. I also include these sensors' set up in the file.

Thanks so much for all the help.




Ah, I understand the confusion now.  For automated shades, you should use the sensor override on the Window component, not the Grid.  Grid sensors are only for manual control mode, the idea being that they represent people -- or work plane regions where people may be sitting.  In auto control mode, Window sensors are used instead.  These represent physical sensors tied to a Window's mechanical shade.


Hi Jon,

it makes sense. thanks again for the explanation. I will check it out.

What about this problem I am still having: with manual shades, with sensors override on the grid component, it does not work if I set up the sensors on a vertical plane (you can check it on the file I uploaded). can you tell why?



Oh, I thought you were asking about automated shades.  What do you mean by 'does not work' in manual mode?  Your definition runs okay on my end, though I notice two issues:

1) Sensors are coincident with wall.  This means test rays may not see the sun, producing an always-off shade schedule.  Try offsetting them a cm or so.

2) Occupancy schedule is always-on.  This won't work for generating manual shade schedules.  The algorithm raises the blinds only when the occupant re-enters the room, which never happens if the occupant never leaves.  The result will tend to be an always-on shade schedule.  In the next revision, I will force a once-daily manual blinds reset to prevent this, but in the meantime stick to schedules with at least a 1-hr off period.  


Reply to Discussion


© 2019   Created by jeff niemasz.   Powered by

Badges  |  Report an Issue  |  Terms of Service