cumulativeSkyMtx error

Replies to This Discussion

Permalink Reply by Leland Curtis on January 13, 2015 at 1:31pm

Hi Mostapha,

 

Thanks for looking into this. I think we have stumbled onto a bug in the code. See attached images and files.

 

With the Sr conversion values all at 1, I get the correct values you have shown. When I then convert those kWh/(m2Sr) output values into kWh by multiplying by the Sr values, I get the correct smooth distribution we expect. Notice how the values gradually get smaller then jump when the patch size changes dramatically. All values are proportional to patch area and Sr values as expected. The values shown below should be the same kWh patch values as those output by the original cumulativeSky module, only I did the Sr conversion in GH rather than in your python script.

 

Your standard module produces different results. As shown below, the raw kWh output values create strange bands that do not correlate with the patch steradian values. Instead of banding where the patch size changes dramatically, the results vary greatly between similar patch sizes. See below. The output values do not correlate with patch area or steradian values as expected.

This appears incorrect. I'm not an expert at python (which is why I love the work you have done) but I think the Sr values are being applied to the wrong patches somehow. If all Sr values were 1, this error would not show up, which may explain why your trouble-shooting failed to catch it.

 

To test this idea I changed the fifth value of your list from 1.0 to 0.5. As you can see in the image below, this changed the 4th patch row (now very blue), not the 5th. I think this is the issue. Do you agree?

I have attached both scripts for you to review. I used a Detroit epw file.

Attachments:

• cumulativeSkyMtxerror_removedStr.gh, 84 KB
• cumulativeSkyMtx error.gh, 82 KB
• USA_MI_Detroit-City.AP.725375_TMY3.epw, 1.5 MB

Permalink Reply by Mostapha Sadeghipour Roudsari on January 22, 2015 at 10:42am

Hi Leland, Looks like something strange is going on with rows. I will take a closer look. Can't thank you enough for your comments.

Permalink Reply by Mostapha Sadeghipour Roudsari on January 22, 2015 at 7:50pm

Hi Leland,

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

Attachments:

• cumulativeSkyMtxerror_removedStr_3.gh, 405 KB

Permalink Reply by Mostapha Sadeghipour Roudsari on January 22, 2015 at 7:52pm

and I think that blue ring on the top is strange but it makes sense when you look at the conversion numbers.

Permalink Reply by Leland Curtis on January 24, 2015 at 12:29pm

Mostapha,

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.

 

-Leland

Permalink Reply by Mostapha Sadeghipour Roudsari on January 24, 2015 at 3:01pm

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.

Permalink Reply by Leland Curtis on January 25, 2015 at 1:22pm

Mostapha,

I am having a few issues with the new userobject file from the GitHub. See images below.

old version of gencumskyMtx

 

 

new version of GencumskyMtx

There are two issues:

1: The cumulative sky dome viewer returns the error "sky type not found". It just recently changed to give me a runtime error, index out of range 144.

2: The selectSkyMtx object now returns all text, where before it returned text and number values. I can get around this issue using your ladybug split text/numbers module, but I thought it may lead to where the issue is.

Any idea what is causing this?

Attachments:

• 2015.01.25 test files.gh, 85 KB

Permalink Reply by Abraham Yezioro on January 25, 2015 at 2:45pm

Leland: You need to update some of the components in your file. Get the most updated from the github. After that it should work. It does  on my system.

-A.

Permalink Reply by Mostapha Sadeghipour Roudsari on January 25, 2015 at 3:11pm

Abraham is right. Attached is the updated file. I also added the version check so it gives you a warning in case you are using it with the wrong version.

Permalink Reply by Mostapha Sadeghipour Roudsari on January 25, 2015 at 3:22pm

Here is the file!

Attachments:

• 2015.01.25testfiles_updated.gh, 354 KB

Permalink Reply by Leland Curtis on January 25, 2015 at 4:17pm

I'm all set. Thanks for the help!

Permalink Reply by Marcello_t on October 5, 2016 at 8:33am

Very interesting Thank you!

One question, about a simpler topic: I see on the first attached image by mr Leland Curtis that the sunpath is overlapped to the sky dome. How can i do it?

Thank you.

M

• ‹ Previous
• 1
• 2
• 3
• 4
• Next ›
• Page