Closed MuellerSeb closed 5 years ago
Hi Sebastian, thanks for your message. This behavior is indeed a bit strange. However, I am pretty sure it is “just” a parallel printing issue. Still, it needs to be solved. As I recently changed some minor things in the parallelization of sce-ua, I need to make sure, that we are using the same version. I just uploaded a new version on pypi (1.4.5). Would you be so kind and test this one again? If the bug is still persisting in this version, I will look closer into this.
I just updated spotpy
, but the behavior is the same. Also the estimated time goes up to the same estimated time with sequential optimization.
Again: Burn-in phase works just right. From ComplexEvo loop #1
on repetition counter becomes unsorted and the estimated time goes up to the sequential time estimate. I don't know, what I could have done wrong on my side.
Perfect, thanks for testing this again. I found some lines in the code of sceua, where the slaves during parallel computing and complex evolution had access to the status of algorithm.py. As the slaves can have different speed, this might have mixed up the tracked repetitions and time shown in the printing message. I think this should be fixed now.
I would assume that the unsorted repetition counter is based on how mpi is implemented. The like values are printed in the mpi-loop, so if a process with a higher repetition count finishes before one with a lower repetition count, it is first printed to the screen.
I think this is clarified. But a new issue came up after version 1.5.0: https://github.com/thouska/spotpy/issues/226
Hey there, when I run the sce algorithm in parallel, the burn-in phase works just right, but afterwards it seems, that there is something going wrong with the parallel processes. The estimated time goes up and the run numbers start to repeat and are sometimes not in an increasing order:
Do you may have a guess, what's going wrong? Thanks in advance!