More exceptions in Planner when changing nothing and inheriting everything

I have selected 38 scenarios through running the random functionality a few times and compared the performance of all given search functions using the same parameters.

For this I used the tutorial_batch_processing.ipynb’s parallel batch processing code section. I only changed the parameters in batch_processing_config.yaml (set the scenario list explicitly, set it to use the list with SPECIFIC, depth of 100, timeout 30 seconds).

Running in the VM, 6 physical cores and 8 GB memory assigned.

Results:
bfs: 4 found, 2 not found, 20 timeout, 38 total
dfs: 22 found, 15 not found, 1 timeout, 38 total
dls: 21 found, 2 not found, 8 timeout, 38 total
gbfs: 22 found, 2 not found, 8 timeout, 38 total
ucs: 2 found, 2 not found, 22 timeout, 38 total
astar: 23 found, 2 not found, 10 timeout, 38 total
examp: 3 found, 2 not found, 31 timeout, 38 total

Then I implemented the student planner (student.py) and inherited literally everything from the GBFS class. How is it possible, that I receive more exceptions and less solutions here than in the original GBFS?

student: 21 found, 2 not found, 7 timeout, 3 exceptions, 38 total

2 Likes

Hi Saunus,

Could you maybe run for a couple of times and see if the results are always like this? One reason I can think of is that the one missing solution takes roughly 30 seconds to find on your machine, and when executing your planner that happened to be over 30 seconds, thereby being aborted.
If with a couple of runs you still get the 22/21 issue, please send the one scenario that was consistently missed to me via edmond.irani@tum.de and I will look into it.

Hi Edmond,

I’ve now ditched the VM container due to a fellow student reporting far better performance using Docker integration and because I had the same and worse issues already on a dedicated Debian installation.
Under Docker, using Ubuntu in Windows-Subsystem for Linux on Windows 10, everything seems to run a bit (a lot) smoother.

My original problem was not the 22/23 solutions difference (I’d assumed the same problem constellation that you describe), but that I randomly get 3 exceptions apparently out of nowhere. It still boggles my mind how these exceptions occured, when I basically just re-used what ran perfectly fine before - just under a different class-name.

To make things worse: now, using the WSL and Docker, I have no exceptions, when using the same code as I did in the VM and the dedicated Debian…

So, in a sense my problem is fixed, but that still seems like odd behaviour.

To all fellow students reading: I’d recommend using Docker on Windows to solve this:

  1. Install Docker
  2. Follow the link saying you need “WSL” (Windows Subsystem for Linux)
  3. Install WSL, then install Ubuntu from the Microsoft Store
  4. Have Docker recognize the Ubuntu subsystem (maybe need to set the WSL-version to 2 instead of 1)
  5. Install by following the docker readme in git (you need the commands listed below to dowload everything and then install the docker container).
  6. Set up PyCharm and open the commonroad-search folder as project folder. It will recognize the Docker setting, follow up on this and configure the settings that you can see in the commands below (port 9000->8888, name of container, “commonroad-search:2020” as tag, mount points $(pwd)->/commonroad/… and “-it” as launch option)

Get-Content .\commonroad_search_2020.dockerfile | docker build - -t commonroad-search:2020_AI

docker run -it -p 9000:8888 --name commonroadsearch --mount src="$(pwd)",target=/commonroad/commonroad-search,type=bind commonroad-search:2020_AI

Kind regards,
Timo

3 Likes