Maintenance note: I am leaving the listing of all completed sieving reservations in the first post here until the files are reserved for testing and fully primality tested. So the list could get rather large since testing takes much longer than sieving but it shouldn't be filled with obsolete sieving completions that have already been tested. It is easy for me to fail to delete a completed sieving reservation when someone completes primality testing so if anyone would like to occassionally double check the posting against the CRUS pages it would be helpful.

S117 has been sieved to 15T.

Renamed thread since the sieve files can be used by anyone doing testing at CRUS whether or not they run BOINC. I also stickied it.

[QUOTE=MisterBitcoin;448944]S117 has been sieved to 15T.[/QUOTE]

I am going to do a "wrap around" additional sieve on this. That is I am going to sieve the 8 k's for R117/n=100K-250K and also sieve the 3 k's for S117/n=200K-250K in with my sieve to increase the n-range of S117 to n=100K-250K. I will then likely sieve the entire range of both sides deeper than P=15T assuming that the timings show that it should be done, which they likely will since I'm searching a wider n-range.

There are two reasons for this: Most of the low-k bases < 200 have been searched/sieved to n=250K with a previous team effort and it is possible to sieve both sides of a base in one sieving effort using sr2sieve and gain a fair amount of efficiency in the process.

MisterB, that is something that you may not be aware of. If you want to increase efficiency even further you can sieve both sides of the same base in the same sieving effort if both sides are at the same search depth and the difference in the number of k's remaining is reasonable.

I am making a note both in the first post and on the reservations page that additional sieving is being done so that no one reserves the base for testing while all of this is going on.

R214 reached p=45T, file attached.

About the S/R-sieve:

How do you splitt the two bases after sieving? Seems like an script is needed.

[QUOTE=MisterBitcoin;449068]R214 reached p=45T, file attached.

About the S/R-sieve:

How do you split the two bases after sieving? Seems like a script is needed.[/QUOTE]

No. Srfile will do it. While the -a switch writes only one file for both sides in ABCD (sr2sieve) format, the -G switch automatically writes out two files in standard (PFGW or NewPGen) format if you are sieving both sides.

S688 k=54
 

S688 (k=54) has been sieved for n=100k-500k up to 40T. File is attached.

The other two ks (k=67 and 104) are in progress and will ready in about 3 and 6 days, respectively, barring any issues.

[QUOTE=MisterBitcoin;449068]

About the S/R-sieve:

How do you splitt the two bases after sieving? Seems like an script is needed.[/QUOTE]


srfile -G


edit: Doh! just saw Gary's response above...

[QUOTE=wombatman;449076]S688 (k=54) has been sieved for n=100k-500k up to 40T. File is attached.

The other two ks (k=67 and 104) are in progress and will ready in about 3 and 6 days, respectively, barring any issues.[/QUOTE]

Are you using sr2sieve? For > 2 k's sr2sieve is somewhat more efficient and easier to use than multiple instances of sr1sieve. It's also easier to post on the reservations pages since we don't want to post multiple files for a base unless we have to.

I am not, but I can certainly switch over. Is there a good way to combine the separated k files? I was using sr1sieve so I could multithread it on the Ubuntu bash shell in Windows 10.

srfile -G/a firstfile.txt secondfile.txt thirdfile.txt

-G writes newpgen/llr style output for posting & primality testing.

-a writes in sr2sieve format.

Your chosen method may well be a better use of your machine; with 3 k's sr2 is usually faster, but not by a whole lot. If one k is much lower weight, sr1 on each k might be quicker.