Restarting Genetic Algorithm after Crash

I'm using the GA to update my Finite Element Model. The fitness function I am using is computationally expensive and takes 4sec each time it is called. Given that my population size is 200, each generation takes about 13min of computation time. I've set an upper limit of 260 generations, so this process should take a bit more than two days to compute. Of particular concern to me is that my fitness function calls on my Finite Element software (Strand7) which tends to crash from time to time.

I have used the 'OutputFcns' option in gaoptimset along with a function that saves the 'state' structure. This ensures that I have a backup of the state of the last completed generation, prior to crashing.

My question is, "how can I recommence my GA from the last generation using the 'state' structure?"

Answer 1

[Alan Weiss]

You can at least get the population from the state structure, and use it as an initial population if you have to restart the optimization. I think that this should do for most purposes. Of course, you should also adjust the number of generations left to go.

Specifically, I think the following should work:

 thePopulation = state.Population;
 options = gaoptimset('InitialPopulation',thePopulation,'Generations',130);

But if you will take my advice, forgo using GA, and try using PATTERNSEARCH. Generally, PATTERNSEARCH is faster, more robust, and easier to tune. You might want to start it from a variety of initial points. You can use any points you want as initial points, but for random initial points when you have finite bounds LB and UB on every component, you can try

 x0 = LB + rand(size(LB)).*(UB - LB);

Also, for such a computationally expensive function, be sure to turn on the cache option.

 options = psoptimset('Cache','on');

Good luck,

Alan Weiss

MATLAB mathematical toolbox documentation

[Craig Cowled]

Alan,

I gave PATTERNSEARCH a go. Had to leave the cache option off because my objective function is stochastic in nature and the Matlab help file recommended leaving the cache option off in such circumstances.

I see what you mean about PATTERNSEARCH being quicker than GA, however, I seem to get better results from the GA. After watching the algorithm chug away, I'm beginning to think that I might need to reduce the upper limit on mesh size. Currently, the max mesh size is 1, however, my LB is 0 and my UB is 1. ... I'm guessing it would be better to limit my mesh size to, say, 0.2 or 0.3.

Answer 2

[Craig Cowled]

Many thanks yet again, Alan. Will write a little function to handle the crash and restart the GA.

As for patternsearch, I might run a parallel optimisation problem (on another PC) and compare the results.

Have also given some thought to using Parallel Computing to speed things up. I gave it a try, but encountered some problems. I realised that I would have to call the Strand7 library every time the fitness function is called (at a cost of a few seconds), making the potential gain of parallel computing minimal.

Craig.

[Craig Cowled]

Just a tip for anyone who may be thinking of using a computationally expensive fitness function. I have noticed that the GA can produce populations where many individuals have the same "genes" (in my case, parameter values).

In order to catch the genetic copies, I have initialised a variable prior to calling the GA. Then, inside the nested fitness function, I check to see if x (i.e., the "individual") matches any previously calculated fitness values of x and return those values instead of running the computationally expensive Strand7 solvers.

The following code has speeded up my optimisation by a factor of 3 or 4 times:

    function x = NestedGA(nvars)

    % create a temporary variable for the purpose of checking whether the
    % individual is unique.  Note size not preallocated because size varies
    tempx = zeros(1, nvars + 1);
    [x, FitFunVal] = ga(@Fitness, nvars);

    % this nested function has access to the variable tempx
    function FitFunVal = Fitness(x)

    % check whether x is a unique individual
    Ltempx = size(tempx, 1);
    [Lia,Locb] = ismember(x,tempx(:, 1:nvars),'rows');

    % If the individual is not unique, return previously 
    % calculated fitness value
    if Lia == 1 
        FitFunVal = tempx(Locb, nvars + 1);
    else
        % if unique, increase size of tempx and write data to new line
        tempx(Ltempx + 1, 1:nvars) = x;

        FitFunVal = % Write your Fitness Function processes here

        % write this value to the tempx variable
        tempx(Ltempx + 1, nvars + 1) = FitFunVal;

    end

    end    % Fitness()

    end    % NestedGA()

[Craig Cowled]

It seems that the tempx variable really does need to be preallocated. As the variable grew, I noticed a definite slowing.