Currently I am trying to model my space with two shading groups with 2 shading states in each of them. However, the daysim annual simulation would not run possibly due to a bug in the .hea file.
the following is the shading control part of my .hea file generated from honeybee. I believe the 1 underneath represents the number of the states I input. When I switch both of the “1” within the .hea. The batch files would start the process but there is another bug for the gen_gdp_profile. It was having problem with .oct that it is looking for outside_daysim.rad which is not exist in the tmp within the folder.
I am still running the gen_dc and I will update it over if I encounter any error after editing the .hea file.
The attached are my files. I have hear heard something from Sarith as well. I believe it would be nice to have three-phase in the future but in the meantime I would prefer to stay with Daysim since my thesis project is due within a month.
I will fix it in the code soon but this can help you go forward with Daysim files itself. I’m not sure how results reader would work in this case. Not sure if I have ever used them with 2 shading groups.
I would say it’s not fine. You can check the source code and see why is it happening. I’m personally very careful in using Daysim’s annual glare analysis as I have seen the results are very different from the point in time analysis.
I couldnt reply on your latest one. Since my simulation is still running, I could not really go in depth to check it but I still see the outside_daysim.rad in the .oct file. Is this supposed to be there.
If it is unreliable, I would look into a different method to perform an annual glare analysis.
I agree with Mostapha. The Daysim glare calcs are not very reliable. Since vertical measurements are one of the variables in those calculations, the Daysim sky-model is not very reliable for it. You will be better off iterating through point-in-time calcs instead of relying on Daysim.
On the error front, I remember Paige having somewhat of a similar issue with her calcs last year.
From Sarith’s and Mostapha’s opinion on the daysim dgp, I have two questions based on that.
1.) Is there anyway to perform annual glare analysis (dgp) without doing a loop in the image based analysis?
2.) If I have dynamic shades control in my building, is there anyway to model it without running the glare analysis in daysim, since the dsparameters require to perform either annual glare analysis only or annual glare analysis and annual illuminance study?
To answer the first question, with whatever functionality is already is existing in Honeybee at the moment, the most straight-forward way to do this (in my opinion) would be to:
do a simplified DGP calc based on (http://ibpsa.org/proceedings/BS2007/p231_final.pdf) . To do this you’d have to do a single point vertical illuminance calc, which is very easy with Daysim. This result is valid only for those hours for which sun isn’t directly visible in your field of view.
Run a glare calculation for those hours. You can probably pick one-in-three cases and cut down the time for calcs further.
A more invasive method, described in (https://www.ibpsa.org/proceedings/BS2009/BS09_0944_951.pdf), requires getting illuminance values from daysim and luminance-based values from evalglare. That will require some additional outputs to be added to the existing Honeybee_Glare Analysis component.
@ Mostapha, I might have found another bug relating to this.
Going back to my project where I have >300 points of measurements, I believe Honeybee/Daysim will separate the points into three files to work. However, the worksfiles_InitDS.bat only perform radfiles2daysim for the first part of the points.