Thank you for responding for me, Mostapha. The last few days have been pretty busy. I have attached a GH definition that shows how to use my solar fan and envelope components. I would suggest opening the GH definition with a weather file that does not generate too many sun vectors for the criteria that I list in the sunpath conditional statement. If more than 500 vectors are being used to construct the solar fan or envelope, the calculation can take upwards of a minute. Let me know if you have any other questions, Petar.
I recently started using Ladybug as a student and it has been a great tool to influence design decisions. I really appreciate your time and effort put into developing this so thank you!
I have an urban site modeled in Rhino and want to run some solar envelop and solar fan studies. I am able to get the fan and envelope but they don’t seem to be changing based on some of the adjacent buildings. Is the sun path tool supposed to pick up on this geometry or does it need to be imported somewhere? I’m guessing it has to be plugged in somewhere but not sure where or how to do this…
Is there a gh file out there that has somewhere to import site geometry?
If I’m understanding the question correctly, what you’re looking for isn’t accommodated by the tool. The solar envelope/fan does not change based on the 3D geometries of adjacent buildings. It only provides the maximum built volume for a given ground geometry. It’s one of the limitations of the tool.
I think what you’re looking for is something closer to an iso solar surface[1]: which weights the volume by solar radiation or illumination levels, and therefore should show how 3D adjacencies effect the envelope/fan.
Hi Jacob and Saeran, I understand that technically solar envelope doesn’t consider the context but there is a way to do it with Ladybug (and that’s why we have two sets of components for solar envelope and solar fan.)
One of solar envelop components accepts sunVectors for input which means you can generate sun vectors from sunpath and filter them based on intersections using Grasshopper native components and use them to calculate the envelop.
Saeran, thanks for your input. And that link to that paper is super helpful!
Mostapha, that first component pictured above is the one I’ve been trying to use and I’m glad to know that it should work. I’m still pretty new to grasshopper and not sure the best way to go about getting the sun vectors to recognize my site context. I will keep trying though.
Everything that you posted is awesome and that paper from my school is super-interesting. There is another developer named Boris who has been working on something similar for Ladybug. With his method for generating the solar envelope, you will put in context breps of neighboring buildings that require solar access instead of taking everything outside the boundary of the site as requiring solar access (what happens currently). Last I checked, his calculation times were huge and he was trying to get this down but it seemed like he would have it ready in the near future. I will try to remember to post back here if he is nearing completion.
Jacob VDR,
In the meantime, if you are looking for a method that is going to be really sensitive to surrounding context, I think that your best bet is to do sunlight hours studies (I know that it’s a different method but it’s the best that we have right now). The ability to select out specific solar vectors that Mostapha pointed out is only useful for qualifying the type of solar access you want (ie. for vegetation, for daylighting, etc). The idea is that you can use the sunpath to select out sun vectors based on radiation or outdoor illumuinance and then plug those into the solar fan/envelope. As they stand right now, the solar fan and envelope components are not made to be sensitive to variations in surrounding context and they thus treat all surrounding context as uniform.
Cool Chris, I’m really interested in checking out Boris’ tool.
I agree, the iso solar tool is pretty exciting. Arguably it’s the current state-of-the-art in terms of these ‘solar voluming tools’. I started coding a version of it with Ladybug, but had to abandon it in favour of other projects (I think it’s still floating around somewhere on my git account). That being said, I’d like to have version of it so if no one else tackles it in the Ladybug community, I’ll see if I can do so, and post an update here.
@Jacob
Reinforcing Chris’ point about the sunlight hours studies, you might want to check out section 3.2 of this paper: http://naturalfrequency.com/articles/solar-availability-cities . There’s a couple of options there, but I think a grid of sunlight studies is one of the more effective methods of capturing the effect of context geometry.
I’ve read all this discussion, which is very helpful… But I still have a huge question: how to combine the “solar constraints” with habitability (or, if you prefer, functionality)? I’ll try to explain myself with an example:
Here you can see my case of study (which is Fort Point District… I think I understand that Chris is from Boston). As you can see the shapes deriving from the Gh def. are considerably smallar than the buildings around… But I need to obtain buildings at least of 5-6 storey… and the ones that you see here are just 1 or 2 storey tall.
Obviously, reducing the amount of imputs (such as a minor number of months or days), the solar envelope would be taller… So, according to you, what is the way to find a good balance between constraints and functionality?
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.
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?
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…
