Riesel base 6 - team drive #4 - EIGHT OR BUST!

[mdettweiler]

Originally Posted by Mini-Geek

How does PFGW store its list of k's to skip? If that could be easily edited to include 59095, that'd be great.
Or, here's a simple trick you could do to get it to skip that k:
Stop PFGW
Open your sieve file in Notepad (or similar)
Delete all lines up to the candidate you're currently working on (leave the current one alone)
Put "59095 171929" on its own line at the top (below the header line, of course)
Start PFGW again

When you start PFGW back up, it'll see that the file changed and restart at line 2, find the PRP, then know to skip all with that k, then continue to the one you left off at and resume from its save file. The only downside is that you have to duplicate the few minutes (for me, 13.85 minutes in far-from-optimal conditions, probably closer to 10 minutes CPU time) to find that number is PRP, and do so for every instance of PFGW.

Hmm...I guess that works too. One other thing you'll have to make sure is that you remove the re-processed prime from the final results file, but as long as you're fine with doing that and can spare about 10 minutes of CPU time, then this method would work OK.

To answer your question about how PFGW stores its list of k's to skip, I think it only stores them in memory, and thus the list is lost every time it's restarted. Hmm...methinks maybe the next version of PFGW could save the list in the .ini file to avoid these problems?

[gd_barnes]

Hey guys, make it much easier on yourself. Just leave k=59095 in your in-process files. Maybe you'll find a top-5000 prime for it! It won't hurt anything to find an extra prime for the same k, especially since it would be top 5000.

It seems that everyone is making it much too hard if you want to remove a k from an in-process file. On your PFGW file, do the following (which is what I always do in files for NON-top 5000 work), which is a variation on what Tim suggested:

1. Change the header to an LLR (NewPGen) header.
2. Use srfile to remove the k.

In the output file from #2, do the following:

3. Remove all lines from the first part of the file that have already been tested.
4. Change the header back to PFGW format.
5. Change the file name back to the same as it was before except add a "-b" or "-2" to the end of it.
6. Run PFGW with the new file name while keeping the existing results named pfgw.out. It just starts from line #1 and continues concatenating results on to pfgw.out.


That's about equal effort and is far less risky than trying to mess with line #'s or inserting a prime at the beginning of it, which would also mess up the line #'s.

One more thing I do in the results file: I manually type a line in there at the CURRENT end of the file that says: Removed k=xxxxx. That would help us if we ever want to match up what was tested with the original sieve file. The comment would show exactly where that k would no longer have results.

Note that I said I do the above for NON-top 5000 work. Personally, I never remove a k from an in-process file if the file is top-5000 work. It's sufficiently sieved. You may as well take a shot with a few more top-5000 tests. Using the approach netted me an extra top 5000 prime on Sierp base 16, even though Max had found a slightly smaller prime on the same k a few days before.

Max note: I have included the # of primes we've found and our current # of k's remaining in the 1st para. of the 1st post here.


Gary

[gd_barnes]

Max,

Let's start uploading files to the noprimeleftbehind server again now. Thanks.


Gary

[MyDogBuster]

Shouldn't the title of the thread be "SEVEN OR BUST" now?

Nice find Tim.

[henryzz]

Originally Posted by MyDogBuster

Shouldn't the title of the thread be "SEVEN OR BUST" now?

Nice find Tim.

FIVE OR BUST didnt change theirs even though they are at 3 now

[Mini-Geek]

170k-175k complete, 1 prime found. The results are attached. (I included the two original, untouched log files, and one where I merged them and took out all non-result info, such as restarting notes and the primality test)

Seventeen or Bust hasn't been changing their name with each prime either. Given the informality of "Eight or Bust" we may change it as we go, but then when we're at Five we'll be named the same as another project.

[Flatlander]

Taking 290-293.

250-255 is complete.

[Flatlander]

280-285 is complete.

[mdettweiler]

Originally Posted by gd_barnes

Max,

Let's start uploading files to the noprimeleftbehind server again now. Thanks.


Gary

Way ahead of you there. When I removed k=59095 from the posted files, I put the updated ones on the noprimeleftbehind.net server.

[gd_barnes]

Max,

Changed my mind...go ahead and post files up to n=320K in 3K chunks now even though we still have one range for n<=250K to finish up. There's no reason to hold up the drive with this much demand. Even if a prime at a lower limit is found, it doesn't hurt much to be searching a k somewhat higher on the offhand chance that we might get two top-5000 primes for it.

I also don't see any problem with leaving the k in the posted files if a prime is found to reduce admin time. Like other drives, I/we will just note in the 1st post here that k=xxxxx has not been removed from any files and people can make their own decision on whether they want to remove it before searching it. The main situation that I want to remove k's from already posted files is when it is non-top 5000 work, especially where many smaller primes are being found like is the case with the base 3 drives.

Of course if we find a prime, we should go ahead and remove the k from the n=320K-1M portion of the file for future posting of files. I assume you've already done that for k=59095 for n=290K-1M.

Ian,

The "xx or bust" projects just leave their name the same as they find primes...that is "17 or bust" and "5 or bust" so we'll leave it at "eight or bust". I'll be keeping the # of primes found and k's remaining in the 1st para. of the 1st post here.


Gary

[mdettweiler]

Originally Posted by gd_barnes

Max,

Changed my mind...go ahead and post files up to n=320K in 3K chunks now even though we still have one range for n<=250K to finish up. There's no reason to hold up the drive with this much demand. Even if a prime at a lower limit is found, it doesn't hurt much to be searching a k somewhat higher on the offhand chance that we might get two top-5000 primes for it.

I also don't see any problem with leaving the k in the posted files if a prime is found to reduce admin time. Like other drives, I/we will just note in the 1st post here that k=xxxxx has not been removed from any files and people can make their own decision on whether they want to remove it before searching it. The main situation that I want to remove k's from already posted files is when it is non-top 5000 work, especially where many smaller primes are being found like is the case with the base 3 drives.

Of course if we find a prime, we should go ahead and remove the k from the n=320K-1M portion of the file for future posting of files. I assume you've already done that for k=59095 for n=290K-1M.

Okay, sounds good. In the particular case of last night when the prime for k=59095 was found, it wasn't a big deal to remove the prime from all the files, since there was only three of them. But, yes, I'll keep that in mind for the future.

Meanwhile, files have been posted up to n=320K. Come and get 'em!