[QUOTE=MisterBitcoin;452623]S7 has reached n=25K.
The prime-list and k´s remaining is attached.[/QUOTE]

I will need the primes for n<=2500 for this range before I can post anything as complete.

[QUOTE=gd_barnes;452688]I will need the primes for n<=2500 for this range before I can post anything as complete.[/QUOTE]


I´m mailed this 1,5 months ago. I'm re-sending it right now.

[QUOTE=MisterBitcoin;452708]I´m mailed this 1,5 months ago. I'm re-sending it right now.[/QUOTE]

Sorry about that.

[QUOTE=MisterBitcoin;452623]S7 has reached n=25K.
The prime-list and k´s remaining is attached.[/QUOTE]

Your k's remaining list is incorrect. For k=10M-50M there were 5143 k's remaining at n=2500. You found 4433 unique k's with primes for n=2500-25K. There should be 710 k's remaining at n=25K. Your file has 742 k's remaining.

I need for you to do two things for future submissions, especially for these large-conjectured bases:

1. Please remove all primes that are duplicates for each k. Only the smallest prime for each k should be included. This will allow you to do #2.
2. Please balance your k's remaining before posting. Take the number of k's remaining at nmin and subtract the primes found after removing duplicates in #1. That should be your number of k's remaining at nmax.

This will save me a lot of work. It looks very strange when there are more primes in the primes file than there are k's remaining at nmin.

You can prevent #1 by using the stop-on-prime option for PFGW and/or LLR. This seems to be an ongoing problem on this project and I cannot stress it enough. Your computers did a lot of extra work here.

So that you can test out your own processes, I have attached the corrected primes and k's remaining files.

Thanks.

Reserving R15 to n=400k (200-400k) (0-10M) for BOINC

[QUOTE=gd_barnes;452729]Your k's remaining list is incorrect. For k=10M-50M there were 5143 k's remaining at n=2500. You found 4433 unique k's with primes for n=2500-25K. There should be 710 k's remaining at n=25K. Your file has 742 k's remaining.

I need for you to do two things for future submissions, especially for these large-conjectured bases:

1. Please remove all primes that are duplicates for each k. Only the smallest prime for each k should be included. This will allow you to do #2.
2. Please balance your k's remaining before posting. Take the number of k's remaining at nmin and subtract the primes found after removing duplicates in #1. That should be your number of k's remaining at nmax.

This will save me a lot of work. It looks very strange when there are more primes in the primes file than there are k's remaining at nmin.

You can prevent #1 by using the stop-on-prime option for PFGW and/or LLR. This seems to be an ongoing problem on this project and I cannot stress it enough. Your computers did a lot of extra work here.

So that you can test out your own processes, I have attached the corrected primes and k's remaining files.

Thanks.[/QUOTE]


I removed every 24 hours all primed k´s using srfile (with -d). [Thats the reason why some k´s have more than 1 prime]
The prp-tests are done by pfgw, using "-f0 -l" (logging it just for myself)
I wonder how there some solved k´s still in my remain-file.

About the "stop on prime": Whats the command for the this and will it stop the whole process or just an that k?

I gonna check if my process contains some problems whichs creates work. I´m realy sorry about that.

[QUOTE=MisterBitcoin;452779]I removed every 24 hours all primed k´s using srfile (with -d).[/QUOTE]
If you change the input file's contents without stopping the running process, you will get unpredictable results. It applies to most programs: prime95, ecm, llr, pfgw, etc. Only a few programs are working in a different mode - they open file, read line #N, do the workunit, then re-open file, attempt to remove the input line (or move the "*" marker, in case of "Cyclo"). prime95 does something in between; it does not re-open the file, it deletes the line and rewrites the file (so your external changes to the file are lost).

Most programs read open files in buffered mode; they don't get notified that the file (for which they have an open file handle) changed. They only know that they've already read 4Kb (or other buffer size) from that file, and until they need more input they will not re-read. When they do, they will read from offset 4Kb. As a consequence, you can even get the program to output data for "input lines" that were never in the input file (that happens if the 4Kb boundary was in the middle of the line when you changed the file: then the line is combined from a chunk that was read before and an unrelated chunk that was read later).

Bottom line: [B]don't use this method of input file pruning. [/B]

[QUOTE=MisterBitcoin;452779]I removed every 24 hours all primed k´s using srfile (with -d). [Thats the reason why some k´s have more than 1 prime]
The prp-tests are done by pfgw, using "-f0 -l" (logging it just for myself)
I wonder how there some solved k´s still in my remain-file.

About the "stop on prime": Whats the command for the this and will it stop the whole process or just an that k?

I gonna check if my process contains some problems whichs creates work. I´m realy sorry about that.[/QUOTE]

If you are using PFGW, use this in the header of the sieve file:

ABC $a*7^$b+1 // {number_primes,$a,1}

If you are using LLR, use this in the llr.ini file (you don't need to change the sieve file):
StopOnPrimedK=1

Those commands in the header or .ini file will cause the programs to stop running tests for a k after a prime is found. That way you don't ever have to stop it and remove k's with primes.

Note that in most older versions of PFGW if you stop the program in the middle it will "forget" which k's have primes. I think in the newer versions it will not forget. You can experiment with it.

Once you do this, you will never go back, especially for small tests. It's a pain to constantly stop the program and remove k's from the sieve file.

R15 tested to n=400k (200-400k) (0-10M)

5 primes found, 9 remain in this range

5149158*15^249605-1
5255502*15^257491-1
3889018*15^275603-1
3347624*15^347109-1
9535278*15^375675-1

Results emailed, Base released

S26 is in progress and well past n=750,000 (with n=1M as the final). The remaining candidates are split into 4 files. I estimate about 4600 candidates remaining between the 4 split parts.

status report
 

S10 tested till n=1.99M
R10 tested till n=1.75M