Pre forward solve constraint evaluation

As discussed in #2 (closed) we should greedily evaluate all constraint expressions that we can before running a forward solver. This will allow us to avoid running (probably expensive) simulations. Currently we support constraints such as d1 < d2 but they will be evaluated after the simulation run.

mentioned in issue #2 (closed)

Yes I think that is a great idea

assigned to @ineichen

Is this maybe covered with #11 (closed)?

No, the greedy evaluation is something that has to be taken care of in the simulation part. #11 (closed) is dealing with evaluating constraints after the simulation has finished.

Ok so this is still open then ?

removed assignee

Sure, someone has to write the code ;). I added this issue as a future enhancement (hence the tag).. anyone who feels up to it can implement it. I leave it as unassigned for now..

mentioned in issue #13 (closed)

I also think this would be very nice to have. If no volunteer is found yet, I could have a look in about two weeks.

assigned to @snuverink_j

I had a look in the code, and to me the right place to add the constraints check is in principle in the Variator class.

However, the genes bounds check is in the Individual(bounds_t) constructor. @ineichen : Is there a reason this is not done in the Variator class? .. So to be consistent one could also add the constraints and constraints check to the Individual constructor.

The code for the constraints comparison is now (duplicated) in OpalSimulation.cpp and FunctionEvaluator.cpp and can be used almost one-to-one to the new location.

Moving this will possibly eliminate some code on the Optimizer side.

@ineichen : does that seem reasonable?

Ok, so let me see if I can answer all the questions (let me know if I miss anything):

• The Individual gets the bounds to be able to generate a valid individual upon creation.
• The Variator is handling the selection and pairing and I moved all the logic for the bounds to the individual (so we can have different Variator implementations without having to take care about the bounds in every implementation). If you think its better to do that in the Variator feel free to change.
• The constraint check in the OpalSimulation was added for Andrew (homotopy optimizer) and was something to get him up and running. I'm fine with moving the constraint check to the optimizer side (the simulation side should not know anything about constraints etc.) but make sure to check with @ext-kranjcevic_m (the idea to correct some individuals on the simulation side can be useful).

Basically the design goal was to be as flexible as possible and allow users to add new variators/optimizers/forward solvers/communication strategies/.. as easy as possible. If one would design everything with a fixed Variator/Optimizer and forward solver in mind, I think the design would be quiet different ;).

of course want to keep the flexibility but just cleanup and remove old stuff.

Well you might have to think about that.. maybe it makes more sense to forfeit some of the flexibility for easier/simpler maintenance etc. Probably the code can be simplified a lot by fixing the forward solver (when moving the pilot to the opal repo).

Thanks for the comments, I think I have a good idea now how it can be implemented, will do this probably next week.

Well actually in the master the optimizer is fully integrated. I would like to keep the flexible structure w.r.t. Variator/Optimizer, the forward solver is OPAL. The forward solver can be fixed forever

closed via commit src@fa92139e

It was a bit more complicated than expected as I initially hadn't realised that constraints for objectives still need to evaluated afterwards. Implementation is probably not done in the cleanest way, comments are welcome. Also the code still needs testing on a real example.

mentioned in issue src#153 (closed)

mentioned in issue src#167 (closed)

mentioned in issue src#218 (closed)

reopened

I reopened this issue because src#218 (comment 5871)

Probably this is not fixed yet, since I forgot to tests the constraints on the cross-over individuals. Further discussion in src#218 (closed).