Placing multiple windows on facade for optimization

Replies to This Discussion

Permalink Reply by Ludvig Haav on January 31, 2016 at 4:17pm

Btw, is this too off topic for this group? Im drifting away from talking about HB/LB components..

Permalink Reply by Mostapha Sadeghipour Roudsari on January 31, 2016 at 5:19pm

Hi Ludvig,

Problems similar to this have been studied before and there are a couple of solutions. You definitely don't want to go toward the random option. Back to the overlapping problem you can either merge the overlap windows or move them aside once they are overlapped and keep track of the distance from the base case as one of the objectives that you want to be minimized.

Do you have any sketch of what you have in mind? and why there need to be 3 windows?

Mostapha

Permalink Reply by Theodoros Galanos on January 31, 2016 at 6:30pm

A grid indeed seems the easiest way to start. I was thinking of using a similar technique for electrical lighting optimization with the new HB components.

In a definition I have, where I wanted to keep 2 geometries from overlapping what I did was similar to what Mostapha suggests. I measured for the distance between the two edges I wanted to keep apart and then set an if statement with the minimum distance I wanted. When that check failed, the false boolean was fed into the simulation component. When it passed the true was passed instead and the simulation would go on. In you case, given that the windows have a constant size and geometry, I'm sure you can find a formula to check the distance between the area centers (e.g. in a square min distance is x/2, etc.)

Not sure if it is the most elegant of solutions but it seemed to work quite well. Furthermore, this check would limit substantially the number of alternatives you will be checking with Octopus. 

Permalink Reply by Ludvig Haav on February 2, 2016 at 7:46am

I've decided to simplify things by just allow the 3 windows to move around in their individual bounding surfaces. It does not cause that many limitations in my case. 

Both of your propositions are interesting. And i have a connected question that has to do with them both; how to minimize computation time while not messing up the solution landscape. I have 4 sliders right now. Two for placement position and two for window size. Some values for window size are unnecessary in certain window placements as it would cause overlapping of surface boundary. I have several ways of dealing with this, all affecting the fitness landscape:

1. make certain slider positions create redundant values, i.e windows cant grow. octopus will be simulating some of those positions all the same. There are sadly no sliders with dynamic bounds to my knowledge, and if i were to use one Im not sure how it would confuse octopus - having genes vary outside its control.

2. penalize overlapping by skipping simulation and assigning it values that gives it a "bad spot" in the solution space, much like Theodoros proposes. Saves computation time but I am worried about discontinuity of fitness landscape.

3. Setting the overlap as an objective to be minimized, like Mostapha proposes. I imagine this works but would require a fair amount of simulations with overlapping windows. I guess it would be similar to the alternative 1 in terms of computation time.

4. Manually creating a list of all possible window position and sizes. Reducing the gene sliders to only 1 instead of 4. hmmm... what impact would that have? I have a feeling its not good.

What do you think?

Permalink Reply by Mostapha Sadeghipour Roudsari on February 5, 2016 at 9:50pm

Interesting! I like number 2 but if you're fine with having boundaries what about something like this.

Evaluate base surface based on UV (2 slide). Find closet point to edges and then remove one of them (1 slides). This will give you 3 different regions. Now you can assign glazing percentage for each window (3 slides). Total 6 slides and it will give you enough options. I didn't create the regions but here is the logic:

Permalink Reply by Theodoros Galanos on February 6, 2016 at 7:40pm

Hi Mostapha,

Thanks for that, looks like a very nice way to do it!

@Ludvig

Thought that this could possible be of interest to you.

Danny's definition apparently places the windows and tests for a valid boundary between the wall (valid = no overlapp). He then stores the fitness of those boundaries only in the optimization process. Geometrically it seems close to what Mostapha is doing only taking an opposite route of creating windows first taking region after. I have to warn you I haven't tested it myself yet. 

Kind regards,

Theodore.

Permalink Reply by Ludvig Haav on March 10, 2016 at 6:19am

Thanks for both of your input!

I ended up only placing one window per surface for other reasons, but mostaphas solution for multiple windows is saved for future use. its nifty.

In my fenestration algorithm I will always have instances where different genome create the same geometry. Unfortunately. Also, I´ve realized that octopus by nature wants to do multiple runs with the same genomes as generations progress. Now I am looking to build a database of simulation results tied to geometry. So that when octopus creates a genome --> builds a geometry i will check this geometry and see if its been simulated before, and if it has I will supply this result to octopus, bypassing the simulation run. This should save time. I'm gonna try to do this with native components within GH. If anyone has done this or has an efficient way to do it, I´d be happy if you shared it. :)

It seems it would be a workflow that could save computing time in every case you have high computaional burden and discrete slider values.