Why execution time increases? about jmetalpy HOT 8 CLOSED

Which problem are you solving and how have you configured OMOPSO?.

Just have into account that OMOPSO uses an external archive to store the non-dominated solutions found during the search. When that archive becomes full, a procedure to remove the worst solution (in the case of OMOPSO, an EpsilonDominanceComparator is used) is applied. If the archive size is large, this can take time; furthermore, this is a sequential step, so adding more cores will not help.

from jmetalpy.

I'm trying to estimate parameters for an epidemiologica compartment model. I've used the configuration present in the documentation, just changing swarm size( in order to keep it between 5 times and 10 times the dimensionality of my problem) and changing the number of iteration. The epsilon value suggested is epsilon=0.0075, how can I change this value in order to keep the archive small?

from jmetalpy.

Have you checked the size of the archive using that epsilon value?

from jmetalpy.

algorithm = OMOPSO( problem=problem, swarm_size=swarm_size, epsilon=0.0075, uniform_mutation=UniformMutation(probability=mutation_probability, perturbation=0.5), non_uniform_mutation=NonUniformMutation(mutation_probability, perturbation=0.5, max_iterations=int(max_evaluations / swarm_size)), leaders=CrowdingDistanceArchive(100), termination_criterion=StoppingByEvaluations(max=max_evaluations) )
This is the code that I run, how can I check the size of the archive?

from jmetalpy.

The size of the leaders archive is 100, so it seems ok. Have you tried SMPSO instead of OMOPSO?

from jmetalpy.

no, which are the main differences?

from jmetalpy.

SMPSO is based on OMOPSO, but it does not use epsilon dominance (https://ieeexplore.ieee.org/document/4938830). It can produce more accurate fronts than OMOPSO when dealing with multi-frontal problems (as, for example, ZDT4).

from jmetalpy.

Ok, thanks. I'll try it.

from jmetalpy.