I see. Hm. I guess I am confused because I expected the sky to look a bit more symmetric. For example…
Here is the sky produced by my original .epw file:
Looks nice!
But after changing the direct radiation values I get this for the same 24 hour analysis period:
As Chris pointed out, it seems to be missing half of the day. I double checked the direct radiation output numbers and your component is doing what it is supposed to from what I see.
Here is another view of the sky from the edited epw file:
Again, I expected a sky that more resembled the one produced by the original .epw file - just different values.
Maybe the raw data I supplied is not correctly formated - or the time step is off. The direct radiation replacement data was given by hour starting from the hour after midnight.
Here is the 3d Chart. The data is all correct from Jan-Dec. Does not explain the lack of symmetry of the sky that was generated.
Is there any other data besides location, direct normal radiation and diffuse horizontal radiation that is taken into account to produce the sky? My only explanation for this asymmetry is that some other data is being calculated or considered from other data sets that exist in the original epw file.
Something looks weird to me, though your image shows only 3 months. The red color is the maximal value in the scale. Weird for me that you get the maximal values in winter months (assuming your site is in the north hemisphere).
Another weird thing is that there is no change at all on those 3 months.
The original data set that Mike provided has the same values for every day of the year…additionally, the values for 06:30 to 12:30 for each those days is the same as 13:30 to 19:30…and additionally (again)…the value for diffuse radiation is assigned as a % of the direct-normal radiation…(see attached image #2).
So, my assumption is that the entire radiation data set of 8760*2 values is based out of just 7 empirically measured values. All of this still doesn’t explain why the plot will turn out that way. I think I have figured out a bug. I will put that in a separate post…
You can find all the data that is used for generating the sky inside wea file. Are you sure that the location data are accurate? It seems the sun rises early and sets sooner than expected.
I am assuming this place is somewhere in Iraq (this info wasn’t provided but it appears so based on longitude and latitude)… I just checked the location info for a nearby location and that given in the dataset. It seems to check out…
Yes that is correct, the location of interest is Iraq.
However, the solar data that I was given is according to a specification. I simply applied my data to a location that I knew would be of interest (Iraq). I did not believe this would cause problems, but perhaps it could be an explanation of the asymmetry caused by data that does not match sunrise/sunset times and locations?
I think I figured out what my problem is. Since my data is uniform across seasons - even when the days are shorter, by using a cumulative sky across a 1 year period i am actually skewing my data, resulting in the weridness we see when I select an analysis period. I am not exactly sure what computations go into producing a cumulative sky, but if it is any sort of averaging I think this could be the problem!
To test this, is there a way that I can produce a cumulative sky for only a single month / week/ or even day?
Thank you to all who have been helping me along the way! Very grateful.
I tested my theory above by changing direct radiation to 0 for all times for all days during the year except for 1 day. Ran the genCumulativeSky component and selected the sky matrix for the single non-zero day. And got the same result as before. So using a cumulative sky is not my problem…
Still can’t figure out why I am getting the asymmetry!
Your hypothesis sounds promising and I think that it might explain the situation. Abraham, to clarify why using the selectedSkyMtx might not address the issue, the GenCumSky component is still running to produce a matrix for the entire year and the selectSkyMtx only pulls certain values out of this based on the analysisPeriod. I’m going to try a test now where we only replace one day in the EPW with the radiation data (istead of replacing the whole year) and see if this fixes it.
Attached you can find an example where I only replace the first day of the year with your data and leave the rest in place. This seems to produce a correct sky when you run the GH script.
It seems that a lot of the asymmetry with the sky might also be the result of you having much more sun in the afternoon than in the morning in comparison to the actual weather file. Also, the fact that the level of sun energy here is almost twice that of any day of the year might also be a source of error.
Thank you for testing this. It does look like a proper sky.
But yes, there is definitely still error introduced by the inconsistent data between the days of the year
Chris I was wondering if Ladybug (or any other tools that work with grasshopper) can create a solar radiation source with a given W/m^2 value.
To elaborate, something that would also be useful to me would be to use the Sun Path component, select a given month, day, hour to determine a sun location. Then use that sun location as a direct radiation source of specified value.
I looked over the available components, but did not see anything that matches this, but then again I am new to Grasshopper so maybe there is something I can do to achieve this.
Also, maybe it is worth starting a new thread for this question. Let me know that would be best and I will post as new thread for you to reply.
A new thread would be a good idea. Sarith and others are more experts on this topic than I but, to briefly answer your question, this is basically what the Honeybee_Generate Custom Sky component does.
You just plug in your location, diffuse+direct rad, and date+time, and you get a sky that you can use in Honeybee radiation studies.
Sorry for the late reply. I tried your file and everything checks out well. The sky looks as I would expect it:
The fact that the csv data has the same length of day for the whole year means that we get some weirdness around the eastern horizon (dark patches in the summer). Still, everything seems good with your code.
