Evaluating expensive blackbox constraints?

[the-alleged-car]

Hi,

Is it possible to use pySOT with expensive blackbox constraints?

For example, if the objfunction() method in the optimisation problem class can be written to use an external piece of simulation software, then how might this be applied for the eval_ineq_constraints() method?

In my case, I would be interpreting simulation results from an external program to provide objective function values and constraint function values to pySOT. But the eval_ineq_constraints() method seems to accept a numpy array for a number of different points all at once, unlike the objfunction() method which accepts one point at a time to be evaluated (if I understand the ReadTheDocs documentation properly). Also, it seems to me that it is possible that objfunction() and eval_ineq_constraints() are not necessarily called as a pair - objfunction(x) could be called multiple times for different x before a single call to eval_ineq_constraints() might be performed which evaluates the constraint functions for multiple points during that single call to eval_ineq_constraints().

I think it is possible for a user to write their objfunction() and eval_ineq_constraints() in a clever way to be able to make efficient use of each call to the external simulation program, e.g. storing both objective and constraint function values from an external simulation run for a point even, if invoked by only one of objfunction() or eval_ineq_constraints(); hence the stored values can be checked by future objfunction() or eval_ineq_constraints() calls later in the optimisation to avoid repeating external simulations if we already have the information stored by an earlier call.

In addition, I have another related question: if there are to be 500 objective function evaluations in an optimisation, then there would also be 500 evaluations for each constraint, where the objective and constraint functions are evaluated on the exact same set of points? I am not familiar enough with either optimisation in general or pySOT in particular to know for sure.

Many thanks.

[dme65]

There is currently no support for computationally expensive constraints, and as you saw in my previous reply, all constraint handling was removed in 0.2.0. There is clearly support from POAP to pass the values from computationally expensive constraints back to the strategy, but we have no strategy that can handle this.

The standard approach to computationally expensive black-box constraints is to use surrogate models to approximate the constraints. Such a strategy will fit well with the new framework, but I'll need help with the implementation since I just graduated.

We definitely need support for analytical and black-box constraint handling.