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

Attachments:

Replies are closed for this discussion.

Replies to This Discussion

Hi Saeran,

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? :-)

-A.

Attachments:

Hi everyone, 

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.

Attachments:

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.

Thanks,

-A.

Attachments:

Hi Abraham,

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,

- Saeran

Hi Saeran,

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.

Thanks,

-A.

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.

-A.

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.

 

-Chris

Attachments:

Thanks Chris,

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,

-A.

Happy Valentines day, everyone!

I have updated my components with the following:

1. Added new icons

2. Changed the inputs conditionals so they behave the same way as the rest of the LB components.

3. Modified the SolarFan boolean union method, to deal with complex input geometries in a more user-friendly way. 

4. Added the 4 dates option!

5. 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... :/

- Saeran 

I've uploaded 

Attachments:

Hi Saeran,

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.

-A.

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. 

Thank you, 

- S.

Attachments:

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service