[b]QUEUED AS C210_35401_47 [/b]
C210 from the MWRB file with OPN weight of 4659.
[CODE]n: 179773904402963540012043768961264342566798484943117147475583899406388058190953868388384099966218950311680302668561319210983780320714214134122852447291950701949152186086065638361328759702523257009816990787667447
# 35401^47-1, difficulty: 218.35, skewness: 5.73, alpha: 0.00
# cost: 6.71447e+17, est. time: 319.74 GHz days (not accurate yet!)
skew: 5.730
c6: 1
c0: -35401
Y1: -1
Y0: 2466744908492248302839724731472763201
type: snfs
rlim: 33500000
alim: 67000000
lpbr: 29
lpba: 29
mfbr: 58
mfba: 58
rlambda: 2.5
alambda: 2.5[/CODE]
Trial sieving 5K blocks.
[CODE] Q Yield
12M 9239
20M 8369
40M 6641
50M 5580[/CODE]

[b]QUEUED AS C215_46988659_29[/b]
C215 from the MWRB file with OPN weight of 4476.
[ a.k.a. Phi_29(Phi_3(29879)/13) ]
[CODE]n: 65434296264879485831057770993488700245967650017100071066373555801095079019465292289811876502805313831172779822893945904680867232753021773924258110416408044145755384753131700041017654832754227289103683721688682472361
# 46988659^29-1, difficulty: 230.16, skewness: 19.00, alpha: 0.00
# cost: 1.75779e+18, est. time: 837.04 GHz days (not accurate yet!)
skew: 18.996
c6: 1
c0: -46988659
Y1: -1
Y0: 229068438192034972228712515721768747299
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 12521
60M 9046
100M 8013
150M 6445
160M 6490[/CODE]

[b]QUEUED AS C207_142_140[/b]
C207_142_140 is ready for SNFS on 15e.
[code]
n: 181880005344312752547351053110561853735044950331211895848228883811460064270237904222338774952556553414116880507683899197306279697981433878482883772909802843586359442171778741141485782104457552276969070355101
# 142^140+140^142, difficulty: 265.70, anorm: 4.97e+039, rnorm: 3.81e+049
# scaled difficulty: 267.34, suggest sieving rational side
# size = 1.215e-013, alpha = 0.000, combined = 2.567e-014, rroots = 0
type: snfs
size: 265
skew: 13.5449
c6: 1
c0: 6175225
Y1: -3792643488006829893221399440992214604544311
Y0: 191581231380566414401000000000000000000000000
rlim: 268000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.8
alambda: 2.8
[/code]


Test sieving on the -r side with Q in blocks of 5K.
[code]
Q=40M 9339
Q=80M 7822
Q=150M 6903
Q=250M 6221
Q=350M 5849
Q=450M 4774
[/code]
Suggesting a sieving range for Q of 40M-390M with a target number of relations = 470M.

[b]QUEUED AS 13_2_855m1[/b]
13*2^855-1 is ready for the 14e queue:
[code]n: 95519134355283049127394540485295355152618486902680103331360583150753730511848530235778980456239748248945293410471413899725329001509844059854119973218445317579036408204225806505836786259576081902844946947
skew: 0.47
type: snfs
size: 259
c6: 104
c0: -1
Y1: -1
Y0: 5575186299632655785383929568162090376495104
rlim: 134000000
alim: 200000000
lpbr: 33
lpba: 33
mfbr: 95
mfba: 66
rlambda: 3.9
alambda: 2.7[/code]
Test sieving indicates Q from 20-200M is sufficient for ~680M relations:
[code]Q=20M 0.109 sec/rel, 7134 rels
Q=50M 0.132 sec/rel, 4785 rels
Q=80M 0.143 sec/rel, 3768 rels
Q=110M 0.166 sec/rel, 3688 rels
Q=140M 0.183 sec/rel, 3104 rels
Q=170M 0.182 sec/rel, 2456 rels
Q=200M 0.190 sec/rel, 2989 rels[/code]
I'll handle the matrix.

[b]QUEUED AS C210_35111_47[/b]
C210 from the MWRB file with OPN weight of 4537.
[CODE]n: 123140103821526141367868525895729213752151515510879839354320225626531677719097382080181388437501784126745255276291978007191332843822755613123585827759246491191876769245187352213190836532413378042429122681260457
# 35111^47-1, difficulty: 218.18, skewness: 5.72, alpha: 0.00
# cost: 6.61978e+17, est. time: 315.23 GHz days (not accurate yet!)
skew: 5.722
c6: 1
c0: -35111
Y1: -1
Y0: 2309646904328828797722369781161055681
m: 2309646904328828797722369781161055681
type: snfs
rlim: 67000000
alim: 134000000
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.6
alambda: 2.6[/CODE]
Trial sieving 5K blocks.
[CODE] Q Yield
16M 11396
20M 11818
40M 9621
70M 7620
80M 7042[/CODE]

[b]QUEUED AS C214_129_104[/b]
C214_129_104 is ready for SNFS on 15e.
[code]
n: 2039345115997108092068814970067350838732124860886370591188261323534941520171057490300273014529879628234476915038525343717416664347928819654105514491661898811669841858698439013003041404719152640591398233197862344263
# 129^104+104^129, difficulty: 265.32, anorm: 3.42e+040, rnorm: -4.58e+048
# scaled difficulty: 266.68, suggest sieving rational side
# size = 1.272e-013, alpha = 0.000, combined = 2.732e-014, rroots = 0
type: snfs
size: 265
skew: 1.0092
c6: 16641
c0: 17576
Y1: -4557536137509512249139998657533399854481408
Y0: 758621374683090977986568634824263809
rlim: 268000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.8
alambda: 2.8
[/code]


Test sieving on the -r side with Q in blocks of 5K:
[code]
Q=30M 8959
Q=40M 8691
Q=80M 7211
Q=140M 6357
Q=220M 5896
Q=320M 5123
Q=430M 4449
[/code]
Which suggests a sieving range for Q of 30-420M with the target number of relations equal to 465M.

[b]QUEUED AS C208_129_112[/b]
C208_129_112 is ready for SNFS on 15e.
[code]
n: 8687879693702338144636986968211660564817429281400836746915055651121586523988408872591099574314760503859538956470068861984738771134706147805179704053349815308646785798083325066042220284352967080647313551641613
# 129^112+112^129, difficulty: 267.16, anorm: 1.15e+041, rnorm: -6.45e+049
# scaled difficulty: 268.62, suggest sieving rational side
# size = 8.519e-014, alpha = 0.000, combined = 1.992e-014, rroots = 0
type: snfs
size: 267
skew: 8.9123
c6: 81
c0: 40589248
Y1: -21607696528935852347172273073430316317671424
Y0: 4208072765367105654891496217370191348523
rlim: 268000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.8
alambda: 2.8
[/code]


Test sieving on the -r side with Q in blocks of 5K:
[code]
Q=30M 8151
Q=70M 7276
Q=120M 7000
Q=180M 5835
Q=250M 5471
Q=350M 5233
Q=450M 4457
[/code]
Suggesting a sieving range for Q of 30-420M with the target number of relations = 460M.

[b]QUEUED AS C179_374xx231_19[/b]
C179 from the OPN t550 file.
[ a.k.a. Phi_19(Phi_23(11)/829/28878847)/457/p45 ]
[CODE]n: 80618562396984935580623859027901093408800599611923946658233231525493005483233781369300047153178992219590691911823783888072577697447227475180025849626735504489297896289167314117439
# 3740221981231^19-1, SNFS-239, sieve on algebraic side
lss: 0
skew: 0.0080
c6: 3740221981231
c0: -1
Y1: -1
Y0: 52322939506884127873809971198569749391
type: snfs
rlim: 134000000
alim: 200000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 91
rlambda: 2.6
alambda: 3.7[/CODE]
Trial sieving 5K blocks.
[CODE] Q Yield
20M 10159
60M 5700
100M 4872
150M 4061
200M 4201
250M 2896[/CODE]

[b]QUEUED AS C224_439xx137_13 [/b]
C224 from the OPN t600 file.
[ a.k.a. Phi_13(Phi_7(84473)/449/18376499)/1773952827739 ]
[CODE]n: 29065076795637688034743639625458916810848275453904537640113617362371801283099817687985068643218163517367185559953718516308646454254209432734832281890922271605922224879990713043005839392665145437016438735412176650211411437799
# 43923080889124454137^13-1, difficulty: 235.71, skewness: 1.00, alpha: 3.10
# cost: 2.7358e+18, est. time: 1302.76 GHz days (not accurate yet!)
skew: 1.000
c6: 1
c5: 1
c4: -5
c3: -4
c2: 6
c1: 3
c0: -1
Y1: -43923080889124454137
Y0: 1929237034792569848573858864418216414770
type: snfs
rlim: 33500000
alim: 67000000
lpbr: 30
lpba: 30
mfbr: 60
mfba: 88
rlambda: 2.6
alambda: 3.6[/CODE]
Trial sieving 5K blocks.
[CODE] Q Yield
20M 10122
60M 6853
100M 6090[/CODE]

[b]QUEUED AS C214_139_76[/b]
C214_139_76 is ready for SNFS on 15e.

[code]
n: 1076923866207269277731155126889807434756461802393269998569592877006451777488997015703355341399203387934595646926324539911300996251225897042110033614126622400319512468566145165349088767833723567470082728753899640689
# 139^76+76^139, difficulty: 264.14, anorm: 4.85e+039, rnorm: -8.38e+049
# scaled difficulty: 265.85, suggest sieving rational side
# size = 2.005e-013, alpha = 0.000, combined = 3.641e-014, rroots = 0
type: snfs
size: 264
skew: 5.3306
c6: 16
c0: 367099
Y1: -36286294260611296958454793269808377419005952
Y0: 7230900796183182881721657019
rlim: 268000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.8
alambda: 2.8
[/code]


Test sieving on the -r side with Q in blocks of 5k
[code]
Q=30M 11400
Q=70M 9786
Q=120M 9418
Q=180M 8107
Q=250M 7690
Q=350M 7349
[/code]

Suggesting a range for Q of 30M-300M with target number of relations equal to 470M.

I need someone else with nfs@home manager access to look after the queues until I come back from the other side of the world in mid-October.

[QUOTE=fivemack;494378]I need someone else with nfs@home manager access to look after the queues until I come back from the other side of the world in mid-October.[/QUOTE]

Recent ones seems to be Jon, Mike and Lionel. Perhaps they can resurface in the short interim.

Maybe Sean should have access to the page as well ?

C230 from the OPN t550 file.
[CODE]n: 15174162268770960233894264658270126627423412474293591543509510191975750187441764089463393121902243943433149310256021469046519626255588846495292104143421417246076547979781844463892799460172690669028682700760746557797269270507209969
# 5419^67-1, difficulty: 250.17, skewness: 0.24, alpha: 0.00
# cost: 8.41423e+18, est. time: 4006.78 GHz days (not accurate yet!)
skew: 0.239
c6: 5419
c0: -1
Y1: -1
Y0: 118334304102821861900700753662999892477619
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 9928
60M 7787
100M 7113
150M 5474
200M 5423[/CODE]

C226_150_82 is ready for SNFS
[code]
n: 1647545255613869542190001676680032690752994252742840761818118323695914234561536322566318339676711058343003911467895128202900162113017869809534959899376985824578908367129472493148707997146091835636555021500877555681771579339793
# 150^82+82^150, difficulty: 263.59, anorm: 3.60e+038, rnorm: 3.60e+049
# scaled difficulty: 265.42, suggest sieving rational side
# size = 3.651e-013, alpha = 0.000, combined = 5.620e-014, rroots = 0
type: snfs
size: 263
skew: 5.6462
c6: 1
c0: 32400
Y1: -11878632009029388427734375
Y0: 85498080771782563631553969990380108517380096
rlim: 268000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.8
alambda: 2.8
[/code]


Test sieving on the -r side with Q in blocks of 5K
[code]
Q=30M 15276
Q=70M 13630
Q=120M 12650
Q=180M 10876
Q=260M 11059
Q=350M 9748
[/code]
Suggesting a sieving range for Q of 30M-220M with the target number of relations = 460M.

C257_143_67 from the xyyx project is ready for SNFS.
[code]
n: 73133280871529205829293177052659837367101847060646430284313351452623957010343101851674742393536355317665771899853123117144368422274912142296442281487720486723266990179156243185270665400010200937134912503969016322303501247437669478310676020676209762340334343
# 143^67+67^143, difficulty: 262.95, anorm: 1.96e+038, rnorm: 3.12e+049
# scaled difficulty: 264.82, suggest sieving rational side
# size = 2.935e-013, alpha = 0.000, combined = 4.832e-014, rroots = 0
type: snfs
size: 262
skew: 4.6086
c6: 1
c0: 9581
Y1: -511324276025564512546607
Y0: 66956888672235945457062019127709902451882721
rlim: 268000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.8
alambda: 2.8
[/code]


Test sieving on the -r side with Q in blocks of 5K
[code]
Q=30M 13750
Q=70M 11761
Q=130M 11562
Q=200M 9754
Q=300M 9046
[/code]
Suggesting a sieving range for Q of 30M-240M with a target # relations = 460M.

[QUOTE=debrouxl;494426]Maybe Sean should have access to the page as well ?[/QUOTE]

I’m willing to help but no offense will be taken if this doesn’t come to pass.

C201 from the OPN t600 file.
[ a.k.a. Phi_11(Phi_3(Phi_3(Phi_11(1009)/617/4647193/23223849323621)/463)/3/43)/991/22626021023 ]
[CODE]n: 739759388509803651204357140303812901622172262736644973521355628524617550175646147607828827714865103641137097659617724482170014007488918713749123090412204168505282001908729019907997420894480626124396539
# 2642270235905971097617^11-1, difficulty: 214.22, skewness: 1.00, alpha: 2.22
# cost: 4.75904e+17, est. time: 226.62 GHz days (not accurate yet!)
skew: 1.000
c5: 1
c4: 1
c3: -4
c2: -3
c1: 3
c0: 1
Y1: -2642270235905971097617
Y0: 6981591999554596155828140689707351743078690
type: snfs
rlim: 33500000
alim: 67000000
lpbr: 29
lpba: 29
mfbr: 58
mfba: 58
rlambda: 2.5
alambda: 2.5[/CODE]
Trial sieving 5K blocks.
[CODE] Q Yield
16M 12673
20M 14028
40M 12710[/CODE]

C255_146_67 is ready for SNFS on 15e.

[code]
n: 264690630627443445537073743009722107035436170028866398376767829005950674105671977262771929590665315352390389558641216095585469295139304027343204713211029242812882049276870925715294650762750422429576513535213908019672456145368794555626411800132062482750293
# 146^67+67^146, difficulty: 268.77, anorm: 1.62e+039, rnorm: -8.91e+049
# scaled difficulty: 270.56, suggest sieving rational side
# size = 1.273e-013, alpha = 0.000, combined = 2.639e-014, rroots = 0
type: snfs
size: 268
skew: 1.7700
c6: 146
c0: 4489
Y1: -66956888672235945457062019127709902451882721
Y0: 642512252044000682756096
rlim: 268000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.8
alambda: 2.8
[/code]


Test sieving on the -r side with Q in blocks of 5K.
[code]
Q=40M 8823
Q=70M 7987
Q=130M 7631
Q=200M 6792
Q=300M 6024
Q=400M 5229
[/code]
Suggesting a sieving range for Q of 40M-390M with 470M target # of relations.

C262_135_91 is ready for SNFS on 15e.
[code]
n: 1135744575215526337336060326822464080431664666556308201902425162770959428253151440131320507245729998159330089683234215171018071595153817907420262231341218539958772831918684093176071262266639511181969343428078937782945819109438419407587983705851198342488528936113
# 135^91+91^135, difficulty: 264.47, anorm: 2.32e+031, rnorm: 4.80e+058
# scaled difficulty: 269.02, suggest sieving rational side
# size = 4.513e-018, alpha = 0.000, combined = 2.641e-014, rroots = 1
type: snfs
size: 264
skew: 2.6673
c5: 1
c0: 135
Y1: -221823642742309798013268161773681640625
Y0: 78364179848159496950215666284642950476127499777670531
rlim: 268000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.8
alambda: 2.8
[/code]


Test sieving on the -r side with Q in blocks of 5K.
[code]
Q=40M 7384
Q=70M 8063
Q=130M 9251
Q=200M 9007
Q=300M 8953
[/code]
Suggesting a sieving range for Q of 40-310M with target # rels = 460M.

IIUC, all numbers starting from [url]http://www.mersenneforum.org/showpost.php?p=494427&postcount=1566[/url] would need to be queued...

It seems that the number in #1570 is a task for 14e, and the number in #1566 could also be one, but the others are more suitable to 15e.

[QUOTE=debrouxl;494665]IIUC, all numbers starting from [url]http://www.mersenneforum.org/showpost.php?p=494427&postcount=1566[/url] would need to be queued...

It seems that the number in #1570 is a task for 14e, and the number in #1566 could also be one, but the others are more suitable to 15e.[/QUOTE]

Yes there are six jobs recently put up for NFS@Home. All four of mine are indeed 15e. I can’t speak to RichD’s intent with his pair of jobs (1566 and 1570).

C248_150_88 is ready for SNFS on 15e.
[code]
n: 12716078305215958779886851021625246942489356647536551626586476333237138056130294061858477826214894872401279648768686365581528330320113825329622633299908869524378634699004185182866534898979607817632229865812939205439692137863965210227256743197466181
# 150^88+88^150, difficulty: 265.98, anorm: 6.00e+037, rnorm: -1.29e+050
# scaled difficulty: 268.03, suggest sieving rational side
# size = 3.170e-013, alpha = 0.000, combined = 4.987e-014, rroots = 0
type: snfs
size: 265
skew: 1.0627
c6: 25
c0: 36
Y1: -124915654782240694753529492552326737324670976
Y0: 2672692202031612396240234375
rlim: 268000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.8
alambda: 2.8
[/code]


Test sieving on the -r side with Q in blocks of 5K
[code]
Q=40M 13187
Q=70M 11794
Q=130M 11251
Q=200M 10149
Q=300M 9267
[/code]
Suggesting a sieving range of 40-255M with the target # relations = 460M.

C249_134_91 is ready for SNFS on 15e.
[code]
n: 409083226406089551073858599774664870131688000296764801917503027789526487424240363081370735574824232266787845645556792753772872551365137460552152673869395171305980394941082807555923813088908198724878425248892510433476488075670713606783682478829690467
# 134^91+91^134, difficulty: 264.64, anorm: 2.11e+039, rnorm: -1.77e+049
# scaled difficulty: 266.29, suggest sieving rational side
# size = 2.841e-013, alpha = 0.000, combined = 4.759e-014, rroots = 0
type: snfs
size: 264
skew: 1.9884
c6: 134
c0: 8281
Y1: -12557715249685059365095784756336096391283081
Y0: 80643984127232967094095054209024
rlim: 268000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.8
alambda: 2.8[/code]


Test sieving on the -r side with Q in blocks of 5K.
[code]
Q=40M 13549
Q=70M 11818
Q=130M 11285
Q=200M 10182
Q=300M 9146[/code]
Suggesting a sieving range for Q of 40-250M with the target # of relations being 460M.

C200 from the OPN t600 file (for 14e).
[ a.k.a. Phi_19(Phi_3(Phi_3(Phi_3(612067)/3/4801)/3/43/9949)/3/41233)/15733/90791273/58231064341 ]
Sieve on algebraic side.
[CODE]n: 25503431421917993101321887118006938878378655964476437605074260560152721672529861314581467042556964110748403572526947437910470022455618855395879515986932272093603127760772643420867362459955421459731663
# 2246354414917^19-1, SNFS-235, sieve on algebraic side
lss: 0
skew: 0.0087
c6: 2246354414917
c0: -1
Y1: -1
Y0: 11335347337562584746201140717669233213
type: snfs
rlim: 134000000
alim: 268000000
lpbr: 31
lpba: 32
mfbr: 62
mfba: 94
rlambda: 2.6
alambda: 3.7[/CODE]
Trial sieving 5K blocks.
[CODE] Q Yield
20M 9932
60M 6084
100M 5822
200M 5389
250M 4015
300M 4021
350M 4561[/CODE]

C210 from the MWRB file with OPN weight of 4346 (for 14e).
[CODE]n: 302207599938805761327997935282174441298042372118133114896888310078307460165125968892528406858735753550901167676371217759725453847200048127229321156974889302081122361260053421396536125780776908768639744719386893
# 35803^47-1, difficulty: 218.59, skewness: 5.74, alpha: 0.00
# cost: 6.8466e+17, est. time: 326.03 GHz days (not accurate yet!)
skew: 5.741
c6: 1
c0: -35803
Y1: -1
Y0: 2699947677985691593842876298358043361
type: snfs
rlim: 33500000
alim: 67000000
lpbr: 29
lpba: 29
mfbr: 58
mfba: 58
rlambda: 2.5
alambda: 2.5[/CODE]
Trial sieving 5K blocks.
[CODE] Q Yield
16M 11396
20M 11818
50M 8738[/CODE]

C228 from the OPN t550 file.
[CODE]n: 610133329304823379137990452248364008749412356143661315676422082332056842806496916720842240747178025392928817537359632286740352866708218652655690083395714909926456219868786649547818393644684102514214039176668727653047860881334377
# 14401^59-1, difficulty: 249.50, skewness: 4.93, alpha: 0.00
# cost: 7.995e+18, est. time: 3807.14 GHz days (not accurate yet!)
skew: 4.932
c6: 1
c0: -14401
Y1: -1
Y0: 383642315790881761534748489578423411344001
type: snfs
rlim: 67000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 92
rlambda: 2.7
alambda: 3.6[/CODE]
Trial sieving 5K blocks.
[CODE] Q Yield
20M 9632
60M 7542
100M 6871
150M 5581
200M 5275[/CODE]

C220_131_101 is ready for SNFS on 15e.
[code]
n: 3767953678893883332716267467828183453837631891089364215353920434335302486201779413847014020785527770168272728418816423264813483592057434320453064348626878501512183743915763049126689629630890438988634553693594132799979777
# 131^101+101^131, difficulty: 266.57, anorm: 2.30e+038, rnorm: -1.27e+050
# scaled difficulty: 268.53, suggest sieving rational side
# size = 1.580e-013, alpha = 0.000, combined = 3.058e-014, rroots = 0
type: snfs
size: 266
skew: 1.0443
c6: 101
c0: 131
Y1: -124471585975092095765485234829277073042312201
Y0: 985398793384554108247251712700460611
rlim: 268000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.8
alambda: 2.8
[/code]


Test sieving on the -r side with Q in blocks of 5K
[code]
Q=30M 9783
Q=70M 8262
Q=130M 8295
Q=200M 7316
Q=300M 6551
Q=400M 5642
[/code]
Suggesting a sieving range for Q of 30-335M with the target number of relations = 460M.

C149_M17_k63 of the kosta project
 

Ready for GNFS on 14e.

[code]
n: 28770129013724456254012926022038295942999171797139048869463849912205920095538086552329863425927882025735381479393393328243705188475654409505084305593
# norm 2.212148e-14 alpha -7.379070 e 6.191e-12 rroots 3
skew: 13234620.06
c0: -132517996544023903180292154396470291801
c1: -64387407817664059509412164511052
c2: 4858165943061193687029062
c3: 1391650619654512688
c4: -28565300397
c5: 540
Y0: -139736423006461113748147066800
Y1: 365292052702687
rlim: 33000000
alim: 33000000
lpbr: 29
lpba: 29
mfbr: 58
mfba: 58
rlambda: 2.5
alambda: 2.5
[/code]


Test sieving on the [b]-a side[/b] with Q in blocks of 5K
[code]
Q=10M 16154
Q=20M 14215
Q=30M 16728
[/code]
Suggesting a sieving range for Q of 10-32M with the target number of relations = 60M.

C210 from the MWRB file with OPN weight of 4229.
[CODE]n: 477608318061078220035580807586190768219717843503705026144306449609421099667415690236209677673602714637764140098824414350805024578083262823875077570458720592700249550251309763421385176012912194515497298013873007
# 36161^47-1, difficulty: 218.80, skewness: 5.75, alpha: 0.00
# cost: 6.9651e+17, est. time: 331.67 GHz days (not accurate yet!)
skew: 5.751
c6: 1
c0: -36161
Y1: -1
Y0: 2923637043761401256527330179458542081
type: snfs
rlim: 33500000
alim: 67000000
lpbr: 29
lpba: 29
mfbr: 58
mfba: 58
rlambda: 2.5
alambda: 2.5
[/CODE]Trial sieving 5K blocks.
[CODE] Q Yield
16M 8344
20M 8840
40M 6929
60M 5450[/CODE]

C164 from 11040:10088 for 14e queue.

[CODE]n: 11857541848676311058331273948237703110453334631120714278401183260173506268505583582796221779457631980617586124117886022109888156608155997738833467983141395236812871
skew: 21850510.91
Y0: -65178690112913129350215256794116
Y1: 3541858018926250721
c0: 37263784939829926343794460682205332355155
c1: 5676124299692241845939292797526373
c2: -705673504845272308670168448
c3: -25997468138957649615
c4: 2559609840931
c5: 10080
#skew 21850510.91, size 7.446e-16, alpha -7.649, combined = 9.561e-13 rroots = 3
rlim: 67000000
alim: 67000000
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.6
alambda: 2.6
lss: 0

[/CODE]
Suggesting sieving range 20M-90M.

C224 from the OPN t550 file (for 14e).
[ a.k.a. Phi_41(861001)/41/3410431504693 ]
[CODE]n: 17970226478284756500825917777413127591432699724724082867878934363247994226560687007931872553468690085370266134455822733333015057240606545991676236034842474222076429402005122503949632832666346899781339076859621162386124042557
# 861001^41-1, difficulty: 249.27, skewness: 9.75, alpha: 0.00
# cost: 7.85355e+18, est. time: 3739.79 GHz days (not accurate yet!)
skew: 9.754
c6: 1
c0: -861001
Y1: -1
Y0: 350772542793886927343204537158902747027001
type: snfs
rlim: 67000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 91
rlambda: 2.7
alambda: 3.7[/CODE]
[CODE] Q Yield
20M 9239
60M 7412
100M 6630
150M 5381
200M 5256[/CODE]

C225 from the MWRB file with OPN weight of 19034 (for 14e).
[ a.k.a. Phi_61(13601)/25638986983/20400733556831 ]
[CODE]n: 153511865673058572234395201480010836659245852765310348714302686729527971981476326579256716871427433073142881301305726006060441316165647637454408183958294024559145911240830885341402188506602253842974514257914401805569810713434205059304539598865856761
# 13601^61-1, difficulty: 252
skew: 0.2045
c6: 13691
c0: -1
Y1: -1
Y0: 231393792734336690347909641528098941841401
type: snfs
rlim: 134000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.8
alambda: 2.8[/CODE]
Trial sieving 5K blocks.
[CODE] Q Yield
20M 12453
60M 10278
100M 10171
150M 8533
200M 8036
250M 7114[/CODE]

C214 from the OPN t600 file.
[ a.k.a. Phi_13(Phi_3(Phi_3(165211)/3/7)/3) ]
[CODE]n: 1016752011489489502104075197870424941325718347050240750739985223066163082493131712858821069318893758081393887852035792335171553496358953780368267408371509513357337120591696595961307049099271820880022810293254692813
# 563120390493837601^13-1, difficulty: 213.01, skewness: 1.00, alpha: 3.10
# cost: 4.29867e+17, est. time: 204.70 GHz days (not accurate yet!)
skew: 1.000
c6: 1
c5: 1
c4: -5
c3: -4
c2: 6
c1: 3
c0: -1
Y1: -563120390493837601
Y0: 317104574189932145187444356161435202
type: snfs
rlim: 16500000
alim: 33500000
lpbr: 29
lpba: 29
mfbr: 58
mfba: 58
rlambda: 2.5
alambda: 2.5[/CODE]
Trial sieving 5K blocks.
[CODE] Q Yield
12M 13533
20M 11787
40M 8718[/CODE]

13_2_857m is ready for the 14e queue:
[code]n: 28233346360797706582983532896286346122910620488805239739699415872705646036968439590028785884686926143888123830264104162865700377302657700507385396484495331232213130614697834588893130602308219209175534681786484489314449
skew: 0.73
type: snfs
size: 260
c6: 13
c0: -2
Y1: -1
Y0: 11150372599265311570767859136324180752990208
rlim: 134000000
alim: 200000000
lpbr: 33
lpba: 33
mfbr: 95
mfba: 66
rlambda: 3.9
alambda: 2.7[/code]
Q-range of 20-200M should be sufficient for ~725M raw relations:
[code]Q-ranges of 1000 were test-sieved
Q=20M 0.082 sec/rel, 7978 rels
Q=50M 0.110 sec/rel, 5157 rels
Q=80M 0.120 sec/rel, 4178 rels
Q=110M 0.136 sec/rel, 4023 rels
Q=140M 0.146 sec/rel, 3533 rels
Q=170M 0.144 sec/rel, 2787 rels
Q=200M 0.161 sec/rel, 3329 rels[/code]
Also, thanks to whomever added a bunch of sieving to 13*2^855-1 on 14e; the original job yielded 685M relations/528M unique, enough to build a 31M matrix at density 96 (100 failed).

C164 from 159978:10262 for 14e queue.


[CODE]n: 22466640612186137942669115058025019144994298858825124329157514708396949687037321242490210291602959752244775522751573969533408789307366891245070791900184482579299087
# norm 7.679347e-16 alpha -6.637729 e 8.696e-13 rroots 5
skew: 79670484.36
c0: -539299151714782181371100783948057421832500
c1: 14029121768187034457881374938478800
c2: 892272025816158471991545115
c3: -10518670741040735503
c4: -173811072579
c5: 264
Y0: -153457050639902061360346653330323
Y1: 12839405177526161
rlim: 67000000
alim: 67000000
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.6
alambda: 2.6
lss: 0
[/CODE]
Suggesting sieving range 20M-90M.

C243 from the MWRB file with OPN weight of 17762.
[CODE]n: 441103696998262845476930097571124636374013297481850359247169294229190024450885199865843109733125371826047994981259186560226021132677252906387614038577852523816045671115256339352875622737437430311041845795617426180926258344634686247972299785061
# 15259^59-1, difficulty: 251.01, skewness: 4.98, alpha: 0.00
# cost: 8.97013e+18, est. time: 4271.49 GHz days (not accurate yet!)
skew: 4.980
c6: 1
c0: -15259
Y1: -1
Y0: 684322359314269231218866444652459664169401
type: snfs
rlim: 134000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.8
alambda: 2.8[/CODE]
Trial sieving 5K blocks.
[CODE] Q Yield
40M 10988
70M 9131
100M 9281
150M 7864
200M 7443
250M 6510
300M 6381[/CODE]

C235_150_92
 

C235_150_92 is ready for SNFS on 15e.

[code]
n: 1201981621132757089209327399562910333349093640038136501765825446383845431909410036795083949491816705268075001848891486851316184917638343093094901490540085971523701918361152184461472668244726160888295861463331417244128066126579697051281
# 150^92+92^150, difficulty: 268.87, anorm: 6.00e+037, rnorm: 3.68e+050
# scaled difficulty: 271.00, suggest sieving rational side
# size = 2.348e-013, alpha = 0.000, combined = 3.970e-014, rroots = 0
type: snfs
size: 268
skew: 1.0627
c6: 25
c0: 36
Y1: -66817305050790309906005859375
Y0: 379529683844894205763212788410058069480833024
rlim: 268000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.8
alambda: 2.8
[/code]

Test sieving on the -r side with Q in blocks of 5K:
[code]
Q=40M 11690
Q=70M 10422
Q=130M 9961
Q=200M 9217
Q=300M 8504
[/code]
Suggesting a range for Q of 40M-280M with target# relations = 460M.

C245_150_76 is ready for SNFS on 15e.

[code]
n: 74496519916065722841036433183175474349675899776938821654215236437925230956836204763444914452448005078788606074410557204143758662583730160742530388959555500931031216600056418931796342843130087291910356343056857552272494331006376480625804189264473
# 150^76+76^150, difficulty: 260.45, anorm: 3.60e+038, rnorm: 1.08e+049
# scaled difficulty: 262.19, suggest sieving rational side
# size = 5.154e-013, alpha = 0.000, combined = 7.288e-014, rroots = 0
type: snfs
size: 260
skew: 5.6462
c6: 1
c0: 32400
Y1: -158381760120391845703125
Y0: 25584672320470074613285508535939109859885056
rlim: 268000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.8
alambda: 2.8
[/code]

Test sieving on the -r side with Q in blocks of 5K:
[code]
Q=40M 17309
Q=70M 15139
Q=120M 14802
Q=180M 12279
Q=250M 11437
[/code]
Suggesting a range of 40M-205M for Q.

C241_148_110 is ready for SNFS on 15e.

[code]
2817186149705883373080367851916338362531239636508061356232000533287667388067618644545632750107259538684163022767104066960158372596391007690398214326650779036101541647646032084227695832001194641420936972474625735006629543740540776071858501357
# 148^110+110^148, difficulty: 261.05, anorm: 4.07e+039, rnorm: 9.07e+048
# scaled difficulty: 262.61, suggest sieving rational side
# size = 1.403e-013, alpha = 0.000, combined = 2.910e-014, rroots = 0
type: snfs
size: 261
skew: 12.6723
c6: 1
c0: 4141225
Y1: -69181660408067279871809273565184
Y0: 32289939950073874605247453153133392333984375
rlim: 268000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.8
alambda: 2.8
[/code]

Test sieving on the -r side with Q in blocks of 5K
[code]
Q=40M 9448
Q=80M 7819
Q=140M 7110
Q=220M 6618
Q=320M 5778
Q=430M 5068
[/code]
Suggesting a Q range of 40-390M with the target number of relations =470M.

C200 from the OPN t600 file (for 14e).
[ a.k.a. Phi_11(Phi_3(Phi_3(Phi_3(Phi_13(7))/3/433)/3/1327/2630809123/59954796907)/3)/23/89/9439/38699 ]
[CODE]n: 31800237517992142214958828920978573745725773835426987338517109073515863409600909574347278617589940565224207434719160700135572446941432418639913806019889408482035821908437906935760486846937479884359503
# 1372831999148013167419^11-1, difficulty: 211.38, skewness: 1.00, alpha: 2.22
# cost: 3.7468e+17, est. time: 178.42 GHz days (not accurate yet!)
skew: 1.000
c5: 1
c4: 1
c3: -4
c2: -3
c1: 3
c0: 1
Y1: -1372831999148013167419
Y0: 1884667697884730426034202778891404923121562
type: snfs
rlim: 33500000
alim: 67000000
lpbr: 29
lpba: 29
mfbr: 58
mfba: 58
rlambda: 2.5
alambda: 2.5[/CODE]
Trial sieving 5K blocks.
[CODE] Q Yield
16M 16296
20M 17071
36M 16500[/CODE]

Yay! Thanks to [B]debrouxl[/B], all numbers (and their associated polynomials) prior to this post has been added to the grid.

[QUOTE=RichD;495445]Yay! Thanks to [B]debrouxl[/B], all numbers (and their associated polynomials) prior to this post has been added to the grid.[/QUOTE]

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=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]

[QUOTE=debrouxl;495530]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.[/QUOTE]

Basically Greg needs to add more 16e work otherwise the Gridcoin clients will just crunch the 14e/15e wus in no time.

If a number for 16e is needed, I have a C208 blocker on HP2(4496) -- [url]http://factordb.com/sequences.php?se=2&aq=4496&action=last&fr=0&to=100[/url]

I have a polynomial, and I believe it's been test-sieved, but I can double-check tonight if there's any interest.

C243 from the MWRB file with OPN weight of 17501. (for 14e)
[CODE]n: 529240584967009887418759189153762339953358445714031976694898445666783001971824396861966104538278993554027238807452605192095977191609642828920933074769390052310464338550743576121946908022304449245179580931209109736429915065760138298351371037557
# 15307^59-1, difficulty: 251.09, skewness: 4.98, alpha: 0.00
# cost: 9.02623e+18, est. time: 4298.20 GHz days (not accurate yet!)
skew: 4.983
c6: 1
c0: -15307
Y1: -1
Y0: 706156273912323084390219106603222678396249
type: snfs
rlim: 134000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.8
alambda: 2.8[/CODE]
Trial sieving 5K blocks.
[CODE] Q Yield
30M 10469
60M 8964
100M 8593
150M 7210
200M 6803
250M 5942
300M 5751
350M 5592[/CODE]

Sean: I'll let you create an entry (button at the bottom of the page) for the number in post #1606, we'll check it and you or me can start it later :smile:

On my side, I'm going to create and start Rich's latest number for 14e, and start 57779_231. Even with those, the grid's probably going to starve by tomorrow morning...

EDIT: looks like I used 20M-220M instead of the suggested 20M-200M range for 13_2_857m1, so there's going to be some oversieving, probably around 800M raw relations.

[QUOTE=debrouxl;495582]Sean: I'll let you create an entry (button at the bottom of the page) for the number in post #1606, we'll check it and you or me can start it later :smile:[/QUOTE]

Done. I think I got it but please check my work. While I was in there, I also corrected the poly for C241_148_110 - it was missing the "n:" in the first line. I checked my original posting and I own the error. :blush: At least it was corrected before sieving started,

Also added some postprocessor names to 14e that appeared tonight.

I have no immediate numbers to add. Maybe one or two in the next 5-7 days.

Are there other projects that would like to submit numbers, at least for the 14e queue? Aliquot?

Sean: doh. Good thing you found the error I failed to detect as well :smile:
The poly looks alright, it has the appropriate number of lines for a two-coefficient polynomial without lss: line anyway.
Neither ^, nor - are reserved characters for Windows or *nix, so the "5009^73-1" prefix for filenames will be alright. Historically, we've avoided such names - in fact, yesterday evening, I created and immediately deleted an entry for this exact reason, that's why there's a hole between #1448 and #1450 - but AFAICT, we don't [i]have[/i] to avoid such names.

[QUOTE=debrouxl;495612]Sean: doh. Good thing you found the error I failed to detect as well :smile:
The poly looks alright, it has the appropriate number of lines for a two-coefficient polynomial without lss: line anyway.
Neither ^, nor - are reserved characters for Windows or *nix, so the "5009^73-1" prefix for filenames will be alright. Historically, we've avoided such names - in fact, yesterday evening, I created and immediately deleted an entry for this exact reason, that's why there's a hole between #1448 and #1450 - but AFAICT, we don't [i]have[/i] to avoid such names.[/QUOTE]

Well. I should have remembered this fact about naming conventions but did not. Why don’t I change it to 5009_73m1? Or can the name be changed now? If not I’ll delete this entry and add it back with the better name choice. Even if it shouldn’t break NFS@Home, why risk it?

You mention “lss:” - should this always be present in the poly or only lss:0 if sieving on the algebraic side?

At best, the "5009^73-1" prefix could now be changed only by Greg, or whoever else has direct write access to the database. It's the only non-editable field in the Web form, and I've just checked that the comment for that database field in the SQL schema reads "number name (cannot be changed)".
It's simpler to create a new entry, copy the contents, and delete #335.

The "lss:" line needn't be present if the sieving side is the one corresponding best to the "type:" line. Most polys I managed over time do not have "lss:" lines. Or put another way: if the original poly has one, I usually keep it, but I don't add it if it's not there.

I've just noticed that polys for e.g. C215_46988659_29 and C210_35111_47 (14e) and C253_131_98b (15e) do [i]not[/i] have "type:" lines - so the fact is that the whole chain works without it, but I didn't remember about that...
There doesn't seem to be any code to fix up the poly, so the sievers seem to be able to cope without these lines, I guess. I remember that missing "skew:" lines caused immediate failures for several past RSALS and/or NFS@Home.

C179_374xx231_19 has a high dup rate (which doesn't surprise me). Can we get a few more relations added to this guy? My last 31-bit job had 178M+ unique relations and built a matrix at TD=120. This failed at TD=112 with 154M unique. I may peek ahead at a couple others. In the mean time I will take another number - posting in the appropriate thread.
[CODE]Found 154649059 unique, 65501730 duplicate, and 6681 bad relations.
Largest dimension used: 568 of 1200
Average dimension used: 472.0 of 1200[/CODE]

Alright, I raised the upper bound for C179_374xx231_19 to 300M.
The poly doesn't have a "type:" line, but since it has a "lss:" line, I'd expect it to have been sieved on the right side anyway.

[QUOTE=debrouxl;495665]Alright, I raised the upper bound for C179_374xx231_19 to 300M.
The poly doesn't have a "type:" line, but since it has a "lss:" line, I'd expect it to have been sieved on the right side anyway.[/QUOTE]

Thanks. I wonder what happened to the "type:" line! It was in the original [url=https://www.mersenneforum.org/showpost.php?p=494206&postcount=1560]post[/url].

[QUOTE=RichD;494880]C200 from the OPN t600 file (for 14e).
[ a.k.a. Phi_19(Phi_3(Phi_3(Phi_3(612067)/3/4801)/3/43/9949)/3/41233)/15733/90791273/58231064341 ]
Sieve on algebraic side.
[CODE]n: 25503431421917993101321887118006938878378655964476437605074260560152721672529861314581467042556964110748403572526947437910470022455618855395879515986932272093603127760772643420867362459955421459731663
# 2246354414917^19-1, SNFS-235, sieve on algebraic side
lss: 0
skew: 0.0087
c6: 2246354414917
c0: -1
Y1: -1
Y0: 11335347337562584746201140717669233213
type: snfs
rlim: 134000000
alim: 268000000
lpbr: 31
lpba: 32
mfbr: 62
mfba: 94
rlambda: 2.6
alambda: 3.7[/CODE]Trial sieving 5K blocks.
[CODE] Q Yield
20M 9932
60M 6084
100M 5822
200M 5389
250M 4015
300M 4021
350M 4561[/CODE][/QUOTE]
Can somebody explain (in simple/layman terms) why these parameters are so different from the other OPN SNFS numbers?
(31-32bit hybrid)
mfba: 94? (not 2x lpba)
and high alambda 3.7
sieving on [U]algebraic[/U] side (I thought SNFS were mostly sieved on the rational side???)

:confused2:

[QUOTE=VictordeHolland;495779]Can somebody explain (in simple/layman terms) why these parameters are so different from the other OPN SNFS numbers?
(31-32bit hybrid)
mfba: 94? (not 2x lpba)
and high alambda 3.7
sieving on [U]algebraic[/U] side (I thought SNFS were mostly sieved on the rational side???) :confused2:[/QUOTE]
mfba 94 is just less than 3 * lpba, which tells you this poly file uses 3 large primes on the algebraic side for sieving. Similar to selecting a sextic rather than a quintic polynomial, there is a size of problem where 3 large primes on one side improves yield quite a lot while sieving as quickly (or, at larger sizes, quite a bit faster) as 2 large primes. ETA: My personal experience is that test-sieving 3LP vs 2LP should be tried starting around SNFS-250 and GNFS-175. 3LP isn't always faster, but on some problems it's a substantial improvement.
Lambda is chosen as 3.x when using 3 large primes, 2.x (or, rarely, 3.0) when using two large primes. So, once 3 LPs on a side were selected, alambda was chosen to match.
Note that 3 large primes on both sides isn't used until *much* larger problems (say, SNFS 310+ or GNFS 220+, perhaps larger- I don't have much experience up there!).

I'm not used to seeing lim's chosen larger on the sieving side than the other side; I'm curious about the test-sieving results on that one!

[QUOTE=VBCurtis;495809]mfba 94 is just less than 3 * lpba, which tells you this poly file uses 3 large primes on the algebraic side for sieving. Similar to selecting a sextic rather than a quintic polynomial, there is a size of problem where 3 large primes on one side improves yield quite a lot while sieving as quickly (or, at larger sizes, quite a bit faster) as 2 large primes. ETA: My personal experience is that test-sieving 3LP vs 2LP should be tried starting around SNFS-250 and GNFS-175. 3LP isn't always faster, but on some problems it's a substantial improvement.
Lambda is chosen as 3.x when using 3 large primes, 2.x (or, rarely, 3.0) when using two large primes. So, once 3 LPs on a side were selected, alambda was chosen to match.
Note that 3 large primes on both sides isn't used until *much* larger problems (say, SNFS 310+ or GNFS 220+, perhaps larger- I don't have much experience up there!).

I'm not used to seeing lim's chosen larger on the sieving side than the other side; I'm curious about the test-sieving results on that one![/QUOTE]
Thanks for satisfying my curiosity :bow:

[QUOTE=VictordeHolland;495779]Can somebody explain (in simple/layman terms) why these parameters are so different from the other OPN SNFS numbers?
(31-32bit hybrid)
mfba: 94? (not 2x lpba)
and high alambda 3.7
sieving on [U]algebraic[/U] side (I thought SNFS were mostly sieved on the rational side???)

:confused2:[/QUOTE]

[B]VBCurtis[/B] did a great job explaining the mechanics of the polynomial, let me see if I can explain the logic.

The OPN numbers are pretty much cookie cutters once you get a working polynomial. Each exponent would have a general form. For p^5-1 and p^7-1 you can divide out a p-1 to make a quartic or sextic. For p^11-1 and p^13-1 a degree halving technique is used to get a quintic or sextic. For p^17-1, p^19-1 and p^23-1 these are troublesome SNFS jobs because of the large coefficients. For sizes suitable for the 14e queue it is better to sieve on the algebraic side. Beginning with p^23-1 and up, these are more traditional SNFS jobs with smallish coefficients. But if the coefficients get too big (say, greater than 7-8 decimal digits) then the algebraic side should be considered. I think I had a large p^31-1 (or a p^29-1) on the -a side not too long ago.

The number you question is a SNFS-235. I had a recent (C179_374xx231_19 - SNFS-239) job that barely fit as a 31-bit job. For some reason the yield was not good at all for the SNFS-235 number. When I bumped it to a 32-bit job, it seemed to be an overkill wth yield above 3:1. To squeeze more yield one can expand the lim’s but that usually only adds about 10% more with a 30% or so penalty in relations time. Another option is to use 3LP on one side. (You can’t use 3LP on both side because GGNFS will barf.) This is more beneficial with OPN numbers. Occasionally the time per rel will slightly decrease but generally one can get a 10-20% bump in yield with only a small penalty in time.

So I decided on a hybrid. Most of my 32-bit post-processing jobs take 2-4 weeks while the 31-bit jobs are around 5-8 days. Split the difference, 2-2.5 weeks??

As [B]Batalov[/B] once said, “try test sieving, you may be missing out on all the fun.”

C206 from the OPN t600 file.
Sieve on ALGEBRAIC side.
[CODE]n: 211729082358149184616654442570096012275452733025471882338226429873172324982177451616911629080660858615779105540909697308361957755666817267484570213046930959867537205284848983532914754295909575808877341405213321228096584089683
# 30027973^31-1, difficulty: 232
lss: 0
c6: 30027973
c0: -1
Y1: -1
Y0: 24413502119045705366054121155817391093
skew: 0.0567
type: snfs
rlim: 134000000
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 11749
60M 10345
100M 10445
150M 9273[/CODE]

[QUOTE=RichD;495869]
So I decided on a hybrid. Most of my 32-bit post-processing jobs take 2-4 weeks while the 31-bit jobs are around 5-8 days. Split the difference, 2-2.5 weeks??[/QUOTE]

I think this is a fallacy; LA time scales with input difficulty and barely changes by LP choice. If you take a typical 31LP job and run it as a 32LP job, the matrix will be less than 10% bigger, and can even be smaller. Your 32LP jobs have taken longer because they're much tougher inputs, not because they're 32LP. Half our 14e jobs would sieve faster 1LP bigger, without altering matrix sizes much. Alas, that requires more disk space, so perhaps the current choices are best for the project even though not optimally efficient.

Yield 3.0 sounds quite nice, not overkill! I'm almost certain yield under 2.0 is a sign to go up an LP, while 2.5 to 3.5 is a sign of good parameter selection. This hybrid ended up with yield around 1.0, so something got lost between test-sieve and queue.

[QUOTE=VBCurtis;495883]I think this is a fallacy; LA time scales with input difficulty and barely changes by LP choice. If you take a typical 31LP job and run it as a 32LP job, the matrix will be less than 10% bigger, and can even be smaller. Your 32LP jobs have taken longer because they're much tougher inputs, not because they're 32LP. Half our 14e jobs would sieve faster 1LP bigger, without altering matrix sizes much. Alas, that requires more disk space, so perhaps the current choices are best for the project even though not optimally efficient.

Yield 3.0 sounds quite nice, not overkill! I'm almost certain yield under 2.0 is a sign to go up an LP, while 2.5 to 3.5 is a sign of good parameter selection. This hybrid ended up with yield around 1.0, so something got lost between test-sieve and queue.[/QUOTE]

You are probably correct. My latest job, C208_129_112, built a 23.5M matrix at TD=140 with ETA less than 600 hours.
[CODE]commencing 2-way merge
reduce to 58897286 relation sets and 38285767 unique ideals
commencing full merge
memory use: 3432.8 MB
found 25400232 cycles, need 23563967
weight of 23563967 cycles is about 3299522725 (140.02/cycle)
distribution of cycle lengths:
1 relations: 2474232
2 relations: 1235095
3 relations: 1227937
4 relations: 1234334
5 relations: 1274818
6 relations: 1283572
7 relations: 1292890
8 relations: 1281564
9 relations: 1263155
10+ relations: 10996370
heaviest cycle: 27 relations
commencing cycle optimization
start with 221581438 relations
pruned 14657964 relations
. . .
matrix is 23557761 x 23557961 (12244.6 MB) with weight 3470184645 (147.30/col)
sparse part has weight 2950713788 (125.25/col)
matrix starts at (0, 0)
matrix is 23557761 x 23557961 (12244.6 MB) with weight 3470184645 (147.30/col)
sparse part has weight 2950713788 (125.25/col)
saving the first 48 matrix rows for later
matrix includes 64 packed rows
matrix is 23557713 x 23557961 (11720.7 MB) with weight 3025470142 (128.43/col)
sparse part has weight 2836938274 (120.42/col)
using block size 8192 and superblock size 589824 for processor cache size 6144 kB
commencing Lanczos iteration (4 threads)
memory use: 11228.2 MB
linear algebra at 0.0%, ETA 598h46m[/CODE]

I believe you suggested a yield of 2:1 with an end point of no greater than two times lim, which I thought I followed. My bad.

[QUOTE=RichD;495886]
I believe you suggested a yield of 2:1 with an end point of no greater than two times lim, which I thought I followed. My bad.[/QUOTE]

Well, that job turned out to run Q-range of 390M for 460M relations, which is a yield of less than 1.2. This is just the sort of job I'd run 33LP without a second thought; typically 70% more yield happens, which in this case would be ~2.0. At least you have enough relations to get TD140 to work!
I agree about trying pretty hard to not have to sieve above 2*lim, though I'm coming to question whether setting lim above 268M is a good idea for jobs that sieve to ~600M or so. Siever memory use and matrix difficulty seem to both jump quite a bit when changing a lim from 268M to ~400M.
I'm by no means sure this is correct, but I've been doing the following on both 14e and 15e queues:
If Q max projects to between 130M and 160M, I use 134/134M for lims.
If Q max projects to between 160M and 225M, I use 134/200 for lims (smaller lim on sieving side)
225-300 gets 200/268M (I test 134/268 also)
300-500 gets 268/268M (I may test 268/400)
500+ gets a *lot* of test-sieving and no firm plan, but 268/268 vs 268/400 vs 268/536 vs 400/400 are likely tests.

I'm downloading copies of the C228_23827_53, C215_46988659_29 and C179_374xx231_19 raw datasets, all 31-bit LPs 14e tasks. The process should finish by 15 minutes from now; then, the raw datasets can be erased from the server to reduce disk pressure.

There were some concerns earlier about the memory use of the 14e client which was surpassing the guidelines. I guess you can’t make all the people happy all the time. :smile:

One thing I did notice on the more traditional SNFS OPN jobs, where the exponent is above say 40-50 which means the size of the coefficient would only be 4 or 5 digits, one can cut the rlim is half and have no affect on the yield. This might save client memory footprint. And might also save 1-3% in timings.

For example:
[CODE]rlim: 67000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.6
alambda: 2.6[/CODE]
I suppose I should also look at pushing some of these to 30 or 31-bit jobs on 15e where larger memory usage is expected.

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. :-)

[QUOTE=RichD;496102]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. :-)[/QUOTE]

Try 32/64, and 32/92-64 (92 on the a side). I've found fastest performance (though not best yield) with mfba =3*lpba -4. 93 could be tested also.
I use a rule of thumb that going up an LP requires 70% more relations, so sec/rel should be approx. 1/1.7 the time of 31LP. If I try a hybrid 31/32, I aim for 30% more relations than I would have for the smaller LP size alone.
If you'd like me to do some test-sieving, I'll have time (and interest) Sunday. I'm interested to test-sieve one of these large-coeff SNFS candidates, so if you wish I'll tackle it then and post a writeup about test results.

I fixed both of my typos for C240_4603759_37_minus1, it's clear that I didn't even read back what I wrote...

With less than a third of the WUs returned at the time of this writing, the extrapolation code suggests 15M-98M for C162_785232_11446. That seems quite different from the previously suggested 15M-70M, is that natural ?

[QUOTE=debrouxl;496145]With less than a third of the WUs returned at the time of this writing, the extrapolation code suggests 15M-98M for C162_785232_11446. That seems quite different from the previously suggested 15M-70M, is that natural ?[/QUOTE]


Test sieving results (for 1000q ranges):
20M 2744
30M 1899
40M 2640
50M 2247
60M 2693
70M 1998
80M 1997

~ 2.3 rel per special-q in average



So, I expected at least 120M raw relations from 55Mq range (15M-70M). Don't know what is wrong, maybe some of the BOINC clients returns zero results or smth like this?

Getting caught up with my notes after a weekend of out of town company. It appears some wires got crossed with the job C240_4603759_37. I was explaining I couldn’t get a good set of parameters to use for a 31-bit job on 14e. I accidentally stumbled upon straight forward parameters for 15e, which I suggested. Then I thought someone was going to look into placing it on 14e as a higher bit job. No one could read my crypt message about the bad set of parameters I tried. Now I see the job is queued using the set that didn’t work very well at all. I am questioning whether we can get enough good relations to build a matrix with TD=120 or better using the bad set I had abandoned...

[QUOTE=RichD;496222]Getting caught up with my notes after a weekend of out of town company. It appears some wires got crossed with the job C240_4603759_37. I was explaining I couldn’t get a good set of parameters to use for a 31-bit job on 14e. I accidentally stumbled upon straight forward parameters for 15e, which I suggested. Then I thought someone was going to look into placing it on 14e as a higher bit job. No one could read my crypt message about the bad set of parameters I tried. Now I see the job is queued using the set that didn’t work very well at all. I am questioning whether we can get enough good relations to build a matrix with TD=120 or better using the bad set I had abandoned...[/QUOTE]

I confess I was a bit of a spectator for all this, but we may headed to a happy ending. The C240_4603759_37 sieving job seems to be holding up, with the estimated number of relations = 285M+ unless yield just falls off the table at high Q.

[QUOTE=swellman;496270]I confess I was a bit of a spectator for all this, but we may headed to a happy ending. The C240_4603759_37 sieving job seems to be holding up, with the estimated number of relations = 285M+ unless yield just falls off the table at high Q.[/QUOTE]

It does seem to be working out satisfactorily. Though not anywhere near optimal - but working. I was thinking 32-bit job when I looked at the accumulated relations with Q already at 400M. It should be fine.

My blunder was bigger by grabbing the wrong dataset and claiming the job was completed so all the data can be deleted. Which strike me a bit odd since there are several OPN datasets still in the directory from last April. Why would such a recent job be deleted so quickly??

Thanks for re-queueing a second copy.

[B]QUEUED AS C242_139_72
[/B]
C242_139_72 is ready for SNFS on 15e as a 31-bit job.
[code]
n: 49812362053064629725046788271819961121661892630136477608704147257280255201509988608805502207069017639692371737945719579827750684563019989923911425010255319944874671885435968709590306732416932774169217125964595170656048055165054576999943008867
# 139^72+72^139, difficulty: 260.58, anorm: 1.70e+037, rnorm: -1.06e+049
# scaled difficulty: 262.54, suggest sieving rational side
# size = 7.498e-013, alpha = 0.000, combined = 9.478e-014, rroots = 0
type: snfs
size: 260
skew: 1.0198
c6: 8
c0: 9
Y1: -10463510478998672094480749996152012350160896
Y0: 52020869037289085480011921
rlim: 134000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.7
alambda: 2.7
[/code]


Test sieving on the -r side with Q in blocks of 5K:
[code]
Q=40M 8954
Q=70M 7669
Q=120M 7023
Q=180M 5562
Q=250M 5050
[/code]
Suggesting a sieving range for Q of 40-230M with a goal of 240M relations.

[B]QUEUED AS C250_137_86[/B]

C250_137_86 is ready for SNFS on 15e.
[code]
n: 4882551164784256604186779948783602599048970696434654487886215653769921928202591397385975701221784264511324160458011717697125201644164505378282039798548809132479379484554962565368112446345390557569925508388404171272247142238595423180920120766222258903
# 137^86+86^137, difficulty: 266.96, anorm: 2.54e+039, rnorm: 9.47e+049
# scaled difficulty: 268.72, suggest sieving rational side
# size = 9.807e-014, alpha = 1.256, combined = 2.191e-014, rroots = 0
type: snfs
size: 266
skew: 10.8307
lss: 0
c6: 1
c0: 1614134
Y1: -820517673944445067756173565489
Y0: 311504538542350645715503145019022560519520256
rlim: 268000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.8
alambda: 2.8
[/code]


Test sieving on the [b]-a[/b] side with Q in blocks of 5K:
[code]
Q=40M 7406
Q=70M 7655
Q=120M 5790
Q=180M 5361
Q=250M 4683
Q=350M 5103
Q=450M 4492
[/code]
Suggesting that this Q range be expanded to run 30-460M to reach a target number of relations = 470M.

Sextics usually sieve better on the algebraic side, ie pass -a to the siever. I've run my script to check .polys against it and there's not much in it but the algebraic side should be better. Or you might want to sieve on both sides if the yield drops too much at higher special-Qs.

Chris

[B]QUEUED AS C221_73659281_29m1
[/B]

C221 from the MWRB file with OPN weight of 4129.
[ a.k.a. Phi_29(Phi_5(3541)/5/427001) ]
[CODE]n: 19158844603971388507581221118976089908628871020460215190214530130501056787301285658416765308797970461345035890827495457011414238965357319835361687150733934985985188072358804187765589233828833700538947707920393190325853309
# 73659281^29-1, difficulty: 236.02, skewness: 20.47, alpha: 0.00
# cost: 2.80247e+18, est. time: 1334.51 GHz days (not accurate yet!)
skew: 20.474
c6: 1
c0: -73659281
Y1: -1
Y0: 2168389904330821777632297211238586600401
type: snfs
rlim: 67000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 91
rlambda: 2.7
alambda: 3.6[/CODE]
Trial sieving 5K blocks.
[CODE] Q Yield
20M 11398
60M 8648
100M 7741
150M 6345
200M 6132[/CODE]