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.
S
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.
S
Hello, sorry I missed your request. It looks like the site’s up again so I hope you had a chance to read it.
For anyone else, if the site goes down again these are the details:
Solar Availability in Cities
ISSN: 1833-7570, Issue No. 006, May 15, 2012
Solar Availability in Cities: A Design Approach
By: Spyros Stravoravdis and Andrew Marsh.
Probably can get it from cumincad, or the like.
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 Saeran, Mostapha, and Chris,
I was wondering if there is a way of achieving this with Ladybug/Honeybee and Rhino. It seems like an amazing analysis.
I am going to try native components perhaps but a heads up of do’s and dont’s would be great!
Is there some option of creating a 3d grid for sunlight studies?
And if there is can we run sunlight studies on 3d grids with Ladybug/Honeybee?
Thanks in advance!
Kind regards,
Theodore.
Sweet, I think it’ll be pretty cool.
Off the top of my head, the workflow I would suggest is modelling a series of planar surfaces, and then applying, one by one, the radiation analysis on them.
I don’t think a 3d grid would work, for the same reason you’d have to run the radiation analyses separately: you’re going to want to avoid self-shading geometries. This is only a pain if you want a denser 3D grid, in which case you might want to look into creating a GH or Python script script to automate the isolation and application of your radiation analysis.
S
Hi Saeran,
Thanks for your reply. I was also thinking that a dense grid would take immense calculation times.
I’m also leaning towards the planar surfaces idea. I think drawings isolines of different illuminance values on each plane and then using GH native components to create 3d surfaces from these isolines could do the trick. It would be rough but ideally there could be some automation on increasing accuracy (i.e. number of planes). I wonder if the parametric definition by Mostapha can be adjusted for this.
Anyways, I’m not as versed in GH scripting but I’ll let everyone know if I had some success.
Regards,
Theodore.
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
SolarFanExample.gh (383 KB)
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
Hi Paul,
Just on the top of my mind (haven’t tried it not currently on the pc), I guess you can specify an analysis period when you are generating the sun vectors for your study. Is that what you are looking for?
Kind regards,
Theodore.
Analysis period will just give you a range, say from 9-3pm. If I use this the solar fan will ensure light is ALWAYS accessing the surface. However, I can accept a min of 2hrs and I can’t find a method to do this. Sunlight hour analysis can sort of do this but only in 2d, not 3d.
Sorry Paul, I don’t think I understand what you are asking for. Do you mean you want a way to specify a specific time and month range for solar fan/ envelope?
I’m not sure how to be any clearer…
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 where each part of the surface receives at least 2hrs?
The ‘Solar fan basic’ component allows required hours (2 hrs), but only a monthly range (so I can’t specify 21 June). Whereas, the ‘solar fan’ component I can specify the sun vectors for a specific analysis period (21 June) but not the min required hours.
Thanks that’s better. This can easily be resolved with the solar fan basic, I just need to modify it to take custom monthly ranges. I am at work now but I’ll get to this when I have some free time.
S
Update: I think the attached file should do want you want. I have the script there set to June 21.
For the record, you should be able to do this with the other solarfan/solarenvelope tool: you just have to set the time range around the location’s solar noon.
I threw this together quickly, so let me know if there’s any glitches I overlooked.