What's next?
 

LLR testing on the variable n-range is slowly but steadily progressing.

n=480000-481650 is complete, along with n=484000-484100 and n=484900-485000.

So, what should we do once the small k n=480000-485000 range is complete? Move on to testing n=485000-490000 for k<100K, or begin testing n=480000-485000 for k=100K-200K instead? The first option has slightly faster LLRing times, while the second option has a higher sieve depth.

Suggestions, ideas, and comments are welcome.

[QUOTE=Oddball;240215]LLR testing on the variable n-range is slowly but steadily progressing.

n=480000-481650 is complete, along with n=484000-484100 and n=484900-485000.

So, what should we do once the small k n=480000-485000 range is complete? Move on to testing n=485000-490000 for k<100K, or begin testing n=480000-485000 for k=100K-200K instead? The first option has slightly faster LLRing times, while the second option has a higher sieve depth.

Suggestions, ideas, and comments are welcome.[/QUOTE]
I guess it all hinges on the question of whether we are planning to test the [i]entire[/i] n=480K-500K, k<10M range eventually, or stop after the first twin. If we're going to test everything, then the faster-testing k's will make no difference over the long run, so we should continue focusing our LLR efforts entirely on 480K-485K until it ceases to be the best-sieved range. (That will be after it reaches optimal depth and is joined there by at least one of the other ranges.) But if we're going to stop after the first twin, then the question becomes, which is the better trade-off in terms of CPU time: the faster-testing k's or the fewer candidates to test because of a higher sieve depth?

Personally, I'd be in favor of going to complete the entire range even after we find a twin. By filling in all holes, we can produce a definitive list of all twin primes in the range, which is the only way our results will be of use to mathematicians studying the distribution of primes. Otherwise, we have nothing but a single isolated twin prime--useless in and of itself--to show for our long efforts. This was, in fact, one of the reasons why searching the variable-n range was advocated in the first place, since a broad search will give a better sample of data than just taking one n to stratospheric k values.

One thing we could consider after we find our first twin for this range is to shrink the upper bound on k, perhaps to 5M or something. That way we wouldn't get bored from staying on this range for too long, but would still maintain continuity in our search. Once everything under that lower bound has been filled in, we could then move on to another, higher n-range and do a similar treatment on it.

[QUOTE=Oddball;240215]
So, what should we do once the small k n=480000-485000 range is complete? Move on to testing n=485000-490000 for k<100K, or begin testing n=480000-485000 for k=100K-200K instead? The first option has slightly faster LLRing times, while the second option has a higher sieve depth.
[/QUOTE]
Couldn't both options be done? The range n=485000-490000 for k<100K could be done on LLRnet, and n=480000-485000 for k=100K-200K could be done on PRPnet.

[QUOTE=mdettweiler;240220]if we're going to stop after the first twin, then the question becomes, which is the better trade-off in terms of CPU time: the faster-testing k's or the fewer candidates to test because of a higher sieve depth?
[/QUOTE]
Here are some benchmarks for n=485000 using different k values:

[code]
15*2^485000-1 is not prime. LLR Res64: 186ADD995AE129E7 Time : 161.337 sec.
357*2^485000-1 is not prime. LLR Res64: 77A56FB0D084B763 Time : 172.791 sec.
1113*2^485000-1 is not prime. LLR Res64: 5FB4A222208895D9 Time : 173.523 sec.
3375*2^485000-1 is not prime. LLR Res64: E4024139304D46E5 Time : 249.398 sec.
10263*2^485000-1 is not prime. LLR Res64: 3B5E9611E7C4677C Time : 249.713 sec.
102525*2^485000-1 is not prime. LLR Res64: E4ECBF01662AE508 Time : 249.873 sec.
198033*2^485000-1 is not prime. LLR Res64: A97985DF152414E4 Time : 293.463 sec.
500727*2^485000-1 is not prime. LLR Res64: 91AA1C9813FF85FC Time : 294.572 sec.
1002333*2^485000-1 is not prime. LLR Res64: ADECF0BA4CC356EA Time : 313.155 sec.
9999657*2^485000-1 is not prime. LLR Res64: 5019E18F1CD3C999 Time : 315.143 sec.

[/code]

Hope that's useful.

We should probably resume discussion on this so that in case we run out of n=480K-485K, k<100K work during the upcoming rally, we know which direction to proceed thereafter.

As I mentioned before, my personal preference would be to plan on doing the entire sieved range eventually (not stopping after the first twin), in which case it would be most optimal to continue on with n=480K-485K, k=100K-200K to continue taking advantage of the much higher sieve depth. If, however, the consensus is to stop after the first twin, then we need to do an optimal depth analysis for just the n=485K-490K, k<100K range, to see whether we're at optimal depth for [i]that[/i] portion of the range. (I know that wouldn't be quite an optimal representation because there is effectively no speed penalty from adding the additional k-range to the sieve, but nonetheless it would take into account the increasing LLR times as k increases. This would then tell us which factor outweighs the other, the fewer candidates from higher sieve depth, or shorter LLR times from lower k.)

Also worth considering is the "best of both worlds" option that MooMoo2 suggested whereby PRPnet would proceed to n=480K-485K, k=100K-200K, and LLRnet to n=485K-490K, k<100K. This would lose a bit of optimality whether or not we stop after the first twin, but it wouldn't be a profound loss and would give contributors some more flexibility in which work they choose to run (as well as providing a more than nominal difference between the choice of LLRnet and PRPnet). This would be my "vote" as to how to proceed.

[QUOTE=mdettweiler;245962]If, however, the consensus is to stop after the first twin, then we need to do an optimal depth analysis for just the n=485K-490K, k<100K range, to see whether we're at optimal depth for [I]that[/I] portion of the range. [/QUOTE]
We're already at optimal depth for the n=485K-490K, k<100K range. The current depth is p=950T, and at 950T-955T, 5466 factors were found for the n=480K-485K, k<10M range:
[URL]http://www.mersenneforum.org/showpost.php?p=230048&postcount=279[/URL]

Extrapolate that to the n=485K-490K, k<100K range, and you get 54-55 factors for a range of p that takes a single core more than a day to sieve. During that time, that core can easily LLR hundreds of candidates.

Even at a depth of 65T, the n=480K-485K, k<100K range was already considered optimal:
[URL]http://www.mersenneforum.org/showpost.php?p=214589&postcount=3[/URL]

Things might be a bit different for n=485K-490K, but it shouldn't be that much of a difference.

[QUOTE=Blackwood;246007]We're already at optimal depth for the n=485K-490K, k<100K range. The current depth is p=950T, and at 950T-955T, 5466 factors were found for the n=480K-485K, k<10M range:
[URL]http://www.mersenneforum.org/showpost.php?p=230048&postcount=279[/URL]

Extrapolate that to the n=485K-490K, k<100K range, and you get 54-55 factors for a range of p that takes a single core more than a day to sieve. During that time, that core can easily LLR hundreds of candidates.

Even at a depth of 65T, the n=480K-485K, k<100K range was already considered optimal:
[URL]http://www.mersenneforum.org/showpost.php?p=214589&postcount=3[/URL]

Things might be a bit different for n=485K-490K, but it shouldn't be that much of a difference.[/QUOTE]
Ah, very good. In that case, it boils down directly to the question of whether we want to continue testing from this range after the first twin is found. If yes, then we should move on to n=485K-490K, k<100K after we complete that range for n=480K-485K. If no, then we should keep going upwards with n=480K-485K, k=100K-200K since the sieve depth there is vastly greater. (We would then get to n=485K-490K later on when that's better sieved; the idea being that if we're going to LLR it all eventually, then we may as well focus on whatever is best-sieved at any given time.)

[QUOTE=mdettweiler;245962]Also worth considering is the "best of both worlds" option that MooMoo2 suggested whereby PRPnet would proceed to n=480K-485K, k=100K-200K, and LLRnet to n=485K-490K, k<100K. This would lose a bit of optimality whether or not we stop after the first twin, but it wouldn't be a profound loss and would give contributors some more flexibility in which work they choose to run (as well as providing a more than nominal difference between the choice of LLRnet and PRPnet). This would be my "vote" as to how to proceed.[/QUOTE]
I like that idea too. If nobody objects, we'll use PRPnet to test n=480K-485K, k=100K-200K, and LLRnet to test n=485K-490K, k<100K.