Oscillating Pareto front

Good morning,

I am trying to optimise a complex shading screen for solar gains and daylight, with Octopus and DIVA.... and so far have struggled to achieve any meaningful convergence.

Looking at the results of different test runs, the pareto front does not seem to be really moving forward meaningfully, but rather 'oscillate'. I understand there may be a number of reasons why it does not converge - like a problem in the grasshopper definition, population too small, mutation rate too high, etc.... but why is the pareto front allowed to go backward at all? Shouldn't a good solution in the SPEA2 archive only replaced by a better one: one that dominates it?

See attached plot. Based on a population of 70, archive 30, mutation rate 0.15, with Octopus 0.1 (for GH 9.0014).

Has anyone experienced similar problem? any idea what could be wrong? suggestion where to look?

Thank you.

Fred

(My other point about conservation of the archive has been edited-out as there was a bug in my post-processing script)

Attachments:

Oscillating pareto front.jpg, 51 KB

Replies to This Discussion

Permalink Reply by fred labbe on July 1, 2013 at 15:07

Hi all - I have found the reason for this 'oscillating' Pareto front, might be useful to someone some day...

I calculate the daylight factor for a grid of points within the building using DIVA for Rhino. DIVA uses Radiance to calculate the daylight factor, which involves a stochastic process... as such the results are slightly different each time. These relatively small deviations in the daylight results become significant in a GA when the steps form a solution to a better one are relatively small. This causes the oscillations and lack of convergence.

I have fixed the problem by taking the mean daylight factor as a performance indicator rather than the percentage floor area with daylight factor < 2%.... this is much less sensitive to the deviation in daylight results.

And it works...!

Fred

Permalink Reply by Nitë on April 19, 2015 at 9:12