Suggestion for improvements to the Optimiser

Some suggestions and observations to improve usability of the optimiser by Michael Abo-Bakr (as far as not already covered in other issues):

• For 1 or 2 optimisation parameters there is no hypervolume calculation.
• It would be very nice to get at the end a final best solution in the output (defined with some cost function)
• .json format is not always ideal for reading or writing new generation files (as starting condition)
• Not all individuals appear to be really new.
• Option to adaptively change optimisation parameters (mutation, crossover etc.)

added Enhancement Feature request Optimiser labels

@snuverink_j The last point. Does it mean during an optimisation? You can already set the mutation or crossover type.

@frey_m Yes changing these values during an optimisation run. In many optimisation algorithms it is common to adapt e.g. the convergence rate (aka learning rate).

I am not sure how feasible all of these points are. We have to see which ones we would like to implement.

assigned to @snuverink_j

@snuverink_j @frey_m where are we with that request? Is that nice to have (then close) or a must ?

@adelmann closing an issue if it is "only" nice to have is ok, but we should keep this ideas/requests somewhere else. Maybe in the Wiki? Or a dedicated issue tracker for feature requests we are not going to implement soon?

@adelmann : We haven't done anything on this. I would like to discuss at some point, if we are going to keep the optimiser. I have the impression there are some issues with it, like the duplicated individuals, or if once pyOPAL is there, we would move to a MOO python implementation anyway. In the latter case, I think working on expanding the optimiser might not be worth it.

Sorry, I don't understand why we should delete issues even if they're "just" nice to have. I don't mind if the number of open issues is big. At least we have them documented somewhere and it really doesn't cost us a dime.

I think it is good to go through the issue list once in a while to see where we are with things, so I welcome the effort, since we have never done this. But I also agree that we shouldn't close issues when the mentioned issue is still open.

Going through the list of all issues and asking what the status is is fine and even setting the weight (so far we don't use this feature in gitlab) to a low priority is fine. Also to close an issue after a discussion among the developers can be done. We don't have to implement every wish. I just oppose to the practice to simply closing feature requests especially when I already have invested time into it.

I fully agree.

changed weight to 12

removed the weight

changed weight to 1