I am getting strange results from the v.58 cumulativeSkyMtx component when I run the Reinhart skypatch model. See attached files and images. The Reinhart model reports an error saying it cannot read the weather data, yet it creates a skydome that is almost reasonable. Strangely, the Reinhart sky has lower values over the hourly sunpath lines. I ran this all using the attached cumulativeSkyMtx module, which should have been updated to resolve an issue with the latest radiance release based on your another post.
The Tregenza sky model calculates fine, but might not be pixelated enough to show the issue that appears in the Reinhart model. Do you know what is going on?
As always, I’m a big fan of your work! Thanks for your help with this.
Hmm. I am not sure why you are getting these messages. Everything looks good to me with the sky domes and I noticed that you do not get the error messages when you run just the Tregenza sky. For now, I would not worry about the messages as the results really seem fine. Hopefully Mostapha will comment on this sometime soon as I think that he would have a much better idea of what’s going on.
Mostapha, here’s a closeup of the message:
It is basically saying that every hour of the year has failed. I remember that this used to be an issue a year ago when there was an hour of the year when genSkyMtx.exe would fail.
I am confused by the banding in the direct and diffuse skydomes. They conveniently line up with the hourly sun paths. Should I expect this? Again, this only happens with the Reinhardt sky. The Tregenza sky looks normal.
Interesting observation and yes, the radiation should line up with the hour lines (or lamellas) of the sunpath. Radiance is only calculating the sky on an hourly time step since the EPW file is on an hourly time step and so this is why that happens. On a tregenza sky dome with a lot less patches, you would never be able to see this phenomenon but the high resolution of the Reinhart sky allows this to be visible. You are peering into the limits of the simulation assumptions. Interesting stuff.
That makes sense for the direct component. But I can’t figure out why we see bands on the diffuse component or why the top of the skydome is nearly zero. Any thoughts?
Is there any way within genCumSky to generate a Reinhart skydome using 1/2 hour or 15 minute increments? It seems that the Reinhart skydome offers false accuracy by adding higher resolution without interpolating hourly data. I would think Reinhart figured out a way around this but I don’t understand the radiance commands. Do you know a way to do this?
It’s true that the banding is a bit weird and my guess is that it just results from trying to apply a lot of the same Radiance algorithms to a higher resolution dome. As far as I remember, the paper in which C Reinhart published the idea of increasing the resolution of the sky dome, it was just about how to divide up the sky patches and validating that it was more accurate. I don’t think that there was much of a proposal for changing the underlying algorithms. Maybe, for the whole year, the Reinhart sky doesn’t change the results much but it definitely improves accuracy on an hour-by-hour basis (the sun of one hour is usually divided across 3 or 4 patches any you can imagine that it makes a big difference if those patches are smaller).
If you do single-hour simulations with the Honeybee Radiance components, I believe that it is possible to get some skies at sub-hourly intervals (I believe that the climate-based sky should do this). For entire-year simulations, both the Tregenza dome and the Reinhart dome are already pretty accurate (at least when you consider that your radiation and cloud cover is probably going to vary from year to year anyway).
If you really need this higher accuracy over the whole year, I think that the only way that you would be able to get it is by editing the Radiance source code and recompiling it. Maybe I’m wrong, though. Mostapha would be the man who knows this.
Hi Leland. This is a bug for conversion factors in Reinhart sky. I did an initial fix right now and it looks to work fine but I want to test it more before uploading it here. Thanks for reporting and for the kind comments. Cheers, -Mostapha
Chris, your idea of using the Honeybee CB module is perfect. This should allow me to do exactly what I need if it can calculate sub-hourly skies. Once I generate a custom matrix of skies, how do I combine them back into the skyFilePath format so I can use it in the other Honeybee components? I can use this custom sky with a basic single-ray calc, but have been unable to translate this into a format radiance can use. I was hoping your new Honeybee components could get me there. Do you know a way?
Also, what sky models are used to create the luminance distributions? CIE clear/overcast/intermediate, Perez, Kittler, or a combination of others? There are so many.
I am not so sure of the best method for integrating across many sub-hourly skies and this is probably a better question for Mostapha when he gets the chance. I can think of some methods where you could animate a slider in GH to run several radiation studies, collect all of the data with a record component, and parse/total all of the data together in grasshopper to get a really high accuracy radiation study for whatever period you ran the slider for. Is there a particular reason why you need such a high accuracy? This seems far beyond the accuracy needed for most design decisions.
Honeybee allows you to generate many different types of skies. Here’s an example comparing the cumulative sky, which is usually a Tregenza sky and a Climate-based sky.
As you see, the climate-based sky is really smooth and accurate but it only for a specific time of day. For cumulative radiation methods, the sky is divided into patches. There are also several types of CIE skies (sunny, cloudy, isotropic, etc.). I think Mostapha put together a whole example file on the different sky types and I would look at that.
We use a single-ray calc engine to test various orientations and shading devices in real-time. A 145 patch skydome is often too coarse to pick up geometry changes. Of course we would use radiance for final runs, but we need something that gives us instantaneous feedback while we explore approaches.
The ability to create custom skies allows us study very particular data sets. We can do this using the method you described and calculate values with our single-ray calc engine, but we can’t run a custom sky in radiance. Is there any way to allow an occ-file type input into the Honeybee CM component? The analysis period defined by a start and end hour is limiting. We need hourly pattern inputs. Or, is there a way to combine a series of CB skies into a single file that can then be input into the Honeybee radiance components? I just can’t wrap my head around the radiance gensky source code to even figure out where to do this.
The shade optimizer seems to already be using a complex custom sky based on E-plus heating/cooling values. I assume this is still the single-ray method used in the ladybug components. Are you planning to expand those kind of capabilities into components that use the radiance engine?
The radiance questions are way out of my league and they are definitely for Mostapha or possibly even Greg Ward and the Radiance team. I don’t know how to make the specific sky that you are looking for.
I can, however, speak to the method I put in the shade shade optimizer, which Mostapha had helped me develop. Right now the shade benefit evaluator only works for direct radiation (I will incorporate diffuse radiation soon) and so it uses just the sun vectors. If you boost up the sky resolution input on that component to the highest value that it can go, it will intersect every sun vector of every hour of the year with your test mesh. This high accuracy usually isn’t necessary to make most design decisions so I usually group these vectors by sky patch in order to cut down the number of intersections and the time that it takes to run the component. Sky resolutions that are lower than 4 just divide up the Tregenza sky patches. So 0 is the original 145 patches, 1 is 4 times 145, 2 is 16 times 145, etc. Perhaps there is a way to use this method of sky patch division in your case too although, if you need the diffuse radiation, I’m not sure that it will be so helpful yet.
Hi Chris and Leland, I’m very late to the party but let’s see if I can address the questions here.
Please find the attached file for the fixed version of the component. I ran comparative studies between 3 different types of sky for Ladybug and also Radiance and the difference is less than 5%.
You can use Daysim subprogram ds_shortterm to generate the sky for less than and hour timesteps (http://daysim.ning.com/page/daysim-subprogram-ds-shortterm-1) but then the number of patches will be limited to 145 patches. It is not applied to Honeybee.
Sky is almost 0 on the top because of the bug that you found. The value for the last row of patches was missing from the code. It should be fixed now.
For the sake of my own curiosity, could you explain more about what ds_shortterm does that is different from the climate based sky. I tested just to be sure that I was actually getting sub-hour skies with the climate based sky as seen here:
Am I right in thinking that ds_shortterm generates cumulative skies at sub-hour timesteps? If so, I understand why it’s not so useful to integrate it into HB as the increased accuracy of sub-hour timesteps is probably offset by the poor resolution of 145 sky patches.
I don’t know how to extract the updated .ghuser object from the .gh file. How do I do that?
This discussion has been very helpful. I think I will use the Tregenza 145 patches to calculate the data, then simply subdivide each patch as required to enable more accurate context masks. It is good to know about the daysim subroutine but I prefer a method that lives entirely in grasshopper.
Is there a method to combine multiple sky files into a single cumulative sky that can then be input into the _skyFile input of the honeybee components?
I don’t know the answer to your first radiance question but I do know that you can get our most updated version of the components by syncing with the github. The process for this is a bit convoluted these days since Github has stopped allowing automatic downloads but here are the steps for the best way if you don’t plan on updating frequently:
Unzip the file and you should see one folder called userObjects. All of the files in here will be most up-to-date LB userObjects
Delete your old Ladybug userObjects by going to File > Special Folders > User Objects Folder in the GH window and deleting all of the LB components there.
Drag the new Ladybug userObjects from the unzipped location onto your GH canvass.
Your components are now up-to-date.
Be wary that, if you stay up-to-date with the github, the overall version of the components might not always be as stable as that which we release at the official download link. For Ladybug, things are pretty stable these days but just be understanding if you do this same github sync for Honeybee right now.
I think I will use the Tregenza 145 patches to calculate the data, then simply subdivide each patch as required to enable more accurate context masks.
This is what Rienhat sky basically is. If you want to do it manually then you should consider recalculating the values for patches, which also involves recalculating stradian angles for each subdivision.
Thank you for your checks. It was definitely helpful. So there was two issues that I needed to address. Both of them were causing minor differences in a way that was so hard to realize by just looking to the results but your trick for putting .5 was really helpful to trace them down.
The main issue was that dayskymtx generates an extra patch for the ground (which is the first one in the results), I was taking care of this is selectSkyComponent but as a result I was multiplying the last patch of each row with the wrong str. angle. If you rotate the sky once you set one of the numbers to .5 you could see that.
The second issue was that the order of angles was reversed which was an easy fix.
Image below shows the sky before conversion on the left, the one with conversion from the angles in the middle and the one with ladybug internal conversation in the right. As you can see the values are very similar. The angles that comes from the geometry is slightly different from the ones from Radiance which is negligible.
I was thinking maybe even for the sake of visualization I should show the values before the conversion in sky dome but I assume that makes it hard for some users to use the values for their own studies as they have to find the angles from geometries so I just left it as it is for now. Let me know your thoughts on this. I hope this fix finally closes this discussion.
Thanks for following up on this, I’m happy we fixed it. Please let me know when the updated .ghuser object is up on the gitHub and I will replace my files.
Thanks Leland. The version on github is already updates! I also fixed update components so you can use them as an alternative to update the userobjects.
