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 .
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.
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!!
I’m also contributing a Solar Fan and Envelope component to Ladybug. Mine is done in a slightly different way from the components presented here. The Fan component is also done differently from the one in DIVA4Grasshopper - mine should produce a more precise boundary that includes all the sun positions for a given user-defined time-period. The trade-off is that it’s a little slower especially for concave shapes. Apologies for the confusing icons, they are just placeholders for now
Attached is an example gh file - please test it out.
solarFan_solarEnvelope_2.gh (56 KB)
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!
solarFan_solarExtrusions_2.gh (47 KB)
Hi Saeran and thanks,
I’ve been testing your components. So first of all: Thanks for sharing!!
A big difference i see between your components and Chris’s is the definition of the period. Chris allows free months/hours while yours are constrained to a specific day (21.9), allowing only to change the amount of exposed hours. Did i get it right?
Comparing with DIVA, your Fan is (kind of) similar, but the big change happens in the Envelope. You set the same date for both components, while in DIVA the Envelope is set for 21.12 (assuming that my previous statement is right).
Personally i find Chris’s more flexible to changing situations related to checking periods. Some places may require different conditions.
I’m attaching a GH comparing yours with DIVA. I’m using there the LB ViewFromSun component to check the compliance to the hours i said before.
As for some bugs i’ve found:The Location input for the Envelope is not working (though in your example it does). I get this error: 1. Solution exception:name ‘FL’ is not defined. Out of that seems to be working well.
I agree with you at some points but disagree at others.
I’ll stat with the envelope. I want to get the volume that i can build without hurting solar rights of my neighbors (roughly speaking). Of course to build this volume you need the solar geometry (which is the technical part of the issue). But once you get this SG you must include for the final envelope the limits of your plot. I assume you are not allowed to build outside those limits. The solar geometry extends beyond these. This is my whole point. For the envelope will be easy to solve if you extrude your boundaries and intersect it with the solar geometry (the Envelope). Then you get what i said should be, which is the correct definition of Solar Envelope.
As for the Fan, it is about the same. If the solar geometry tilts towards the plot limits you are saying, theoretically, that your neighbor can build inside your plot since technically he wouldn’t hurt your solar rights (i’m exaggerating a bit just to make my point). So you might be right that filling the gap is inaccurate (it is from the point of view of the solar geometry) but it will be correct as for the definition of Solar Fan respects … which it is what you want to get. Unfortunately i don’t know in this case what kind of operation is needed to fill the gap. Maybe the Substraction of the plot extrusion and the solar fan geometry and then the Union of this result with the Solar Fan geometry (2 operations).
Attached a gh of my intent of showing my points and the way to solve. Not very elegant but …
Did i convince you?
solarFan_solarEnvelope_2_A.gh (63.8 KB)
Thanks so much for doing this detailed testing. It’s extremely helpful.
Yes I’ve constrained the period from the summer solistice to the autumn equinox.
And yes, you’re correct that the DIVA envelope has set it’s cutoff date for December 21, while mine is set to September 22.
I think you’re right about flexibility. I’m thinking about allowing the users to select between March 21, June 21, Sept 21 and Dec 21 (the solistices/equinoxes) as the key beginning and cutoff points. What do you think about this? I don’t want to allow users to choose any date because (in my tests with students at my school) - most don’t know enough to choose these optimal points.
As for the bugs, I think you were using the compnents from here correct: https://github.com/saeranv/cityGraph ? That’s where I started developing the components but for the record the most up to date components will be here - my forked repo of ladybug: https://github.com/saeranv/ladybug . That bug is fixed in those components.
I’ll make sure to send a pull request to Mostapha/Chris when I make significant changes, but the changes will first be made in my forked repo.
I’ll make another post with the next iteration of the components - and show you the instances where the fan changes drastically from DIVA’s model.
Thanks again Abraham,
Flexibility is important. As for your idea of 4 dates, it could be. Better than the actual situation. Even for the case of North/South hemisphere you need to allow this flexibility. In case you agree to consider maximum flexibility maybe you can implement a boolean flag, for Experts/Novice users. So the former can input freely and the later go with defaults (say, the 4 options you mentioned).
In case you don’t think this is applicable for whatever reasons, the 4 dates is a must.
Hi Abraham, I think the Chris’s version already provides the flexible version so it should be fine to have another version which is designed for more novice users/educational use. I think we probably don’t want to have two components that are exactly the same so it should be a good idea to keep the days to 4. -Mostapha
Good point!! Agree.
Thank you, Abraham, for clarifying, Saeran for explaining the situation, and Mostapha for weighing in,
I am sorry that I have been out of the loop for the past 5 days while my classes have been starting up but I’m glad the discussion has been rolling!
I understand what you mean, Abraham with property boundary rights and I’ll admit that I can potentially see some usefulness in what you are suggesting with the solar envelope. For example, I could imagine this integrated into the component as a “trimWithSiteBoundary” boolean input that a user could flip if they are only interested in seeing what is going above their property boundary. However, I have a big fear that new users might not fully understand what this operation is doing if they are first encountering my component and would therefore end up with a misleading result. In other words, I would like users to see the complete solar geometry before they trim it with the site boundary extrusion so that they are fully aware of what is going on. Also, because this trimming operation is very easy to set up with existing grasshopper components (you were able to do it yourself pretty easily in the file that you uploaded), I would rather have users employ this method rather than having something built into the component.
As for the solar fan suggestion, I think that filling in that portion of the fan would just be too misleading. I could all-too-easily see new users making the mistake of saying that a neighbor’s cantilever over the north part of their site blocks their sun, which is simply not true. Also, there is the argument that this operation (if the user really wants it) should be very easy to set up with existing grasshopper components. However, I see that in your uploaded GH file, this has not been working correctl. I have been playing around with it for the last hour and I am pretty confident that you have found a bug in Grasshopper that I will report to Guilio shortly. In the meantime, I have uploaded a new file in which you are able to get the type of solar fan that you desire. I will try to keep you posted.
As Mostapha and Saeran have suggested, I think things would be best if we press forward with having my component useful for very detailed lengthy solar fan/envelope analysis and Saeran’s component useful for quick, initial analysis. By the way, Saeran, I am really impressed with the speed of your component, especially for the solar envelope. I like the methodology you used and it’s a huge asset to the Ladybug suite.
Thanks again, Abraham, for all of the feedback and I hope that you are able to get a lot of use out of these components.
solarFan_solarEnvelope_2_A_edited.gh (62.8 KB)
I appreciate your comments. It is so nice that there are thoughtful minds behind the tools. I mean the three of you.
If i may, i believe your “proposal” of a TrimToSiteBoundary will be nice. The default can be set to False, so users get the solar geometry, as you want. But this is your call. Either way, i can tell you that both versions are an excellent contribution. Hope Saeran will agree to set the 4 dates for his version. Once he does, :-), i will update the Compare file and upload it, so everyone can have and understand the differences.
Thanks again to all of you,
Could someone tell me which file is the one of Chris, where I could change month, day and time of hours for solar fan? I have tried all files in this topic, but I can not seam to find it.
Hi Petar, I’m attaching the most recent version of Chris’s work. It works based on sun vectors. You should use the sunpath to generate sun vectors for months, days and hours that you are looking for.
Happy Valentines day, everyone!
I have updated my components with the following:
Added new icons
Changed the inputs conditionals so they behave the same way as the rest of the LB components.
Modified the SolarFan boolean union method, to deal with complex input geometries in a more user-friendly way.
Added the 4 dates option!
Debugged issues Abraham pointed out.
I’ve uploaded a gh file with the up to date components.
I will issue pull requests for both new components soon… I somehow managed to lose my Ladybug fork in its local directory while trying to update the master. Still don’t really understand github…
solarFan_solarEnvelope_2.gh (56 KB)
Very nice. Very quick.
Just a couple of comments/suggestions, if you don’t mind.
The type hint for the SolarFan month range is missing. Is very helpful to have it.
I prefer to input just one option for the month range. I mean to pick an index for a pre-defined combination of months instead of inputting two numbers. But if you don’t agree Option 1 is only Winter Solstice, Option 3 is only Summer Solstice (the hint says it is both seasons).
A typo: Solstice instead of Solistice.
Great job and thank you for sharing.
I like your point about setting the monthRange as a single number.
I’ve updated the components accordingly with typos / missing hint fixed.
The Winter/Summer Equinox is actually referring to what it is known as in the Northern/Summer Hemispheres respectively. It is confusing, I’ve clarified that in the hint now.
solarFan_solarEnvelope_2.gh (56 KB)