Solar Fan + Solar Envelope with Ladybug

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!

Attachments:

solarFan_solaeEnvelope.gh, 71 KB

Replies are closed for this discussion.

Replies to This Discussion

Permalink Reply by Chris Mackey on February 28, 2015 at 7:45pm

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

Permalink Reply by Leonardo Roli on March 1, 2015 at 2:44am

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?

Permalink Reply by Leonardo Roli on March 2, 2015 at 9:56am

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!

Permalink Reply by Saeran Vasanthakumar on April 14, 2015 at 12:18pm

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

Permalink Reply by Anastasios Kokkos on April 10, 2015 at 12:13pm

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

Permalink Reply by Saeran Vasanthakumar on April 11, 2015 at 3:59am

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

Permalink Reply by Mostapha Sadeghipour Roudsari on April 11, 2015 at 9:08am

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.

Permalink Reply by Saeran Vasanthakumar on April 14, 2015 at 11:22am

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.

Permalink Reply by Evan Wakelin on August 25, 2015 at 6:18am

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

Permalink Reply by Saeran Vasanthakumar on August 25, 2015 at 4:41pm

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 =)

Permalink Reply by Chris Mackey on September 6, 2015 at 10:08am

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:

SolarFanExample.gh, 383 KB

Permalink Reply by Paul Wintour on April 18, 2016 at 10:33pm

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