5x5x5, 6x6x6, 7x7x7 or NxNxN solvers

[dwalton76]

Below is the latter part of my message when running the 5x5x5:
rubikscubennnsolver.RubiksSide.SolveError: parity error made kociemba barf, kociemba ULUUUFDBBLUFBRBUDFLLDDFRUBRLDBRDRDLDFRFLLFBFBRDLUBURFR

That is weird, kociemba does not barf for me

ddwalton-mbp:rubiks-cube-NxNxN-solver ddwalton$ kociemba ULUUUFDBBLUFBRBUDFLLDDFRUBRLDBRDRDLDFRFLLFBFBRDLUBURFR
U2 D2 R U B L F B R D B2 R B2 U L2 U2 F2 U B2 U' R2 F2
ddwalton-mbp:rubiks-cube-NxNxN-solver ddwalton$

Are you running kociemba from https://github.com/dwalton76/kociemba/ ? I made a couple of small changes to it a while back but I don't think any of them would have an impact here...couldn't hurt to try though.

 

[SteveCuber]

That is weird, kociemba does not barf for me

ddwalton-mbp:rubiks-cube-NxNxN-solver ddwalton$ kociemba ULUUUFDBBLUFBRBUDFLLDDFRUBRLDBRDRDLDFRFLLFBFBRDLUBURFR
U2 D2 R U B L F B R D B2 R B2 U L2 U2 F2 U B2 U' R2 F2
ddwalton-mbp:rubiks-cube-NxNxN-solver ddwalton$

Are you running kociemba from https://github.com/dwalton76/kociemba/ ? I made a couple of small changes to it a while back but I don't think any of them would have an impact here...couldn't hurt to try though.

I first setup the kociemba per the "Install 3x3x3 solver"
$ git clone https://github.com/dwalton76/kociemba.git
$ cd ~/kociemba/kociemba/ckociemba/
$ make
$ sudo make install

This was done on July 12, 2018. Were the changes to kociemba made before this date?

I may not have been clear in a previous message. When I run:

reset; ./usr/bin/rubiks-cube-solver.py --state RFFFUDUDURBFULULFDBLRLDUFDBLUBBBDDURLRDRFRUDDBFUFLFURRLDFRRRUBFUUDUFLLBLBBULDDRRUFUUUBUDFFDRFLRBBLRFDLLUUBBRFRFRLLBFRLBRRFRBDLLDDFBLRDLFBBBLBLBDUUFDDD

the last few lines are:
2 D' Bw2 F2 R2 Bw2 D Fw2 Dw' L2 Dw' L2 F2 Dw2 L2 F2 Dw' F2 Dw' x Dw B2 Dw R2 F2 Uw' F2 Dw' F2 Uw2 R2 Uw z' Dw2 F2 Dw' R2 Dw F2 Dw' L2 B2 F2 Uw EDGES_GROUPED y y x y
2018-07-20 09:06:08,680 __init__.py INFO: 96 steps total
ULLLUUUUUFUUUUFUUUUFDBBBBLUUUFBRRRBBRRRBBRRRBUDDDFLLLLDDFFFRDFFFRDFFFRUBBBRLDDDBRDDDRRDDDRRDDDRDLLLDFRRRFLLLLFLLLLFLLLLFBFFFBRDDDLUBBBUUBBBUUBBBURFFFR
Traceback (most recent call last):
File "./usr/bin/rubiks-cube-solver.py", line 381, in <module>
cube.solve()
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/__init__.py", line 3906, in solve
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/__init__.py", line 3112, in solve_333
rubikscubennnsolver.RubiksSide.SolveError: parity error made kociemba barf, kociemba ULUUUFDBBLUFBRBUDFLLDDFRUBRLDBRDRDLDFRFLLFBFBRDLUBURFR
pi@raspberrypi:~/rubiks-cube-NxNxN-solver $

When I then run the final state of the NxNxN program into kociemba, with the following command:
reset; ./usr/bin/rubiks-cube-solver.py --state ULUUUFDBBLUFBRBUDFLLDDFRUBRLDBRDRDLDFRFLLFBFBRDLUBURFR

it correctly solves the 3x3x3 cube.

I'm thinking that I may be running into memory limitations. When you run the above 5x5x5 through the NxNxN solver, does it solve the cube?

 

[dwalton76]

yep, I am able to solve that one without issue. If you run out of memory and start swapping when python calls subproces.check_output() to launch kociemba it will barf...I bet that is what is happening. When the solver isn't running how much free memory do you have? The 555 solver should take around 500M.

Have you tried it with the --min-memory option that I added the other night? With that the 555 only takes around 200M.

 

[SteveCuber]

yep, I am able to solve that one without issue. If you run out of memory and start swapping when python calls subproces.check_output() to launch kociemba it will barf...I bet that is what is happening. When the solver isn't running how much free memory do you have? The 555 solver should take around 500M.

Have you tried it with the --min-memory option that I added the other night? With that the 555 only takes around 200M.

You are correct. Was a memory issue.
To preserve memory I first ran the below from the CLI instead of the desktop. The additional free memory (834 M instead of 782 M when launched from a desktop terminal) made the difference.
reset; ./usr/bin/rubiks-cube-solver.py --state RFFFUDUDURBFULULFDBLRLDUFDBLUBBBDDURLRDRFRUDDBFUFLFURRLDFRRRUBFUUDUFLLBLBBULDDRRUFUUUBUDFFDRFLRBBLRFDLLUUBBRFRFRLLBFRLBRRFRBDLLDDFBLRDLFBBBLBLBDUUFDDD

Then took advantage of the -min-memory feature and it ran from a terminal in a desktop.
reset; ./usr/bin/rubiks-cube-solver.py --min-memory --state RFFFUDUDURBFULULFDBLRLDUFDBLUBBBDDURLRDRFRUDDBFUFLFURRLDFRRRUBFUUDUFLLBLBBULDDRRUFUUUBUDFFDRFLRBBLRFDLLUUBBRFRFRLLBFRLBRRFRBDLLDDFBLRDLFBBBLBLBDUUFDDD

Thanks for the help. I look forward to seeing an updated 4x4x4.

 

[dwalton76]

If you can run 555 without --min-memory then you should also be able to run 444 at this point, 444 takes about 450M.

 

[SteveCuber]

FYI .. ran 4x4x4 again from CLI before going to desktop. Did not complete to a solution. Gave error message "Index Error: index out of range".
The 5x5x5 will keep me busy. Let me know when you have a --min-memory version and I'll try it out.

 

[SteveCuber]

Try this...everytime you see a "wget https..." that fails run that wget manually from the command line and then run the solver again. You are just running out of memory, how much memory do you have?

Hi dwalton76,
In your note above you had asked how much memory I had and replied that that the latest 5x5x5 version worked. A more complete answer for the Raspberry Pi 3 is:

When starting the Raspberry Pi without going into Pixel, the memory is below. The 5x5x5 solver completed and provided a solution.
total used free shared buff/cache available
Mem: 927 30 855 6 62 843
Swap: 99 0 99

After going into Pixel, the memory dropped to the below. The 5x5x5 solver gave an error message.
total used free shared buff/cache available
Mem: 927 74 710 6 142 797
Swap: 99 0 99

After getting on the internet to download the default condition, the memory dropped still further. As could be expected, the 5x5x5 solver gave an error message.
total used free shared buff/cache available
Mem: 927 276 28 51 363 565
Swap: 99 0 99

This confirms that the amount of memory was the problem on the 5x5x5 solver on Raspberry Pi 3.

 

[dwalton76]

444 now supports --min-memory, it should take 300M with that option.

 

[SteveCuber]

444 now supports --min-memory, it should take 300M with that option.

I'm not able to get the above working right now. Use the following command. Will look into further tomorrow.

reset; ./usr/bin/rubiks-cube-solver.py --min-memory --state DRFDFRUFDURDDLLUFLDLLBLULFBUUFRBLBFLLUDDUFRBURBBRBDLLDURFFBBRUFUFDRFURBUDLDBDUFFBUDRRLDRBLFBRRLB

 

[SteveCuber]

Hi dwalton76,

More information today.

Three cases were ran (B, C, and D below). They were ran from Pixel in a Terminal after a small text file with the test cases were opened. All three cases failed. The Raspberry Pi was shutdown, restarted, and the next case ran.
In each case them available memory was found before the test case was ran. The test case was ran and then the available memory found again.
Below lists the memory available before running the test case, the command used to run the test case, a partial list of the failure printout, and the memory available after the test case was ran.

One add thing I noticed was that two files (lookup-table-4x4x4-step30-reduce333.txt and
lookup-table-4x4x4-step31-reduce333-edges.hash-cost-only.txt) were sometimes deleted when the files were ran. Also, in several instances I verified the two files were in place before running the cube-solver. In every (if not all) cases the cube-solver program would go look on the internet and download the .gz file.

In several cases the cube-solver was ran from the command line without starting Pixel. The results were the same.

Let me know if you have any suggestions.


******************************
Case B
total used free shared buff/cache available
Mem: 927 76 708 6 142 796
Swap: 99 0 99

reset; ./usr/bin/rubiks-cube-solver.py --min-memory --state FUULURFFRLRBDDDULUDFLFBBFUURRRUBLBLBDLUBDBULDDRDFLFBBRDBFDBLRBLDULUFFRLRDLDBBRLRUFFRUBFDUDFRLFRU
Traceback (most recent call last):
File "./usr/bin/rubiks-cube-solver.py", line 381, in <module>
cube.solve()
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/__init__.py", line 3887, in solve
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/RubiksCube444.py", line 1445, in group_centers_guts
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/LookupTable.py", line 973, in ida_heuristic
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/LookupTable.py", line 662, in heuristic
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/LookupTable.py", line 910, in steps_cost
IndexError: index out of range

pi@raspberrypi:~/rubiks-cube-NxNxN-solver $ free -m
total used free shared buff/cache available
Mem: 927 89 408 6 429 780
Swap: 99 0 99


Case C:
pi@raspberrypi:~ $ free -m
total used free shared buff/cache available
Mem: 927 75 709 6 142 796
Swap: 99 0 99

reset; ./usr/bin/rubiks-cube-solver.py --min-memory --state DRFDFRUFDURDDLLUFLDLLBLULFBUUFRBLBFLLUDDUFRBURBBRBDLLDURFFBBRUFUFDRFURBUDLDBDUFFBUDRRLDRBLFBRRLB
Traceback (most recent call last):
File "./usr/bin/rubiks-cube-solver.py", line 381, in <module>
cube.solve()
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/__init__.py", line 3887, in solve
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/RubiksCube444.py", line 1445, in group_centers_guts
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/LookupTable.py", line 973, in ida_heuristic
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/LookupTable.py", line 662, in heuristic
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/LookupTable.py", line 910, in steps_cost
IndexError: index out of range
total used free shared buff/cache available
Mem: 927 88 405 6 433 780
Swap: 99 0 99


Case D:
total used free shared buff/cache available
Mem: 927 76 708 6 142 796
Swap: 99 0 99

reset; ./usr/bin/rubiks-cube-solver.py --min-memory --state FLDFDLBDFBLFFRRBDRFRRURBRDUBBDLURUDRRBFFBDLUBLUULUFRRFBLDDUULBDBDFLDBLUBFRFUFBDDUBFLLRFLURDULLRU
Traceback (most recent call last):
File "./usr/bin/rubiks-cube-solver.py", line 381, in <module>
cube.solve()
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/__init__.py", line 3887, in solve
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/RubiksCube444.py", line 1445, in group_centers_guts
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/LookupTable.py", line 973, in ida_heuristic
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/LookupTable.py", line 666, in heuristic
rubikscubennnsolver.RubiksSide.SolveError: 4x4x4-step31-reduce333-edges.hash-cost-only: pt_state cae6f745k1mn02l3ijg8hd9b cost is 0 but this is not a state_target
pi@raspberrypi:~/rubiks-cube-NxNxN-solver $
total used free shared buff/cache available
Mem: 927 87 405 6 434 781
Swap: 99 0 99

*******************************

 

[dwalton76]

In every (if not all) cases the cube-solver program would go look on the internet and download the .gz file

Let's focus on this part first...it will do this if the size of the file that you have isn't the size we are looking for. Can you do the

$ git pull
$ python setup.py build
$ sudo python3 setup.py install

steps again and run the solver twice. Note that the "python setup.py build" step is new.

On the second time it should not need to download any new tables.

 

[Duncan Bannon]

Wait. I'm totally a noob here. Is python used to make solvers? I'm currently learning python, that's why I'm asking.

 

[dwalton76]

Wait. I'm totally a noob here. Is python used to make solvers? I'm currently learning python, that's why I'm asking.

Why yes it is
https://github.com/dwalton76/rubiks-cube-NxNxN-solver

 

[SteveCuber]

In every (if not all) cases the cube-solver program would go look on the internet and download the .gz file

Let's focus on this part first...it will do this if the size of the file that you have isn't the size we are looking for. Can you do the

$ git pull
$ python setup.py build
$ sudo python3 setup.py install

steps again and run the solver twice. Note that the "python setup.py build" step is new.

On the second time it should not need to download any new tables.

When I run the second line, it returns the following:
pi@raspberrypi:~/rubiks-cube-NxNxN-solver $ python setup.py build
running build
running build_py
creating build/lib.linux-armv7l-2.7
error: could not create 'build/lib.linux-armv7l-2.7': Permission denied

Can you suggest how overcome the permission issue?

HOWEVER, after running "sudo python3 setup.py install", all three cases I provided are solved!
Thanks!

 

[dwalton76]

Ah I bet the "install" step must also do the "build" step. If you hit that error again though you can do "sudo rm -rf build/" to remove the build directory.

 

[SteveCuber]

Thank you!

The Raspberry Pi 3 hardware is limited to 1GB. I've been able to get a second laptop and install Ubuntu on it. I see that the memory requirement for the NxNxN has been reduced to 3.2 G. This will be a big help.

 

[SteveCuber]

Thank you!

The Raspberry Pi 3 hardware is limited to 1GB. I've been able to get a second laptop and install Ubuntu on it. I see that the memory requirement for the NxNxN has been reduced to 3.2 G. This will be a big help.

dwalton76,
Increased memory on laptop from 4 GB to 8 GB. Running old dual core laptop with AMD E1-1500 APU (certainly not powerful by today standards)
For 4x4x4 through 11x11x11 cubes ran cube solver with and without the --min -memory options. Time it took to run the program as well as the number of moves are listed in the attached table.
Whether or not the program "burped" (that is stopped without completing a solution) was also listed. This happened on the 8x8x8 and 10x10x10 programs only. Final positions in burped cases had been reduced to 3x3x3 solutions that were solved when the updated position was put into the cube solver.
One interesting thing is that the 6x6x6 case with --min-memory took longer to run than without --min-memory and had a solution with fewer moves. I suspect that it went one level deeper on one of the searches.

Would it be possible to get 10 more random cases of 4x4x4 through 11x11x11 cubes? I'd like to evaluate more data.

Regards

 

[dwalton76]

View attachment 9342
dwalton76,
Increased memory on laptop from 4 GB to 8 GB. Running old dual core laptop with AMD E1-1500 APU (certainly not powerful by today standards)
For 4x4x4 through 11x11x11 cubes ran cube solver with and without the --min -memory options. Time it took to run the program as well as the number of moves are listed in the attached table.

Wow you are seeing some really long times. Can you do a `git pull` and make sure you are running the latest? I checked in some fixes the other day that should bring down the 7x7x7 times.

Whether or not the program "burped" (that is stopped without completing a solution) was also listed. This happened on the 8x8x8 and 10x10x10 programs only. Final positions in burped cases had been reduced to 3x3x3 solutions that were solved when the updated position was put into the cube solver.
One interesting thing is that the 6x6x6 case with --min-memory took longer to run than without --min-memory and had a solution with fewer moves. I suspect that it went one level deeper on one of the searches.

Can you cut-n-paste the error you are getting on the burps? With 8GB you should not be running out of memory so it must be something else.

Would it be possible to get 10 more random cases of 4x4x4 through 11x11x11 cubes? I'd like to evaluate more data.

Regards

yep there are some in here
https://github.com/dwalton76/rubiks-cube-NxNxN-solver/blob/master/utils/test-cubes.json

 

[SteveCuber]

Thanks for the extra test cases.

I've done another git pull as well as re-running the "--min-memory" version for the 6x6x6 through 10x10x10 cases. The 7x7x7 time was reduced from 28:30 to 3:55. The 9x9x9 decreased from 14:55 to 5:14. The 10x10x10 increase from 7:28 to 13:02.
Unfortunately, the 8x8x8 and 10x10x10 barfs still exist. Attached is a file updating the times as well as the conditions and outputs of the 8x8x8 and 10x10x10 cases.
Hope this helps!

 

[SteveCuber]

A few cases added to file for Aug 10th.
Before running each of the recent solves the computer was shutdown and only a terminal and a text file was opened to hopefully use the minimum amount of memory. The solver was ran, results noted, and memory after running noted.
I'm not good an interpreting the results. Hope the data provides hints for you.
Regards,
SteveCuber