Dear all,
I am pasting here the following,
that i copied from a previous post that found no popularity before:
Hi there, i think this is serious, or i am seriously wrong:
I connect the AnalysisPeriod to the occupancyGenerator to create a Daysim occupancy csv, to be used for annual analysis, in my case daylight autonomy results reading.
When i input from 9:00 to 17:00 (fromHour = 9 and toHour =17), the occupancy csv created is actually from 8:00 to 17:00. The occupancyGenerator default hourly schedule is also set to create a “from 9:00 to 17:00” schedule, but creates a csv with occupancy from 8:00 to 17:00.
This means that there is always an extra hour added in the beginning of the hourly period for each day. 9:00 to 17:00 should be 8 hours, but the csv created has 9 hours as occupied per day.
Can somebody check that too? Its either the AnalysisPeriod or the occupancyGenerator or their combination or i am wrong somewhere.
screenshot of created daysim csv : (Notice how the occupancy is set to 1 in excel row 34, for the hour 8,5. This 8.5 stands for 8:00 to 9:00 i believe.
Hi @IasonBournas,
The minimum unit of time that Daysim accepts for occupancy duration is 15 mins. So 8.5 is 8:30 am and 17.5 is 5:30 pm. That maintains the occupied hours you wish to consider I believe.
thank you for your reply.
It is my understanding though, that Daysim yields hourly illuminances,
thus the 8760 occupancy values (0 or 1) in the occupancy csv and thus the 8760 illuminances (for each sensor) in the ill file. Illuminances for points-in-time like 8:30 or 17:52 are calculated based on interpolation between representative solar positions as per the daylight coefficients. The issue i mentioned is different:
In this post i uploaded an example for the timespan from 9:00 until 18:00 (fromHour = 9 and toHour =18)
This timespan would have to be 9 hours in duration (see attached image below). But in the csv i previously attached it seems to be 10 hours, the extra hour being added in the beginning of the timespan i believe.
Yes. Your assumptions are right. Daysim dose all the calculations for the average position between start and end of a time-step: Here is why.
This is an issue in the occupancy generator and should be fixed.
For the default schedule since people take one hour off at noon the schedule should start at 8 and end at 17 with one hour off at noon. That way they will work for 8 hours total.
Thank you for reporting this and sorry that nobody replied to the original question. Analysis period was one of the bad choices that I made originally. In the [+] plugins we’re using hours of the year instead which is easy to read and debug.
After doing so, the Occupancy_Generator component still says JUL_28_2017. Is that correct?
[EDIT]
Nevermind, I guess. Exiting Rhino and restarting puts that at JAN_04_2018.
I had originally put the components in a sub-dir of AppData\Roaming\Grasshopper\UserObjects to try and keep things in that directory “tidy” but this process put everything in that root directory. Starting Grasshopper after that throws up a few hundred complains about identical files… Any chance of making the update process smart enough to find the original directory?
We can do that and it’s not that complicated but do you agree that it’s not really a high priority at this point? Opening an issue will help us not to forget about this. I also suspect that we already have an open issue for this request.
