Did Auto_LLR ever get modified to output the ks remaining somehow?
I can't find that that was fixed anywhere in this thread.
Also we could do with a conversion to PFGW to get the huge speedup(would it be worth using pfgw's sieving and testing for longer than previous because of that).
Is this script still the best way for running base 3 from n>5k.

[QUOTE=henryzz;184502]Did Auto_LLR ever get modified to output the ks remaining somehow?
I can't find that that was fixed anywhere in this thread.
Also we could do with a conversion to PFGW to get the huge speedup(would it be worth using pfgw's sieving and testing for longer than previous because of that).
Is this script still the best way for running base 3 from n>5k.[/QUOTE]

if you try the AutomatedLLR.zip with calling 'do 15' the testfile for base 15 (k*15^n-1) with k<1000 and n<200 will be done in seconds.

the file 't17_b15.prp' ist the results of the Automated_low_n.zip for base 15.

after completion there's a file called 't17_b15_log.txt' which contains a detailed summary:
every PRP is listed. the last line states:
found: 858 80 (1 sequnces left, 5 pairs remain, 11 pairs deleted, 12 pairs LLR tested)

this means:
858*^5^80-1 was the last PRP found
1 sequence is left up to this ranges of k and n -> for 1 k-value there's no PRP found upto n=200

the file 't17_b15.org' contains this k-value with pairs.

the file 't17_b15_prp.txt' contains the PRP found for every k-value starting with n=1 upto n=80 (no PRP for higher n found).

so k=256 is the only values <1000 for which no PRP was found!

i've not tested it with the new pfgw version because i have to change many awk-scripts to do the same.

try a little bit (also the example for the Riesel-Problem for 1024<n<10000 is included).

it seems to have the fix then
does it work on linux? edit: not at all and it will be no easy conversion for me(could be for others)
i will try and modify it to use pfgw

[QUOTE=henryzz;184558]it seems to have the fix then
does it work on linux? edit: not at all and it will be no easy conversion for me(could be for others)
i will try and modify it to use pfgw[/QUOTE]

Wouldn't it just be easier to use PRPNet? Is there a feature that PRPNet is missing that could be useful for this effort?

[quote=rogue;184575]Wouldn't it just be easier to use PRPNet? Is there a feature that PRPNet is missing that could be useful for this effort?[/quote]
good idea
being able to do sieving assignments would be nice

[QUOTE=henryzz;184580]good idea
being able to do sieving assignments would be nice[/QUOTE]

Sorry. That won't happen with PRPNet.

[quote=rogue;184598]Sorry. That won't happen with PRPNet.[/quote]
i did realize that was the case but minds can change:smile:
does anyone feel like writing a sieving server/client?

[quote=henryzz;184605]i did realize that was the case but minds can change:smile:
does anyone feel like writing a sieving server/client?[/quote]

That would be AWESOME!! Then it could be combined with a testing client so that you just tell it what range you want, and it will automatically sieve and test it for you.

Of course the hard part would be coming up with an optimal sieve depth that works in all situations...an extremely difficult task.


Gary

Does anyone know how PrimeGrid runs automatic sieves?

Obviously, a major problem with any automatic distributed sieve, at least when run with something like sr2sieve, is distributing the sieve file.

Why would it be difficult to have an optimal sieve depth calculator? It seems like a very exact scientific process to me, at least when certain data is available.

[quote=Mini-Geek;184646]Does anyone know how PrimeGrid runs automatic sieves?

Obviously, a major problem with any automatic distributed sieve, at least when run with something like sr2sieve, is distributing the sieve file.

Why would it be difficult to have an optimal sieve depth calculator? It seems like a very exact scientific process to me, at least when certain data is available.[/quote]Although I haven't been following the PrimeGrid forum too closely of late, last I heard they've been using a combination of BOINC-based and manual coordination for their sieving. What they do for the BOINC setup is have a "wrapper" for the particular sieving application that acts as a go-between for the siever and BOINC; the sieve file is downloaded the first time someone does a workunit for that sieve, and I think they release a new "version" of the application every time they have a new sieve file (which prompts the clients to download the latest sieve file version).

The sieve file is not necessarily difficult to distribute, depending on its size. As long as the client only has to redownload it when it changes, it shouldn't be too big a deal.

As for optimal depth, I think PrimeGrid's people calculate it manually just like we do; they then use the manual calculations to decide exactly how much work to load into the server or open up in manual drives.

I would imagine that developing a PRPnet-like automated sieving client would be somewhat of a major undertaking, though a lot of the work could possibly be saved by basing it on PRPnet. It would of course need some heavy modification because of the fundamental differences between sieving and primality testing, but it could probably be done.

One thing I had considered would be to write a "wrapper" of sorts to "fool" PRPnet into thinking that a sieving application (say, sr2sieve) is really PFGW--and having it pass parameters to the client as PFGW input parameters. Say, the pmin and pmax could be passed in the field for the number to be tested, and the factors could be passed back as a concatenated string in the residual field. Nah, I guess that would be a bit too hacked-together to be of any good use--it would probably be better to just modify PRPnet directly. :smile:

IMHO by far the easiest way for getting the sieve file would be manual download
this is what prime search problems lack
if sieving could be added to prpnet then primesearching could be run fully automated