Dynamically changing parameter bounds

[ThomasEwaldETH]

Hello there,

while using the global optimization module I realized, that I have a problematic phenomenon in my optimization problem, that I cannot solve on my own. I will describe it with a simple example:

My optimization has, say, five parameters (a, b, c, d, e), that have lower and upper bounds, which I know up front. Those five parameters determine the area of one large rectangle (a x b), the area of a number of smaller rectangles (c x d), and finally the number of small rectangles (e). I have a strict constraint, that all small rectangles must fit into the large one. If not, the solution is invalid, no matter of the objective function's return value. Problematic is the fact, that I must expect the objective function to return invalid values for the optimizer then (e.g., NaN), maybe also just errors that are raised.

Regarding the optimization, I cannot tell if, or when this will happen. I can only check this with every run inside the _evaluate method. In addition, my objective function is quite computationally intensive. Checking the constraints on the other hand is not. To make things worse, I create a plot of the Pareto front during the optimization using the Callback class. This means I don't like to have any NaNs or infs, or very large numbers in my generation evaluations, that would otherwise corrupt the plot.

My basic understanding is that this is a typical inequality constraint, that I have to provide for the algorithm class. However, I wonder when the constraints are checked in the algorithm, and what the algorithm does with the corresponding objective function's values when finding that a constraint is violated. In addition, I was wondering if there is an alternative option to proceed in the _evaluate method after a failed constraint check of this kind.

My main goals here are
a) at least make sure that the results always are valid numbers
b) save a lot of time by avoiding function evaluations that are not necessary (if possible)

I hope I made my problem clear. If not, I am prepared to elaborate further.

Best regards and thanks a lot in advance,
Thomas

[blankjul]

Hi Thomas,

interestingly problem you are working on!

I would create constraints that provide the amount of infeasibility because this will help a lot during convergence.
Also, I would not calculate F, whenever G is violated (especially if F is expensive).

import numpy as np

from pymoo.core.problem import Problem


class MyProblem(Problem):

    def _evaluate(self, x, out, *args, **kwargs):

        # write a function that >0 describes the amount of constraint violation
        # don't use a death constraint if not absolutely necessary
        G = eval_constraints(x)
        
        is_infeasible = np.any(G > 0)


        if is_infeasible:
            F = np.inf
        else:
            F = eval_objective(x)

        out["F"] = F
        out["G"] = G

During plotting you can give infeasible solutions some extra treatment, as they have no objective values to plot.

Honestly, I think you can only achieve one or the other. Either you save time not evaluating F which means you don't have valid numbers or otherwise always evaluate but lose some time.

[ThomasEwaldETH]

Hello there,
thanks a lot for the reply!
As for now, I was using a quite similar approach, where I set infeasible solutions to a high value that I absolutely do not expect from feasible solutions, because I did not know what pymoo does internally when it encounters inf. For plotting I filter out those solutions, which works quite good so far. The proposed approach gives me the courage to keep this approach, so thanks a lot!

I have a little follow-up question, where I don't know if a new topic is appropriate. In my scripts I implemented this:

def callback(algorithm: Algorithm) -> None:
    if (
        not any(child.feas for child in algorithm.pop)
        and not algorithm.termination.force_termination
    ):
        algorithm.termination.force_termination = True

which essentially terminates the optimization if any generation (I am looking especially at the first one) does not contain feasible solutions. The question is, if this is the best case to deal with it. Is it possible that the algorithm reaches feasible solutions after one generation has no feasible children? If so, my approach would terminate unnecessarily. For now, my algorithm terminates quite often due to this “hard stop”, which might be avoidable, if pymoo offers some internal, better "infeasibility-handling". Is that the case?

Best regards
Thomas

[blankjul]

In NSGA-II, at the point where the first feasible solution was found, in any generation after at last one feasible solution will be part of the generation. You can initially NSGA-II with some feasible solutions in the beginning to avoid your case: https://pymoo.org/customization/initialization.html

e.g. have a little pre-init algorithm that repeats random sampling until at least one is feasible. However, I don't see any advantage over NSGA-II just doing what it is doing anyway.

[ThomasEwaldETH]

Hello,
I tried around a little bit and found that my approach seems to terminate way to often way to early, so I agree with your suggestion to just let the algorithm run.
Thanks a lot!
Greetings and a nice day, Thomas