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: 10292

Attachments:

Replies are closed for this discussion.

Replies to This Discussion

Leonardo,

I am glad that you found this discussion as it is probably the most complete description of the solar fan/envelope tools.

I do not understand your question exactly.  There is a finite amount of sunlight and I think that you need to assess the tradeoffs between having the sun go to the roof or the ground.

Also, I would encourage you to be critical of taking a solar envelope as the actual boundary of what you should build.  As far as I understand, the methodology is meant mostly to make you aware of what sun you might block with a building and there seems to be a consensus that taking the boundary too religiously in several cases does not yield much benefit: http://www.gsd.harvard.edu/research/gsdsquare/Publications/Solar_En...

The benefits can probably be improved if you have a clear reason for why solar access is needed (ie. is it to ensure that street trees get sufficient sunlight for photosynthesis, or for passive solar heating of neighboring buildings, etc.).  This reasoning would give you criteria for selecting sun vectors with annualHourlyData and a conditional statement (for example, selecting just the sun vectors when it is cold out and the solar radiation is above a certain minimum will give you a sense of how to build in a manner that does not infringe on neighboring buildings's passive solar heating).

Lastly, you should probably play around a bit with the boundary of the "site." If you are concerned about solar access to the street, the present setup that you have is ok but, if you are looking at the effect on neighboring buildings, you should extend the boundary out to the base of these buildings.

-Chris

Hi Chris,

thanks for answering me. Meanwhile I've opened another discussion, in which an user advised me to try Octopus or Galapagos.. So I've done some researches on this group, finding this publication that, at first glance, seems to be something good for me (what do you think? Before beginning to work on it I'd like to know if you think it might help me).

Thanks to your video tutorial I've understood the meaning of "solar envelope", so I never meant to consider an envelope as the final shape of a building..
But..

The central point of my question is: the component SolarEnvelope is written in order to guarantee the best sun exposure at the ground level. To do this it's forced to reduce the envelope's surface, specially on the sides exposed to South.. and this could limit the energy performances of a building. How can I find a good compromise? 

We could see the problem from another point of view, if you prefer: how to pass from a first level, in which we define a solar envelope, to a second level, in which we start to design the building without interrupting the workflow and keeping all parametric?

Hi,

I've read the publication previously linked and I started to play with the definition attached.. As you'll se, I'm not so experienced in GH, so I'm asking a little help to understand how to relate the solar envelope (already determined) with this new Galapagos definition..

Thanks!

Hi Leonardo, 

I'm late to the discussion, but I wanted to add some points regarding your central questions.

First, the SolarEnvelope guarantees solar exposure for a specified amount of time, at the plane at which it is defined, not just the ground plane. So technically you can apply it at a higher level to guarantee solar exposure for the facades of surrounding buildings (for passive solar gain) although this obstructs solar access at ground level.

You're right that by limiting the south side, you're limiting the passive solar energy potential for the building mass within the SolarEnvelope. But I think this gets at a broader point about the use of this tool in the context of building energy performance: it's only one strategy amongst many, and many of these strategies will contradict each other.

Here are a couple examples of relevant conflicts, off the top of my head, to your problem: (1) in order to maximise passive solar gain, it would be ideal to concentrate built massing on the north side side of the lot (increasing solar exposure on the south face) - as you suggest - but that would then obstruct solar exposure to the south face of the building immediately north of your site. (2) Increasing the surface area to passive solar gain and daylighting could reduce building energy, but it can also increase building energy due to surface heat loss, or increased air conditioning loads. If air conditioning loads are high, it would be better to do the opposite of the solar envelope, use the neighbouring massing to obstruct heat gain.

So the interaction between overshadowing, passive or active energy gain, built massing, glazing ratios and building energy is complicated. A couple of things you need to address: what is the dominant load in your buildings - is it heating (like residential) or lighting (like office)? You may require different energy strategies for each. If the building is multi-use, you have an opportunity to combine different strategies. I believe commercial ground programs for example usually don't require daylighting or passive solar gain, as their primary energy load is air conditioning. As I mentioned above, you can therefore raise the SolarEnvelope, ignoring the ground plane, and instead focusing solar exposure to neighbouring facades. 

Keep in mind that at a certain point (as I believe the paper Chris linked mentions) SolarEnvelopes constrain density to a point where it can be detrimental to broader urban goals. So if you want higher densities I wouldn't use the SolarEnvelope so 'strictly'.  

s

Hi all, 

I am trying to use SolarFan_alt Component but when I input a number to _height input I get an error : "1. Solution exception:unsupported operand type(s) for //: 'str' and 'float' ". I use the latest github component. Any ideas? 

Thanks

Tasos

Hmm... I can't reproduce this error. Can you send a file? I'll check it out.

Saeran, My guess is that Tatos is using a panel to input the number and since you haven't clarified the input type explicitly GHPython component considers it as a string and that's why the issue happens. If you change it to float that should avoid this issue.

Hey Mosstapha, I think you're right, thanks for pointing it out. I thought I had all the input types set, but looks like I missed this one. I'll block some time out in order to update this.

Is there a way you can generate a solar fan for a vertical surface? Such as a west facing facade?

Hey Evan, to clarify, are you asking how to use the solar fan to prevent casting shadow on a west facing facade? 

Including an example file would help me understand / resolve your problem =) 

S

 

Evan,

The sort answer is that you can use the solar fan for windows.  See attached for an example file showing a solar fan around a window for a solar passive house that needs solar access when it is very cold:

Your west facade sounds a bit different, though.

-Chris

Attachments:

What is the best way to get a solar fan for a specific analysis period for a min number of hours, for example 21 June 9am-3pm for 2hrs?

Solar fan basic allows required hours, but onlt a monthly range. Whereas solar fan I can specify the sun vectors (i.e. analysis period) but not the required hours.

Thanks

RSS

About

Translate

Search

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service