First of all, you need to know that for the annual DGP simulation, DaySim is used as the calculation engine, while for the Point In Time analysis (Image-Based), Radiance and EvalGlare are used.
As specified by @EspenHansen, the annual simulation through Daysim is a simplified procedure and I can assure you that if you compare it with an image-based PIT analysis, you will have 2 very different results.
Some standards, such as the European one, accept the simplified method, but if in the same project you also have to illustrate a Fish-Eye image with the PIT results, it will be difficult to make the client understand why there is all that glare difference for a given month / day / time.
The solution would be to generate a PIT analysis for a whole year (using per example the colibri component) and extrapolate ONLY the glare value, through Evalglare, so to generate an annual chart, without to generate the 7860 images, which would be very time-expensive (based on the radiance parameters) and it would also take up a lot of memory. But here the Maestro is @mikkel. Maybe he has a better solution.
I have never ventured into annual PIT renderings (8760 images). The longest time period has been one full month (744 images), but that was with matrix-based methods when I did some testing in relation to integration of the imagebased 3-phase method in HB[+]. Another option is the imagebased DC method, which is a more stable recipe in HB[+].
The obvious benefit of matrix-based methods is that you only have to do one simulation, and the rest is matrix multiplication to generate images for each hour. While that is great, I did experience that the matrix multiplication (dctimestep) is also a slow process. Multi-core is not possible for dctimestep by default, though running dctimestep in parallel is possible, but not part of Honeybee. During testing I also experienced that dctimestep is significantly slower on Windows compared to Linux - I used Windows Subsystem for Linux, so it was still on a Windows machine. The comparison is seen in the image below - note that the 6 cores for Linux is only for rcontrib and not dctimestep.
So to answer your query, I am not sure I have a better solution, but if I was forced to do 8760 renderings I would likely opt for matrix-based methods (HB[+]) rather than rpict (HB-Legacy). And as you mention it will take up a lot of memory. I currently only have a 256 GB hard drive - I wouldn’t even make it past January!!!
Dear @mikkel, thanks for your time and for the preciuos explanation,
my idea was to bring out the DGP result of every single hour through the PIT analysis, group all the 8760 results and create an annual chart, without rendering the images. If later I want to create one or more example images, for a given month/day/hour, the result must be almost equal to the value in the chart (as you well know, almost will depend on the resolution of the Radiance parameters)
The DGP annual simulation (without Daysim), is a method that I would like to be able to perform sooner or later, when the new components in LBT are ready, but obviously the question of the renderings is a limit that I would like to overcome. This is why I wanted to ask for your advice.
… but I didn’t have the right project to get to the bottom of the matter, but could this be the right method?
I guess the imageless glare method is perfect to create an annual chart. You just have to keep in mind which sky the analysis is performed with if you later want to compare imageless with a rendering. The annual imageless is climate-based using an epw file. You could also do it with a sky created by gensky, and then loop through every month, day, and hour - so essentially 8760 PIT imageless simulations. The imageless method will still be quick if you do it this way.
The DGP annual simulation (without Daysim), is a method
Just to be sure, are you thinking of the imageless method here?
Anyway, for fun I did - outside Grasshopper - some quick low quality renderings (-ab 3 -ad 1024 -as 512 -ar 128 -aa 0.3 -lw 0.005) for different hours of the year and found the DGP, and compared them with imageless DGP. It is nice to see some similarity between my graph and Nathaniel’s comparisons.
There is confusion because the standards are different wherever I look.
Remember that the parameters very much depend on your specific model. The first link @EspenHansen mentioned is very useful, I believe, because it also provides information on how the parameters affect the simulation time. Furtherwore I would suggest you look at Chapter 6: Daylight Simulation in Rendering with Radiance, at least section “6.9.1 Ambient Calculation Parameter Values”. For the settings of ar and aa, look at equation 6.12.
To clarify, do you wish to create an annual chart (like your image) for a given view?
If so, you have to do that manually as I did not add any options to visualize the results. Below you will see how the dgp file should look if generated. To visualize as an annual chart, you will have to extract the rows manually, and put the data into for example Ladybug’s 3D Chart.
When you simulate with Radiance, you will never have the same results between one simulation and another.
You have to calculate that you can always have a 5-10% swing.
But from experience, I can tell you that if you use fairly accurate Radiance parameters, you can narrow the difference in results between the simulations.
The more accurate the parameters are, the more accurate the resolution will be and the time for each simulation will be far greater.
But from what I see from your graph, line 1 apart, it looks like a good result.
Hi, thanks so much for the GH script. However, I got an error ‘failed to import honeybee’ for the imageless glare recipe component. The other components worked fine. Would like to check if it can run on Rhino 7? thanks!