Welcome to pygmo2 Discussions!

[bluescarni]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[IgSMS]

Good morning,
I am an aerospace engineering student and I am trying to use pygmo for its optimization algorithms versatility and variety.

I've been having some problems trying to implement the multiprocessing capabilities in pygmo with my UDP. When I run the code, the archipelago status says idle-error occurred, and when I inspect what happened it says that weakref objects can not be pickled.

I have been inspecting my UDP with all of its arguments, checking whether it is pickable or not, and I haven't had any problems so far. If I try running the following code:

from dill import dumps
data = dumps(UDP(args))

It correctly serializes the data. However, if instead I define the pygmo problem pg.problem(UDP(args)) and then use dumps(), an error will be raised. I do not understand where in the process the object became a weakref.

[IgSMS]

I changed the serialization library from cloudpickle to dill with pygmo.set_serialization_backend() and it works now! Thank you very much for your help.

Also, I have been testing the archipelago and after evolving an error is being raised:

• An attempt has been made to start a new process before the current process has finished its bootstrapping phase.

I was wondering, is it necessary to always use archi.wait() after archi.evolve()?

[bluescarni]

Are you using the latest version of dill? We have had troubles with recent versions of dill, I haven't had time to investigate but you could try to downgrade to dill 0.3.5.1 and see if it helps.

[IgSMS]

Yes, I am using dill 0.3.5.1. I found that initial problem when running the tests and downgraded it.

[bluescarni]

You should then open an issue and provide detailed information, ideally with code reproducing the problem.

[IgSMS]

I think it won't be necessary since is not a library error. I have been investigating and my guess is that it had to do with the debugging in Spyder. When running the code freely, without stopping points, no errors were raised.