Bug or not, it is easy ( like you do) to make small change in header, and then in future save a lot of time to time right sport for start.

[QUOTE=gd_barnes;450790]I'm out of town for 10 days and my old laptop won't handle 7zip files. Old Windows Vista just can't handle it so I have WinZip on it. Could you do an older zip of the files so that I can post them to the pages?[/QUOTE]

[QUOTE=pepi37;450794]Look at [B]wombatman[/B] post, and he says that he sieved at P=30e12 or 30000000000000 ( if I understand it)
But when you open 7Z file and look at header it says only 1000000000.
In future, with so many posts, it will be nearly impossible to find this particular post, when correct sieve depth is written. And if somebody continues, he will be lost some time until reach true depth for nothing

SR 564 is in zip file now :)[/QUOTE]

Thanks Pepi. I'll try and make sure to fix any future sieved files so they correctly reflect the sieve depth. I do solemnly swear that I sieved SR564 to P=30e12. :smile:

[QUOTE=wombatman;450799]Thanks Pepi. I'll try and make sure to fix any future sieved files so they correctly reflect the sieve depth. I do solemnly swear that I sieved SR564 to P=30e12. :smile:[/QUOTE]

No problem: I hope you didnot understand my critique in wrong way

Not at all! I enjoy continuing to learn more about all of this. :smile:

[QUOTE=MisterBitcoin;450796]There is a bug in srfile/sr2sieve. The header won´t display the higher sieve depht.
I use 100e6 as initial sieve depht using srsieve. After sieving to (e.g.) 15e12 and deleting factors found using srfile the value keeps at 100e6. [I change that value manually using Notepad++]
This work fine if you use sr1sieve, but somehow only creates this bug for more k-values sieving.[/QUOTE]
It's not a bug, really: sr2sieve is designed for distributed sieving. Sieving from 5e12 to 6e12 should not update the header to 6e12, as there might be a gap below 5e12. The programs leave the header untouched, relying on users to manually update when *they* know gaps are filled. sr2sieve uses a checkpoint file to track where it has actually sieved, while the header is for human use.

S821
 

S821 is sieved to P=30e12 for n=200k-500k. File is attached. :smile:

S87 reached p=50T. File attached.

[QUOTE=MisterBitcoin;451119]S87 reached p=50T. File attached.[/QUOTE]

You can also remove those candidates since they have factors

32*87^1002459+1 has a factor: 556573255368421
32*87^1006659+1 has a factor: 911268953003789
32*87^1027003+1 has a factor: 3218020792424693
32*87^1028467+1 has a factor: 291794143979017
32*87^1041187+1 has a factor: 796310494372537
32*87^1045243+1 has a factor: 5193612583315217

S66 update
 

The first part from S66 sieve is done. The next two parts are >p=80B, they should end in a few days.
The last part will be started soon.

There a lot of single Riesel k´s left on n=200K. Let´s sieve them. :) Maybe Wombatman or some else wants to jump on the train.

Taking R867 to nmax=1M. Using the "old" srsieve to avoid any problems.

For a single k, use sr1sieve?