Hi Mike,
You can generate epw files with meteonorm.
best,
Omid
1 Like
Hi Mike,
In addition to what Omid said, if you want to create a sky matrix from your data alone, youâd also need horizontal diffuse radiation values. The sky model used in Ladybug and Honeybee is based on Perez Skies. The sky matrix is created based on Reinhart patch subdivisions.
Below is a visualization of the Perez sky for a particular time and the sky-matrix corresponding to that.
The issue with using direct solar radiation only is that you wonât be able to consider the effect of sky radiation in your simulation as shown below (the image on the right is sun-only):
Once you have the hourly data for direct-normal and diffuse horizontal radiation for the entire year, generating an epw(and then the wea) file from that isnât that difficult. We should be able to help you with that.
Ok great, thank you for the response.
So now I have 2 data columns - one for direct radiation (hour by hour for 1 year) and for diffuse radiation (also hour by hour for 1 year).
And then I have the location data.
I took a look at the link that Omid provided, but it seems as if it is paid software, which I want to avoid. Since I have all of the necessary data, I would like to make an epw file or a custom sky using the Ladybug/Honeybee components. Could you help me with this? Thank you!
Omid, Thank you for providing that link. Iâd like to avoid paying money for now, but I will play around with the demo version to see if I can use it. Thanks!
Can you share the files here?
Yes absolutely!
Attached is the raw data: Direct solar radiation, diffuse radiation, ambient temperature, and location.
A couple things I would like to note:
weatherFile.xlsx (248 KB)
So, here is a quick fix. The idea is to take an existing epw file and replace the desired datasets and location info. Below are some images as proof of concept. The first sun path contains data from the original epw file. The next one contains your dataset. The dataset to be replaced needs to be contained in a csv file as attached. You can replace more data from the original file by addiing additional columns in that CSV and assiging the correct column number in the grasshopper file. The ordering of columns in an EPW file is shown in the last image. For example, Direct-Normal rad is column -21 and Diff-Horz rad is -20. All of this will be clearer once you check the attached gh file.:
By the way, that theory about diffuse radiation being 10-40% of direct does not really hold. In a place like Seattle, one can expect to go without seeing the sun for extended periods of time and only see visible radiation from the sky.
(PS: I am sure there are probably more elegant ways to do thisâŚI just wrote it this way to check if it was at all possible to do this with grasshopper).
weatherDataReplace.gh (475 KB)
weatherFile.csv (134 KB)
Additional data that needs to be entered in the csv file is as per this:
Thank you, it worked! I was able to use your component successfully to change the .epw file by substituting in my data.
I then tried to feed the new EPW file into the following components: genCumulativeSkyMtx > selectSkyMtx > SkyDome for visualization. This required an Ladybug update, so i used the update component to update everything from 0.0.63 to 0.0.64. After the update I was able to see this:
which is over a 24 hour analysis period. (Look good?)
However, after I was able to obtain the sky matrix, the sun path component gave me an error : 1. Solution exception:global name âsolarOrStandardTimeâ is not defined
I checked to make sure that _solarOrStandardTime was defined on the compnent (it is set to false).
Any ideas on what is going on?
Is this happening with both the epw files ? If yes, it has to be a bug.
Just connected the original EPW file to the sun path component, and the error did not go away. So, possible bug. I am going to make sure I updated the components properly
it looks like the input variable on the gh component is âsolarOrStandardTime_â but in the code it is âsolarOrStandardTimeâ Maybe this could be the problem.
I looked at the old 0.0.63 component and the difference is that first underscore is not present on the variable. This could be the issue?
Hi Mike,
That error has nothing to do with the EPW file and everything to do with how you updated the components. If you updateAllUserObjs, you will see that the new sunpath component has an input called solarOrStandardTime_. When you use the updateThisFile option, it only replaces code inside the sunpath component and not the inputs or outputs in the Grasshopper UI. Hence the error. Drag/drop a new sunpath component onto the canvas and all will work.
-Chris
Also, Mike, it looks like half of the day is missing from your sky dome component as only half the sky is showing values. I would venture a guess that this has to do with the weather data replacement rather than a bug with geCumulativeSky.
-Chris
Chris, you are absolutely right. Dragging a new component on the canvas solved the problem.
You are also right about the data not being read in properly.
This is an image produced by the original EPW file:
The sky looks like it is being constructed properly using the original epw file.
With the ânewâ EPW file after data replacement, the genCumulativeSkyMtx component outputs some failures:
This list goes on all the way from January - December, so something is definitely wrong with the data replacement.
Sarith, Is there a nice way to view an .epw file? I tried opening one in excel and notepad but it looks pretty unorganized.
Thank you both for the continued help on this.
Hi Mike,
Based on the error message in your screenshot, it appears that the Ladybug is using cached values to generate the sky matrices. For the same date and times that you chose, everything seems to be working fine on my system.
Mike, You need to set useOldRes input to False so Ladybug regenerates the sky definition every time that you run the script.
Ok, thank you Mostapha.