algorithmic modeling for Rhino
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.
Replies are closed for this discussion.
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.
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?
Thanks for your help.
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
I look forward to testing it out when it's ready.
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.
Thanks for your help.
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.
1. 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%.
2. Ladybug is using gendaymtx to generate the sky. You can read the details here: http://www.radiance-online.org/learning/documentation/manual-pages/...
3. 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.
4. 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.
Thanks for the knowledge and wisdom, Mostapha.
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.
© 2023 Created by Scott Davidson. Powered by