Gunnar Völkel

The singleton pattern is a very unfortunate choice for JMetalRandom since this prohibits parallel reproducible algorithm runs. Parallel algorithm runs will interfere unpredictably with the JMetalRandom singleton. Hence, it is...

Dropping the singleton approach and configuring the algorithm instance with a pseudo-random number generator would be the cleanest design. Though this is much more work than ThreadLocals fix mentioned above.

The algorithm could pass its PRNG instance to its operators during initialisation.

Just to be clear: my criticism of the singleton approach came from a real use case - parameter tuning of an NSGA-II algorithm with parallel evaluations on several different computation...

The point in one sentence: I need reproducible algorithm runs using specified seeds such that each run has exactly the same sequence of random numbers. This fails with a global...

Correct, several algorithm runs in the same JVM in parallel. In the tuning setup the fitness evaluations are done sequentially.

Yes, each algorithm run (e.g. NSGA-II) must have the same sequence of random numbers.