adding naive bfe implementation for moead

[kirbyherm]

If bfe enabled for moead, for each generation, the algorithm will first create all the individuals to be evaluated and then batch evaluate the whole population at once. This allows for parallelization of the fitness evaluation, but sacrifices the ability for the algorithm to create individuals based on previously evaluated individuals in the same generation.

[darioizzo]

I think the logic is that of the implementation in this paper? : https://link.springer.com/chapter/10.1007/978-3-319-10762-2_70 If so we could consider to create a separate algorithm pade? another option is to follow the pattern we had for PSO with a pso_gen?

The difference being between the steady state version and a generational one. The advantage is to keep the algorithm results identical if a bfe is passed. @kirbyherm ?

[kirbyherm]

Yes I agree it makes sense to split this away from the base moead algorithm. What I coded is basically a generational moead so we could just take this and split it off into a moead_gen algorithm.

I can't say I fully understand how pade works, but would that be something we could just pull directly from the old pagmo repo?

@darioizzo what would you recommend?

[kirbyherm]

Finally circling back to this, I will split off my current implementation into a moead_gen algorithm which is identical for both parallel and serial evaluation.

I'll take a quick look at the pade paper and see how difficult it would be to implement here.

@darioizzo

[darioizzo]

Fantastic, I was not suggesting to imement pade, only to check if the logic is similar ... and if not to quickly point out the differences ....

[darioizzo]

@kirbyherm I think that is unavoidable without overengineering excessively the code, and not really the bottleneck since, as you noted, bfe should only be used when the fitness evaluation footprint is anyway a main component. (pinging also @bluescarni here who wrote the bfe data structures and maybe can suggest a different solution?)

[kirbyherm]

@darioizzo @bluescarni If there's not any other suggestions for this, is there anything more to take care of before pulling in this branch? From what I can tell the only error on the tests came from a connection error in the CircleCI test?

Then there is the question of making the appropriate changes to the pygmo interface as well so we can call this algorithm from there.

Let me know what the next steps are..

[darioizzo]

Absolutely! I think its ready for merge, just want a last quick check from @bluescarni on your earlier question ...

[kirbyherm]

@darioizzo @bluescarni

checking back in on this, is it possible these changes can be accepted and worked in with the python bindings?

I'm looking to add this capability to some simulations I'm working with but can only work with the prebuilt/conda installed libraries on the servers I use.

Thank you both!

[darioizzo]

Ok for me. Merging.