Ikpx and grills

[googleplex]

Did you get it to work on Windows at all? Or is it just working on your Pi?

Only on the pi.

[Hooloovoo]

have either of you tried running linux on your x86 box? That should be way faster than a pi.

I suspect there are some differences in windows threading (maybe) or IPC (likely??) which causes problems, if you're getting no output at all.

[googleplex]

i'm trying to spin up a vm on my gaming pc.

[googleplex]

would there be any way to configure ikpx to search for wide spaceships?

[Giada Carrara]

It seems to have this problem with Cygwin, and windows in particular, but I can't figure anything out beyond that.

I can confirm that ikpx has some compatibility problems with Cygwin, I tried to run some searches with it but the same thing that happened to Googleplex happened to me. The SAT solver iglucose was functional, and ikpx was able to automatically extend search width, but it didn't print any partial or use any of my computer's CPU.
Well,that's too bad, because I'd have liked to run it.

[googleplex]

My house lost power, and the ikpx search i've been running for over 3 months was lost. I tried restarting the search from the backup but it restarted the search. R.I.P.

[77topaz]

My house lost power, and the ikpx search i've been running for over 3 months was lost. I tried restarting the search from the backup but it restarted the search. R.I.P.

Doesn't it automatically save last partials or positions in the search tree or something like that? I recall Calcyman was able to find Sir Robin as part of a larger tagalong-partial output by ikpx. But anyway, if there isn't such a saving functionality, I think it should be a priority to add one, to avoid major time losses like this.

[calcyman]

My house lost power, and the ikpx search i've been running for over 3 months was lost. I tried restarting the search from the backup but it restarted the search. R.I.P.

The backups have redundancy (the last 2 backups are retained), so you can resume even in the unlikely event that your computer crashed *whilst saving a backup*.

Do you still have those files?

[googleplex]

My house lost power, and the ikpx search i've been running for over 3 months was lost. I tried restarting the search from the backup but it restarted the search. R.I.P.

The backups have redundancy (the last 2 backups are retained), so you can resume even in the unlikely event that your computer crashed *whilst saving a backup*.

Do you still have those files?

when I tried running the same command with the same folder, it started over.

[wildmyron]

I've been able to run ikpx on Windows after compiling iglucose using Ubuntu under Windows Subsytem for Linux. It seems to run well, though I don't have a good performance comparison. There is one caveat: the working directory needs to be under the Linux rootfs, probably because named pipes don't work when using a directory on the Windows file system.

I posted the results of a trial 2c/5 search on the Spaceship Discussion thread. There's a lot of scope for searching with ikpx but I lack a good understanding of how to run those searches efficiently. In particular, selection of an optimal k still eludes me. For the width 9 search with k=60 there's a wide variation of glucose run times. A large fraction seem to complete in under 1s, a large minority take around 5-10s and a few take up to a minute. For a width 10 search I ran (from scratch, so no length 500 partials in the search tree) with k=50, I saw the majority of SAT problems also running for a fraction of a second, many for 2-15s, several up to 2 min, and one for 44min! (Actually, shouldn't the default timeout of 600 have prevented that?) Should I keep increasing k until glucose frequently takes > 1min to run or is this about right.

Reading through the blog entry detailing the discovery of Sir Robin I'm amazed that a search can run to completion at widths in excess of 30. Presumably one of the following is true: My 2c/5 searches are running with very sub-optimal performance, the search tree for 2c/5 in CGoL is much bigger than the tree for (2,1)c/6, or calcyman was throwing a lot of cores at the problem.

I'm yet to try adding partials to the search tree and allowing ikpx to extend them, but I expect this could be a very useful tool for this purpose. I understand it's possible to add partial heads to the search, but is it also possible to add middles to the search and to tell ikpx to exclusively try to extend the provided partial? I'm guessing that's what the 'i' parameter to -f and -b are for. I just need to figure out the format to enter the rows.

[calcyman]

I've been able to run ikpx on Windows after compiling iglucose using Ubuntu under Windows Subsytem for Linux.

Excellent!

It's not straightforward to compare widths/depths across different velocities, because they're expressed in 'logical rows' and 'logical columns' as opposed to physical rows/columns. So the width-30 search at (2,1)c/6 was only 15 physical columns, whereas your width-9 search at 2c/5 corresponds to 9 physical columns. And since 2c/5 is lower-period, its search tree is likely to branch more at any given physical width.

Those timings look good to me; most iglucose runs should take about a second.

Selection of an optimal k is difficult. If you don't specify any k, ikpx will suggest what it thinks is a reasonable value to try, but there's no guarantees of optimality. Judging by your partials, I think your suggestion of k=60 is better than ikpx's suggestion of k=42.

It currently supports loading partial fronts but not partial backs. To do so, use --loadhead 'path/to/file.rle' where file.rle contains a partial front in ikpx format. If you have a partial from a different search program, you'll need to run golly2ikpx.py and then shave off the back few rows [because they're likely to be messed up].

I did use lots of cores, yes; I think I had about 50 head threads and 20 tail threads running, but the machine was being shared by many people running higher-priority tasks.

[2718281828]

It currently supports loading partial fronts but not partial backs. To do so, use --loadhead 'path/to/file.rle' where file.rle contains a partial front in ikpx format. If you have a partial from a different search program, you'll need to run golly2ikpx.py and then shave off the back few rows [because they're likely to be messed up].

I tried a test on this head partial (ikpx format):

Code: Select all

x = 11, y = 51, rule = B3/S23
7bo$7bo$6b3o$6bobo$6b3o$6b3o$5bo3bo$5bo3bo$5bo3bo$6b3o$5b4o2$4bo$3b2ob
4o$3b2o5bo$3b3o3b2o$2bo6b2o$2bo2b2o2b2o$b2ob2o3b2o$2bo3bo$b2o5bo$4bo2b
obo$bo5bob2o$b3ob2o$bobob3o$2bob2o$4b2obo2bo$bo5b2o$5bob3o$2bo2bobobo$
3bobo3b2o$2b2obob3o$4bo4bo$3b4o$7bo$bo2bo2bo$b3ob3o$b3o3bo$b2o3b3o$o$o
6bo$b5ob2o$bob3o2bo$4b4o$4bo3bo$5b2obo$5b3o$4bo2bo3$6bo!

which corresponds to this golly-rle head:

Code: Select all

x = 51, y = 17, rule = B3/S23
7bo19bo18b3o$6bobo17b3o17b3o$5bo3bo15bo3bo15bo3bo$6b3o16b4o$4bo18b2ob
4o13b2o5bo$3b3o3b2o11bo6b2o11bo2b2o2b2o$b2ob2o3b2o11bo3bo14b2o5bo$4bo
2bobo11bo5bob2o10b3ob2o$bobob3o14bob2o18b2obo2bo$bo5b2o16bob3o12bo2bob
obo$3bobo3b2o11b2obob3o14bo4bo$3b4o20bo13bo2bo2bo$b3ob3o13b3o3bo13b2o
3b3o$o19bo6bo13b5ob2o$bob3o2bo15b4o16bo3bo$5b2obo16b3o16bo2bo$46bo!

I used the command (test_head_c3o.rle is in ikpx format)

Code: Select all

python ikpx.py -d ikpxtestc3o -f p1k30w12 -v c/3o -l head/test_head_c3o.rle

I got many outputs, e.g. this thing:

Code: Select all

Spaceship completed by extending heads.
As integer list: (4096, 4096, 14336, 10240, 14336, 14336, 17408, 17408, 17408, 14336, 15360, 0, 512, 31488, 33536, 50944, 49280, 52352, 50880, 2176, 8384, 20992, 53312, 3520, 7488, 1664, 38400, 12352, 29696, 21632, 50432, 30080, 16896, 3840, 4096, 4672, 7616, 4544, 14528, 32, 4128, 14272, 10048, 7680, 8704, 11264, 7168, 4608, 0, 0, 2048, 0, 96, 96, 1780, 1686, 1902, 758, 1542, 1, 105, 521, 1862, 770, 224, 320, 64, 512, 384, 384, 128)
As plaintext:
............*
............*
...........***
...........*.*
...........***
...........***
..........*...*
..........*...*
..........*...*
...........***
..........****
.
.........*
........**.****
........**.....*
........***...**
.......*......**
.......*..**..**
......**.**...**
.......*...*
......**.....*
.........*..*.*
......*.....*.**
......***.**
......*.*.***
.......*.**
.........**.*..*
......*.....**
..........*.***
.......*..*.*.*
........*.*...**
.......**.*.***
.........*....*
........****
............*
......*..*..*
......***.***
......***...*
......**...***
.....*
.....*......*
......*****.**
......*.***..*
.........****
.........*...*
..........**.*
..........***
.........*..*
.
.
...........*
.
.....**
.....**
..*.****.**
.**.*..*.**
.***.**.***
.**.****.*
.**......**
*
*..*.**
*..*.....*
.**...*.***
.*......**
.....***
......*.*
......*
.........*
.......**
.......**
.......*

If I transform it back to golly-rle I get

Code: Select all

x = 66, y = 24, rule = B3/S23
37bo24bo$11b3o22bobo22b3o$11b3o21bo3bo20bo3bo$10bo3bo21b3o21b4o$34bo
23b2ob4o$8b2o5bo17b3o3b2o16bo6b2o$7bo2b2o2b2o15b2ob2o3b2o16bo3bo$6b2o
5bo20bo2bobo16bo5bob2o$6b3ob2o19bobob3o19bob2o$9b2obo2bo15bo5b2o21bob
3o$7bo2bobobo18bobo3b2o16b2obob3o$9bo4bo18b4o25bo$6bo2bo2bo18b3ob3o18b
3o3bo$6b2o3b3o16bo24bo6bo$6b5ob2o17bob3o2bo20b4o$9bo3bo21b2obo21b3o$9b
o2bo$11bo43b2o$5b2o20bob4ob2o15b2obo2bob2o$b3ob2ob3o15b2ob4obo16b2o6b
2o$o24bo2bob2o18bo2bo5bo$b2o3bob3o15bo6b2o20b3o$6bobo22bo27bo$7b2o23b
2o23bo!

The questions is why is it not working? I see that tail bits looks like something that is quite common for p3 orthogonal ships. Still it is not stable.

[wildmyron]

Try chopping 3 - 6 rows off the ikpx partial before using it. If you look at the three phases of the partial you'll note that the third phase when evolved 1 generation does not correctly generate the first phase for all rows which should be valid.

Edit: you may need to chop more off, 9 rows should be sufficient

[2718281828]

Try chopping 3 - 6 rows off the ikpx partial before using it. If you look at the three phases of the partial you'll note that the third phase when evolved 1 generation does not correctly generate the first phase for all rows which should be valid.
Edit: you may need to chop more off, 9 rows should be sufficient

Thanks, I chopped off the golly-rle partial, instead of the ikpx one. Is it worth doing so? I mean additionally.

[calcyman]

Try chopping 3 - 6 rows off the ikpx partial before using it. If you look at the three phases of the partial you'll note that the third phase when evolved 1 generation does not correctly generate the first phase for all rows which should be valid.
Edit: you may need to chop more off, 9 rows should be sufficient

Thanks, I chopped off the golly-rle partial, instead of the ikpx one. Is it worth doing so? I mean additionally.

No, you need to truncate the ikpx partial instead.

[AforAmpere]

Has anyone found a way to get this to work with Cygwin yet? Afind is really the only other option beside ikpx and WLS to find short, wide ships, and certain knightship speeds.

[googleplex]

So I just lost all my searches, my PI's microSD card got corrupted and my only option was to flash it and reset everything. I'm currently reinstalling Ikpx.

EDIT: how do i install Ikpx? I forgot XD

[googleplex]

Compiled without error, but a whole lot of warnings:

Code: Select all

Compiling: /home/pi/metasat/iGlucose/core/Solver.o
In file included from /home/pi/metasat/iGlucose/core/../core/Solver.h:35:0,
                 from /home/pi/metasat/iGlucose/core/Solver.cc:33:
/home/pi/metasat/iGlucose/core/../utils/Options.h:285:29: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
             fprintf(stderr, "%4"PRIi64, range.begin);
                             ^
/home/pi/metasat/iGlucose/core/../utils/Options.h:291:29: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
             fprintf(stderr, "%4"PRIi64, range.end);
                             ^
/home/pi/metasat/iGlucose/core/../utils/Options.h:293:25: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
         fprintf(stderr, "] (default: %"PRIi64")\n", value);
                         ^
In file included from /home/pi/metasat/iGlucose/core/../utils/Options.h:30:0,
                 from /home/pi/metasat/iGlucose/core/../core/Solver.h:35,
                 from /home/pi/metasat/iGlucose/core/Solver.cc:33:
/home/pi/metasat/iGlucose/core/../utils/ParseUtils.h: In function ‘double Glucose::parseDouble(B&)’:
/home/pi/metasat/iGlucose/core/../utils/ParseUtils.h:103:5: warning: this ‘while’ clause does not guard... [-Wmisleading-indentation]
     while (*in >= '0' && *in <= '9')
     ^~~~~
/home/pi/metasat/iGlucose/core/../utils/ParseUtils.h:107:2: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘while’
  if (*in != 'e') printf("PARSE ERROR! Unexpected char: %c\n", *in),exit(3);
  ^~
/home/pi/metasat/iGlucose/core/Solver.cc: In member function ‘unsigned int Glucose::Solver::computeLBD(const Glucose::vec<Glucose::Lit>&, int)’:
/home/pi/metasat/iGlucose/core/Solver.cc:379:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
       if(nbDone>=end) break;
          ~~~~~~^~~~~
/home/pi/metasat/iGlucose/core/Solver.cc: In member function ‘unsigned int Glucose::Solver::computeLBD(const Glucose::Clause&)’:
/home/pi/metasat/iGlucose/core/Solver.cc:408:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
       if(nbDone>=c.sizeWithoutSelectors()) break;
          ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
/home/pi/metasat/iGlucose/core/Solver.cc: In member function ‘Glucose::lbool Glucose::Solver::search(int)’:
/home/pi/metasat/iGlucose/core/Solver.cc:1147:19: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
      if(conflicts >=  curRestart * nbclausesbeforereduce )
         ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Compiling: /home/pi/metasat/iGlucose/core/Main.o
In file included from /home/pi/metasat/iGlucose/core/Main.cc:36:0:
/home/pi/metasat/iGlucose/core/../utils/Options.h:285:29: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
             fprintf(stderr, "%4"PRIi64, range.begin);
                             ^
/home/pi/metasat/iGlucose/core/../utils/Options.h:291:29: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
             fprintf(stderr, "%4"PRIi64, range.end);
                             ^
/home/pi/metasat/iGlucose/core/../utils/Options.h:293:25: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
         fprintf(stderr, "] (default: %"PRIi64")\n", value);
                         ^
/home/pi/metasat/iGlucose/core/Main.cc:49:12: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
     printf("c restarts              : %"PRIu64" (%"PRIu64" conflicts in avg)\n", solver.starts,(solver.starts>0 ?solver.conflicts/solver.starts : 0));
            ^
/home/pi/metasat/iGlucose/core/Main.cc:49:47: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
     printf("c restarts              : %"PRIu64" (%"PRIu64" conflicts in avg)\n", solver.starts,(solver.starts>0 ?solver.conflicts/solver.starts : 0));
                                               ^
/home/pi/metasat/iGlucose/core/Main.cc:50:12: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
     printf("c blocked restarts      : %"PRIu64" (multiple: %"PRIu64") \n", solver.nbstopsrestarts,solver.nbstopsrestartssame);
            ^
/home/pi/metasat/iGlucose/core/Main.cc:50:47: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
     printf("c blocked restarts      : %"PRIu64" (multiple: %"PRIu64") \n", solver.nbstopsrestarts,solver.nbstopsrestartssame);
                                               ^
/home/pi/metasat/iGlucose/core/Main.cc:51:12: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
     printf("c last block at restart : %"PRIu64"\n",solver.lastblockatrestart);
            ^
/home/pi/metasat/iGlucose/core/Main.cc:58:12: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
     printf("c conflicts             : %-12"PRIu64"   (%.0f /sec)\n", solver.conflicts   , solver.conflicts   /cpu_time);
            ^
/home/pi/metasat/iGlucose/core/Main.cc:59:12: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
     printf("c decisions             : %-12"PRIu64"   (%4.2f %% random) (%.0f /sec)\n", solver.decisions, (float)solver.rnd_decisions*100 / (float)solver.decisions, solver.decisions   /cpu_time);
            ^
/home/pi/metasat/iGlucose/core/Main.cc:60:12: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
     printf("c propagations          : %-12"PRIu64"   (%.0f /sec)\n", solver.propagations, solver.propagations/cpu_time);
            ^
/home/pi/metasat/iGlucose/core/Main.cc:61:12: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
     printf("c conflict literals     : %-12"PRIu64"   (%4.2f %% deleted)\n", solver.tot_literals, (solver.max_literals - solver.tot_literals)*100 / (double)solver.max_literals);
            ^
In file included from /home/pi/metasat/iGlucose/core/Main.cc:35:0:
/home/pi/metasat/iGlucose/core/../utils/ParseUtils.h: In function ‘double Glucose::parseDouble(B&)’:
/home/pi/metasat/iGlucose/core/../utils/ParseUtils.h:103:5: warning: this ‘while’ clause does not guard... [-Wmisleading-indentation]
     while (*in >= '0' && *in <= '9')
     ^~~~~
/home/pi/metasat/iGlucose/core/../utils/ParseUtils.h:107:2: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘while’
  if (*in != 'e') printf("PARSE ERROR! Unexpected char: %c\n", *in),exit(3);
  ^~
/home/pi/metasat/iGlucose/core/Main.cc: At global scope:
/home/pi/metasat/iGlucose/core/Main.cc:76:13: warning: ‘void SIGINT_exit(int)’ defined but not used [-Wunused-function]
 static void SIGINT_exit(int signum) {
             ^~~~~~~~~~~
Compiling: utils/System.o
Compiling: utils/Options.o
In file included from /home/pi/metasat/iGlucose/core/../utils/Options.cc:21:0:
/home/pi/metasat/iGlucose/core/../utils/Options.h:285:29: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
             fprintf(stderr, "%4"PRIi64, range.begin);
                             ^
/home/pi/metasat/iGlucose/core/../utils/Options.h:291:29: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
             fprintf(stderr, "%4"PRIi64, range.end);
                             ^
/home/pi/metasat/iGlucose/core/../utils/Options.h:293:25: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
         fprintf(stderr, "] (default: %"PRIi64")\n", value);
                         ^
In file included from /home/pi/metasat/iGlucose/core/../utils/Options.h:30:0,
                 from /home/pi/metasat/iGlucose/core/../utils/Options.cc:21:
/home/pi/metasat/iGlucose/core/../utils/ParseUtils.h: In function ‘double Glucose::parseDouble(B&)’:
/home/pi/metasat/iGlucose/core/../utils/ParseUtils.h:103:5: warning: this ‘while’ clause does not guard... [-Wmisleading-indentation]
     while (*in >= '0' && *in <= '9')
     ^~~~~
/home/pi/metasat/iGlucose/core/../utils/ParseUtils.h:107:2: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘while’
  if (*in != 'e') printf("PARSE ERROR! Unexpected char: %c\n", *in),exit(3);
  ^~
/home/pi/metasat/iGlucose/core/../utils/Options.cc: In function ‘void Glucose::printUsageAndExit(int, char**, bool)’:
/home/pi/metasat/iGlucose/core/../utils/Options.cc:62:5: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
     if (usage != NULL)
     ^~
/home/pi/metasat/iGlucose/core/../utils/Options.cc:65:9: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘if’
         sort(Option::getOptionList(), Option::OptionLt());
         ^~~~

[googleplex]

As the searches on the Raspberry pi were going reeeeeaaaaalllllyyyyy slowly, I assembled a Linux box and am now installing Ikpx. here's hoping it works!

[googleplex]

Ikpx works on my linux box. it goes very fast. (compared to raspberry pi)

[testitemqlstudop]

Can ikpx search for oscillators like lls?

[calcyman]

Can ikpx search for oscillators like lls?

I'm afraid it can't. One of the constraints is that it can only search for (x,y)c/z spaceships when gcd(x, y, z) = 1. The rationale for this is that the pattern naturally lies on the quotient Z^3 / <(x, y, z)>, whereas ikpx finds configurations on the two-dimensional lattice Z^2 (in a row-by-row manner, representing each row as an integer using binary). This quotient Z^3 / <(x, y, z)> is isomorphic to Z^2 if and only if the gcd condition holds, which is why ikpx could find Sir Robin and p6 tagalongs, but could never find a p12 tagalong for Sir Robin.

(The reason LLS is able to do these sorts of things is because LLS tackles the whole problem at once, whereas ikpx tackles it incrementally.)

As for your earlier PM about metasat (and SAT solvers in general), think of SAT problems as being similar to those hotel showers. Specifically, those with temperature controls where a twist of one arcsecond anticlockwise gives you freezing water, and one arcsecond clockwise gives you boiling water. Changing the hyperparameters of a problem even slightly can make the difference between an easy problem and an infeasible one*. I suspect finding a p19 oscillator directly using a SAT solver lies firmly on the infeasible side.

However, I suspect that there is one possible avenue worth exploring: to use a SAT solver to look for a quickly-recovering elbow for a 2c/3 signal. The SAT solver will be able to quickly make use of conditions such as 'the initial pattern is p1' to narrow down its search space. Because there are so many possible locations/timings of output signal relative to input signal, you'll ideally want to run a separate SAT solver instance for each combination.

--------

* I found this the hard way: the metasat project was my attempt to brute-force the 99-vertex graph problem; I failed miserably, finding only that [brute-forcing] the 99-vertex graph problem is immensely hopelessly hard. This is actually a good thing -- it means that whoever solves it will need to develop some new mathematical ideas along the way instead of just throwing computational power at it.

[testitemqlstudop]

Wow, thank you very much for your explanation!

I'm trying to assemble an LLS input file, replacing the current 2c/3 signal elbow with variables and asterisks to generate the CNF file, and then I'll guess I'll try various ways and see what works.
There will have to be a different CNF for every period from 20 to 1, though, but a 2c/3 elbow with repeat time under 10 is unlikely. I'll PM you the set if you want to try searching some of the periods.

Thanks for the advice, though!

On a side note, do any SAT solvers have a state-saving mechanism akin to ikpx? There still might be a chance at solving the p19 oscillator, but my desktop is honestly quite run-down.

[dvgrn]

I'm trying to assemble an LLS input file, replacing the current 2c/3 signal elbow with variables and asterisks to generate the CNF file, and then I'll guess I'll try various ways and see what works.
There will have to be a different CNF for every period from 20 to 1, though, but a 2c/3 elbow with repeat time under 10 is unlikely. I'll PM you the set if you want to try searching some of the periods.

This sounds like exactly what I was planning to try to get set up, some time in early 2018. It's one of my New Year's resolutions, just haven't found time for it yet. Seems like omniperiodicity is only just barely out of reach these days, and a large enough collection of LLS searches might well just happen to find a lucky working elbow -- it's another of those search spaces that no one has actually checked out thoroughly yet.

Maybe a good setup would be to search the whole collection of different offsets and timings for 10 seconds each, then 100 seconds each, then 1000 seconds each, etc.?

If you'd be interested in posting whatever collection of CNF files you come up with, I might still have access to some computing resources borrowed from Tom Rokicki -- could try setting up a queue to test some subset of them and see if any solutions pop up.

Another possibly workable angle might be either a 0-degree or a 90-degree converter from a double 2c/3 signal to a single signal. The known single-to-double elbow works perfectly well down to period 15, so a double-to-single converter with <p20 repeat time would prove omniperiodicity very nicely.

[Moosey]

I feel I need a grills module. Where can I find it?
I am on mac
[DELETED photo]