Radiation analysis without epw weather file

I would like to conduct a radiation analysis using LadyBug. To do that I must input a sky matrix. To generate a sky matrix I need an .Epw weather file. I do not have a .epw file for my location but I do have the longitude/latitude location and I also have an hour by hour direct solar radiation values given in W/m^2. So I can generate a solar path and I know the direct radiation. I feel like this should be enough data to carry out a radiation analysis but I can't figure out how to do this be I am unsure how to generate a sky matrix from his data. I was thinking maybe I can create my own custom sky matrix? Or generate an .epw file (Although I have no clue on how to do either of these)?

Given the data that I have (direct solar radiation and location) how can I use the radiation analysis tool ?

Replies are closed for this discussion.

Replies to This Discussion

Permalink Reply by Sarith Subramaniam on March 16, 2017 at 11:10am

Hi Abraham !

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..

Permalink Reply by Mostapha Sadeghipour Roudsari on March 16, 2017 at 11:18am

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.

Attachments:

MIL_STD_810__.wea, 178 KB

Permalink Reply by Sarith Subramaniam on March 16, 2017 at 11:35am

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..

All the files used for that above calc are here.. https://www.dropbox.com/sh/t2o10lilig7rn9u/AAC7MYwvxdSrGRyxunmMJC4-...

Permalink Reply by Mike Johnson on March 16, 2017 at 11:49am

Sarith,

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?

Permalink Reply by Mike Johnson on March 16, 2017 at 11:40am

Mostapha,

The location and timezone are correct. However, you may be on to something. The data that I was given (the direct, diffuse data shown above) is not tied to a specific location - it is arbitrary solar data for a theoretical location. I have simply selected a location that is applicable to my problem.

With your comment in mind, looking at the sky generated by my replacement data almost seems as if time has been "phase shifted" which has caused the sky patches to move and reflect the asymmetry that we see.

So perhpas my data is not properly representing the sunrise / sunset of my location which causes the "weirdness."

What do you think?

Permalink Reply by Mike Johnson on March 16, 2017 at 2:28pm

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.

Permalink Reply by Abraham Yezioro on March 16, 2017 at 3:23pm

Sure!

In the LB_selectSkyMtx input your desired analysisPeriod.

-A.

Permalink Reply by Mike Johnson on March 16, 2017 at 3:36pm

Ok, yeah that's what I have been doing.

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!

Permalink Reply by Chris Mackey on March 17, 2017 at 1:10pm

Mike,

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.

-Chris

Permalink Reply by Chris Mackey on March 17, 2017 at 1:33pm

Mike,

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.

-Chris

Attachments:

CorrectRadiationSubstitution.gh, 403 KB
iran.epw, 1.8 MB

Permalink Reply by Mike Johnson on March 17, 2017 at 2:22pm

Chris,

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.

Thanks again,

Mike

Permalink Reply by Chris Mackey on March 17, 2017 at 2:50pm

Mike,

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.