# Placing multiple windows on facade for optimization

Hi!

I want to optimize a single zone for energy and light metrics using octopus. Simple enough. The examples i find use a single window varying in size & placement. I want there to be up to 3 windows on the same surface that do not overlap but vary individually.

All the solutions I can come up with involve either random placement or renaming the XZ placement plane in such a way that it would disrupt octopus from learning about the genome as the generations progress. My last hand solution is making a simple pixel grid, but making this work unfortunately allows for an unlimited number of windows.

Im sure this problem has been tackled before, so I’m putting it out here instead of inventing the wheel… Thanks for ANY input!

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

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

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.

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.

1. 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.

2. 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?

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:

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.

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.