[QUOTE=swellman;495454]Hear! Hear!

FYI, Greg reached out to me (at Carlos’s suggestion) re: becoming a 14e/15e mod. I’m willing to do it but will likely need some handholding early on.[/QUOTE]

Excellent! I'm happy to help if you wish for assistance with e.g. choosing sieve ranges.
Perhaps this is a good time to remind submitters to include a suggested Q-range to hit their target relations count.

Yeah, all polynomials between posts #1566 and #1593 inclusive should now have been entered into the 14e and 15e management pages, and 5 14e numbers + 4 15e numbers are now in the SIEVING state :smile:
Hungry clients immediately restarted chewing WUs, and more than half of those in queue were already consumed, so it looks like I need to start at least another number to prevent starvation by tonight...

Dmitry: the "type: gnfs" line is missing from the Aliquot polynomials you posted :wink:
Historically, this caused an immediate rejection of the polynomial by the siever, and therefore WU failures; things are probably still that way, the Web interface has no check against that. So I've fixed the polynomials while queuing them.

Sean: good to see that Greg contacted you at Carlos' suggestion. I'll provide the handholding early on :smile:
You can double-check the current bunch of numbers in "QUEUED for SIEVING" and "SIEVING" states, as well as expand the ranges when needed. You'll notice that I usually trim the comment lines in the polynomials, to make them easier to review: for instance, 5419_67_minus1 and most OP tasks with simple (two-coefficient) polynomials don't need scrolling in the input dialog, they fit exactly the default number of lines displayed, so I use that as a quick double-check. Then, you can create entries in either queue, and I'll do my best reviewing them - I did my share of mistakes over time, we all did anyway...

Suggested Q ranges, test sieving yields and target number of relations are definitely nice for queue managers, but I didn't have those for most of the hundreds of numbers I dealt with since 2009, so maybe they shouldn't be a requirement - or better, this is a good opportunity to further share the test sieving infrastructure and knowledge among "project scientists" :smile:
I usually target 55-60M raw relations for a 29-bit LPs task, 110-120M for 30-bit, 210-220M for 31-bit. I seldom handled 32-bit and 33-bit tasks, but I know that the targets almost double for every additional bit of single large primes.

Hey Sean, glad you were contacted by Greg.

Lionel, what about a Skype call with share screens with Sean so he can easily familiarise himself with the management system, might be a good idea..

Well, I don't use any communication system of that sort outside of work, and even at work, only very infrequently :smile:

I forgot to mention that the "Add Number" button is at the very bottom of the management pages.

Please note, C200_224xx917_19 on the 14e queue is really a 31/32 hybrid which only needs about 330M relations.

[QUOTE=VBCurtis;495469]Excellent! I'm happy to help if you wish for assistance with e.g. choosing sieve ranges.
Perhaps this is a good time to remind submitters to include a suggested Q-range to hit their target relations count.[/QUOTE]

Any ideas on Q range for [url=https://www.mersenneforum.org/showpost.php?p=494880&postcount=1577]C200_224xx917_19[/url]? It’s tricky and I don’t have my handy homemade integration tool, er, handy.

The poly file does have the line
[code]
lss: 0[/code]
Which IIRC is the flag for -a sieving, so that seems good.

ETA: Assume Q0 = 20M. That value is already in 14e and I’m reluctant to change it at this point.

As RichD points out in the post previous to this, we need ~330M relations. I could just keep raising the upper value of Q behind the scenes until we have sufficient relations if necessary, but that seems the less than optimal method.

Thanks to all helping here. So far queue wrangling doesn’t seem too bad, but Lionel did most of the work.

[QUOTE=swellman;495511]Any ideas on Q range for [url=https://www.mersenneforum.org/showpost.php?p=494880&postcount=1577]C200_224xx917_19[/url]? It’s tricky and I don’t have my handy homemade integration tool, er, handy.[/QUOTE]

I use a quick eyeballing tactic. The first range is about 6100 to 9900 so the midpoint (or average) is 8000. So I take 8K divided by the 5K block and multiple by the 40M range which yields 64M in this range. Next range is 5800 to 6000 or 5.9K average. 5.9/5 x 40M = 47.2M. Running total of 111.2M.

Next is 5400 to 5800 or 5.6K average. 5.6/5 x 50M = 56M. Running total 167.2M

Next is 4000 to 5400 or 4.7K average. 4.7/5 x 50M = 47M. Running total 214.2M

Next is 4000 to 4000 or 4.0K average. 4.0/5 x 50M = 40M Running total 254.2M

Next is 4000 to 4600 or 4.3K average. 4.3/5 x 50M = 43M Running total 297.2M

The two 4000 yield seems to be a bit out of line so a good starting point might be Q=20-350 or 360. Then add more as needed.

My two cents.

RichD nicely wrote what I generally do. :tu:
Yields below 1 make me sad.

As long as the number is in QUEUED for SIEVING state, the starting q value, and other parameters, can be changed.
The 14e clients are going to starve by the end of this European morning, so I'll start this number very soon anyway, unless Sean is in a comparable timezone and beats me to it.
That's a persistent issue with the 14e grid: clients chew through WUs very quickly, which makes for a poor management effort / amount of food for clients ratio.

I'm going to queue [url]http://stdkmd.com/nrr/c.cgi?q=57779_231[/url] to 14e. SNFS difficulty ~231, and I had raised the amount of ECM work on it to ~2t50 at the beginning of the year, so the likelihood of an ECM miss is low.

Other near-repdigit numbers suitable for 14e as 31-bit LPs tasks, which had more than t50 ECM work but would need some more:
* [url]http://stdkmd.com/nrr/c.cgi?q=50009_239[/url] : needs to be raised from ~2t50 to 4t50;
* [url]http://stdkmd.com/nrr/c.cgi?q=99299_121[/url] : ~3t50 -> 5t50
* [url]http://stdkmd.com/nrr/c.cgi?q=50009_245[/url] : 2t50 -> t55
* [url]http://stdkmd.com/nrr/c.cgi?q=33833_123[/url] : <2t50 -> t55

15e Candidate
 

C267 from the MWRB file with OPN weight of 82654 for the 15e queue.
[CODE]n: 241079894716333956997275789346920646655531394780507391247328955383478377149896567501095555675373806142099785688420020790135741399964709763094815151900512401691797751695735733687285516689544356819226105554350311890647572125672001839259413989185068061577008377026799241
# 5009^73-1, difficulty: 270.08, skewness: 0.24, alpha: 0.00
# cost: 3.71449e+19, est. time: 17688.07 GHz days (not accurate yet!)
skew: 0.242
c6: 5009
c0: -1
Y1: -1
Y0: 249466584045729700780614014127899907656076481
type: snfs
rlim: 134000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 94
rlambda: 2.8
alambda: 3.7[/CODE]
Trial sieving 5K blocks.
[CODE] Q Yield
40M 10741
60M 10095
100M 9878
150M 8355
200M 8348
250M 7021
300M 7060[/CODE]