Grasshopper

algorithmic modeling for Rhino

I received multiple emails about solar fan and solar envelope and if I want to add this components to Ladybug. Here is how you can calculate both of them with shading designer!

Views: 10156

Attachments:

Replies are closed for this discussion.

Replies to This Discussion

Hi Abraham,

Thanks for letting me know about this.  It turns out that what you were experiencing was not specifically related to concave or convex shapes but was a result of a bug in the BooleanIntersect operation of RhinoCommon.  Essentially, some solar vectors were being discounted from the generation of the solar envelope because the BooleanIntersect operation was failing.  The shape you found that broke the component just happen to have the last booleanIntersect fail and so it output no results.  

I have put up the issue I was experiencing in a discussion and we will hopefully get it resolved soon (http://www.grasshopper3d.com/forum/topics/differening-results-with-...). For the time being, you can definitely trust the results of the solar fan but hold off on using the solar envelope until we get this bug in BooleanIntersect addressed.

Thanks Chris,

These are a great couple of components.

Hope there will be an answer from the GH guys ... soon

Best,

-A.

Hi Abraham,

I am happy to report that the issue with the Solar Envelope has been solved and it now outputs a reliable result.  The new component has been uploaded to the github and you should feel free to try it out.  I ensured that it works on all of the curves in your original file as well as some more.

Thanks for the awesome work-around that made this fix possible goes to Guilio, the author of GHPython.  Guilio's code was also used to pimp-up the solarFan such that it always outputs a single brep.

Enjoy experimenting with solar geometry!

Hi Chris.

Great!! Seems to be working.

Now i've found that for some cases (so far, L shapes) some geometry is baked into the rhino model. See attached for that, lower shapes.

Thanks a lot. This is good dtuff.

-A.

Attachments:

Hi Abraham,

Thanks again for keeping me posted.  The issue that you are having seems to be pretty minor.  It looks like you are getting the right result out of the component and the component is just having difficulty cleaning up after itself.  I was not able to reproduce your problem with the GH file that you sent me (it's working fine for a bunch of weather files that I have tried in you GH file).  What epw file are you using with Ladybug to generate the solar vectors?

Also, could you let me know if the attached version of your GH file fixes the problem (I just put in another check that helps the component clean up after itself)?

-Chris

Attachments:

Hi Chris and thanks!

Looks fine now.

The weather file i am using is ISR_Tel.Aviv-Bet.Dagan.401790_MSI.epw. I tested other EPWs too and it works good.

Should i update the component?

Thanks again.

-A.

Awesome!  If that extra set of checks fixed the problem, then we're set.  I put a similar check into the solar Fan so that hopefully no one ends up with geometry accidentally baked when they use that.  I pushed the two new components to the github.  Go ahead and sync!

Excellent! Thanks,

-A.

Hi Chris and Mostapha,

Playing with both components i've found something inconsistent with the definition of Envelope and Fan.

I'll say first that this will be a wish ...

Assume a rectangle shape with the long side facing south and north. Define the period from 10 am to 14 pm (doesn't matter). Now when you get:

Envelope: You see the volume extending out of the boundaries of the rectangle. I suggest this to be sectioned/trimmed out to get the real envelope for the site.

Fan: About the same as the envelope but on the north side. The volume is entering into the "own" boundaries. In this case the Fan should be completed in order to get fully into the north border.

Does it make any sense for you? I understand that there could be some difficulties to accomplish this, but the result will be more correct .

Thanks,

-A.

Hi Abraham,

I have tried testing the scenario that you describe and I think I understand some of what you mean about the solar fan but I am still unsure of what you mean with the solar envelope.

In the case of the solar fan, I know that it does not form a perfectly rectangular extension for a rectangular starting surface but this is actually the right geometry for those solar vectors (albeit, it is probably more specific than you would actually need for a given project and it takes much more calculation time than is necessary for such a simple question).  If you are looking for something that gives you a slightly abstracted solar fan just for a given hour range and has a much quicker calculation time, I know that Saeran Vasanthakumar has just pushed an alternative solar fan and envelope to the ladybug github and this might better suit your needs (https://github.com/saeranv/enviro_simulation/tree/master/gh_files).

I feel I should put a bit of a disclaimer and say that these component that I made are for in-depth solar fan and envelope analysis where you might set criteria other than a simple hour range for selecting solar vectors.  For example, you can use the sunPath component to select just the sun vectors when the temperature is cold enough that people want sun and the radiation is strong enough to provide warmth.  You could then build a solar fan from those vectors to ensure outdoor comfort for a certain time of year in a given space.  Another scenario would be selecting solar vectors that pertain just to a growing season (ie. between a certain temperature range and humidty level).  You might then choose vectors when the sun is strong enough in this growing season and build a solar fan off of that.

Let me know if this answers your question and, if not, perhaps you can annotate the attached screenshots of the scenario you described to give us a better sense of what you mean.

-Chris

Attachments:

Hi Chris,

Thanks a lot for your detailed explanation.

My comment is not related to the criteria (which can be implemented with existing LB components). It is more related to the created geometry.

Probably i wasn't clear in my explanation, so now i'm attaching a screenshot. In the Envelope, and assuming that the BaseSurface is your design plot, you see that the volume is extending beyond the plot limits towards the south. For this case the limit of the volume should rise vertically.

As for the Fan, it is about the same, just that a portion of the volume is missing towards the north, without affecting the required performance (analysis period).

This results happen depending on my analysis period definition. In this case, months: 9-12, hours_ 10-14. Which seem to me reasonable for autumn/winter seasons.

Saying that i know that my comment goes beyond the vector checking. That's why i said is kind of wish list.

Hope this is clear now and thanks again!!

-A.

Attachments:

Hi Abraham, 

If we take the Fan in your example, the portion of the geometry that is extending into the BaseSurface from is technically the limits of the solar geometry. Filling in the north would be inaccurate because the Fan is only supposed to generate the minimum 3d boundaries that guarantee solar access.

You could, for example, build into that gap on the north side, and it would cast no shadow within our BaseSurface. 

The same applies to the solar Envelope.

Is this what you meant? Or am I misunderstanding your question?

I made a sample gh file that shows the solar extrusions that the fan operates by for my component. The fan works by "filling in" these extremes together to form the overall 3d boundary. Anything outside those extremes are not in the path of the solar vectors, therefore will not cast a shadow - this includes that portion to the north you've identified.

Hope it helps!

- Saeran

Attachments:

RSS

About

Translate

Search

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service