C162 from 785232:i11446 for 14e queue


[CODE]n: 120200802921012037919315743851322324648338387287699183328099465615901872437571638375522676889046805645100018711742445165451122601438764030595100336427729254081173
# norm 1.265296e-15 alpha -6.802752 e 1.161e-12 rroots 5
skew: 27986273.62
c0: 36891961793113385651782128115039492790875
c1: 4229635392040346226271944154082037
c2: -260433884364123901182411245
c3: -22747677353174073699
c4: 489986750080
c5: 4452
Y0: -30638702839885683853466656422426
Y1: 218304098080241773
rlim: 67000000
alim: 67000000
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.6
alambda: 2.6
type: gnfs
[/CODE]Suggesting sieving range 20M-80M. I'll run LA for this number.

C162 poly
 

[QUOTE=unconnected;495938]C162 from 785232:i11446 for 14e queue


[CODE]n: 120200802921012037919315743851322324648338387287699183328099465615901872437571638375522676889046805645100018711742445165451122601438764030595100336427729254081173
# norm 1.265296e-15 alpha -6.802752 e 1.161e-12 rroots 5
skew: 27986273.62
c0: 36891961793113385651782128115039492790875
c1: 4229635392040346226271944154082037
c2: -260433884364123901182411245
c3: -22747677353174073699
c4: 489986750080
c5: 4452
Y0: -30638702839885683853466656422426
Y1: 218304098080241773
rlim: 67000000
alim: 67000000
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.6
alambda: 2.6
type: gnfs
[/CODE]Suggesting sieving range 20M-80M. I'll run LA for this number.[/QUOTE]
A spinned-up poly with better E and surprising c5 (don't ask) for the above number:
[code]
Y0: -61277405373647460442775718918866
Y1: 218304098080241773
c0: 75543047841236298206569254372418080145020
c1: 9811299947071811429889849748908030
c2: -613642512052347317677082674
c3: -21351592179214966459
c4: 252797074370
c5: 1113
skew: 50937101.01
# size 1.144e-15, alpha -7.755, combined = 1.248e-12 rroots = 5
[/code]

15e Candidate
 

C240 from the MWRB file with OPN weight of 6720 for the 15e queue.
[CODE]n: 744822874420876233458923367945655307569152801862856562088507501346332816800292929072183589933446057869501960576430008108565773799257456260338665041117688020503279438090005561266763646471131309343423234949252179748225431168342729615301426721
# 4603759^37-1, difficulty: 247
skew: 0.0775
c6: 4603759
c0: -1
Y1: -1
Y0: 9520844789294346565511217928502073721441
type: snfs
rlim: 67000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.7
alambda: 2.7[/CODE]
Trial sieving 5K blocks.
[CODE] Q Yield
20M 10368
60M 8326
100M 7070
150M 5638
200M 5284
250M 4531[/CODE]

Although it would be slightly less efficient than using 15e, a 31-bit LPs task of SNFS difficulty 247 would help filling the 14e queue.
But both queues are still broken anyway...

This is definitely a 32-bit job if parameterized for the 14e queue. I was surprised how easy it worked as a 31-bit for 15e.

Edit: The best I could squeeze in 14e was 134/200 31/91a/3.6. The yield at 60M was 1.36. The kick in the pants is the seven digit coefficient.

C231 from the MWRB file with an OPN weight of 4176 (for 14e).
[CODE]n: 589470085638367943192974599027279943093828364938148311581636494878437898852030929478021141792049865392682126799756097273338295662495810826408804300923625102363936591501031429807074638456784409369277395132979916609500313986538937941
# 27409^53-1, difficulty: 239.65, skewness: 5.49, alpha: 0.00
# cost: 3.72874e+18, est. time: 1775.59 GHz days (not accurate yet!)
skew: 5.491
c6: 1
c0: -27409
Y1: -1
Y0: 8730491982047459268817962922083396659089
type: snfs
rlim: 67000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.6
alambda: 2.6[/CODE]
Trial sieving 5K blocks.
[CODE] Q Yield
20M 13165
60M 9959
100M 8767
150M 7282[/CODE]

13*2^860-1 is ready for the 14e queue:
EDIT: One should check ECM results file before posting to the queue. 13,860 has a P54 found by the last round of ECM (B1=650M).

Poly from Max for C162 is clearly better (at least by 10% according to test-sieve) than my, so lets use it.

[CODE]n: 120200802921012037919315743851322324648338387287699183328099465615901872437571638375522676889046805645100018711742445165451122601438764030595100336427729254081173
Y0: -61277405373647460442775718918866
Y1: 218304098080241773
c0: 75543047841236298206569254372418080145020
c1: 9811299947071811429889849748908030
c2: -613642512052347317677082674
c3: -21351592179214966459
c4: 252797074370
c5: 1113
skew: 50937101.01
# size 1.144e-15, alpha -7.755, combined = 1.248e-12 rroots = 5
rlim: 67000000
alim: 67000000
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.6
alambda: 2.6
type: gnfs
[/CODE]


Corrected sieving range is 15M-70M.

For the OPN numbers, can we please keep the filenames on the server and the displaynames on the statuspage as recognisable as possible? (see what happened in the 14e)

My personal preference is the C200_1234567_89 names and not the Phi123/Phi45/6789 etc names.

Just my 2 cents

In fact, the 14e management Web interface automatically copies the field containing the "name", used for filenames, to the field containing the "display name". In RSALS times, as well as for more than the first half of NFS@Home's 14e activity so far, the name and the display name matched.

We could ask Greg to modify several lines in crunching.php and crunching_e.php so that the "Now sieving", "Queued for post processing" and "Post processing" tables contain the (currently missing) name and the (currently displayed) display name.
How does that sound ?

EDIT:
* I have created 14e entries for the numbers since post #1623;
* Rich, could you double-check that what you meant in #1631 + #1633 was:
[code]n: 744822874420876233458923367945655307569152801862856562088507501346332816800292929072183589933446057869501960576430008108565773799257456260338665041117688020503279438090005561266763646471131309343423234949252179748225431168342729615301426721
# 4603759^37-1, difficulty: 247
skew: 0.0775
c6: 4603759
c0: -1
Y1: -1
Y0: 9520844789294346565511217928502073721441
type: snfs
rlim: 134000000
alim: 2004000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 97
rlambda: 3.6
alambda: 3.6[/code]* Sean, could you double-check the polys I entered ?
* tomorrow, I should be able to enter [url]http://stdkmd.com/nrr/c.cgi?q=50009_239[/url] into the 14e queue, unless my 16 GMP-ECM instances running curves at B1=43e6 find an unlikely factor by then.

TIA.

[QUOTE=RichD;495973]The best I could squeeze in 14e was 134/200 31/91a/3.6.[/QUOTE]

What I meant by this is the following, meaning 3LP on the -a side.
[CODE]rlim: 134000000
alim: 200000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 91
rlambda: 2.6
alambda: 3.6[/CODE]
I used most tricks to squeeze out more yield but couldn't get a decent yield. I am not too familiar with 32-bit jobs or 15e jobs unless they fall out nicely. That is why I try to avoid them. I guess this is the place to seek assistance. I was going to shelve this number (for now) because other potential 32-bit jobs were more important in the food chain. :-)