cumulativeSkyMtx error

Replies to This Discussion

Permalink Reply by Leland Curtis on November 10, 2014 at 8:35am

This is very informative, thank you.

 

I don't know how to extract the updated .ghuser object from the .gh file. How do I do that?

 

This discussion has been very helpful. I think I will use the Tregenza 145 patches to calculate the data, then simply subdivide each patch as required to enable more accurate context masks. It is good to know about the daysim subroutine but I prefer a method that lives entirely in grasshopper.

 

Is there a method to combine multiple sky files into a single cumulative sky that can then be input into the _skyFile input of the honeybee components?

 

Again, thank you both for your time.

Permalink Reply by Chris Mackey on November 10, 2014 at 8:57am

Leland,

I don't know the answer to your first radiance question but I do know that you can get our most updated version of the components by syncing with the github.  The process for this is a bit convoluted these days since Github has stopped allowing automatic downloads but here are the steps for the best way if you don't plan on updating frequently:

1) Download a copy of our code to your computer by going here (https://github.com/mostaphaRoudsari/ladybug) and clicking on 'download ZIP.'

2) Unzip the file and you should see one folder called userObjects. All of the files in here will be most up-to-date LB userObjects

3) Delete your old Ladybug userObjects by going to File > Special Folders > User Objects Folder in the GH window and deleting all of the LB components there.

4) Drag the new Ladybug userObjects from the unzipped location onto your GH canvass.

Your components are now up-to-date.

Be wary that, if you stay up-to-date with the github, the overall version of the components might not always be as stable as that which we release at the official download link.  For Ladybug, things are pretty stable these days but just be understanding if you do this same github sync for Honeybee right now.

-Chris

Permalink Reply by Mostapha Sadeghipour Roudsari on November 14, 2014 at 4:10pm

Hi Leland,

I think I will use the Tregenza 145 patches to calculate the data, then simply subdivide each patch as required to enable more accurate context masks.

This is what Rienhat sky basically is. If you want to do it manually then you should consider recalculating the values for patches, which also involves recalculating stradian angles for each subdivision.

Mostapha

Permalink Reply by Leland Curtis on November 14, 2014 at 7:30am

Mostapha,

I downloaded the latest cumSky userObject from the gitHub but I still have banding on the diffuse sky. See image below. It is not the same as my original error, but still looks unnatural. Could there be another bug?

 

Original error

 

sky using 11/08 version

Permalink Reply by Mostapha Sadeghipour Roudsari on November 14, 2014 at 4:15pm

Thanks for reporting this. I'm not sure if this is a wrong result actually. Diffuse sky tended to be evenly distributed so it does make sense that each strip have a similar value all over. What I'm not sure about though is distribution of the values vertically. I will take a closer look myself and also share it with Greg, Rob and Andy for their input and will copy you on the emails.

Cheers,

Mostapha

Permalink Reply by Mostapha Sadeghipour Roudsari on November 29, 2014 at 11:04pm

I made some progress on this. It is because applying numbers for stradian angles. I should double check the angles and see if it does make sense as it is, but at least it is clear now why the image and sky dome are different.

Permalink Reply by Leland Curtis on December 19, 2014 at 8:26am

Hi Mostapha,

Has this issue been resolved in the latest cumulativeSkyMtx user object on the github?

Permalink Reply by Mostapha Sadeghipour Roudsari on December 23, 2014 at 10:37pm

Hi Leland, If you are concerned about the results of the study, the component that you already have is generating accurate results. The bounds that you see in visualization is because of multiplying the values with stradian angles to plot the kWh/m2 values. The angles are going up and down for each raw and are making the bounds. As you can see once I remove them and plot the sky for kWh/m2.str the sky looks as expected. I'm not sure what is the best way to address this issue for visualization but as far as it is related to the results the current numbers are correct.

Mostapha

Permalink Reply by Leland Curtis on January 5, 2015 at 2:53pm

Mostapha,

I am having trouble following. I agree sky patch Radiance (kwh/m2*sr) should not change with patch size and it should appear smooth as you have shown. Up to this point I assumed the Radiant Exitance (kWh/m2) in the "value" output was actually a measure of total radiant energy (kWh) per sky patch. I assumed the area of the skypatch (/m2 unit) was accounted for in your code so that any size skydome, be it 100m radius or 1km radius, would have the same values per skypatch. Changing the skydome scale in your module changes the patch areas but not the value, so this seems to hold.  

 

If that is how it works, I would assume a larger patch should have more energy (larger value output). A skydome made of a single patch should have all the energy in it. So I expect the banding to occur when the patch size changes dramatically, as a different size sky patch would have a larger or smaller value output than one nearby with a different area. Instead, the banding occurs between similarly sized patches, and is relatively constant between other patches that change size dramatically. This doesn't line up with changes in solid angle as you describe. I cannot replicate your results and it confuses me. Can you please explain where I am going wrong? Thanks a lot.

Permalink Reply by Mostapha Sadeghipour Roudsari on January 6, 2015 at 11:51pm

Hi Lenald,

Your assumptions in the first paragraph is correct.

About the second paragraph it's about the solid angle and converting the values from kWh/m2.str to kWh/m2 (which is also related to size of the patches). Each row has a different value for solid angle. For Reinhart sky the values are this list for each row: [0.00921483254, 0.00612971396, 0.0121875626, 0.00905126163, 0.0119026242, 0.00974295956, 0.011436609, 0.00974713106, 0.0108025291, 0.0117312774, 0.0125224872, 0.0105335058, 0.0109255262, 0.0111894547, 0.0113221971]

Once the original values are multiplied by solid angles the ones with lower conversion numbers are creating the bounds and since in diffuse sky the values are so close you can see the difference. If you change the conversion list with all 1's you will see the image that I uploaded before which has no bounds. Maybe I should visualize the skies with kWh/m2.str to avoid this issue.

I think I should also reply to Ian on the email. They know much more than me how to calculate these angles and conversions. I'm just keeping it for a time spot that I can follow up on the emails.

Mostapha

Permalink Reply by Leland Curtis on January 7, 2015 at 12:50pm

Hi Mostapha,

I follow your reasoning but am still running into an issue. I expect the kWh/m2*sr numbers to be smooth, as you describe. When I try to derive these numbers from the output values by dividing by the corresponding sr values, the discontinuous bands still exist. Take the 2nd and 3rd patch from the bottom shown in the images below. I expect the kWh/sr values here to be nearly identical.  The sr quantities vary by 3% but the kWh values vary by almost 40%. Plotting the kWh/sr values shows that the banding still exists. This makes sense considering similarly sized patches have sharp color changes between them. This seems wrong to me. If you are getting the correct numbers by changing the sr values to 1 inside the script, perhaps there is an issue with the math that generates the output values? Let me know what you think. I have attached my gh file for you to look at.

 

 

Attachments:

• cumulativeSkyMtx error.gh, 80 KB

Permalink Reply by Mostapha Sadeghipour Roudsari on January 12, 2015 at 2:58pm

Hi Leland, Thank you for updating the file. It definitely helps. I removed the conversation numbers inside the component (line 215 in gencumulativesky) and generated the sky only for diffuse values. Now you can see the bounds are gone. Try the attached file and let me know if it addresses your concerns.

PS: I didn't update the legend so it is kwh/m2.str

Attachments:

• cumulativeSkyMtxerror_removedStr.gh, 77 KB

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