# 5x5x5, 6x6x6, 7x7x7 or NxNxN solvers



## dwalton76 (Jan 16, 2017)

I am working on a lego robot that can solve various size rubiks cube, I have it working for 2x2x2, 3x3x3 and 4x4x4. The robot is large enough to handle a 5x5x5, 6x6x6 and mini 7x7x7 but I am struggling to find solvers for those sizes. I found various threads about NxNxN solvers but haven't found one that produces a low enough number of moves for me to feasibly do with a robot. https://github.com/aditya-r-m/Rubiks-Cube for instance appears to work but produces 700+ moves to solve a reasonably scrambled 5X5X5, that would take my robot about 35 minutes execute.

Any recomendations on solvers for these sizes (or NxNxN)? Ideally it would be something I can run from the command line and would be lightweight enough to run on a raspberry Pi3 but I realize that may be wishful thinking.


----------



## ruwix (Jan 17, 2017)

I made a robot 8 years ago that solved the 3x3 in 35 minutes and that was considered pretty impressive back then  




I don't know about an optimal NxN algorithm but I'm very interested how this project comes along. 
Good luck and keep us updated with the progress.


----------



## dwalton76 (Jan 18, 2017)

If you did this 8 years ago you were pretty early on in the world of using LEGO to solve rubiks cubes, very nice  There is a very popular robot out there called MINDCUB3R that can be built from a standard Mindstorms EV3 kit that can solve a 3x3x3. I built it a while back and made a little video:





It was designed by David Gilday who has designed several well known rubiks cube solving LEGO robots.

MINDCUB3R is pretty cool but I wanted to build something that was faster and that could solve various sizes of cubes. What I came up with was heavily influenced by some of David's robots so I definitely owe him some kudos. I need to take some more videos but here is a short one I took while troubleshooting something. Note that I only started recording after it had already snapped a pic of each side to figure out the colors and compute a solution. Also the cube wasn't very scrambled at the start but you can get the general idea of how it works:





Right now it takes about 50 seconds to:

take an image of all six sides
process those images to find the squares in each and extract the mean RGB value for each square
process the RGB values to classify each square as U L F R B or D
compute a solution
Then it is about 3100ms per move....so a 3x3x3 that takes 20 turns to solve can be done just under 2 minutes. My goal is to get that down to 90s, right now I spend almost 40s taking images of all six sides (the ev3 cpu is pretty slow) so I need to do some digging and make that faster.

All of the code is available here:
https://github.com/dwalton76/lego-crane-cuber

I plan on putting together some build instructions when all is said and done. What I built is a mashup between http://brickset.com/sets/31313-1/Mindstorms-EV3 and http://brickset.com/sets/42009-1/Mobile-Crane-MK-II


----------



## xyzzy (Jan 18, 2017)

I wrote a 5×5×5 solver in Java a while ago, but the code is pretty horrific and I've been too "busy" (read: lazy) to clean it up for public consumption. It generates solutions of about 90 moves (OBTM) in a few seconds, but also uses a few gigabytes of lookup tables, which might not be suitable for your use. (If you want to take a look at the code for my solver anyway, I could upload it somewhere.)

Herbert Kociemba is also working on another big cube solver, but it's not finished yet. There's also unsolved's solver and IAssemble's solver, which aren't publicly released either. I don't know of any other "low-move-count" big cube solvers in development.


----------



## dwalton76 (Jan 18, 2017)

xyzzy said:


> I wrote a 5×5×5 solver in Java a while ago, but the code is pretty horrific and I've been too "busy" (read: lazy) to clean it up for public consumption. It generates solutions of about 90 moves (OBTM) in a few seconds, but also uses a few gigabytes of lookup tables, which might not be suitable for your use. (If you want to take a look at the code for my solver anyway, I could upload it somewhere.)



If you could that would be great...an unclean 5x5x5 solver is much better than no solver  I can always run it on my desktop instead of a pi.

github would be a great place to put it, it makes it easy for others to contribute. Thanks!


----------



## dwalton76 (Jan 25, 2017)

ok 5x5x5 is now working!!  Kudos to xyzzy for providing the solver


----------



## Herbert Kociemba (Mar 18, 2017)

xyzzy said:


> I wrote a 5×5×5 solver in Java a while ago, but the code is pretty horrific and I've been too "busy" (read: lazy) to clean it up for public consumption. It generates solutions of about 90 moves (OBTM) in a few seconds, but also uses a few gigabytes of lookup tables, which might not be suitable for your use. (If you want to take a look at the code for my solver anyway, I could upload it somewhere.)
> 
> Herbert Kociemba is also working on another big cube solver, but it's not finished yet. There's also unsolved's solver and IAssemble's solver, which aren't publicly released either. I don't know of any other "low-move-count" big cube solvers in development.



I did not read this thread before so maybe it is a bit late to answer. The word "lazy" may also apply to me. I did not work further on the solver since then and I fear when I dive into the code again it might be difficult to understand what I did before. In the moment I try to learn Python and the best way to do seems for me to port my two-phase algorithm (for 3x3x3) to Python. I am writing it in its fully developed form using symmetry reduction and large pruning tables in contrast to my Java implementation ( http://kociemba.org/download.htm ) which is much less powerful. 
Once I have finished this I definitely will return to the nxnxn project sooner or later


----------



## dwalton76 (Mar 18, 2017)

@Herbert Kociemba do you (or anyone else) have any interest in working on a open source python big cube solver? (hopefully NxNxN eventually) I am working on a python based solver where the goals are:

Must be able to run on a Raspberry Pi3 (1G RAM, 1.2Ghz quad core)
solve a 4x4x4 cube
solve a 4x4x4 cube in a reasonable number of moves...hopefully less than 60 moves on average
solve a 5x5x5 cube
solve a 5x5x5 cube in a reasonable number of moves...hopefully less than 100 moves on average
solve a 6x6x6 cube
solve a 6x6x6 cube in a reasonable number of moves ("reasonable" is TBD)

solve a 7x7x7 cube
solve a 7x7x7 cube in a reasonable number of moves ("reasonable" is TBD)

solve a NxNxN cube
I currently have #2 and #4 done and I think I am getting close on #3 (I have not started on #5 -> #10). I can solve a 4x4x4 cube in an average of 93 moves. For 4x4x4 I solve via:

Solve UD centers via a lookup table (8 or 9 moves on average)
Solve LFRB centers via a lookup table (8 or 9 moves on average)
Pair edges via the method described at http://www.rubik.rthost.org/4x4x4_edges.htm
Solve 3x3x3 via the C kociemba solver
I am able to work around the Pi3's limited RAM by storing the lookup tables in text files where the entries are sorted, I then do a binary search through the file for the current state of the cube. So I never load the lookup tables in memory, I just open a filehandle and search.

My next goal is to build a lookup table that can pair the 4x4x4 edges without destroying the centers, once I have that working #4 should be done.

I know python really well but I am fairly new to the world of rubiks cubes and this is the first time I've attempted writing a solver so I'm sure there would be huge benefit to having folks who know way more about this than I do jump in on the project. I have been picking xyzzy's brain offline and he has been a big help with answering my questions.

The code lives here...warning that I haven't had a chance to clean things up yet as the code is churning at a pretty high rate right now. I'll clean it up and make it more readable once things settle down.
https://github.com/dwalton76/rubiks-cube-solvers/tree/master/NxNxN

To use it

```
$ git clone https://github.com/dwalton76/rubiks-cube-solvers.git
$ cd rubiks-cube-solvers/NxNxN/
$ sudo python3 setup.py install
$ rubiks-cube-solver.py --state LFBDUFLDBUBBFDFBLDLFRDFRRURFDFDLULUDLBLUUDRDUDUBBFFRBDFRRRRRRRLFBLLRDLDFBUBLFBLRLURUUBLBDUFUUFBD
```


----------



## Herbert Kociemba (Mar 22, 2017)

dwalton76 said:


> @Herbert Kociemba do you (or anyone else) have any interest in working on a open source python big cube solver? (hopefully NxNxN eventually) I am working on a python based solver where the goals are:


 Maybe later. I want to get some more experience with Python first while programming my 3x3x3 two-phase solver. Btw I also have a Raspberry Pi3 (1G RAM, 1.2Ghz quad core) and the routines I have programmed so far also work there. The memory requirements for my solver (mostly for the pruning tables) are about 100 MB, this should be possible with the Raspberry without problems.


----------



## dwalton76 (Mar 23, 2017)

The fact that yours will run on a Pi3 is some great news.

I'll keep posting updates to this thread on where things are with my solver...I made some improvements to 4x4x4 edge pairing and have the average number of moves down from 93 to 83. There is still room for improvement on edge pairing...I have some ideas to explore.


----------



## Herbert Kociemba (Mar 28, 2017)

dwalton76 said:


> The fact that yours will run on a Pi3 is some great news.


It depends. Python is really slow compared to a static typed language. And Pi3 is really slow compared to a PC. This combination makes the perfomance (slow)^2 .
Let's take the pruning table for phase 1 for example. It gives the exact number of moves (modulo 3) to solve phase 1 for a given state. Reduced by 16 symmetries there are 140930280 entries. With Pascal/Delphi and a PC it takes less than a minute to compute this table. My python implementation takes about three hours on a PC ! I use numpy for the arrays here. To compute the table with python and the Pi3 takes about two days!
Once the tables are created they load very fast, within a few seconds, even on the Pi3. I am still quite optimistic that this will give a powerful solver on the Pi3.


----------



## dwalton76 (Mar 28, 2017)

Pi3 feels like a supercomputer compared to the 300Mhz LEGO Mindstorms EV3 brick 

Just speaking for myself here I would be fine building the tables on a PC and copying them to the Pi3 or ev3 brick. Or heck if they compress down enough make them available for download.


----------



## Herbert Kociemba (Mar 28, 2017)

The program will need about 80 MB of RAM, so I think it will not run on the EV3 brick.

Edit: I found that the numpy module is very slow for array access and that using the standard array module gives much better performance. It has no twodimensional arrays but it is not difficult to change the code to use only onedimensional arrays. I think it will run 3x as fast when finished.


----------



## Herbert Kociemba (Apr 7, 2017)

The Python 3x3x3 solver is working now in a basic form. The two-phase-algorithm is working only in "one direction" yet. In the advanced form it should run in parallel in three different directions within three threads or even in 6 threads if we include the inverse cubes. On my PC I got the following test results:
Creating all tables: less than an hour
Solving 100 random cubes within <= 20 moves : 380 seconds
Solving 1000 random cubes within <=21 moves : 138 seconds

On a Raspberry Pi3 100 cubes were solved within <=21 moves in 150 seconds, so it is about 10 times slower than a PC


----------



## dwalton76 (Apr 7, 2017)

When you say python and threads...are you using actual python threads or are you breaking the work up into subprocess calls? Python threads kinda suck in that they won't use multiple cores so if you are CPU bound they don't end up helping that much.


----------



## Herbert Kociemba (Apr 7, 2017)

dwalton76 said:


> When you say python and threads...are you using actual python threads or are you breaking the work up into subprocess calls? Python threads kinda suck in that they won't use multiple cores so if you are CPU bound they don't end up helping that much.



I will use Python treads. I know of the Python Global Interpreter Lock (GIL) and surely it will use only one CPU. But still I expect an increase in perfomance. I think I would have to load the pruning tables several times if I use several processes - or am I wrong?


----------



## dwalton76 (Apr 7, 2017)

Ack just wanted to make sure you were aware of the whole GIL thing. It can be a shocker the first time you break something into multiple threads to get around being CPU bound only to find that you are still CPU bound due to GIL 

Agreed I think each process would have to load the pruning tables which I'm guessing will consume a lot of memory. I've been using text files (the content is sorted) for table storage and then I do a binary search through the file. It is pretty fast and doesn't use much memory as all you are doing is moving the filehandle around in the file.


----------



## dwalton76 (Apr 7, 2017)

An update on my solver...

4x4x4 solver is down to 66 moves on average
~20 steps so solve the centers
~26 steps to pair the edges
~20 steps to solve 3x3x3

5x5x5 solver is down to 128 moves
~36 steps to solve centers
~72 steps to pair edges
~20 steps to solve 3x3x3
Out of the 72 steps to pair the edges, 27 of them were to pair the last two wings. So 45 steps to pair the first 22 wings and 27 steps to pair the final two...there are some savings to be had here. 

6x6x6 solver, I am just getting started, I can't solve a 6x6x6 yet.
I need to get the tables compressed enough to check in on github (there is a 100M limit per file) in case anyone wants to try this out.


----------



## Herbert Kociemba (Apr 8, 2017)

dwalton76 said:


> Ack just wanted to make sure you were aware of the whole GIL thing. It can be a shocker the first time you break something into multiple threads to get around being CPU bound only to find that you are still CPU bound due to GIL



I got the multithreaded part working now and the results are much better than I expected with GIL in mind. I solved 1000 random cubes with the condition to return a solution with at most 20 moves. On my PC I got:

single thread: 3910 seconds
two threads, cube and inverse cube: 1026 seconds
three threads, cube and the cubes rotated 120° and 240° around the long diagonal: 641 s
six threads, all combinations of rotated and inverse cubes: 320 s

So there is a perfomance increase by a factor 12 when running 6 threads in parallel without using more CPU-time due to GIL!
The reason is that the solution time for a cube greatly depends on the depth in phase1 which is needed to find a solution within 20 moves. So if in one of the six combinations the phase1 length is one or two moves less on average, the factor 12 can be explained easily.

Edit: Using the six thread version, my Raspberry Pi3 took 1 hour to solve 1000 random cubes with <= 20 moves.


----------



## Herbert Kociemba (Apr 9, 2017)

Some more detailed statistics to explain the better performance using 6 threads:

With 1000 random cubes solved with <= 20 moves, here is the distribution of the phase 1 lengths for which the solution appeared:


```
phase 1 length           7         8         9         10        11        12         13      14    
counts with 6 threads    1         6        41        370       466       114          2       0    
counts with 1 thread     0         0        13        158       274       335        187      33
```
The same for 1000 random cubes solved with <= 21 moves

```
phase 1 length           7         8         9         10        11        12         13      14      
counts with 6 threads    0         3        27        246       700        24          0       0
counts with 1 thread     0         0        18        151       648       170         13       0
```

Increasing the phase 1 depth by 1 increases the computing time by a factor about 13. So the many cases in the first table with one thread and depth 13 and 14 are responsible for the longer solving times.


----------



## dwalton76 (Apr 19, 2017)

I've move the solver to its own repo here:
https://github.com/dwalton76/rubiks-cube-NxNxN-solver

The lookup tables for 2x2x2 and 4x4x4 are small enough that gzipped them and checked them into the repo. The lookup tables for 5x5x5 and 6x6x6 are several gigs so I cannot put them in the repo but I have them in a dropbox folder that I can share...ping me if you want access.

I've been working on 6x6x6 centers, I can stage them now





The algorithm for staging 6x6x6 centers is

stage the UD inner x-centers
pair the UD oblique edges (the edges in the centers, between the outer x-centers)....kudos to xyzzy for this idea
at this point the UD centers have been reduced to 5x5x5 centers so use the 5x5x5 solver to stage the UD outer x-centers
stage the LR inner x-centers and LR oblique edges
at this point the LR centers have been reduced to 5x5x5 centers so use the 5x5x5 solver to stage the LR outer x-centers


----------



## Herbert Kociemba (Apr 19, 2017)

Nice, I will have a look at it soon! Meanwhile my 3x3x3 Python solver is almost finished and the code just needs a bit to be polished up and documented. I consists of a server you can run on any machine and which takes the cube definition string from the client and returns the solving maneuver to the client. You can connect to the server with telnet for example or easier with a simple GUI-interface I also provide. The performance is better than I expected with the combination Python/Raspberry PI3. Running the server on the RaspberryPi3 with a time limit of 3 seconds per solve I got the following results for 100 random cubes:
18: 4, 19: 31, 20: 48 and 21:17. So the average solving length is less than 20 moves on the Raspi if 3 secons of "thinking" is allowed.

I also will upload it to Github soon and I think it is better to open a new thread for discussions concerning the solver since it seems a bit misplaces in this thread which deals with 5x5x5 and higher.


----------



## dwalton76 (Apr 19, 2017)

Sounds cool, I'm looking forward to trying it out


----------



## dwalton76 (Apr 21, 2017)

Can now solve 6x6x6 centers...next step is to reduce the edges to a 4x4x4


----------



## qqwref (Apr 27, 2017)

Cool to see the development of more good NxNxN solvers! Many of the ones in the past have been private or never got released, so there are actually very few out there.



dwalton76 said:


> 4x4x4 solver is down to 66 moves on average


Sounds pretty good for reduction! I think in the 4x4x4 FMC challenge some people had solvers that could reduce the 4x4x4 in not much move than 25 moves, but that probably requires a lot of searching.



dwalton76 said:


> 5x5x5 solver is down to 128 moves [...] 45 steps to pair the first 22 wings and 27 steps to pair the final two...there are some savings to be had here.


You definitely want to fix parity while solving centers here. In fact, that's a good idea for all big cubes; 4x4/5x5 have one parity type, 6x6/7x7 have two, and so on. You can generally do this by adding an extra slice move somewhere in the centers stage. Then the final two wings can only have some very simple "slice, flip edge, slice back" solutions, or you could just solve everything at the same time.


----------



## abunickabhi (Apr 27, 2017)

dwalton76 said:


> I am working on a lego robot that can solve various size rubiks cube, I have it working for 2x2x2, 3x3x3 and 4x4x4. The robot is large enough to handle a 5x5x5, 6x6x6 and mini 7x7x7 but I am struggling to find solvers for those sizes. I found various threads about NxNxN solvers but haven't found one that produces a low enough number of moves for me to feasibly do with a robot. https://github.com/aditya-r-m/Rubiks-Cube for instance appears to work but produces 700+ moves to solve a reasonably scrambled 5X5X5, that would take my robot about 35 minutes execute.
> 
> Any recomendations on solvers for these sizes (or NxNxN)? Ideally it would be something I can run from the command line and would be lightweight enough to run on a raspberry Pi3 but I realize that may be wishful thinking.


good to hear that a feasible solver for 5x5 can be constructed.


----------



## xyzzy (Apr 27, 2017)

qqwref said:


> You definitely want to fix parity while solving centers here. In fact, that's a good idea for all big cubes; 4x4/5x5 have one parity type, 6x6/7x7 have two, and so on. You can generally do this by adding an extra slice move somewhere in the centers stage. Then the final two wings can only have some very simple "slice, flip edge, slice back" solutions, or you could just solve everything at the same time.



Yeah, that's something I brought up too, but honestly I'm not sure if solving slice parity is that useful with redux. (Compared to "subgroup descent" methods, as in solvers that go from the full group into smaller subgroups defined by a restricted move set, e.g. mine. You can sort of see what it's doing in the video dwalton76 posted on the first page of the thread.)

On the 555, there's the 9-move parity fix (r U2)5 which can solve 3 wings at once if you spend a bunch of moves to set up the pieces appropriately. It's worse than using 3-cycles (5 moves to solve 2 wings), but not that much worse. Solving parity at the start would probably save only about 2 moves on average. For the last two edges, the parity cases are also only about 3-4 moves longer on average (iirc). (Compare this (non-parity; 10 moves optimal) with this (parity; 12 moves).)

Also, doing L2E/L4E on 555 the same way we do it for speedsolving is actually pretty bad in terms of move count, because slice-flip-unslice costs 7 moves, or 8 if you need to set it up. In contrast, most wing 3-cycles are either 5 or 6 moves, so if you let the unpaired wings be anywhere on the cube instead of just the 2U/2D layers, the move count just magically drops. On the flip side, solving the wings with 3-cycles is not compatible with freeslice, and almost everyone seems to think that freeslice is the best way to do edge pairing on 666 and up. I don't have data on this (yet).


----------



## Herbert Kociemba (Apr 27, 2017)

I uploaded my 3x3x3 Python solver to https://github.com/hkociemba/RubiksCube-TwophaseSolver now.
For me it was the fun way to learn Python but I would appreciate if anybody with more experience with Python would have a look at the code and give me some suggestions for improvements. Maybe dwalton76 has use of it for the last phase of his NxNxN solver or some other persons who want to build a cube solving robot.


----------



## dwalton76 (Apr 29, 2017)

Herbert Kociemba said:


> I uploaded my 3x3x3 Python solver to https://github.com/hkociemba/RubiksCube-TwophaseSolver now.



I tried it out, this is pretty cool. I haven't had a chance to look at the code yet but just some quick feedback:

Have you thought about including the tables in the repo so the user doesn't have to build them? If you 'gzip --best' they are only about 40M, thats plenty small enough to check into github.


```
[email protected] ~/l/RubiksCube-TwophaseSolver> ls -lh *.gz
-rw-rw-r-- 1 dwalton dwalton  54K Apr 29 11:00 co_classidx.gz
-rw-rw-r-- 1 dwalton dwalton  37K Apr 29 10:59 conj_twist.gz
-rw-rw-r-- 1 dwalton dwalton 1.2M Apr 29 11:00 conj_ud_edges.gz
-rw-rw-r-- 1 dwalton dwalton 2.2K Apr 29 10:58 coord.py.gz
-rw-rw-r-- 1 dwalton dwalton 5.0K Apr 29 11:00 co_rep.gz
-rw-rw-r-- 1 dwalton dwalton  12K Apr 29 11:00 co_sym.gz
-rw-rw-r-- 1 dwalton dwalton 1.7M Apr 29 11:00 fs_classidx.gz
-rw-rw-r-- 1 dwalton dwalton  96K Apr 29 11:00 fs_rep.gz
-rw-rw-r-- 1 dwalton dwalton  14K Apr 29 11:00 fs_sym.gz
-rw-rw-r-- 1 dwalton dwalton 1.3M Apr 29 11:01 move_corners.gz
-rw-rw-r-- 1 dwalton dwalton 308K Apr 29 11:01 move_d_edges.gz
-rw-rw-r-- 1 dwalton dwalton  45K Apr 29 11:00 move_flip.gz
-rw-rw-r-- 1 dwalton dwalton 311K Apr 29 11:01 move_slice_sorted.gz
-rw-rw-r-- 1 dwalton dwalton 1.5K Apr 29 10:58 moves.py.gz
-rw-rw-r-- 1 dwalton dwalton  53K Apr 29 11:00 move_twist.gz
-rw-rw-r-- 1 dwalton dwalton 838K Apr 29 11:01 move_ud_edges.gz
-rw-rw-r-- 1 dwalton dwalton 308K Apr 29 11:01 move_u_edges.gz
-rw-rw-r-- 1 dwalton dwalton  29M Apr 29 11:25 phase1_prun.gz
[email protected] ~/l/RubiksCube-TwophaseSolver>
```

For the gui, is there a way to specify the default center colors?
start_server.py reports 'Error while receiving data. Connection closed' but I do get the correct response


```
[email protected][RubiksCube-TwophaseSolver]# curl 'http://localhost:8080/?DUUBULDBFRBFRRULLLBRDFFFBLURDBFDFDRFRULBLUFDURRBLBDUDL'
<html><head><title>Answer from Cubesolver</title></head><body>
D2 L3 D3 L2 U1 R2 F1 B1 L1 B1 D3 B2 R2 U3 R2 U3 F2 R2 U3 L2 (20f)
</body></html>
[email protected][RubiksCube-TwophaseSolver]#
```


----------



## Herbert Kociemba (Apr 29, 2017)

dwalton76 said:


> Have you thought about including the tables in the repo so the user doesn't have to build them? If you 'gzip --best' they are only about 40M, thats plenty small enough to check into github.


I am not sure if this is works The problem is that the endianess might be different in different operating systems and this could break the program since some tables store information on the bit level. So it is saver to build the tables on the system where the server is running.


dwalton76 said:


> For the gui, is there a way to specify the default center colors?


No, the gui is intented only as a very simple demonstration how to interact with the server.


dwalton76 said:


> start_server.py reports 'Error while receiving data. Connection closed' but I do get the correct response


You savely can comment out the corresponding print-line in the try-except block in sockets.py if this is irritating.


----------



## xyzzy (Apr 30, 2017)

Herbert Kociemba said:


> The problem is that the endianess might be different in different operating systems and this could break the program since some tables store information on the bit level.



Is there a reason you're using a `signed long` array instead of, say, an `unsigned long` or `unsigned char` array? Using an unsigned type would get rid of some of the weird checks you have for ix%16 == 15, and using `char` would get rid of endianness concerns.


----------



## Herbert Kociemba (Apr 30, 2017)

xyzzy said:


> Is there a reason you're using a `signed long` array instead of, say, an `unsigned long` or `unsigned char` array? Using an unsigned type would get rid of some of the weird checks you have for ix%16 == 15, and using `char` would get rid of endianness concerns.



I suppose you address issues in the module pruning.py .
Indeed both issues you address were also part of my considerations and what you propose was exactly what I tried in my original coding attempts.
1. Using char instead for the arrays flipslice_twist_depth3 and corners_ud_edges_depth3: Yes this would be possible. But the generation of the two pruning tables (which take the most time to generate) really was much faster using "long" instead, mainly because it is *much *faster for the lower depths where the tables are sparsely populated (if not backsearch and idx % 16 == 0 and corners_ud_edges_depth3[idx // 16] == -1...).

2. I know the lines in set_flipslice_twist_depth3 and in set_corners_ud_edges_depth3 look weird but using unsigned long which I tried first simply did not work. If I remember correctly I could not get around problems similar to what happens here:

import array
test = array.array('L', [0] *5)
test[0] = ~(3 << 30)

If you run this code you get an OverflowError: can't convert negative value to unsigned int.
But thanks, I will give the unsigned approach another try, I think this will simplify the code because I now have the extra handling for << 30 also in the signed version!


----------



## xyzzy (Apr 30, 2017)

Herbert Kociemba said:


> ut the generation of the two pruning tables (which take the most time to generate) really was much faster using "long" instead, mainly because it is *much *faster for the lower depths where the tables are sparsely populated



Hm, I knew there had to be a catch somewhere. Would it be better to generate the tables as long (or even long long) and then convert them to char when saving them to disk?

I haven't looked at the code very closely, but I'm assuming you use the `corners_ud_edges_depth3[idx // 16] == -1` test to simultaneously check 16 entries at once? That's pretty cool.


Herbert Kociemba said:


> 2. I know the lines in set_flipslice_twist_depth3 and in set_corners_ud_edges_depth3 look weird but using unsigned long which I did tried first simply did not work. If I remember correctly I could not get around problems similar to what happens here:
> 
> import array
> test = array.array('L', [0] *5)
> ...



Python 3's ~ operator works almost as though we're in the 2-adics. The ~ of any positive number will have "infinitely many" 1s to the left of it, so it'd be treated as a negative number, which Python refuses to implicitly convert to an unsigned int; you need to mask it with 0xFFFFFFFF to get it to be a 32-bit unsigned int.


----------



## mark49152 (Apr 30, 2017)

dwalton76 said:


> Can now solve 6x6x6 centers...next step is to reduce the edges to a 4x4x4


Or you could solve inner edges like a 4x4 then outers like 5x5.


----------



## Gold Cuber (Apr 30, 2017)

mark49152 said:


> Or you could solve inner edges like a 4x4 then outers like 5x5.


that would probably be an easier stratagie but i don't know how to make a cube robot so...


----------



## Herbert Kociemba (Apr 30, 2017)

xyzzy said:


> I haven't looked at the code very closely, but I'm assuming you use the `corners_ud_edges_depth3[idx // 16] == -1` test to simultaneously check 16 entries at once? That's pretty cool.



That's indeed the reason. I changed to unsigned long again and committed and pushed the changes. Really looks much nicer now. In the moment I do not do the mask you proposed but just make an extra handling for <<30 . But I also will try your approach today. With unsigned long long I am not sure how this performs on 32 bit systems because it extends the native int size. So maybe I better leave it as it is now.

Edit: Used the mask operation you proposed now. Even seems to be a tiny bit faster.


----------



## dwalton76 (May 1, 2017)

@Herbert Kociemba want to announce your 3x3x3 python solver in another thread so we don't end up with two conversations in this one?


----------



## dwalton76 (May 1, 2017)

mark49152 said:


> Or you could solve inner edges like a 4x4 then outers like 5x5.



yep, I ended up doing that for 6x6x6. This also made me realize that I could simplify my 5x5x5 edge pairing code a good deal by using my 4x4x4 edge pairing code to pair all of the outer wings. That eliminates quite a few scenarios for pairing the last two edges 5x5x5, you only have to take care of 1, 5, 6, 7, and 8 from here:


----------



## dwalton76 (May 1, 2017)

VICTORY!! Or something like that


----------



## mark49152 (May 1, 2017)

dwalton76 said:


> This also made me realize that I could simplify my 5x5x5 edge pairing code a good deal by using my 4x4x4 edge pairing code to pair all of the outer wings.


I guess it depends whether there's any advantage to you in reducing slices or phases. If you look at each wing and pair it up with its midge you have a single phase to reduce to the last 2-3 tredges using outer block moves only. (Search AvG edge pairing.)


----------



## dwalton76 (May 1, 2017)

There is a bug in the screenshot, near the bottom it should read "110 steps to group edges", not 68 steps.


----------



## dwalton76 (May 1, 2017)

mark49152 said:


> I guess it depends whether there's any advantage to you in reducing slices or phases. If you look at each wing and pair it up with its midge you have a single phase to reduce to the last 2-3 tredges using outer block moves only. (Search AvG edge pairing.)



I found this post on AvG edge pairing
https://www.speedsolving.com/forum/threads/arnauds-5x5x5-edge-pairing-method-examples.1447/

and loaded up the 57 move scramble. I am able to pair the edges in 72 moves so what I am doing seems pretty comparable in terms of the move count (his 'expert' number was 73 moves). I do:

pair the outside wings via 4x4x4 edge pairing
attempt to pair 3 edges on a Uw slice and pair three more on the Uw' slice back...sometimes the stars align and I can pair 4 at once on either the slice forward or slice back.
pair all remaining edges via https://i.imgur.com/wsTqj.png No 1, 5, 6, 7, or 8


----------



## xyzzy (May 1, 2017)

AvG uses a few more moves than freeslice (as implemented on a human being, so no backtracking or deep lookahead), in exchange for having less stuff to keep track of.

Here's two different human solves of the same scramble: [1] [2]

First one is freeslice (67 moves), second one is freestyle chain pairing (57 moves).

Solving the wings then matching them to the midges is necessarily significantly less efficient than most other methods that don't do that (freeslice, chain pairing, 3-cycles), although it certainly is a much simpler algorithm if we have a 4×4×4 edge pairing black box to exploit.


----------



## dwalton76 (May 1, 2017)

57 moves is impressive


----------



## dwalton76 (Jun 5, 2017)

First solve of a 6x6x6. This is only the last few moves, there were 239 moves total, it took the robot about 10-12 minutes.


----------



## Malkom (Jun 5, 2017)

dwalton76 said:


> First solve of a 6x6x6. This is only the last few moves, there were 239 moves total, it took the robot about 10-12 minutes.


it looks like 4 edges are swapped in the back, is it just the lighting?


----------



## dwalton76 (Jun 5, 2017)

They are, the code that crunches the RGB values to figure out the colors got red and orange backwards on two squares. Red vs orange has been difficult I have some more work to do there. So not 100% solved but "solved" in terms of the solving algorithm and mechanics of the robot working.


----------



## Dr_Detonation (Jun 5, 2017)

That is awesome. Coolest thing I've seen in my life. Or at least this week


----------



## xyzzy (Jun 6, 2017)

dwalton76 said:


> They are, the code that crunches the RGB values to figure out the colors got red and orange backwards on two squares. Red vs orange has been difficult I have some more work to do there. So not 100% solved but "solved" in terms of the solving algorithm and mechanics of the robot working.



Would it work better with, say, a stickerless cube? (Or worse, if the detection algorithm needs to have a border around each facelet?)


----------



## dwalton76 (Jun 6, 2017)

xyzzy said:


> Would it work better with, say, a stickerless cube? (Or worse, if the detection algorithm needs to have a border around each facelet?)



So there are two phases at play here

Take photos of all six sides, find all of the facelets, get the mean (red, green, blue) values of each facelet. Having clear borders around the facelets def makes them easier to find here but I have it working even if there are white facelets separated by a white border. Sticker vs stickerless I don't think would matter much. Example of white on white:





Take the RGB values for each facelet and ID each facelet as U,L,F,R,B, or D
Phase 2 is where the red vs. orange confusion is. The way this part works is

ID "anchor" facelets which will act as our color point of reference for each side. For odd cubes this is easy we just take the middle facelet of each side. For even cubes we take a corner to get the first three anchors then we find the other corner that has the greatest "color distance" from our first corner, that gives us the other three anchors.
"color distance" is calculated by https://en.wikipedia.org/wiki/Color_difference#CIEDE2000
Build a list of the color combos we need for corners
Build lists of the color combos we need for each orbit of edges
Build lists of the colors we need for the various types of center facelets
So for corners say we know we need a Green, White, Red corner, we look at all of the corner facelets and find the corner that matches the Green, White, Red anchor facelet colors with the smallest color distance. We do this same basic thing for all of the corners, then all of the edges, etc.


----------



## dwalton76 (Jun 6, 2017)

FYI the code for the first phase is https://github.com/dwalton76/rubiks-cube-tracker and the code for the second phase is https://github.com/dwalton76/rubiks-color-resolver


----------



## dwalton76 (Jun 26, 2017)

Can now solve a 7x7x7!!!


----------



## dwalton76 (Jul 14, 2017)

Misc update

For 5x5x5 edge pairing I am no longer starting out by using 4x4x4 edge pairing to pair all of the outside edges. This dropped the average number of moves for pairing 5x5x5 edges by about 20 moves.
I had an IDA bug that led me to building my lookup tables much larger than they needed to be. With that IDA bug fixed all of my lookup tables are now small enough to include in the repo on github. The repo is about 700M though so the git clone takes a few minutes and takes a bit of RAM. This is big news because now anyone can just git clone the repo and use the solver, they no longer need to download massive tables from dropbox.
Lots of performance improvements
4x4x4 takes ~200ms to solve
5x5x5 about 5s
6x6x6 about 7s
7x7x7 about 7s

Move counts are down
4x4x4 averages 65 moves
5x5x5 averages 119 moves
6x6x6 averages 214 moves
7x7x7 averages 304 moves

I've started working on NxNxN even support by trying to solve a 14x14x14...not working yet
A few other people have started using the solver, filing bugs, etc


----------



## dwalton76 (Oct 26, 2017)

Major milestone today, I have NxNxN working!! 

*14x14x14*










*15x15x15*


----------



## ruwix (Oct 28, 2017)

That's insane! 
I would be happy to make a nice UI and host it here https://rubiks-cube-solver.com/


----------



## dwalton76 (Oct 28, 2017)

That would be cool  Let me know if you need any changes made to make it easier to incorporate into your site.


----------



## ruwix (Oct 29, 2017)

Could you please provide a PHP or JavaScript function that takes the scrambled fields as input and returns the rotations? I will take care of the rest.


----------



## dwalton76 (Oct 30, 2017)

I think the best thing to do would be to have php do a 
shell_exec() call to run rubiks-cube-solver.py. You pass rubiks-cube-solver.py the state of the cube via a "--state" arg and it prints out the solution.


----------



## abunickabhi (Apr 2, 2018)

dwalton76 said:


> So there are two phases at play here
> 
> Take photos of all six sides, find all of the facelets, get the mean (red, green, blue) values of each facelet. Having clear borders around the facelets def makes them easier to find here but I have it working even if there are white facelets separated by a white border. Sticker vs stickerless I don't think would matter much. Example of white on white:
> 
> ...



Great work in tracking the colours of big cubes.
I have started out learning image processing in my coursework, and using color distance is great.
The natural approach would be image segmentation , but then building the list of color combos for the various types of pieces will be lengthy.


----------



## Horia (Jun 19, 2018)

Hi, I try to make a lego robot that solve the 4*4*4 cube, and for weeks I just tried to search on web but I couldn't find anything. But today I found your files on Git Hub and watch the video with the Crane Cuber. It's very amazing! I plan to use Raspberry Pi 3 to control the motors (I don't have the Mindstorms set so I use some stepper motors). I build with Lego a robot like you, but is not very efficient, I need to change the structure. I am on PC so I can't show you a picture. So I ask if you can publish some pictures around the Crane Cuber, to try improve my robot. I have the lego pieces that you used to build it, so if you want to help us (the people who want to create amazing things), I would be very pleased. Thanks again for your work, I know that it's not easy to do that and I will be very happy if you can help me. Hope you will reply to this. Thanks!


----------



## dwalton76 (Jun 19, 2018)

Awesome  The Lego Digital Designer instructions for crane-cuber are available in this repo (the .lxf file):
https://github.com/dwalton76/lego-crane-cuber

Just install LDD, open that .lxf file and you can zoom in all you want to see how it is put together.


----------



## Horia (Jun 20, 2018)

Ok thanks a lot. I will reply with a video when it's all done. Thanks again!


----------



## Horia (Jun 22, 2018)

So i installed two days ago on my raspberry pi and the solver did a great job. But I ran out of memory ( I had 8gb) and today I bought a 32 one, and install again the solver, the color resolver and the color tracker. Everything work fine, but when attempt to solve the cube (any cube), give me this error: Cant import pyhashxx; No file named pyhashxx


----------



## dwalton76 (Jun 30, 2018)

Sorry for being slow to reply. You can do “sudo pip3 install pyhashxx” and that should fix it. I updated the install instructions in the readme to include this step.


----------



## SteveCuber (Jul 13, 2018)

dwalton76,
Great work!
Several years ago I was able to make a 3x3x3 solver in C++. More recently, I've been using Python on the Raspberry Pi and am interested in getting a solver working. I'm using a Raspberry Pi 3 with 32 GB microSD.

I was able to download your NxNxN solver and get the 3x3x3 and 4x4x4 solver running smoothly. I'm having trouble generating the 5x5x5 lookup tables. I've read through the README.md file and compiled the rotate program, but, am not able to get the builder program to work. when I run with 
./builder.py --cores 1 --depth 10 --type 5x5x5-B-centers-solve-unstaged
it returns a "Permission Denied" message.
Do you have any suggestions as to what can be done to fix this problem?
Below is my current directory.

[email protected]:~/rubiks-cube-NxNxN-solver $ ls -l
total 842392
drwxr-xr-x 5 root root 4096 Jul 12 10:55 build
-rw-r--r-- 1 pi pi 27612 Jul 13 11:21 builder555.py
-rw-r--r-- 1 pi pi 7277008 Jul 13 11:23 builder555ss.py
-rw-r--r-- 1 pi pi 1644626 Jul 13 00:51 builder666.py
-rw-r--r-- 1 pi pi 186496782 Jul 12 13:32 builder666ss.py
-rw-r--r-- 1 pi pi 3129039 Jul 12 13:32 builder666ss.py.gz
-rw-r--r-- 1 pi pi 37220 Jul 13 13:02 buildercore.py
-rw-r--r-- 1 pi pi 8160 Jul 13 12:55 builder-crunch-workq.c
-rw-r--r-- 1 pi pi 48211 Jul 13 12:56 builder-crunch-workq.py
-rw-r--r-- 1 pi pi 4319 Jul 13 12:57 builder-find-new-edges-pattern-states.py
-rw-r--r-- 1 pi pi 4070 Jul 13 13:01 builder-find-new-states.py
-rw-r--r-- 1 pi pi 81793 Jul 13 01:03 builder.py
-rw-r--r-- 1 pi pi 3123 Jul 13 13:03 builderui.py
drwxr-xr-x 2 pi pi 4096 Jul 12 10:58 cache
drwxr-xr-x 2 root root 4096 Jul 12 10:55 dist
-rw-r--r-- 1 pi pi 1336 Jul 13 12:54 gitignore.txt
-rw-r--r-- 1 pi pi 35141 Jul 12 10:54 LICENSE
-rw-r--r-- 1 pi pi 34028370 Jul 12 10:56 lookup-table-4x4x4-step10-ULFRBD-centers-stage.txt
-rw-r--r-- 1 pi pi 552269325 Jul 12 10:56 lookup-table-4x4x4-step110-edges.txt
-rw-r--r-- 1 pi pi 16711681 Jul 12 10:56 lookup-table-4x4x4-step11-UD-centers-stage.cost-only.txt
-rw-r--r-- 1 pi pi 16711681 Jul 12 10:56 lookup-table-4x4x4-step12-LR-centers-stage.cost-only.txt
-rw-r--r-- 1 pi pi 16711681 Jul 12 10:56 lookup-table-4x4x4-step13-FB-centers-stage.cost-only.txt
-rw-r--r-- 1 pi pi 21609000 Jul 12 10:56 lookup-table-4x4x4-step30-ULFRBD-centers-solve.txt
-rw-r--r-- 1 pi pi 2279 Jul 13 12:54 Makefile.txt
drwxr-xr-x 2 pi pi 4096 Jul 12 10:54 misc
drwxr-xr-x 2 pi pi 4096 Jul 13 14:19 NewTemp
-rw-r--r-- 1 pi pi 100360 Jul 13 13:03 process-workq-results.py
-rw-r--r-- 1 pi pi 9028 Jul 12 10:54 README.md
-rw-r--r-- 1 pi pi 15097 Jul 13 13:04 repopulate-workq.py
-rwxr-xr-x 1 pi pi 1593964 Jul 13 01:00 rotate
-rw-r--r-- 1 pi pi 127445 Jul 13 00:36 rotate.c
-rw-r--r-- 1 pi pi 658463 Jul 12 23:25 rotate_char_xxx.c
-rw-r--r-- 1 pi pi 551 Jul 12 23:33 rotate_char_xxx.h
-rw-r--r-- 1 pi pi 2440364 Jul 12 23:22 rotate_xxx.c
-rw-r--r-- 1 pi pi 755 Jul 13 00:38 rotate_xxx.h
-rw-r--r-- 1 pi pi 693662 Jul 13 00:41 rotate_xxx.py
drwxr-xr-x 2 pi pi 4096 Jul 12 10:54 rubikscubennnsolver
drwxr-xr-x 2 root root 4096 Jul 12 10:55 rubikscubennnsolver.egg-info
-rw-r--r-- 1 pi pi 438 Jul 12 10:54 setup.py
drwxr-xr-x 3 pi pi 4096 Jul 12 10:54 usr
drwxr-xr-x 2 pi pi 4096 Jul 12 10:54 utils
-rw-r--r-- 1 pi pi 7270 Jul 13 00:43 write_keepers.py
drwxr-xr-x 2 pi pi 4096 Jul 12 10:54 www
[email protected]:~/rubiks-cube-NxNxN-solver $ ./builder.py --cores 1 --depth 10 --type 5x5x5-B-centers-solve-unstaged
bash: ./builder.py: Permission denied


Thanks!


----------



## dwalton76 (Jul 14, 2018)

SteveCuber said:


> dwalton76,
> I've read through the README.md file and compiled the rotate program, but, am not able to get the builder program to work. when I run with
> ./builder.py --cores 1 --depth 10 --type 5x5x5-B-centers-solve-unstaged
> it returns a "Permission Denied" message.
> Do you have any suggestions as to what can be done to fix this problem?



Hey SteveCuber, you just need to make the file executable via "chmod 755 builder.py". FYI on the rubiks-cube-lookup-tables repo though:

Right now rubiks-cube-lookup-tables is a bit of a moving target. I came up with a cleaner way to build the tables and have been migrating from the old way to the new way. If you are interested in the new way take a look at buildercore.py and builder555.py. To build a table you would do "./builderui.py Build555UDCenterStage --cores 4 --depth 4" or do not list a depth to build it the entire way, be careful though some tables would be so large you will die an old man before it finishes if you try to build the entire thing.
You shouldn't need to build any tables at all. When you run the rubiks-cube-NxNxN-solver it will automatically download the tables from the following repos:
https://github.com/dwalton76/rubiks-cube-lookup-tables-4x4x4

https://github.com/dwalton76/rubiks-cube-lookup-tables-5x5x5

https://github.com/dwalton76/rubiks-cube-lookup-tables-6x6x6

https://github.com/dwalton76/rubiks-cube-lookup-tables-7x7x7

If you do want to build them though just be aware it will take a while, the 4x4x4-step110-edges tables took several days to build on a 12-core machine.

You may have to tweak some things to get the latest version of the solver to run on a RaspberryPi if you are solving anything larger than a 5x5x5. The reason being the solver now reads the lookup-tables into memory to speed things up, it used to binary search through the lookup-tables on the disk but the disk IO was a huge bottleneck. If you go through and comment out all of the "preload_cache()" calls it will read the tables from disk but will be slower.


----------



## SteveCuber (Jul 17, 2018)

I have two older systems that I haven't been using lately. Was thinking I could offer them to make lookup tables. With access to a 12 core system, sounds like you don't need it! 

The 4x4x4 solve worked well. The 5x5x5 had a memory allocation problem when ran on the raspberry pi 3. It sounds like this will only get worse with bigger cubes. I have an old dual boot laptop. Will try and see if I can get it running on Ubuntu.


----------



## dwalton76 (Jul 17, 2018)

I should be able to get the mem usage low enough to to be able to run it on a pi3...stay tuned.


----------



## SteveCuber (Jul 18, 2018)

Thanks! I dusted off my dual system laptop to find out that the Ubuntu side is corrupt. Will need to rebuild before going further with Ubuntu.

One thing I had heard, but never verified, is that that background desktop image of the Raspberry Pi can take a fair amount of memory. I changed the desktop to the "No background" option and the solver ran further. Now it stops when looking for a file 'lookup-table-5x5x5-step40-LR-t-centers-solve.txt'. This file is the in my directory and it is also not in "rubiks-cube-lookup-tables-5x5x5" on github. If this file is needed, can you post to github?

I'm sure you can interpret the warnings better than I can. Below is a part of the printout when the 5x5x5 is ran. I hope it can be of help.

****************
Location: https://media.githubusercontent.com...able-5x5x5-step30-ULFRBD-centers-solve.txt.gz [following]
--2018-07-18 09:53:20-- https://media.githubusercontent.com...able-5x5x5-step30-ULFRBD-centers-solve.txt.gz
Resolving media.githubusercontent.com (media.githubusercontent.com)... 151.101.188.133
Connecting to media.githubusercontent.com (media.githubusercontent.com)|151.101.188.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 757460 (740K) [application/octet-stream]
Saving to: ‘lookup-table-5x5x5-step30-ULFRBD-centers-solve.txt.gz’

lookup-table-5x5x5-step30-ULFRBD-centers-solve.txt.gz 100%[================================================================================================================================>] 739.71K --.-KB/s in 0.1s 

2018-07-18 09:53:20 (5.69 MB/s) - ‘lookup-table-5x5x5-step30-ULFRBD-centers-solve.txt.gz’ saved [757460/757460]

2018-07-18 09:53:20,847 LookupTable.py WARNING: gunzip lookup-table-5x5x5-step30-ULFRBD-centers-solve.txt.gz
2018-07-18 09:53:21,088 LookupTable.py WARNING: 5x5x5-step30-ULFRBD-centers-solve: begin preload cache
2018-07-18 09:53:22,235 LookupTable.py WARNING: 5x5x5-step30-ULFRBD-centers-solve: end preload cache (3,145,780 bytes)
2018-07-18 09:53:22,241 LookupTable.py WARNING: 5x5x5-step101-stage-second-four-edges: begin preload cache
2018-07-18 09:53:25,145 LookupTable.py WARNING: 5x5x5-step101-stage-second-four-edges: end preload cache (6,291,508 bytes)
2018-07-18 09:53:25,154 LookupTable.py INFO: Downloading table via 'wget https://github.com/dwalton76/rubiks...-table-5x5x5-step40-LR-t-centers-solve.txt.gz'
--2018-07-18 09:53:25-- https://github.com/dwalton76/rubiks...-table-5x5x5-step40-LR-t-centers-solve.txt.gz
Resolving github.com (github.com)... 192.30.255.112, 192.30.255.113
Connecting to github.com (github.com)|192.30.255.112|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2018-07-18 09:53:25 ERROR 404: Not Found.

2018-07-18 09:53:25,687 LookupTable.py WARNING: gunzip lookup-table-5x5x5-step40-LR-t-centers-solve.txt.gz
gzip: lookup-table-5x5x5-step40-LR-t-centers-solve.txt.gz: No such file or directory
Traceback (most recent call last):
File "./usr/bin/rubiks-cube-solver.py", line 388, in <module>
cube.solve()
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/__init__.py", line 3863, in solve
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/__init__.py", line 3723, in group_centers
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/RubiksCube555.py", line 1201, in group_centers_guts
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/RubiksCube555.py", line 1018, in lt_init
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/RubiksCube555.py", line 900, in __init__
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/LookupTable.py", line 221, in __init__
FileNotFoundError: [Errno 2] No such file or directory: 'lookup-table-5x5x5-step40-LR-t-centers-solve.txt'
[email protected]:~/rubiks-cube-NxNxN-solver $


----------



## dwalton76 (Jul 19, 2018)

You can ignore the warnings...I need to change the loglevel on those that is misleading.

Can you try the following? This should fix the lookup-table-5x5x5-step40-LR-t-centers-solve.txt error

```
$ cd ~/rubiks-cube-NxNxN-solver
$ git pull
$ sudo python3 setup.py install
```

I added memory requirements to the README...in a nutshell 4x4x4 takes 1G, 5x5x5 takes 600M, etc. I should be able to bring the memory requirements down some more though.


----------



## SteveCuber (Jul 19, 2018)

dwalton76 said:


> You can ignore the warnings...I need to change the loglevel on those that is misleading.
> 
> Can you try the following? This should fix the lookup-table-5x5x5-step40-LR-t-centers-solve.txt error
> 
> ...



Thanks for the quick response.
Unfortunately, was not able to solve the 5x5x5. I went back to verify smaller cubes. The 3x3x3 worked, but, the 4x4x4 (which previously solved) did not solve.
Below are partial outputs of the 5x5x5 then the 4x4x4.
I have a question on the memory requirements. Is 1 Gig required for the 4x4x4 and 600 Meg total required for the 5x5x5 or is it 1.6 G?

*************
The 5x5x5 is below:
2018-07-18 18:22:39,264 __init__.py INFO: B B L R F 
2018-07-18 18:22:39,264 __init__.py INFO: 
2018-07-18 18:22:39,264 __init__.py INFO: 
2018-07-18 18:22:39,284 LookupTable.py WARNING: 5x5x5-step11-UD-centers-stage-t-center-only.cost-only: begin preload cost-only
2018-07-18 18:22:40,002 LookupTable.py WARNING: 5x5x5-step11-UD-centers-stage-t-center-only.cost-only: end preload cost-only (7,632 bytes delta, 32,536 bytes total)
2018-07-18 18:22:40,004 LookupTable.py WARNING: 5x5x5-step12-UD-centers-stage-x-center-only.cost-only: begin preload cost-only
2018-07-18 18:22:40,720 LookupTable.py WARNING: 5x5x5-step12-UD-centers-stage-x-center-only.cost-only: end preload cost-only (16,368 bytes delta, 48,904 bytes total)
2018-07-18 18:22:40,725 LookupTable.py WARNING: 5x5x5-step10-UD-centers-stage: begin preload cache string
2018-07-18 18:22:56,194 LookupTable.py WARNING: 5x5x5-step10-UD-centers-stage: end preload cache string (340,868 bytes delta, 389,772 bytes total)
2018-07-18 18:22:56,224 LookupTable.py WARNING: 5x5x5-step21-LR-t-centers-stage: begin preload cache dict
2018-07-18 18:22:56,372 LookupTable.py WARNING: 5x5x5-step21-LR-t-centers-stage: end preload cache dict (0 bytes delta, 389,856 bytes total)
2018-07-18 18:22:56,373 LookupTable.py WARNING: 5x5x5-step22-LR-x-centers-stage: begin preload cache dict
2018-07-18 18:22:56,464 LookupTable.py WARNING: 5x5x5-step22-LR-x-centers-stage: end preload cache dict (592 bytes delta, 390,448 bytes total)
2018-07-18 18:22:56,464 LookupTable.py WARNING: 5x5x5-step20-LR-centers-stage: begin preload cache dict
2018-07-18 18:22:56,768 LookupTable.py WARNING: 5x5x5-step20-LR-centers-stage: end preload cache dict (4,436 bytes delta, 394,884 bytes total)
2018-07-18 18:22:56,776 LookupTable.py WARNING: 5x5x5-step31-UL-centers-solve.hash-cost-only: begin preload cost-only
2018-07-18 18:22:58,868 LookupTable.py WARNING: 5x5x5-step31-UL-centers-solve.hash-cost-only: end preload cost-only (45,980 bytes delta, 440,864 bytes total)
2018-07-18 18:22:58,889 LookupTable.py INFO: Downloading table via 'wget https://github.com/dwalton76/rubiks...able-5x5x5-step30-ULFRBD-centers-solve.txt.gz'
Traceback (most recent call last):
File "./usr/bin/rubiks-cube-solver.py", line 378, in <module>
cube.solve()
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/__init__.py", line 3886, in solve
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/RubiksCube555.py", line 1297, in group_centers_guts
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/RubiksCube555.py", line 1103, in lt_init
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/RubiksCube555.py", line 669, in __init__
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/LookupTable.py", line 840, in __init__
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/LookupTable.py", line 222, in __init__
File "/usr/lib/python3.5/subprocess.py", line 247, in call
with Popen(*popenargs, **kwargs) as p:
File "/usr/lib/python3.5/subprocess.py", line 676, in __init__
restore_signals, start_new_session)
File "/usr/lib/python3.5/subprocess.py", line 1221, in _execute_child
restore_signals, start_new_session, preexec_fn)
OSError: [Errno 12] Cannot allocate memory
[email protected]:~/rubiks-cube-NxNxN-solver $ 

********
The 4x4x4 is below:
2018-07-18 18:28:45,161 __init__.py INFO: R U F U 
2018-07-18 18:28:45,161 __init__.py INFO: 
2018-07-18 18:28:45,161 __init__.py INFO: 
2018-07-18 18:28:45,165 LookupTable.py WARNING: 4x4x4-step11-UD-centers-stage.cost-only: begin preload cost-only
2018-07-18 18:28:45,885 LookupTable.py WARNING: 4x4x4-step11-UD-centers-stage.cost-only: end preload cost-only (6,084 bytes delta, 29,688 bytes total)
2018-07-18 18:28:45,887 LookupTable.py WARNING: 4x4x4-step12-LR-centers-stage.cost-only: begin preload cost-only
2018-07-18 18:28:46,607 LookupTable.py WARNING: 4x4x4-step12-LR-centers-stage.cost-only: end preload cost-only (16,368 bytes delta, 46,056 bytes total)
2018-07-18 18:28:46,609 LookupTable.py WARNING: 4x4x4-step13-FB-centers-stage.cost-only: begin preload cost-only
2018-07-18 18:28:47,325 LookupTable.py WARNING: 4x4x4-step13-FB-centers-stage.cost-only: end preload cost-only (16,368 bytes delta, 62,424 bytes total)
2018-07-18 18:28:47,329 LookupTable.py WARNING: 4x4x4-step10-ULFRBD-centers-stage: begin preload cache set
2018-07-18 18:28:50,376 LookupTable.py WARNING: 4x4x4-step10-ULFRBD-centers-stage: end preload cache set (68,888 bytes delta, 131,312 bytes total)
2018-07-18 18:28:50,445 LookupTable.py WARNING: 4x4x4-step20-highlow-edges: begin preload cache string
2018-07-18 18:28:58,346 LookupTable.py WARNING: 4x4x4-step20-highlow-edges: end preload cache string (166,676 bytes delta, 297,988 bytes total)
2018-07-18 18:28:58,348 LookupTable.py WARNING: 4x4x4-step31-reduce333-edges.hash-cost-only: begin preload cost-only
Traceback (most recent call last):
File "./usr/bin/rubiks-cube-solver.py", line 378, in <module>
cube.solve()
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/__init__.py", line 3886, in solve
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/RubiksCube444.py", line 1384, in group_centers_guts
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/RubiksCube444.py", line 1377, in lt_init
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/RubiksCube444.py", line 875, in __init__
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/LookupTable.py", line 806, in __init__
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/LookupTable.py", line 770, in __init__
MemoryError
[email protected]:~/rubiks-cube-NxNxN-solver $



dwalton76 said:


> You can ignore the warnings...I need to change the loglevel on those that is misleading.
> 
> Can you try the following? This should fix the lookup-table-5x5x5-step40-LR-t-centers-solve.txt error
> 
> ...



I sent a reply a moment ago, but, it is under moderator review at the moment. The message (without the solver output) is:
Thanks for the quick response.
Unfortunately, was not able to solve the 5x5x5. I went back to verify smaller cubes. The 3x3x3 worked, but, the 4x4x4 (which previously solved) did not solve.
Below are partial outputs of the 5x5x5 then the 4x4x4.
I have a question on the memory requirements. Is 1 Gig required for the 4x4x4 and 600 Meg total required for the 5x5x5 or is it 1.6 G?

Part of the output from the 4x4x4 is below:

*********************
2018-07-18 18:28:58,346 LookupTable.py WARNING: 4x4x4-step20-highlow-edges: end preload cache string (166,676 bytes delta, 297,988 bytes total)
2018-07-18 18:28:58,348 LookupTable.py WARNING: 4x4x4-step31-reduce333-edges.hash-cost-only: begin preload cost-only
Traceback (most recent call last):
File "./usr/bin/rubiks-cube-solver.py", line 378, in <module>
cube.solve()
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/__init__.py", line 3886, in solve
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/RubiksCube444.py", line 1384, in group_centers_guts
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/RubiksCube444.py", line 1377, in lt_init
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/RubiksCube444.py", line 875, in __init__
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/LookupTable.py", line 806, in __init__
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/LookupTable.py", line 770, in __init__
MemoryError
[email protected]:~/rubiks-cube-NxNxN-solver $

Part of the output from the 5x5x5 is below:
*****
2018-07-18 18:34:53,367 LookupTable.py WARNING: 5x5x5-step31-UL-centers-solve.hash-cost-only: end preload cost-only (46,848 bytes delta, 438,504 bytes total)
2018-07-18 18:34:53,378 LookupTable.py INFO: Downloading table via 'wget https://github.com/dwalton76/rubiks...able-5x5x5-step30-ULFRBD-centers-solve.txt.gz'
Traceback (most recent call last):
File "./usr/bin/rubiks-cube-solver.py", line 378, in <module>
cube.solve()
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/__init__.py", line 3886, in solve
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/RubiksCube555.py", line 1297, in group_centers_guts
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/RubiksCube555.py", line 1103, in lt_init
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/RubiksCube555.py", line 669, in __init__
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/LookupTable.py", line 840, in __init__
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/LookupTable.py", line 222, in __init__
File "/usr/lib/python3.5/subprocess.py", line 247, in call
with Popen(*popenargs, **kwargs) as p:
File "/usr/lib/python3.5/subprocess.py", line 676, in __init__
restore_signals, start_new_session)
File "/usr/lib/python3.5/subprocess.py", line 1221, in _execute_child
restore_signals, start_new_session, preexec_fn)
OSError: [Errno 12] Cannot allocate memory
[email protected]:~/rubiks-cube-NxNxN-solver $

A small part of the 5x5x5 is below:
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/RubiksCube555.py", line 669, in __init__
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/LookupTable.py", line 840, in __init__
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/LookupTable.py", line 222, in __init__
File "/usr/lib/python3.5/subprocess.py", line 247, in call
with Popen(*popenargs, **kwargs) as p:
File "/usr/lib/python3.5/subprocess.py", line 676, in __init__
restore_signals, start_new_session)
File "/usr/lib/python3.5/subprocess.py", line 1221, in _execute_child
restore_signals, start_new_session, preexec_fn)
OSError: [Errno 12] Cannot allocate memory
[email protected]:~/rubiks-cube-NxNxN-solver $


----------



## dwalton76 (Jul 19, 2018)

It is just 1G for 444 and 600M for 555, not 1.6G for 555. The reason being the 555 solver doesn't need the 444 solver at all but 666 and larger NxNxN even cubes do create an instance of the 444 solver.

I just pushed another change (do the 'git pull' and 'setup.py install' again) that brings it down to 675M for 444. Give that a try and lets see if we can get you going on 444 and then we will tackle 555.

I think I can get 444 down to ~450M but I need to rebuild a big table first to do so (takes about a day).


----------



## SteveCuber (Jul 19, 2018)

4x4x4 is not solving with new pull. Below is the partial output:

****************
2018-07-18 20:00:48,205 __init__.py INFO: R U F U 
2018-07-18 20:00:48,205 __init__.py INFO: 
2018-07-18 20:00:48,206 __init__.py INFO: 
2018-07-18 20:00:48,212 LookupTable.py WARNING: 4x4x4-step11-UD-centers-stage.cost-only: begin preload cost-only
2018-07-18 20:00:48,945 LookupTable.py WARNING: 4x4x4-step11-UD-centers-stage.cost-only: end preload cost-only (6,388 bytes delta, 30,284 bytes total)
2018-07-18 20:00:48,947 LookupTable.py WARNING: 4x4x4-step12-LR-centers-stage.cost-only: begin preload cost-only
2018-07-18 20:00:49,669 LookupTable.py WARNING: 4x4x4-step12-LR-centers-stage.cost-only: end preload cost-only (16,368 bytes delta, 46,652 bytes total)
2018-07-18 20:00:49,670 LookupTable.py WARNING: 4x4x4-step13-FB-centers-stage.cost-only: begin preload cost-only
2018-07-18 20:00:50,388 LookupTable.py WARNING: 4x4x4-step13-FB-centers-stage.cost-only: end preload cost-only (16,368 bytes delta, 63,020 bytes total)
2018-07-18 20:00:50,399 LookupTable.py WARNING: 4x4x4-step10-ULFRBD-centers-stage: begin preload cache string
2018-07-18 20:00:51,340 LookupTable.py WARNING: 4x4x4-step10-ULFRBD-centers-stage: end preload cache string (21,384 bytes delta, 84,404 bytes total)
2018-07-18 20:00:51,349 LookupTable.py WARNING: 4x4x4-step31-reduce333-edges.hash-cost-only: begin preload cost-only
Traceback (most recent call last):
File "./usr/bin/rubiks-cube-solver.py", line 379, in <module>
cube.solve()
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/__init__.py", line 3886, in solve
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/RubiksCube444.py", line 1383, in group_centers_guts
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/RubiksCube444.py", line 1376, in lt_init
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/RubiksCube444.py", line 875, in __init__
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/LookupTable.py", line 890, in __init__
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/LookupTable.py", line 854, in __init__
MemoryError


----------



## dwalton76 (Jul 19, 2018)

yeah that 4x4x4-step31-reduce333-edges.hash-cost-only table takes about ~450M, that is the one I am rebuilding, I may be able to cut that in half.

For 555 I just added a "--min-memory" option that tells it to download a much smaller tables for one of the phases (it will take longer to find a solution though). With that option 555 takes 250M to run. I just pushed this a second ago so you may need to pull again.


----------



## SteveCuber (Jul 19, 2018)

dwalton76 said:


> yeah that 4x4x4-step31-reduce333-edges.hash-cost-only table takes about ~450M, that is the one I am rebuilding, I may be able to cut that in half.
> 
> For 555 I just added a "--min-memory" option that tells it to download a much smaller tables for one of the phases (it will take longer to find a solution though). With that option 555 takes 250M to run. I just pushed this a second ago so you may need to pull again.



555 is not working. Let me know how I can help.


*****
2018-07-18 21:03:52,762 LookupTable.py INFO: 5x5x5-step11-UD-centers-stage-t-center-only.cost-only: begin preload cost-only
2018-07-18 21:03:53,473 LookupTable.py INFO: 5x5x5-step11-UD-centers-stage-t-center-only.cost-only: end preload cost-only (7,816 bytes delta, 31,972 bytes total)
2018-07-18 21:03:53,474 LookupTable.py INFO: 5x5x5-step12-UD-centers-stage-x-center-only.cost-only: begin preload cost-only
2018-07-18 21:03:54,186 LookupTable.py INFO: 5x5x5-step12-UD-centers-stage-x-center-only.cost-only: end preload cost-only (16,368 bytes delta, 48,340 bytes total)
2018-07-18 21:03:54,190 LookupTable.py INFO: 5x5x5-step10-UD-centers-stage: begin preload cache string
2018-07-18 21:04:09,708 LookupTable.py INFO: 5x5x5-step10-UD-centers-stage: end preload cache string (336,004 bytes delta, 384,344 bytes total)
2018-07-18 21:04:09,819 LookupTable.py INFO: 5x5x5-step21-LR-t-centers-stage: begin preload cache dict
2018-07-18 21:04:09,956 LookupTable.py INFO: 5x5x5-step21-LR-t-centers-stage: end preload cache dict (0 bytes delta, 385,796 bytes total)
2018-07-18 21:04:09,957 LookupTable.py INFO: 5x5x5-step22-LR-x-centers-stage: begin preload cache dict
2018-07-18 21:04:10,042 LookupTable.py INFO: 5x5x5-step22-LR-x-centers-stage: end preload cache dict (1,012 bytes delta, 386,808 bytes total)
2018-07-18 21:04:10,042 LookupTable.py INFO: 5x5x5-step20-LR-centers-stage: begin preload cache dict
2018-07-18 21:04:10,339 LookupTable.py INFO: 5x5x5-step20-LR-centers-stage: end preload cache dict (4,356 bytes delta, 391,164 bytes total)
2018-07-18 21:04:10,349 LookupTable.py INFO: 5x5x5-step31-UL-centers-solve.hash-cost-only: begin preload cost-only
2018-07-18 21:04:13,320 LookupTable.py INFO: 5x5x5-step31-UL-centers-solve.hash-cost-only: end preload cost-only (45,696 bytes delta, 436,860 bytes total)
2018-07-18 21:04:13,449 LookupTable.py INFO: Downloading table via 'wget https://github.com/dwalton76/rubiks...able-5x5x5-step30-ULFRBD-centers-solve.txt.gz'
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/RubiksCube555.py", line 1309, in group_centers_guts
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/RubiksCube555.py", line 1115, in lt_init
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/RubiksCube555.py", line 681, in __init__
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/LookupTable.py", line 924, in __init__
File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver-1.0.0-py3.5.egg/rubikscubennnsolver/LookupTable.py", line 256, in __init__
File "/usr/lib/python3.5/subprocess.py", line 247, in call
with Popen(*popenargs, **kwargs) as p:
File "/usr/lib/python3.5/subprocess.py", line 676, in __init__
restore_signals, start_new_session)
File "/usr/lib/python3.5/subprocess.py", line 1221, in _execute_child
restore_signals, start_new_session, preexec_fn)
OSError: [Errno 12] Cannot allocate memory
[email protected]:~/rubiks-cube-NxNxN-solver $


----------



## dwalton76 (Jul 19, 2018)

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?


----------



## SteveCuber (Jul 19, 2018)

All Raspberry Pi 3 boards have 1G of memory.

Excellent progress.
For reasons I don't understand, after downloading and decompressing the lookup-table-5x5x5-step30-ULFRBD-centers-solve.txt.gz file from the 5x5x5 lookup table directory (and putting it into the rubiks-cube-NxNxN-solver), the 5x5x5 program ran much further. It ran to where the cube was ready for a 3x3x3 solve, but, the program stopped, saying there was a parity error.
I took the 3x3x3 equivalent and loaded it into the cube solver at www.rubiks-cube-solver.com and it solved in 22 moves. 
The kociemba listed was kociemba ULUUUFDBBLUFBRBUDFLLDDFRUBRLDBRDRDLDFRFLLFBFBRDLUBURFR. I'll send the latter part of my output file in a following message.

Very close!!


----------



## SteveCuber (Jul 19, 2018)

Below is the latter part of my message when running the 5x5x5:

146 147 148 149 150 

2018-07-19 08:20:06,603 __init__.py INFO: U L L L U 
2018-07-19 08:20:06,604 __init__.py INFO: U U U U F 
2018-07-19 08:20:06,604 __init__.py INFO: U U U U F 
2018-07-19 08:20:06,605 __init__.py INFO: U U U U F 
2018-07-19 08:20:06,605 __init__.py INFO: D B B B B 
2018-07-19 08:20:06,605 __init__.py INFO: 
2018-07-19 08:20:06,606 __init__.py INFO: F R R R F L L L L D L U U U F R D D D L 
2018-07-19 08:20:06,606 __init__.py INFO: L L L L F D F F F R B R R R B U B B B U 
2018-07-19 08:20:06,606 __init__.py INFO: L L L L F D F F F R B R R R B U B B B U 
2018-07-19 08:20:06,606 __init__.py INFO: L L L L F D F F F R B R R R B U B B B U 
2018-07-19 08:20:06,607 __init__.py INFO: B F F F B U B B B R U D D D F R F F F R 
2018-07-19 08:20:06,607 __init__.py INFO: 
2018-07-19 08:20:06,607 __init__.py INFO: L D D D B 
2018-07-19 08:20:06,608 __init__.py INFO: R D D D R 
2018-07-19 08:20:06,608 __init__.py INFO: R D D D R 
2018-07-19 08:20:06,608 __init__.py INFO: R D D D R 
2018-07-19 08:20:06,608 __init__.py INFO: D L L L D 
2018-07-19 08:20:06,609 __init__.py INFO: 
2018-07-19 08:20:06,609 __init__.py INFO: 
2018-07-19 08:20:06,610 __init__.py INFO: 
URL : https://alg.cubing.net/?puzzle=5x5x...2_Dw_F2_Dw-_L2_B2_F2_Uw_EDGES_GROUPED_y_y_x_y
2018-07-19 08:20:06,610 __init__.py INFO: 
Solution: Uw2 L' Fw R2 Uw' D2 Fw' Dw' Bw' Rw Uw Dw F R' Uw' B Bw2 Dw' R' Dw2 Lw2 Uw' Uw2 L2 Bw2 Dw2 L' Fw2 Lw2 Fw2 Rw2 Dw2 B2 Dw2 F' Rw2 CENTERS_SOLVED Lw' U2 F L' U2 F' Lw U2 B' D' Fw2 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
Uw2 L' Fw R2 Uw' D2 Fw' Dw' Bw' Rw Uw Dw F R' Uw' B Bw2 Dw' R' Dw2 Lw2 Uw' Uw2 L2 Bw2 Dw2 L' Fw2 Lw2 Fw2 Rw2 Dw2 B2 Dw2 F' Rw2 CENTERS_SOLVED Lw' U2 F L' U2 F' Lw U2 B' D' Fw2 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-19 08:20:06,611 __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


----------



## SteveCuber (Jul 19, 2018)

Two earlier messages I sent out are awaiting moderator approval. Here is a very brief summary so this message can have the right context.
The 5x5x5 program was reran after the lookup-table-5x5x5-step30-ULFRBD-centers-solve.txt.gz file was decompressed and put into the rubiks-cube-NxNxN-solver directory. The 5x5x5 program ran much further than previously, but, stopping due to what the program called a parity error. I put the output ULUUUFDBBLUFBRBUDFLLDDFRUBRLDBRDRDLDFRFLLFBFBRDLUBURFR into another online solver and it solved in 22 moves.

Since those email, I've put the above configuration into the 3x3x3 solver from your program and it solved correctly! Hope these clues help.


----------



## SteveCuber (Jul 19, 2018)

More information ...
There are 7 initial positions for a 5x5x5 cube listed in the rubiks-cube-solver.py file. I tested the first 5 of those 7 with the NxNxN solver. Four of the five positions said there was a "parity error". All four positions reached a solution when ran with the NxNxN program when the 3x3x3 position was entered. The fifth initial position was a solved cube and no turns were necessary.
I don't know how to interpret this. Do you have any suggestions?


----------



## dwalton76 (Jul 20, 2018)

SteveCuber said:


> 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 (Jul 20, 2018)

dwalton76 said:


> That is weird, kociemba does not barf for me
> 
> ```
> ddwalton-mbp:rubiks-cube-NxNxN-solver ddwalton$ kociemba ULUUUFDBBLUFBRBUDFLLDDFRUBRLDBRDRDLDFRFLLFBFBRDLUBURFR
> ...



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
[email protected]:~/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 (Jul 21, 2018)

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 (Jul 21, 2018)

dwalton76 said:


> 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 (Jul 21, 2018)

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 (Jul 21, 2018)

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 (Jul 23, 2018)

dwalton76 said:


> 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 (Jul 27, 2018)

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


----------



## SteveCuber (Jul 27, 2018)

dwalton76 said:


> 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 (Jul 27, 2018)

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

[email protected]:~/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:
[email protected]:~ $ 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
[email protected]:~/rubiks-cube-NxNxN-solver $ 
total used free shared buff/cache available
Mem: 927 87 405 6 434 781
Swap: 99 0 99

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


----------



## dwalton76 (Jul 27, 2018)

_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 (Jul 27, 2018)

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 (Jul 28, 2018)

Duncan Bannon said:


> 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 (Jul 28, 2018)

dwalton76 said:


> _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
> 
> ...



When I run the second line, it returns the following:
[email protected]:~/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 (Jul 28, 2018)

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 (Jul 29, 2018)

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 (Aug 5, 2018)

SteveCuber said:


> 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 (Aug 6, 2018)

SteveCuber said:


> 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.



SteveCuber said:


> 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.



SteveCuber said:


> 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 (Aug 7, 2018)

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 (Aug 11, 2018)

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


----------



## SteveCuber (Aug 11, 2018)

P.S. The below was ran prior to the latest additions being ran.
$ git pull
$ python*3* setup.py build
$ sudo python3 setup.py install


----------



## SteveCuber (Sep 8, 2018)

Hi dwalton76,
I see you've been very busy upgrading the solver and getting the larger cube sizes down further.

I noticed a few weeks back that some of the solver runs were taking longer than they had previously on my laptop. More recently, I've been getting error messages that seem to start after the program prints out "ida_search is missing". The solver began to abort on as low as a 4x4x4 cube (the 3x3x3 still worked). 
I decided to rename my existing solver directory and reinstall from github. I'm still seeing the same problem.

On my Raspberry Pi 3 (which has not had connected to the internet for several weeks and has not received recent updates) can still solve a 4x4x4, but, on the 5x5x5 takes hours to run and does not find a solution.

Below is an example from the 4x4x4.


Do you have any ideas as to what I can do to fix the problem.

Thank You,
SteveCuber

2018-09-08 10:04:23,349 __init__.py INFO: F L D F 
2018-09-08 10:04:23,350 __init__.py INFO: D L B D 
2018-09-08 10:04:23,350 __init__.py INFO: F B L F 
2018-09-08 10:04:23,350 __init__.py INFO: F R R B 
2018-09-08 10:04:23,350 __init__.py INFO: 
2018-09-08 10:04:23,351 __init__.py INFO: D F L D R U D R D R F R U B F L 
2018-09-08 10:04:23,351 __init__.py INFO: B L U B R B F F R U R B L R F L 
2018-09-08 10:04:23,351 __init__.py INFO: F R F U B D L U R D U B U R D U 
2018-09-08 10:04:23,351 __init__.py INFO: F B D D B L U U B D L U L L R U 
2018-09-08 10:04:23,351 __init__.py INFO: 
2018-09-08 10:04:23,352 __init__.py INFO: L U F R 
2018-09-08 10:04:23,352 __init__.py INFO: R F B L 
2018-09-08 10:04:23,352 __init__.py INFO: D D U U 
2018-09-08 10:04:23,352 __init__.py INFO: L B D B 
2018-09-08 10:04:23,352 __init__.py INFO: 
2018-09-08 10:04:23,353 __init__.py INFO: 
2018-09-08 10:04:24,143 LookupTable.py INFO: 4x4x4-step31-reduce333-edges.hash-cost-only: end preload cost-only (230,228 bytes delta, 267,836 bytes total)
2018-09-08 10:04:24,387 LookupTable.py INFO: 4x4x4-step32-reduce333-centers: end preload cache dict (8,976 bytes delta, 276,812 bytes total)
2018-09-08 10:04:24,577 LookupTable.py INFO: 4x4x4-step30-reduce333: end preload cache string (101,112 bytes delta, 377,924 bytes total, 103,676,544 characters)
2018-09-08 10:04:24,578 RubiksCube444.py INFO: 4x4x4: Start of Phase1, 0 steps in
2018-09-08 10:04:24,578 LookupTable.py INFO: LookupTableIDA444ULFRBDCentersStage: recolor
2018-09-08 10:04:24,579 LookupTable.py INFO: ida_search is missing...compiling it now
ida_search_555.c: In function ‘ida_heuristic_ULFRBD_centers_555’:
ida_search_555.c:218:42: warning: ‘__builtin___sprintf_chk’ may write a terminating nul past the end of the destination [-Wformat-overflow=]
sprintf(UL_centers_state_str , "%09lx", UL_centers_state);
^
In file included from /usr/include/stdio.h:862:0,
from ida_search_555.c:3:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:33:10: note: ‘__builtin___sprintf_chk’ output between 10 and 17 bytes into a destination of size 16
return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
__bos (__s), __fmt, __va_arg_pack ());
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ida_search_555.c:235:42: warning: ‘__builtin___sprintf_chk’ may write a terminating nul past the end of the destination [-Wformat-overflow=]
sprintf(UF_centers_state_str , "%09lx", UF_centers_state);
^
In file included from /usr/include/stdio.h:862:0,
from ida_search_555.c:3:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:33:10: note: ‘__builtin___sprintf_chk’ output between 10 and 17 bytes into a destination of size 16
return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
__bos (__s), __fmt, __va_arg_pack ());
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ida_search_555.c:252:42: warning: ‘__builtin___sprintf_chk’ may write a terminating nul past the end of the destination [-Wformat-overflow=]
sprintf(LF_centers_state_str , "%09lx", LF_centers_state);
^
In file included from /usr/include/stdio.h:862:0,
from ida_search_555.c:3:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:33:10: note: ‘__builtin___sprintf_chk’ output between 10 and 17 bytes into a destination of size 16
return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
__bos (__s), __fmt, __va_arg_pack ());
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/ccdFnIK7.o: In function `ida_heuristic':
ida_search.c.text+0xc7b): undefined reference to `ida_heuristic_step60_777'
ida_search.c.text+0xccb): undefined reference to `ida_heuristic_centers_444'
ida_search.c.text+0xd34): undefined reference to `ida_heuristic_UD_oblique_edges_stage_666'
ida_search.c.text+0xd59): undefined reference to `ida_heuristic_LR_inner_x_centers_and_oblique_edges_stage_666'
ida_search.c.text+0xd6c): undefined reference to `ida_heuristic_UD_oblique_edges_stage_777'
ida_search.c.text+0xd7c): undefined reference to `ida_heuristic_LR_oblique_edges_stage_777'
ida_search.c.text+0xda1): undefined reference to `ida_heuristic_step40_777'
ida_search.c.text+0xdc9): undefined reference to `ida_heuristic_step50_777'
/tmp/ccdFnIK7.o: In function `ida_search':
ida_search.c.text+0x17b7): undefined reference to `ida_heuristic_step60_777'
ida_search.c.text+0x1a27): undefined reference to `ida_heuristic_centers_444'
ida_search.c.text+0x1aa0): undefined reference to `ida_heuristic_UD_oblique_edges_stage_666'
ida_search.c.text+0x1acd): undefined reference to `ida_heuristic_LR_inner_x_centers_and_oblique_edges_stage_666'
ida_search.c.text+0x1ae8): undefined reference to `ida_heuristic_UD_oblique_edges_stage_777'
ida_search.c.text+0x1b00): undefined reference to `ida_heuristic_LR_oblique_edges_stage_777'
ida_search.c.text+0x1b2d): undefined reference to `ida_heuristic_step40_777'
ida_search.c.text+0x1b5d): undefined reference to `ida_heuristic_step50_777'
/tmp/ccdFnIK7.o: In function `ida_solve':
ida_search.c.text+0x2169): undefined reference to `ida_heuristic_step60_777'
ida_search.c.text+0x224f): undefined reference to `ida_heuristic_step50_777'
ida_search.c.text+0x2287): undefined reference to `ida_heuristic_step40_777'
ida_search.c.text+0x22a2): undefined reference to `ida_heuristic_LR_oblique_edges_stage_777'
ida_search.c.text+0x22c2): undefined reference to `ida_heuristic_UD_oblique_edges_stage_777'
ida_search.c.text+0x22f7): undefined reference to `ida_heuristic_LR_inner_x_centers_and_oblique_edges_stage_666'
ida_search.c.text+0x2312): undefined reference to `ida_heuristic_UD_oblique_edges_stage_666'
ida_search.c.text+0x23c1): undefined reference to `ida_heuristic_centers_444'
/tmp/ccdFnIK7.o: In function `ida_search_complete':
ida_search.c.text+0x1015): undefined reference to `ida_search_complete_UD_oblique_edges_stage_666'
ida_search.c.text+0x1025): undefined reference to `ida_search_complete_LR_inner_x_centers_and_oblique_edges_stage'
ida_search.c.text+0x1035): undefined reference to `ida_search_complete_UD_oblique_edges_stage_777'
ida_search.c.text+0x1045): undefined reference to `ida_search_complete_LR_oblique_edges_stage_777'
ida_search.c.text+0x1055): undefined reference to `ida_search_complete_step40_777'
ida_search.c.text+0x1065): undefined reference to `ida_search_complete_step50_777'
ida_search.c.text+0x1075): undefined reference to `ida_search_complete_centers_444'
ida_search.c.text+0x1085): undefined reference to `ida_search_complete_step60_777'
/tmp/ccoD7PC6.o: In function `ida_heuristic_ULFRBD_centers_555':
ida_search_555.c.text+0x3b1): undefined reference to `XXH32'
ida_search_555.c.text+0x46b): undefined reference to `XXH32'
ida_search_555.c.text+0x52e): undefined reference to `XXH32'
collect2: error: ld returned 1 exit status
Traceback (most recent call last):
File "./usr/bin/rubiks-cube-solver.py", line 301, in <module>
cube.solve()
File "/usr/local/lib/python3.6/dist-packages/rubikscubennnsolver/__init__.py", line 3935, in solve
self.group_centers_guts()
File "/usr/local/lib/python3.6/dist-packages/rubikscubennnsolver/RubiksCube444.py", line 1119, in group_centers_guts
self.lt_ULFRBD_centers_stage.solve()
File "/usr/local/lib/python3.6/dist-packages/rubikscubennnsolver/LookupTable.py", line 1252, in solve
subprocess.check_output("gcc -O3 -o ida_search ida_search_core.c ida_search.c rotate_xxx.c ida_search_555.c -lm".split())
File "/usr/lib/python3.6/subprocess.py", line 336, in check_output
**kwargs).stdout
File "/usr/lib/python3.6/subprocess.py", line 418, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['gcc', '-O3', '-o', 'ida_search', 'ida_search_core.c', 'ida_search.c', 'rotate_xxx.c', 'ida_search_555.c', '-lm']' returned non-zero exit status 1.


----------



## SteveCuber (Sep 9, 2018)

Hi dwalton76,
One more thing. I thought that I may have caused problems on both my laptop and Raspberry Pi 3, so I made a microSD with a fresh Raspbian Stretch install and downloaded the 3x3x3 and the NxNxN-solver per github. 
A 4x4x4 case was ran with and without the --min-memory options were ran. There did not run to completion. Attached are the files.
SteveCuber


----------



## dwalton76 (Sep 17, 2018)

Apologies for being slow to respond...was out of town then had some hurricane fun. Can you try the following and let me know if it fixes the failures?



```
$ git pull
$ make clean
$ make all
```


----------



## SteveCuber (Sep 18, 2018)

dwalton76 said:


> Apologies for being slow to respond...was out of town then had some hurricane fun. Can you try the following and let me know if it fixes the failures?
> 
> 
> 
> ...



Hope you came out of the hurricane OK.

Thanks again for your efforts as well as the effort to put the code together in the first place!
I did the three lines above and ran 4x4x4, 5x5x5, 6x6x6 and 7x7x7. Only the 4x4x4 case gave a solution. Attached are the files.

I'm happy to run ideas that you have. If you are short on time let me know and I can reinstall Ubuntu and try again. Not much of a problem as my laptop had Ubuntu installed recently. There is not much installed beyond the NxNxN solver. Either way is fine with me.


----------



## dwalton76 (Sep 18, 2018)

Can you run this and send me the output:

```
./ida_search --kociemba .DBL.FxxxFFxxxDFxxxD.DUF..BRL.FLLLBDLLFLUFFLB.BRF..LFR.RLFLRLFFFBBLFFL.FBL..ULU.RxxxUBxxxULxxxU.URB..LDD.FFLFULFLLURFLFL.BUD..DRB.RLFLDDLFLFRFLFD.UFR. --type 5x5x5-LR-centers-stage
```


----------



## SteveCuber (Sep 18, 2018)

dwalton76 said:


> Can you run this and send me the output:
> 
> ```
> ./ida_search --kociemba .DBL.FxxxFFxxxDFxxxD.DUF..BRL.FLLLBDLLFLUFFLB.BRF..LFR.RLFLRLFFFBBLFFL.FBL..ULU.RxxxUBxxxULxxxU.URB..LDD.FFLFULFLLURFLFL.BUD..DRB.RLFLDDLFLFRFLFD.UFR. --type 5x5x5-LR-centers-stage
> ```



Attached is the result.


----------



## dwalton76 (Sep 19, 2018)

ah, I forgot to push a commit. I've pushed it now, can you redo the "git pull, etc" steps and try it again.


----------



## SteveCuber (Sep 19, 2018)

Great news. 5x5x5 works. 6x6x6 is running


----------



## SteveCuber (Sep 19, 2018)

Mixed news. 6x6x6 passed, but, 7x7x7 does not solve. Attached is 7x7x7 file. Will continue testing and advise results.


----------



## dwalton76 (Sep 19, 2018)

What do you get for:

```
./ida_search --kociemba DLFFRRLFDUUDULRDUUDUDBDUUDUDBDUUDUFFDUUDUURBFRBFFUBLBBDBFLLLLLUDRRRRRFRRRRRRDRLLLLLBULLLLLUBLUUDRRDDUFLURBFBBFFLBFFBBBLFFBFFFBDBBFFFDBFBBBFFDDUDRRLRFLFFDULUDDUDBLUDDUDRDUDDUDLDUDDUDRFUDDUDUFFUUBDBLDFLDLFRRRRRRUULLLLLLULLLLLLURRRRRLRRRRRRDURFRUUBDDUULBFRBFFBBBDBFFBFFLFBBBBBRFBFFFBLBBBFBBULRRBRL --type 7x7x7-step60
```


----------



## SteveCuber (Sep 19, 2018)

dwalton76 said:


> What do you get for:
> 
> ```
> ./ida_search --kociemba DLFFRRLFDUUDULRDUUDUDBDUUDUDBDUUDUFFDUUDUURBFRBFFUBLBBDBFLLLLLUDRRRRRFRRRRRRDRLLLLLBULLLLLUBLUUDRRDDUFLURBFBBFFLBFFBBBLFFBFFFBDBBFFFDBFBBBFFDDUDRRLRFLFFDULUDDUDBLUDDUDRDUDDUDLDUDDUDRFUDDUDUFFUUBDBLDFLDLFRRRRRRUULLLLLLULLLLLLURRRRRLRRRRRRDURFRUUBDDUULBFRBFFBBBDBFFBFFLFBBBBBRFBFFFBLBBBFBBULRRBRL --type 7x7x7-step60
> ```



Attached is file when the above was ran.

Also, have ran five cases of 3x3x3, 4x4x4, 5x5x5, and 6x6x6. They all were solved. Five of five cases for the 7x7x7 were unsolved. One of one case of 8x8x8 ran and was unsolved. Files for unsolved cases attached.


----------



## dwalton76 (Sep 19, 2018)

7x7x7 and larger should be working now (just pushed a fix)


----------



## SteveCuber (Sep 19, 2018)

Thanks for the quick reply.

Nothing but good news this time. All five cases of 7x7x7 are passing. All five cases of 8x8x8 are passing. Two of two 9x9x9 cases passing. Will be doing more testing later today.


----------



## SteveCuber (Sep 20, 2018)

SteveCuber said:


> Thanks for the quick reply.
> 
> Nothing but good news this time. All five cases of 7x7x7 are passing. All five cases of 8x8x8 are passing. Two of two 9x9x9 cases passing. Will be doing more testing later today.



dwalton76,

Planned testing is completed. Five cases of 7x7x7, 8x8x8, 9x9x9, 10x10x10, and 11x11x11 were done. All cases were solved.
Thanks for resolving this problem.


----------



## dwalton76 (Nov 20, 2018)

FYI I have installed my solver on a pi3 and will use that for testing in the future. 4x4x4 takes ~10s, 5x5x5 takes ~180s, 6x6x6 and larger run out of RAM and do not produce a solution. Am going to work on making this run faster on pi3 but the solutions will be a little longer than "--normal" mode.


----------



## SteveCuber (Nov 21, 2018)

dwalton76 said:


> FYI I have installed my solver on a pi3 and will use that for testing in the future. 4x4x4 takes ~10s, 5x5x5 takes ~180s, 6x6x6 and larger run out of RAM and do not produce a solution. Am going to work on making this run faster on pi3 but the solutions will be a little longer than "--normal" mode.



Thanks! I look forward to seeing it.


----------



## SteveCuber (Jul 26, 2019)

Hi dwalton76,
I had previously made a cube tracker to determine cube color values for a 3x3x3. Decided to update my code instead of using the rubiks-cube-tracker.py code you have. I was thinking that as long as the output file that goes into the solver is the same format, then there should not be a problem. I have typed into the files the values of each of the six faces. My tracker code takes one file from each of the six faces and simply combines them. For the moment I'm cutting and pasting the result into the command line after "reset; ./usr/bin/rubiks-cube-solver.py --state" and pressing return. My hope was that this would validate the approach.
It hasn't turn out exactly that way. For the test case I created files for a cube that has had only two turns. The 5x5x5 case solved as expected. When I ran the attached "11x11x11InputToSolver" case the program did not run to completion. The cube was as expected when it was displayed early in the solve process. It ran until only edge and corner cubes were unsolved and gave a message ending with "raise Exception("L4E group but where?") Exception: L4E group but where?". 
Can you see anything wrong with my "11x11x11InputToSolver" file? Would you be able to tell me if it runs on your system? Any help would be appreciated.


----------



## dwalton76 (Jul 27, 2019)

@SteveCuber yep I can reproduce it with your 11x11x11 state file. Your state file looks legit, I think you just found a new bug. Looking...


----------



## Dylan Swarts (Jul 27, 2019)

I'm sorry that this is totally unrelated to the conversation, but I just spent a quarter of an hour or so reading through some messages on this thread and this is so fascinating. I know very little of what any of you say but I wish I did, are you programmers or coders? Or is coding a hobby?


----------



## dwalton76 (Jul 27, 2019)

I just pushed a fix, the odds of hitting that bug were 1 in 40,320!!  There is one more bug to fix here, for some reason the entire cube rotations (x, y, z moves) are not being removed as they should be.


----------



## dwalton76 (Jul 27, 2019)

Dylan Swarts said:


> I'm sorry that this is totally unrelated to the conversation, but I just spent a quarter of an hour or so reading through some messages on this thread and this is so fascinating. I know very little of what any of you say but I wish I did, are you programmers or coders? Or is coding a hobby?



I write code for a living and as a hobby  I do a lot of lego mindstorms projects for fun and one of those was a rubiks cube solving robot which led me down this path of writing a NxNxN rubiks cube solver.


----------



## SteveCuber (Jul 28, 2019)

dwalton76 said:


> I just pushed a fix, the odds of hitting that bug were 1 in 40,320!!  There is one more bug to fix here, for some reason the entire cube rotations (x, y, z moves) are not being removed as they should be.


One in 40,320! I was really scratching my head over this one. Tried out the fix and it worked like a charm. Thanks for the quick solution.


----------



## dwalton76 (Jul 29, 2019)

dwalton76 said:


> There is one more bug to fix here, for some reason the entire cube rotations (x, y, z moves) are not being removed as they should be.



Pushed a fix for this bug @SteveCuber here is the solution for your 11x11x11 without the x, y, z rotations


----------



## SteveCuber (Jul 30, 2019)

dwalton76 said:


> Pushed a fix for this bug @SteveCuber here is the solution for your 11x11x11 without the x, y, z rotations


Thanks again.


----------



## SteveCuber (Jan 21, 2020)

Hi dwalton76,
Unfortunately, the uSD on my RaspberryPi 3 crashed. Fortunately, a backup of key files was done a few days before. Reinstalled Raspbian and tested a few Python programs and all looked good. I did a reinstall of rubiks-cube-NxNxN-solver and kociemba 3x3x3 solver, per github instructions.
Tried 3x3x3 and 5x5x5 and was not able to get either to work.

Have attached the results from my installation and running of the attempt to solve the first cube. A common error on install and the first run is an invalid syntax related to a filesize, such as below:

File "/usr/local/lib/python3.5/dist-packages/rubikscubennnsolver/LookupTable.py", line 286
log.info(f"{filename}: filesize {os.path.getsize(filename):,} does not equal target filesize {filesize:,}")
^
SyntaxError: invalid syntax

Any suggestions you have to offer would be appreciated.

Thank You


----------



## dwalton76 (Jan 21, 2020)

It is because of the f-strings, this feature was introduced in python3.6 but you are running 3.5. I should have the installer catch this and raise a better error.

In a nutshell though if you upgrade to python 3.6 or later you should be good.


----------



## SteveCuber (Jan 21, 2020)

dwalton76 said:


> It is because of the f-strings, this feature was introduced in python3.6 but you are running 3.5. I should have the installer catch this and raise a better error.
> 
> In a nutshell though if you upgrade to python 3.6 or later you should be good.



Thanks for the quick reply.


----------



## SteveCuber (Jan 22, 2020)

Hi dwalton76,
Updated python3 and now have Rev 3.7.3 installed. FYI, the code is being ran on a Raspberry Pi 3. The latest version of Raspbian was downloaded earlier this week.

With Python 3.7.3 installed, a 3x3x3 cube was solved. One case each of 4x4x4 and 5x5x5 cubes were not solved. Output files are attached.
Do you have any other suggestions?
Regards.


----------



## Hakodora (May 2, 2021)

dear all
great post for cube solver, it is the best in the world.
i followed all instructions in GitHub to setup software, but comes with error in beginning when I ran ”cranecube.py“ on my Ev3, which shows largemotor doesn’t have attribute “wait_until_moving”, and one more problem is 6x6x6 is automatically set in the beginning (while I get 3x3x3 cube only).
appreciate much if any one can help or guide me, millions thanks.


----------



## abunickabhi (May 18, 2021)

I just wanted to solve a 17x17 on my machine and was lazy to write a kociemba order for 17x17 (https://www.speedsolving.com/threads/program-to-convert-a-scramble-to-kociemba-order-string.84674/). Is there a better way rather than manually typing down the cube state. (I dont own a 17x17 real cube so scanning is not an option.)

The lookup-table folder currently is 11.5GB, I hope it includes all the lookup tables that were uploaded by you.

Also, dwalton76, have you tried 18x18 solve on this program?


----------



## ruwix (Aug 23, 2021)

Have you seen this NxN solver: https://cube-solver.com/
It's far from being optimal but it's worth checking out.


----------



## dwalton76 (Aug 24, 2021)

SteveCuber said:


> Hi dwalton76,
> Updated python3 and now have Rev 3.7.3 installed. FYI, the code is being ran on a Raspberry Pi 3. The latest version of Raspbian was downloaded earlier this week.
> 
> With Python 3.7.3 installed, a 3x3x3 cube was solved. One case each of 4x4x4 and 5x5x5 cubes were not solved. Output files are attached.
> ...



My apologies for replying a year and a half later  I tried those two cubes and they are both working today on later master. Can you try


```
git pull
make clean
make init
source ./venv/bin/activate
```

and try to solve those cubes again.


----------



## dwalton76 (Aug 24, 2021)

Hakodora said:


> dear all
> great post for cube solver, it is the best in the world.
> i followed all instructions in GitHub to setup software, but comes with error in beginning when I ran ”cranecube.py“ on my Ev3, which shows largemotor doesn’t have attribute “wait_until_moving”, and one more problem is 6x6x6 is automatically set in the beginning (while I get 3x3x3 cube only).
> appreciate much if any one can help or guide me, millions thanks.



Are you still seeing this issue? I suspect you were on a later release of ev3dev-lang-python that did not have `wait_until_moving`


----------



## dwalton76 (Aug 24, 2021)

abunickabhi said:


> I just wanted to solve a 17x17 on my machine and was lazy to write a kociemba order for 17x17 (https://www.speedsolving.com/threads/program-to-convert-a-scramble-to-kociemba-order-string.84674/). Is there a better way rather than manually typing down the cube state. (I dont own a 17x17 real cube so scanning is not an option.)
> 
> The lookup-table folder currently is 11.5GB, I hope it includes all the lookup tables that were uploaded by you.
> 
> Also, dwalton76, have you tried 18x18 solve on this program?



This will print the cube and the kociemba string for a scrambled 17x17x17

```
from rubikscubennnsolver import configure_logging, RubiksCube
from rubikscubennnsolver.RubiksCubeNNNOdd import solved_171717

configure_logging()
cube = RubiksCube(solved_171717, 'URFDLB')
cube.randomize(count=2000)
cube.print_cube()
print((cube.get_kociemba_string(True))
```

11.5G for the tables sounds about right

I tried up to a 20x20x20 at some point but eventually the cubes become so large that alg.cubing.net cannot load the page with the solution. The solver will work with any size cube though.


----------



## dwalton76 (Aug 24, 2021)

ruwix said:


> Have you seen this NxN solver: https://cube-solver.com/
> It's far from being optimal but it's worth checking out.


Interesting...it is lighting fast at producing a solution but the solutions are huuuuge. For a scambled 5x5x5 is produced a solution 1067 steps long! 

230 steps to solve the centers
675 steps to pair the edges
162 steps to solve the 3x3x3
That is the only web-based solver that I know of for 5x5x5 and larger though so even though the solutions are long at least it is out there.


----------



## abunickabhi (Aug 25, 2021)

dwalton76 said:


> This will print the cube and the kociemba string for a scrambled 17x17x17
> 
> ```
> from rubikscubennnsolver import configure_logging, RubiksCube
> ...


I think the new twizzle software made by Lucas Garron can go higher than 17x17 representations.
The alg.cubing had a NxN limit, but twizzle will not have one.


----------



## dwalton76 (Aug 26, 2021)

twizzle looks pretty cool, I'll switch my solver over to that once it is ready


----------

