Can gamultiobj skip over instances where the function cannot solve?

I am solving a complex dynamic model describing an adsorption process. With some specific combinations of variables the function becomes very stiff and at times does not solve. Is it possible to that the gamultiobj can skip over instances where the function does not solve and continue to run?

[Torsten]

gamultiobj or a helper function needed to evaluate the objective (e.g. an integrator for ordinary differential equations) do not solve ? We need more details.

[Lucy Barton]

Thank you! Yes this is correct. It is a very complex system of partial differential equations solved using a finite volume method (WENO) and then put into the ode15s solver. There seems to be few instances where the ode15s solver struggles and hits the minimum timestep and does not solve. What happens then is the entire GA stops. It is a very stiff problem. The equations used in the finite volume method have been checked and verified many times and solve okay in most instances. I believe that it is the ode sovler struggling with some combinations of variables passed through by the GA.

Answer 1

[Walter Roberson]

gamultiobj() is constantly evaluating the objective function over a population of values. It does cross-over and mutation to produce new population members. It keeps the best-performing fraction of the population unchanged and mixes in the best-performing remainder of the cross-over / mutated values.

For any one population member, the population member effectively will die if the objective function returns inf. But it is probably best filter out exceptions using the nonlinear constraints.

If the entire population dies off, gamultiobj will stop and will return the best existing results.

Now... I suspect that what you are talking about is a situation where gamultiobj gets "stuck", where the population is not productive. You have some control over the behaviour by modifying the MaxStallGenerations and MaxStallTime options. But if those are activated, gamultiobj will stop rather than continuing to run.

gamultiobj() does not have any option to somehow repopulate and carry on if a population gets "stuck"

Note that if you ask for the final population to be output, then you can filter it as desired and then call gamultiobj() again, passing in the filtered population using the InitialPopulationMatrix option.

[Lucy Barton]

Thank you! There seems to be a few combinations of my decision variables where the ode15s solver hits the minimum time step and fails. In this scenario it seems the entire GA is stopped with no results. I will have a look into the initial population matrix option and whether max stall generations can help me with this. If the GA stops as a result of this error am I able to still output the final population somehow?

Answer 2

[Star Strider]

II am not certain about gamultiobj because I have very limited experience with it. However ti has been my experience when using ga to optimise a system of kinetic equations to estimate the kinetic constants (system parameters), if the diifferential equatiion integrator (usually ode15s) returns an error when the integration stops because it encounters a singulalrity, ga keeps on going and eventually discovers a set of parmaeters that ode15s has no problems with. It then proceeds to optimise the system.

If you are having problems with a stiff system, use a stiff solver such as ode15s or ode23s. That should work. Usiing ode45 to integrate a stiff system could take forever.

[Lucy Barton]

Thank you! I am using ode15s for the system. For most combinations of variables it is fine but there seem to be a few scenarios where ode15s fails (i.e. hits the minimum time step). If this happens then the ode15s solver does not solve and the whole GA stops. I was hoping for these very few scenarios the GA could throw that combination of variables out and continue to run.

[Star Strider]

My pleasure!

The ‘minimum time step’ error means that initegrator is encountering a singularity (±Inf). I don’t know of any specific way to avoid that, although specifying bounds on the parameters (if you have a good idea of what their ranges should be, for example individual kinetic parameters are usually bounded on [0,1]) may work in some instances. Specifying an 'InitialPopulationMatrix' as part of the optimoptions call may also help to avoiid this, since it limits the parameter range values.

Answer 3

[Torsten]

Schemes that discretize the first-order derivatives second-order accurate and stable often lead to problems with the ode integrator because the discretization is discontinuous. In my opinion, a less accurate scheme with a continuous discretization like the first-order upwind scheme is better suited in the present situation than WENO. You can compensate for the lower accuracy by choosing more grid points in the spatial direction. Or you could use the parameters obtained from the less accurate method as initial guesses for your WENO method.

Another thing you could try is to give bounds to the parameters to be estimated so that the system remains physical during the optimization.

Or see what happens if you return +Inf or NaN in cases where the integrator fails and see how gamultiobj reacts.

Answer 4

[Lucy Barton]

Thank you @Torsten, @Star Strider and @Walter Roberson for the advice it has helped a lot! Based on this I printed the decision variables in the fuction to check at what instances the ode solver failed. From this I could identify which two variables (their interaction) was causing the problem and implement a linear inequality constraint in the optimiser and some conditional changes to the ode solver options to help move past this. This has allowed me to not over constrain the variables. I have also implemented an initial population matrix - lets see how it goes. I will have a look at the first order upwind scheme!