Overview
| module url | N/A | ||||||||||
| git repository | https://bitbucket.org/arrizza-public/ai-pso-simple-test-concurrent-rb | ||||||||||
| git command | git clone git@bitbucket.org:arrizza-public/ai-pso-simple-test-concurrent-rb.git | ||||||||||
| verification report | https://arrizza.com/web-ver/ai-pso-simple-test-concurrent-rb-report.html | ||||||||||
| version info |
|
- repo status: Repo Information
- installation: Common Setup
Summary
See PSO Simple Test for the original repo. It describes the solution space, how to use it and so on. Those still apply to this repo.
This project is to determine if using multiple threads would help when individual scenario calculations take a long time.
The result is that it does help make the algorithm run faster, however the ability for it to find the global minima/maxima is impacted negatively.
An effective PSO depends on each particle updating its path towards a global best continually and as early as possible. Otherwise, the particles will use a less direct path to finding it. The earlier and more often the particle updates it's path, the better the chances it has of finding the local minima (or maxima) and therefore the better the chances one of those is the global minima/maxima.
Results
With only 3 dimensions enabled, the 0.0 global minima was found nearly every run without threads. With threads, it was found only 1 out of 5 or so attempts.
Restart
As a double check, I commented out this line:
def run_scenario(scenario)
<snip>
# comment this line to check if restart has an effect
check_restart(scenario)
to see if the restart mechanism was causing the issues.
Unfortunately, it had no effect. The 0.0 global minima success rate was about the same without the restart.
I also tried moving the restart check after the current pool of scenarios was completed, i.e. after
batch_futures.each(&:wait)
That did not impact the success rate either.