[RBFOpt] R: Problem with parallelization
Cristina Elsido
cristina.elsido at polimi.it
Mon Mar 16 09:49:12 EDT 2020
Dear Giacomo,
I solved the issue by wrapping the script with the "if __name__ == '__main__'" block, as you suggested.
Now the parallelization works fine both for the minimal example and the expensive black-box function.
Many thanks for your help!
Best regards,
Cristina
________________________________
Da: Giacomo Nannicini <giacomo.n at gmail.com>
Inviato: sabato 14 marzo 2020 20:44
A: Cristina Elsido <cristina.elsido at polimi.it>; rbfopt at list.coin-or.org <rbfopt at list.coin-or.org>
Oggetto: Re: [RBFOpt] Problem with parallelization
That seems to be a problem with the multiprocessing Python library.
Maybe there is some recursive initialization going on.
Did you properly wrap your script in a "if __name__ == '__main__'"
block? The multiprocessing library imports the modules every time, so
it may keep importing the main script if it is not inside such a
block.
However, you mention that this happens also with the minimal working
examples, so I am a bit at a loss: that example works on every
platform that I tried it on; this makes me think that the problem is
with your particular platform, but I am not sure what's causing it.
Could you tell me your configuration (architecture, python version)
and post the script that you are trying to run? (Or a simpler version
of it)
G
On Fri, Mar 13, 2020 at 6:27 AM Cristina Elsido
<cristina.elsido at polimi.it> wrote:
>
> Hi Giacomo,
> Sorry that I was not clear. By getting stuck I mean that nothing happens and there is no output shown to screen.
> In the serial case, this is the output printed in the console:
>
> runfile('C:/Users/elsido/Desktop/Prove_Rbfopt/prova_serial.py', wdir='C:/Users/elsido/Desktop/Prove_Rbfopt')
>
> Iter Cycle Action Objective value Time Gap
>
> ---- ----- ------ --------------- ---- ---
>
> 0 0 Initialization -0.782797 3.02 100.00 *
>
> 0 0 Initialization 59.515133 3.02 100.00
>
> 0 0 Initialization 20.000000 3.02 100.00
>
> 0 0 GlobalStep 26.484123 7.14 100.00
>
> 1 0 GlobalStep -9.996551 7.58 100.00 *
>
> 2 0 GlobalStep 0.066845 7.91 100.00
>
> 3 0 GlobalStep -8.247187 8.19 100.00
>
> 4 0 GlobalStep -8.500124 8.56 100.00
>
> 5 0 LocalStep -10.000000 8.79 100.00 *
>
> 6 1 GlobalStep -0.010023 9.12 100.00
>
> 7 1 GlobalStep -7.460795 9.41 100.00
>
> 8 1 GlobalStep -9.941907 9.83 100.00
>
> 9 1 GlobalStep -9.992450 10.31 100.00
>
> 10 1 GlobalStep -9.992260 10.69 100.00
>
> 11 1 LocalStep -10.000000 10.94 100.00
>
> 12 2 GlobalStep 99.331824 11.26 100.00
>
> 13 2 GlobalStep -5.108895 11.56 100.00
>
> 14 2 GlobalStep -9.874616 11.88 100.00
>
> 15 2 GlobalStep -9.892637 12.18 100.00
>
> 16 2 GlobalStep -9.997121 12.49 100.00
>
> 17 2 LocalStep -10.000000 12.77 100.00
>
> 18 3 Discarded 12.81
>
> 19 3 GlobalStep -0.001899 13.17 100.00
>
> 20 3 GlobalStep -5.979762 13.47 100.00
>
> 21 3 GlobalStep -7.675801 13.75 100.00
>
> 22 3 GlobalStep -9.963098 14.05 100.00
>
> 23 3 GlobalStep -9.999701 14.37 100.00
>
> 24 3 LocalStep -10.000000 14.96 100.00
>
> 25 4 GlobalStep 0.305285 15.27 100.00
>
> 26 4 GlobalStep -8.985101 15.70 100.00
>
> 27 4 GlobalStep -9.902675 16.00 100.00
>
> 28 4 GlobalStep -9.987039 16.43 100.00
>
> 29 4 GlobalStep -9.976530 16.82 100.00
>
> 30 4 LocalStep -10.000000 17.14 100.00
>
> 31 5 GlobalStep 87.907661 17.47 100.00
>
> 32 5 GlobalStep -5.088840 18.00 100.00
>
> 33 5 GlobalStep -9.915832 18.35 100.00
>
> 34 5 GlobalStep -9.999337 18.69 100.00
>
> 35 5 GlobalStep -9.580714 19.03 100.00
>
> 36 5 LocalStep -10.000000 19.41 100.00
>
> 37 5 RefinementStep -6.357577 19.56 100.00
>
> 38 6 Discarded 19.56
>
> 39 6 GlobalStep 30.981585 20.00 100.00
>
> 40 6 GlobalStep -5.263918 20.38 100.00
>
> 41 6 GlobalStep -9.974259 20.93 100.00
>
> 42 6 GlobalStep -9.991540 21.24 100.00
>
> 43 6 GlobalStep -9.998681 21.59 100.00
>
> 44 6 AdjLocalStep -9.997359 22.15 100.00
>
> 45 7 Discarded 22.16
>
> 46 7 GlobalStep 36.620812 22.57 100.00
>
> 47 7 GlobalStep -4.323961 23.02 100.00
>
> 48 7 GlobalStep -8.752531 23.57 100.00
>
> 49 7 GlobalStep -9.999654 23.94 100.00
>
> Summary: iters 50 evals 50 noisy_evals 0 cycles 7 opt_time 23.94 tot_time 24.09 obj -10.000000 gap 100.00
>
>
> In the parallel case (num_cpus=2):
>
> runfile('C:/Users/elsido/Desktop/Prove_Rbfopt/prova_parallel.py', wdir='C:/Users/elsido/Desktop/Prove_Rbfopt')
>
> Iter Cycle Action Objective value Time Gap
>
> ---- ----- ------ --------------- ---- ---
>
>
> In addition, I have tried adding the following lines at the beginning and at the end of my script:
>
> beginning
> import logging
> logging.basicConfig(filename='example_parallel.log', level=logging.DEBUG)
> logging.info('Started')
> end
> logging.info('Finished')
>
> As a result, in the serial case a file was printed with the following content:
>
> INFO:root:Started
> INFO:root:Finished
>
>
> Instead, in the parallel case I obtained a list of several "INFO:root:Started", and it was being updated continuously until I stop the code.
>
> Please let me know if I can provide additional information to solve the problem.
> Thanks for your help!
> Best regards,
> Cristina
>
> ________________________________
> Da: Giacomo Nannicini <giacomo.n at gmail.com>
> Inviato: giovedì 12 marzo 2020 19:40
> A: Cristina Elsido <cristina.elsido at polimi.it>
> Cc: rbfopt at list.coin-or.org <rbfopt at list.coin-or.org>
> Oggetto: Re: [RBFOpt] Problem with parallelization
>
> Hi Cristina,
> could you be more specific about "getting stuck"? Can you post a log
> of the parallel and serial version on your problem?
> The minimal working example seems to work fine, even in parallel mode.
> There are many "Discarded" iterations and a few restarts, but that's
> because the algorithm finds the optimum after a few iterations and
> afterward realizes that the model is not improving, hence the
> restarts.
>
> G
>
> On Thu, Mar 12, 2020 at 1:42 PM Cristina Elsido
> <cristina.elsido at polimi.it> wrote:
> >
> > Hi,
> > First of all thank you for your work and for sharing the Rbfopt library.
> > I have recently downloaded Rbfopt (v4.1.1). I would like to use Rbfopt for the optimization of an expensive black-box function (about 10' per evaluation), but I am experiencing some problems with parallelization. I noticed that if I run an optimization problem with the parameter "num_cpus" larger than 1, the optimization gets 'stuck', showing no output or progress even for many hours.
> >
> > I have also tested the parallel version of the optimizer with the minimum working example, and I got the same problem (instead, the serial version with the same parameters except for the num_cpus was solved in few seconds). Here is the script I used:
> >
> > import rbfopt
> > import numpy as np
> >
> > def obj_funct(x):
> > return x[0]*x[1] - x[2]
> >
> > bb = rbfopt.RbfoptUserBlackBox(3, np.array([0] * 3), np.array([10] * 3),
> > np.array(['R', 'I', 'R']), obj_funct)
> > settings = rbfopt.RbfoptSettings(max_evaluations=50,num_cpus=4,print_solver_output=False,algorithm='Gutmann')
> > alg = rbfopt.RbfoptAlgorithm(settings, bb)
> > val, x, itercount, evalcount, fast_evalcount = alg.optimize()
> >
> >
> > Should I use different settings for parallelization? Which parameters do you recommend for the parallel optimizer?
> > Thanks in advance for your help.
> > Best regards,
> > Cristina Elsido, PhD
> > _______________________________________________
> > RBFOpt mailing list
> > RBFOpt at list.coin-or.org
> > https://list.coin-or.org/mailman/listinfo/rbfopt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/rbfopt/attachments/20200316/55d15f89/attachment.html>
More information about the RBFOpt
mailing list