Solar calculation plugin

Replies to This Discussion

Permalink Reply by Abraham Yezioro on June 11, 2013 at 2:07am

Hi Eirik,

Nice plugin.

Is there a way to control the scale of the Fan you are getting? Sometimes you might need bigger distances to be covered/influenced.

Another one: Will be useful to input the hours range instead of the whole day.

Thanks,

-A.

Permalink Reply by Eirik K on June 12, 2013 at 11:51am

Ver 0.2

 - I swapped the Brep.CreateSweep methods with the PerformSweep() method of the  Rhino.Geometry.SweepOneRail Class - and the script became 20-50 times quicker calculating Context intersections (because of a cleaner Brep there are less points to evaluate)

- Implemented the scale and time range suggestions from Abraham Yezioro.

Cheers, and thanks for your input.

Attachments:

• sunpath ver0-2.gh, 31 KB

Permalink Reply by Abraham Yezioro on June 12, 2013 at 2:38pm

Very nice.

Another suggestion: Could be useful to know the times the sun is unobstructed. Knowing how many minutes you have sun is OK, but knowing the times will be great.

-A.

Permalink Reply by Eirik K on June 14, 2013 at 6:41am

antoher update.

Ver 0.3

- fixed minor bugs on context intersection

- added sunrise/sunset + blocked time of date

Attachments:

• sunpath ver0-3.gh, 37 KB

Permalink Reply by Abraham Yezioro on June 15, 2013 at 12:18pm

Hi Eirik,

First of all thanks for your work.

But ... now i'm getting confused. Some issues are appearing:

Please open the attached. You"ll see that no fan is created even though the location of the point is fine.

When i do succeed with the fan creation (most of the times) the blocked fan is flattened and located over the 0 height level. Is this what you intended to? If i may suggest, will be better to draw it with a different color (as you are doing), but with the real geometry and not flattened.

I believe there is a problem with the hours printed in the sunpath. They are hard to read but the numbers seem to be wrong for me.

Speaking about the hours, their input is not clear for your calculation component. I assume that the "starting hour" is pretty straight forward (but sometimes the sunpath disappears when i get to some hour). The "Time Range" is unclear. I suggest Start Hour and End Hour, so i know that if i want to see the fan from 10 am to 2 pm i'll give 10 and 14 (or something similar).

Hope i'm not bothering you too much.

-A.

Attachments:

• sunpathver03_A.3dm, 195 KB
• sunpathver03_A.gh, 35 KB

Permalink Reply by Eirik K on June 17, 2013 at 6:15am

Hi Abraham.

Thanks for your feedback. I'm a little busy with my master's thesis at the moment, but I'll look into it as soon as possible.

A couple of notes:

Try to shift the GMT slider on the top to +3 (for Haifa), that should give you more accurate times?

As this is part of a much larger genetic algorithm, I have made some choices for speed over accuracy.

The script generates the time for each 3 minute within the timeframe of the selected day. The sun vectors of these build the basis of the solar path on that day. Each minute would be more accurate, but also take longer to calculate.

My first idea was to intersect each sun vector with the surroundings. This would give me (with an accuracy of a minute/3 minutes accordingly) the excact time of the block. It would also mean that I had to potentiale check 60 * 14 = 840 for interactions with all context. So my approach was a bit different. I know the length of the solar path. I know the exact time of where this path starts/ends. So I approximate solarPathLength/minutes = length of a unit along the sun path. When I find a block, I check the length of the block and see how many minutes this would approximately be. As this is all math, it is very quick. But not super accurate. It gives me the indication I need though.

Cheers, Eirik

Permalink Reply by Abraham Yezioro on June 17, 2013 at 8:14am

Hi Eirik,

Your approach sounds fine by all means. I don't know what are you trying to optimise, but in case it is related to energy consumption (for instance) i would suggest to add an "Accuracy" slider, so you, or any user can decide the "price" you or he, is willing to pay: Increase accuracy = increase time calculation. I would give 3-4 levels: Very accurate (1 minute), Close accuracy (3-5 minutes), Approximate accuracy (10-15 minutes), Rough accuracy (30 minutes), or something similar. It could be nice to compare results, so maybe for some situations you can be satisfied with the less accuracy ...

Interesting in any case.

Keep going and thanks,

-A.