As of when I'm writing this, we're now crunching GFN n=15 (32768), GFN n=16 (65536), GFN n=17 (131072) low and mega, n=21 (2097152) and n=22 (4194304). By the way, in case it's not clear, 2^15=32768, 2^16=65536, etc. n=16 and higher are still worthy of more sieving. Just to make it clear, I thought I'd explain how all that works.

Every time I process a GFN sieving range, my program creates an up-to-date sieve file with all factors applied to it. In other words, every candidate that had a factor has already been removed from the sieve file. That sieve file is used to generate work in BOINC. For GFN n values where we're still sieving, BOINC work is always generated immediately before being loaded, so the very latest sieve file is used. All known factors have already been applied.

The program that processes factor files "knows" what ranges have been loaded into BOINC. If it enounters a new factor for a loaded candidate, it interacts with the server to remove that candidate from consideration. There are several scenarios:

If the candidate has not been turned into a workunit, it's completely deleted from the system. The effect is exactly the same as if it had been previously removed by sieving.

If a workunit exists but no task has been sent out to a client, the workunit is canceled. The tasks are set to "not needed" and the workunit is set to be deleted normally.

If there are both sent and unsent tasks, the unsent one is cancelled and the workunit is adjusted so that no more tasks will be created. The workunit is set to validate with a single task (so that the user who has the task will get credit for it).

If the workunit is completed and validated, no change takes place.

The gist of this is that any new sieving will affect already-loaded work. That's why all 32768 work up to the OCL3 b-limit has already been loaded. Anything sieved out in future will be removed and no genefer testing will take place, unless it's already in progress at that time. I'll still be doing GFN sieving and I encourage others to do the same.

So, I was doing some sieving a few questions came to my mind when seeing the "GFN Sieve for k^(insert gfn range here) +1 [k == 2 to 100.000.000]"

1- For something like GFN 16, we already searched k< 2.4M.... so what's the point of sieving 2<k<2.4M? Wouldn't that be a waste of computational power / wouldn't the program go faster if it didn't have to test those candidates?

2- Likewise, when looking at n=22, k = 100M seems like a rather.... utopic future, to say the least. Even if we were to consider the OCl 2 limit, it's still around 23M. Given the very slow pace of WR tasks, wouldn't it be faster to just ignore everything above OCL3 for (which still would take WAY longer to reach) and focus on smaller K? And if we ever get closer to OCL 2, then we can just re-sieve the same ranges for higher K?

3- Also, that thing about "(b)^(n) is the same as (b^2)^(n/2)" and "you'll always want to crunch the number at the lowest n possible", does it apply / has en equivalent for the sieve program?

The answer to 1 and 2 is that with this sieve, the range of b that is sieved doesn't matter. The sieve runs the same speed whether we're sieving 10<b<20 or 2<b<100,000,000. So we sieve the full range even if we don't expect to ever need it, because it comes for free.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

3- Also, that thing about "(b)^(n) is the same as (b^2)^(n/2)" and "you'll always want to crunch the number at the lowest n possible", does it apply / has en equivalent for the sieve program?