You can combine the integration node's designs per execution setting with HPC and DSO settings for AEDT solvers in many different ways. optiSLang can send 4 designs per AEDT call when AEDT is geared at solving 4 design variations simultaneously. Or you type 9999 into the field for designs per execution and each optiSLang algorithm will always send all designs waiting in the pipeline at once, for example, a robustness sampling of 1000 designs can be cast into one single DSO job. Due to HPC settings AEDT can still be made to break it down with ntasks=ncores=4. The drawback is that the success/failure info becomes visible in optiSLang only at the very end of the job. A large value for designs per execution can make sense for optimization algorithms demanding design sets of fluctuating size.

With population-based optimizers it can be useful to match the population size with compute resources. Maybe a population size of 24 can be perfectly suitable to busy 96 cores with four cores per design. A matched population size can help avoid job load fluctuations.

If 95% of designs need around 8 mesh refinement passes and every twentieth design is observed to consume above 10 refinement passes so that from time to time a design consumes several times the average compute time, then you can have the situation that every other group job is blocking your machine for a long time while all designs except one are finished. In such a case you may ask yourself: is it necessary that a global optimizer runs with highest accuracy? Could it not be okay to restrict the refinement passes during population-based global optimization and add a dedicated and economic local optimizer to the end of the workflow which can fine-tune with high accuracy later? Would it be okay to artificially stop the long-runners creating erroneous designs? Anyway erroneous designs will not be considered for meta-modelling or will not create huge drag for a population-based optimizer if the fraction is not too high. Why not think practically?