Galapagos ES mystery? Fittest genomes sacked

Hi there

I was running a Galapagos optimisation using its Evolutionary Solver with following, relevant settings.

Fitness: Minimize
Population: 50
Initial boost: 2
Maintain: 5%
Inbreeding: +40%

From generation 5 to 6 the fittest genomes of the pool were discarded and replaced by unfitter genomes. I thought that a Maintain of 5% combined with a Population of 50 would make sure to pass on the two fittest genomes at all times, so I don't understand this event.

Can someone explain what happened?

(I tried copy pasting the solver record into a text document, but unfortunately only half of the record was copied, which I realised too late. And btw don't be disturbed by the sudden peak in the generation fitness graph starting from generation 8, this only happens due to a filtering process, in which I give very high fitness values to already calculated genomes, so they won't reappear in the gene selection pool.)

Generation 1
Generation 5

Generation 6

Generation 8

Replies to This Discussion

Permalink Reply by David Rutten on May 21, 2015 at 5:52am

Hi Daniel,

based on the blocky nature of your genome graph (the purple on in the middle) it seems your sliders have a limited amount of possible values. Galapagos does not like to evaluate the same genome more than once so when an offspring has a genetic makeup that already once occurred in the population it will be mutated. In fact it will be mutated up to 1000 times trying to find a 'fresh' genetic makeup.

My guess is that here all the fittest genomes have been evaluated and Galapagos is now scraping the bottom of the barrel trying to do anything at all that will increase the information. This is not a problem per se, it just means there won't be another fittest genome ever again and after X generations Galapagos will call it quits.

Permalink Reply by Daniel Kolling Andersen on May 21, 2015 at 6:13pm

1. Ok, thanks David. Luckily, these incidents happen rarely in my case, but I just had another one and this time I managed to copy the solver record, so maybe you could have a look at it and verify your theory (I’ve taken a look myself but can’t make sense of it). I’ve zipped the relevant documentation.

Attachments:

Happened again.zip, 2.4 MB

Permalink Reply by Daniel Kolling Andersen on May 26, 2015 at 5:30am

Generation 6

Generation 7

Attachments:

Solver Record.txt, 107 KB

Permalink Reply by Daniel Kolling Andersen on May 21, 2015 at 6:17pm

2. Now that we’re at it and while having the privilege of your attention, I would much appreciate to discuss the nature of my genome in relation to the Evolutionary Solver.

My optimisation routine distributes structural supports for a uniformly loaded domain using e.g. the internal energy of the loaded domain as fitness. Here the uniformly loaded domain is represented by the trimmed surface.

My genomes are the support positions (green crosses), which are restricted to a set of predefined grid points. I’m currently using an (i,j)-coordinate indexing for these grid points (illustrated in the viewport just below) as opposed to a sequential , “one-dimensional” numbering (illustrated in the viewport further down).

(i,j)-indexing system
Altenative, sequential indexing system

The support positions are computed by two gene pools; one governing the i-index, Gene List {i}, and one governing the j-index, Gene List {j}, of each support. The value of slider 0 in Gene List {i} is paired with the value of slider 0 in Gene List {j} etc. and the amount of sliders corresponds to the amount of supports. The screen shot below depicts the slider constellation corresponding to the support distribution depicted above. Unfortunately the j-index represented in the sliders needs remapping as the number of j-indices vary for each i-index (horizontal row of grid points). With the current setup I have 12^6 x 9^6 = 1,6 x 10^12 different genomes.

If I were to use the sequential, “one-dimensional” numbering, I would only use one gene pool with sliders ranging from 0 to 76 meaning that remapping could be avoided and thereby having only 76^6 = 1,9 x 10^11 different genomes.

So, my current genome setup causes a bunch of issues related to the Evolutionary Solver:

Remapping
Changing one of the j-index sliders, will not necessarily change the related support position but it will still facilitate another genome to be calculated by the solver. (This problem could be eliminated by using the sequential, “one-dimensional” numbering)

Switching slider values around
If the values of e.g. slider 0 were to be switched around with the values of slider 5, this again would yield a new genome but an identical solution. (This problem cannot be eliminated by using the sequential, “one-dimensional” numbering)

Coincident support positions
Two or more supports may be located in the same position. (This problem cannot be eliminated by using the sequential, “one-dimensional” numbering)

I find it impossible to imagine the fictive “fitness landscape” of this problem and not only because of the multidimensional genome characteristic but just as much because of these listed, intertwined peculiarities. I’ve tried running the Simulated Annealing Solver as well, but my experience is that the Evolutionary Solver yields better results.

To my awareness, the solver uses some kind of topographical proximity searcher. This is why, I think that the solving process itself benefits more from analysing the (i,j)-index system, in which neighbouring grid points hold more uniform topographical information than the sequential, “one-dimensional” numbering, which might have big ID-numbering gaps between neighbours. Have I understood this correctly?

Cheers

RSS