rute force algorithm analysing all possible support constellations and their related w[max] values. Therefore I know the global optimum value of the fitness (smallest w[max]) and its related genome (location of the three point supports). Now the reason I've done this, is because I wanted to test whether one type of genome data structure would yield better results when fed to the Evolutionary Solver of Galapagos. The two genome data structures tested were the following types:
Sequential genome indexing for support positions, uses one slider per point support [supports @ node 2, 23 & 25]
Coordinate genome indexing for support positions, uses two sliders per point support [supports @ node (0;2), (3,5) & (4,1)]
My own hypothesis beforehand was that the coordinate indexing system would be the better performer, as I had imagined that the solver might build up some kind of geographic intelligence based on this genome information system.
Based on my tests with the Evolutionary Solver the two genome indexing types seem to perform equally well; they both manage to find the optimal fitness sooner or later with same hit rates. But now I worry that the used example might be too small to draw a final conclusion upon, and as I will be applying the same type of deflection analysis for more complicated deflection cases with both larger and arbitrarily shaped meshes having more than three point supports, I would like to ask:
Should the coordinate indexing system, theoretically speaking, perform better than the sequential indexing system? …
stributes 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 systemAltenative, 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…