[QUOTE=RichD;451178]The 14e queue is behaving normally except for the last entry. Nothing is moving from Pending to Received. This has been going on for hours and hours. May be nothing.[/QUOTE]

No, it's not nothing. Thanks for pointing that out. The original request for this number included the polynomials/parameters, which I just copied into the form. Unfortunately it contained an errant line break in the middle of the "n:" line. Added anew.

[QUOTE=jyb;451174]Yes, apologies for mucking that up. I was never given any information about what constituted legal characters for the name.

As for the parameters, they're not great but as you've suggested I don't think that's the reason it's sieving slowly. The yield is within a tolerable range. It's just that there are very few work units being done. The status page has been showing alarmingly low numbers of pending units for a while, and I didn't have an explanation as to why. Now I do.

Can we get Greg to cancel outstanding work units, then re-insert the number with a new name? And if that happens, is there a way to carry over the relations that have already been found?[/QUOTE]

If Dmitry doesn't mind, I'd be inclined to download all the relations found so far, delete the job, do the rest of the sieving with my own resources, and run the linear algebra myself. Would that be OK?

It's ok with me. According to status page now about 96% of sieving were done.

14e candidate
 

C196_145_47 - survived full t55 by yoyo.

[code]
n: 1539638978922756670166928811628782239346356516505821625978040069660069049848080998194283427693933723544136963787753348060058257380159087715113685388408710955508626354533622263911689449038438482213
# 145^47+47^145, difficulty: 242.45, anorm: 2.90e+032, rnorm: 1.14e+054
# scaled difficulty: 246.05, suggest sieving rational side
# size = 6.363e-017, alpha = 0.000, combined = 1.774e-013, rroots = 1
type: snfs
size: 242
skew: 7.3206
c5: 1
c0: 21025
Y1: -28334269484119140625
Y0: 3096263264537031876137686856267255616967297523567
rlim: 134000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.7
alambda: 2.7
[/code]

[QUOTE=jyb;451183]No, it's not nothing. Thanks for pointing that out. The original request for this number included the polynomials/parameters, which I just copied into the form. Unfortunately it contained an errant line break in the middle of the "n:" line. Added anew.[/QUOTE]

I presume this is C222_125_92b. My cut/paste submittal but I have no idea how a random line break got into the mix. My fault for not noticing it. Apologies to all. Won't happen again.

14e candidate
 

C213_121_106 - survived 4K curves @B1=11e7 and 4K curves @B1=3e8.

[code]
n: 242203525663681892246786058737395625770451922074691383053760278389874986634479141176831595050748121453887679020782594441722484311032448030112575838772991966136007682217835911089128815053532392058505386628231019751
# 121^106+106^121, difficulty: 247.09, anorm: 2.27e+038, rnorm: 3.17e+046
# scaled difficulty: 248.44, suggest sieving rational side
# size = 1.726e-012, alpha = 0.000, combined = 1.828e-013, rroots = 0
type: snfs
size: 247
skew: 1.0223
c6: 106
c0: 121
Y1: -2810243684806424785061213903353404851
Y0: 32071354722128447318829929845779491454976
rlim: 134000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.7
alambda: 2.7
[/code]

AS 3408
 

AS3408-i1668 (15e siever)

[code]
n: 29460893303338144751360360097976743017149046981259832053501450854362438285630845458294329588136961317820466603439061784124252469966169391148524869909406500896547611862071404959591325864761463
# norm 1.222655e-18 alpha -8.479287 e 1.735e-14 rroots 3
skew: 17653518.44
c0: 826319531224681659341264214653314828053252960
c1: 26940857953335994224321141436849154800
c2: -22688220016211567990602767782164
c3: 15607687492217763886884
c4: 54690847245705303
c5: 1286485200
Y0: -1870545265872388890161243166679811449
Y1: 554791760382776548817
rlim: 450000000
alim: 450000000
lpbr: 33
lpba: 33
mfbr: 66
mfba: 66
rlambda: 3.0
alambda: 3.0
[/code]

Test sieving on the -a side for 10K range at various Q starting values were as follows:

Q_start yield
150M 2.17
300M 2.15
450M 1.81
600M 1.80

alim of 450M seems to work nicely, but perhaps it should be 500M. This factorization is outside my comfort zone.

14e queue stuck again, maybe smth wrong with the 19218301^31 - 1 poly?

[QUOTE=unconnected;451251]14e queue stuck again, maybe smth wrong with the 19218301^31 - 1 poly?[/QUOTE]

See post #874. The original C222_125_92 has been deleted from the queue, but its work units are still being handed out. Since they keep failing, they keep getting recycled back and handed out again. I've emailed Greg but haven't heard back yet; until he cancels those work units the queue will stay stuck.

I have collected the 842952:8053 relations and deleted the task; matrix size 22.26M at density=120, should be done by the end of the month.

[QUOTE=unconnected;451251]14e queue stuck again, maybe smth wrong with the 19218301^31 - 1 poly?[/QUOTE]

Bump. 14e is almost dry. Can someone kick the server?

[QUOTE=swellman;451325]Bump. 14e is almost dry. Can someone kick the server?[/QUOTE]

To the best of my knowledge, Greg is the only one who can do that. And he is apparently unavailable at the moment.

Looks like 14e is stuck again. (Not sending out new WUs.)

[QUOTE=RichD;451465]Looks like 14e is stuck again. (Not sending out new WUs.)[/QUOTE]

Still the same problem. Greg needs to cancel the bad work units.

[QUOTE=jyb;451475]Still the same problem. Greg needs to cancel the bad work units.[/QUOTE]

Sorry guys, I've decided to take an annual leave on this project but 20 mins ago I left an email to Greg which he has just replied so please wait until the end of this week to get this issue sorted out.

Workunits have been canceled. Hopefully that fixes it.

[QUOTE=swellman;451245]AS3408-i1668 (15e siever)

[code]
n: 29460893303338144751360360097976743017149046981259832053501450854362438285630845458294329588136961317820466603439061784124252469966169391148524869909406500896547611862071404959591325864761463
# norm 1.222655e-18 alpha -8.479287 e 1.735e-14 rroots 3
skew: 17653518.44
c0: 826319531224681659341264214653314828053252960
c1: 26940857953335994224321141436849154800
c2: -22688220016211567990602767782164
c3: 15607687492217763886884
c4: 54690847245705303
c5: 1286485200
Y0: -1870545265872388890161243166679811449
Y1: 554791760382776548817
rlim: 450000000
alim: 450000000
lpbr: 33
lpba: 33
mfbr: 66
mfba: 66
rlambda: 3.0
alambda: 3.0
[/code]

Test sieving on the -a side for 10K range at various Q starting values were as follows:

Q_start yield
150M 2.17
300M 2.15
450M 1.81
600M 1.80

alim of 450M seems to work nicely, but perhaps it should be 500M. This factorization is outside my comfort zone.[/QUOTE]

Bump.

[QUOTE=swellman;447972]Please withdraw the above candidates from 15e queue. Based on [url=http://www.mersenneforum.org/showpost.php?p=447876&postcount=1593]recent discussions[/url], I am going to run additional ECM on these numbers. Thanks.[/QUOTE]

Another one apparently missed is this [URL=http://www.mersenneforum.org/showthread.php?t=20024&page=784"]post[/URL]. Plus, one of the "n" numbers is wrong.

[QUOTE=RichD;451624]Another one apparently missed is this [URL=http://www.mersenneforum.org/showthread.php?t=20024&page=784"]post[/URL]. Plus, one of the "n" numbers is wrong.[/QUOTE]

I think your link is pointing to the wrong place. Which post are you talking about? And which "n"? I think it's all been fixed but let me know.

[QUOTE=swellman;451627]I think your link is pointing to the wrong place. Which post are you talking about? And which "n"? I think it's all been fixed but let me know.[/QUOTE]

The "n" in the 15e queue.

Edit: C187_141_61 to be exact. The "n" is a C237.

[QUOTE=RichD;451628]The "n" in the 15e queue.

Edit: C187_141_61 to be exact. The "n" is a C237.[/QUOTE]

Indeed, the n is the old incorrect value in the poly and ini files for C187_141_61 on 15e. It should be

[code]
5084489050566775179592003313348801937179533477099429174053297255387060223505309107949313623243535576335735180641443792678300621272851343104861268721864517835102764733898119986107069118573
[/code]

The matter was discussed [url=http://www.mersenneforum.org/showpost.php?p=450489&postcount=853]here[/url]. The correction was never implemented when it was enqueued.

Can a gatekeeper please make the correction for C187_141_61? Thanks.

This OPN is ready and comes from the [URL=http://www.lirmm.fr/~ochem/opn/t490.txt]t490[/URL] file.

63601^47-1 (C190) SNFS-231

C150
 

If a C150 isn't too small for 14e, please consider the following for HP2(4496) Index 308:
[CODE]n: 186268686335827877320004854432051878822128838126242537957264027670795037255662305248760790177888122105986774051056721859678174962268961805642675348313
c5: 4296600
c4: -2917007031510
c3: -4790076774663310507
c2: 1670064884437700063934274
c1: 554651519036985580252614263896
c0: 35031679686473547988714210631764400
Y1: 481307053823461
Y0: -33682396687270334451539720481
skew: 542112.99
rlim: 20800000
alim: 10399999
lpbr: 29
lpba: 29
mfbr: 58
mfba: 58
rlambda: 2.6
alambda: 2.6
[/CODE]

Everything after skew was set automatically based on the factmsieve.py choices.

better E score for c150
 

@wombatman
After CADO optimization:
[code]
Y0: -33682396661918448005496559228
Y1: 481307053823461
c0: 24457818467628788035786542630926349
c1: 386035412486131568983076678246
c2: 870862274534921302685050
c3: -5285460019326801427
c4: -1785432972510
c5: 4296600
skew: 484727.35042
# alpha -6.66, 5 real roots
# MurphyE=5.80851238e-12
[/code]

[QUOTE=wombatman;451760]If a C150 isn't too small for 14e, please consider the following for HP2(4496) Index 308:
[/QUOTE]

My personal opinion is that a C150 is too small for NFS@Home. That's firmly in the realm of numbers which can be factored by individuals on personal hardware. However, I don't have any desire to assert my own will on others in this matter, so can anybody provide a compelling contrary opinion?

A C150 is in the vicinity of 60 Ghz-days, under a week for a quad-core. If I had a vote, I'd set 158 as the bottom for GNFS.

[QUOTE=jyb;451903]My personal opinion is that a C150 is too small for NFS@Home. That's firmly in the realm of numbers which can be factored by individuals on personal hardware. However, I don't have any desire to assert my own will on others in this matter, so can anybody provide a compelling contrary opinion?[/QUOTE]

No worries. I figured I would ask and see what the bottom limit was. I'll go ahead and start it on personal hardware! Thanks for the consideration :smile:

C197_148_45 looks like a good 14e candidate and it has seen a full t55, but it's yield is not great unless 32-bit LP is used in sieving (or 31-bit and lots of patience). Otherwise it's an easy 15e/31 job. I'm not a fan of 14e/32 jobs but they are doable. I'll sign up to postprocess it regardless of siever used.

Otherwise the next unequivocal 14e candidate for the xyyx project is 2-3 weeks away.

The old "feed the grid or use it most efficiently" quandry.

(I'll have post the poly tomorrow. I don't have access to my files tonight.)

I have a few OPNs to keep the grid going. These are not as significant as others because they all come from the t800 file. Perhaps keep these on the back shelf and when one is needed, queue it right before the grid runs dry. Feel free to add other numbers before these when applicable. These are about SNFS-235 +/-.

P40.15461_7M.C186
1546180993982253931724756630608282852337^7-1
P40.12838_7M.C181
1283810768507270931382867729773882314783^7-1
P39.83661_7M.C179
836611965227956085219418549834729037351^7-1

C197_148_45
 

C197_148_45

[code]
n: 15329895267044302873891174984944617312806978355057983047383161451244893344826822099919196732930271476610619814172093285276608197494910298520152145552947810495264359766139916240459649381787095666477
# 148^45+45^148, difficulty: 249.38, anorm: 3.38e+040, rnorm: 1.19e+046
# scaled difficulty: 249.38, suggest sieving rational side
# size = 9.088e-013, alpha = 0.000, combined = 1.168e-013, rroots = 0
type: snfs
size: 249
skew: 4.58
c5: 1
c0: 2025
Y1: 34068690316840665088
Y0: -39479842665806602234295041487552225589752197265625
[/code]

[QUOTE=swellman;451955]C197_148_45

[code]
n: 15329895267044302873891174984944617312806978355057983047383161451244893344826822099919196732930271476610619814172093285276608197494910298520152145552947810495264359766139916240459649381787095666477
# 148^45+45^148, difficulty: 249.38, anorm: 3.38e+040, rnorm: 1.19e+046
# scaled difficulty: 249.38, suggest sieving rational side
# size = 9.088e-013, alpha = 0.000, combined = 1.168e-013, rroots = 0
type: snfs
size: 249
skew: 4.58
c5: 1
c0: 2025
Y1: 34068690316840665088
Y0: -39479842665806602234295041487552225589752197265625
[/code][/QUOTE]

I did some test sieving with this polynomial and with the (IMO) somewhat more obvious polynomial given by
[code]
c5: 1
c0: 375
Y1: 2631989511053773482286336099170148372650146484375
Y0: -34068690316840665088
[/code]

The latter turned out to sieve substantially better. In fact so much so that I think it actually works out better as a 31-bit job. Not a great yield, but it should do the job.

[QUOTE=jyb;452034]I did some test sieving with this polynomial and with the (IMO) somewhat more obvious polynomial given by
[code]
c5: 1
c0: 375
Y1: 2631989511053773482286336099170148372650146484375
Y0: -34068690316840665088
[/code]

The latter turned out to sieve substantially better. In fact so much so that I think it actually works out better as a 31-bit job. Not a great yield, but it should do the job.[/QUOTE]
Hmm... Yafu goof?

[QUOTE=Dubslow;452037]Hmm... Yafu goof?[/QUOTE]

Either Yafu or the goof using it!

[QUOTE=jyb;452034]I did some test sieving with this polynomial and with the (IMO) somewhat more obvious polynomial given by
[code]
c5: 1
c0: 375
Y1: 2631989511053773482286336099170148372650146484375
Y0: -34068690316840665088
[/code]

The latter turned out to sieve substantially better. In fact so much so that I think it actually works out better as a 31-bit job. Not a great yield, but it should do the job.[/QUOTE]

Glad you found a better poly for a proper 14e/31 job. Thanks for queuing it.

C160 from aliquot sequence 11040:

[CODE]n: 4409532288489507333192213562147876845858469211971052677426795037544285442856497325035968905612741429947472557253258960082522920912787534519079753213510746880477
skew: 9585821.81
c0: -1395226932920371783655399374640500722728
c1: 787057682706312479937484965784314
c2: 162253448848063731693547989
c3: -81843495325963337576
c4: -2399371743138
c5: 48060
Y0: -9829283146069545412959458697837
Y1: 212129417225543797
rlim: 60000000
alim: 60000000
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.6
alambda: 2.6
lss: 0[/CODE]

OPN from the Most Wanted Road Block [URL=http://www.lirmm.fr/~ochem/opn/mwrb2000.txt]file[/URL] is ready.

4018159^37-1 (C238) SNFS-245

C256 from XYYXF that has been ECM'd. Seems like a fit for 15e:

[CODE]n: 2279019635262178260223610372866161113233537351181247262995589386985378698045180235228538838348697209388279801210996958280092611824762735859504092308376304672536049578066139601245777058442691694530960357274040042752387753146406894539941430545737889457466479
# 127^121+121^127, difficulty: 266.60, anorm: 2.48e+38, rnorm: 5.33e+49
# scaled difficulty: 268.49, suggest sieving rational side
# size = 2.087e-13, alpha = 1.491, combined = 3.768e-14, rroots = 0
type: snfs
size: 266
skew: 1.0081
c6: 121
c0: 127
Y1: -1191446152405248657777607437681912764659201
Y0: 54763699237492901685126120802225273763666521
m: 1662494550986228882566228817664053580038096714821209997934679199277061987019250219666195095292608720990844899512073487570488175183098414434723678817318610879312388031432395464414980456036350664791631044752565052965047488994184947124894919850559221309624285
rlim: 79600000
alim: 79600000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.6
alambda: 2.6[/CODE]

Parameters chosen by YAFU and polynomial chosen as the best by trial sieving.

Shouldn't rlim/alim be higher than 80e6 for a 15e/32 job?

Seems like a/rlim=200M, a/rlambda=2.8 would be a bit better though it's ultimately the gatekeeper's call.

[QUOTE=VBCurtis;452355]Shouldn't rlim/alim be higher than 80e6 for a 15e/32 job?[/QUOTE]

[QUOTE=swellman;452361]Seems like a/rlim=200M, a/rlambda=2.8 would be a bit better though it's ultimately the gatekeeper's call.[/QUOTE]

I readily admit I have no idea what it should be and am going with YAFU's choices. If anybody can suggest some good rules of thumb, I'm all ears.:smile:

[QUOTE=wombatman;452363]I readily admit I have no idea what it should be and am going with YAFU's choices. If anybody can suggest some good rules of thumb, I'm all ears.:smile:[/QUOTE]

No worries - this composite is beyond what Yafu's original design parameters from years ago. The polynomial is what it is, but the sieving parameters often need a bit of tweaking.

11040:i10009 on 14e
 

Job entitled "11040:i10009" is next in the 14e queue. Is this name going to cause problems with Windows machines as discussed [url=http://www.mersenneforum.org/showthread.php?t=20024&page=80]earlier in posts 870-872 of this thread[/url]?

Another OPN from the [URL=http://www.lirmm.fr/~ochem/opn/t500.txt]t500[/URL] file.

17189128703^23-1 (C198) SNFS-246

[QUOTE=swellman;452443]Job entitled "11040:i10009" is next in the 14e queue. Is this name going to cause problems with Windows machines as discussed [URL="http://www.mersenneforum.org/showthread.php?t=20024&page=80"]earlier in posts 870-872 of this thread[/URL]?[/QUOTE]

Poly named correctly as C160_11040_10009.

[QUOTE=unconnected;452461]Poly named correctly as C160_11040_10009.[/QUOTE]

Ok I'll shut up now :-).

[QUOTE=unconnected;452461][QUOTE=swellman;452443]Job entitled "11040:i10009" is next in the 14e queue. Is this name going to cause problems with Windows machines as discussed [url=http://www.mersenneforum.org/showthread.php?t=20024&page=80]earlier in posts 870-872 of this thread[/url]?[/QUOTE]

Poly named correctly as C160_11040_10009.[/QUOTE]

Yeah, there's a distinction between the "Name" which functions as a unique ID for numbers in the queue (and is also used for the naming of work files), and "Display name" which is what actually shows up on the status page (in the column labeled "Name" of course).

It's the ID which can't have any questionable characters, since it's used for file names. As Dmitry said, the ID for this particular number, which is what appears when the server hands out work, is C160_11040_10009, so it should be fine.

[QUOTE=RichD;452458]Another OPN from the [URL=http://www.lirmm.fr/~ochem/opn/t500.txt]t500[/URL] file.

17189128703^23-1 (C198) SNFS-246[/QUOTE]

This one sieves really badly and pretty much just needs to be a 15e job.

Which means we're out of new 14e candidates and sieving the last one in the queue. Does anybody have any good ones?

I was afraid of that. How about the following from the same file?

1727870509^23-1 (C196) SNFS-222

[QUOTE=jyb;452543]This one sieves really badly and pretty much just needs to be a 15e job.

Which means we're out of new 14e candidates and sieving the last one in the queue. Does anybody have any good ones?[/QUOTE]
I've C162 from aliquot sequence 842592, running poly select for it now.

13*2^792-1:
[code]# 13*2^792-1 difficulty: 240
n: 66550801146937079103992492175872914857940591301476171283380617092315776829518809046492004774878541988107461118430923903657718756354189489215744823922285881259537614063082698043500928020281
m: 5444517870735015415413993718908291383296
type: snfs
skew: 1.53
c6: 13
c0: -1
rlim: 110000000
alim: 110000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.7
alambda: 2.7[/code]
ECM'ed to 2.4t50. With 32LP, target 340-350M rels; I'd like to do LA when ready.

Poly for C162 from aliquot sequence 842592.

[CODE]n: 868347356005122985615018760925237076252576211185291927037972365629369515625168105175451670164964539413087823848439528991318405466048138600755392043193731720352681
skew: 6434585.17
c0: -1286035186241687506780441717878407121546
c1: -1750691765895045653927709391211289
c2: -222403686364331708431746696
c3: 64178599865917602326
c4: -1846268782180
c5: 387600
Y0: -18623527690680223075484694980779
Y1: 244728030520968961
rlim: 60000000
alim: 60000000
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.6
alambda: 2.6
lss: 0[/CODE]

C 162 poly
 

@unconnected
CADO's pick, same E/c1/Y1. Sieve just in case, could be faster.
[code]
Y0: -18623527746589320560122137997073
Y1: 244728030520968961
c0: -898460662223698858536351049141010182020
c1: -1638931728746173173452044597687793
c2: -267013628851361541451559988
c3: 66068043027303817206
c4: -2289012634180
c5: 387600
skew: 6387179.13700
# MurphyE=1.03841053e-12
[/code]I will do a CADO run. Will be ready in the morning.

Two OPNs which are just a bit smaller than the previous p^17-1. Based on past experience, would these be considered for the 14e queue? Both from the [URL=http://www.lirmm.fr/~ochem/opn/t500.txt]t500[/URL] file.

5889307277311^17-1 (C196) SNFS-231
5968930061879^17-1 (C198) SNFS-231

poly for C162 from aliquot sequence 842592
 

@unconnected
CADO's pick
[code]
skew: 13445834.38785
c0: 7889973539432590338319757861480303163342
c1: -1386187955297181359306847776038029
c2: -272938635073788106929707332
c3: -5138801211526159081
c4: 3397060679100
c5: 67680
Y0: -34830257973490639281816833143030
Y1: 814873975693312880707
# lognorm 51.83, E 44.20, alpha -7.63 (proj -1.92), 3 real roots
# MurphyE=1.04745223e-12
[/code]

poly for C162 from aliquot sequence 842592
 

@unconnected
my tweak (different alpha)
[code]
Y0: -34831391682391928141535061490213
Y1: 814873975693312880707
c0: -88222397575805084992367746274955803520
c1: 353270482381529568223124483376434
c2: -213884622752669061727977775
c3: -22733668068860945881
c4: 2926255249500
c5: 67680
skew: 7693677.00957
# lognorm 50.45, E 43.70, alpha -6.74 (proj -1.92), 5 real roots
# MurphyE=1.05110104e-12
[/code]

poly for C162 from aliquot sequence 842592
 

@unconnected
Msieve's pick
[code]
R0: -34829958535825161138599124145275
R1: 814873975693312880707
A0: 7343550345674532950650471543876825778032
A1: -1588180026426821700115930241892464
A2: -275817800354664032231221327
A3: -54208941595153081
A4: 3521410835100
A5: 67680
skew 13348906.39, size 8.616e-016, alpha -7.597, combined = 1.048e-012[/code]

Max0526, thank you, but it's almost sieved with the old poly.
BTW, can you help with this C170?
[CODE]16155374118973955813091649522779062742170185143586034082882967704389689802848431254319353182125901255550801551714585711083348904636336944688336558457044065738232253533181[/CODE]

C170
 

@unconnected
I started a CADO run. Will post a base line poly tomorrow.

C170 base line poly
 

@unconnected
[code]
Y0: -481577775502292719691222533466215
Y1: 392211303392590918613
c0: 676967562821041360271590945010038194072
c1: -558415222231268297449660083358513
c2: -826058768396258624186120634
c3: 55554649634344546624
c4: 336759873568398
c5: 13097700
skew: 2622076.914
# lognorm 53.43, E 46.57, alpha -6.86 (proj -2.56), 3 real roots
# MurphyE(Bf=1.00e+07,Bg=5.00e+06,area=1.00e+16)=3.19e-13
[/code]

a better poly for C170
 

@unconnected
[code]
Y0: -356499010538523947157269092419110
Y1: 163775572678930471897
c0: -1419966496866041669939081375489923857981
c1: -549273100465567594192894754191774
c2: 430139899851675599574155400
c3: -396728027079635269034
c4: -15914193900339
c5: 8416800
skew: 5162933.640
# alpha -6.45, 3 real roots
# MurphyE=3.37e-13
[/code]

a poly for C170
 

@unconnected
[code]
Y0: -403920761452835638309562584753452
Y1: 139734402761902162972331
c0: 15704423812350540538584439783197718518
c1: 48287137381509733962200801315009
c2: 20057458849965438898060633
c3: -770495243261323908886
c4: -1219618934494020
c5: 1307662200
skew: 561981.62560
# alpha -7.21, 3 real roots
# MurphyE=3.21639857e-13
[/code]

a better poly for C170 (#2)
 

@unconnected
[code]
Y0: -344623661964797284651302945866525
Y1: 2092245837566369065883
c0: 11364326858502652614799619552973463104
c1: 185585567921498971874548054774742
c2: -434778363686352781085550351
c3: -264918417403388724737
c4: 16623616036032
c5: 39881520
skew: 1485775.61878
# lognorm 52.44, E 45.69, alpha -6.75 (proj -2.04), 3 real roots
# MurphyE=3.85192527e-13
[/code]

My best poly (cpu-selected):

[CODE]# norm 1.539532e-16 alpha -7.087319 e 3.239e-13 rroots 5
skew: 33518269.72
c0: 2289333875874569327497038535389419976873388
c1: 382077774062248187325136662799008916
c2: 4894543817187396719305221893
c3: -975365628950895601351
c4: 2294158842579
c5: 202860
Y0: -602870618958276747402796697188929
Y1: 470565207875800817
[/CODE]

Two OPNs from the [URL=http://www.lirmm.fr/~ochem/opn/t600.txt]t600[/URL] file.

2899469274619^19-1 (C172) SNFS-225
3740221981231^19-1 (C179) SNFS-227

Here is another 14e/32 candidate. Yoyo@home is just finishing up ECM to a full t55.

I will run the postprocessing once the sieving is complete. Thank you.

[code]
n: 283191072481051249914583228194650177905740292063875589919551516909659396832663031861991559472215415672107338058778319830834676384387536217135281552494362019768235081706813041110232151987119291978490269
# 137^62+62^137, difficulty: 247.35, anorm: 2.16e+039, rnorm: 5.24e+046
# scaled difficulty: 248.58, suggest sieving rational side
# size = 7.319e-013, alpha = 0.000, combined = 9.909e-014, rroots = 0
type: snfs
size: 247
skew: 10.2559
c6: 1
c0: 1163678
Y1: -2329194047563391944849
Y0: 167883826163764944817996215305490271305728
rlim: 200000000
alim: 200000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.8
alambda: 2.8
[/code]

C170 poly
 

@unconnected
CADO-NFS optimizes your poly quite a bit:
[code]
Y0: -602870617628107487170292489335813
Y1: 470565207875800817
c0: 405890601951855611817366374002328675248140
c1: 386640105807127966082616274304256764
c2: -3220985513457604782071787655
c3: -933216056338410174583
c4: 5161329338979
c5: 202860
skew: 35150350.24883
# lognorm 54.92, E 46.95, alpha -7.96 (proj -1.77), 5 real roots
# MurphyE=3.83902180e-13
[/code]Consider speed testing this one by actual sieving.

[QUOTE=RichD;453242]Two OPNs from the [URL=http://www.lirmm.fr/~ochem/opn/t600.txt]t600[/URL] file.

2899469274619^19-1 (C172) SNFS-225
3740221981231^19-1 (C179) SNFS-227[/QUOTE]

Never mind.
I mis-calculated the difficulty. They should be:
SNFS-237
SNFS-239
Which might be better suited for 15e.

But I do have another within range.

327668647153^19-1 (C172) SNFS-219

Best poly for c170 (other parameters suggested by yafu, I've increased alim/rlim a bit):
[CODE]n: 16155374118973955813091649522779062742170185143586034082882967704389689802848431254319353182125901255550801551714585711083348904636336944688336558457044065738232253533181
Y0: -602870617628107487170292489335813
Y1: 470565207875800817
c0: 405890601951855611817366374002328675248140
c1: 386640105807127966082616274304256764
c2: -3220985513457604782071787655
c3: -933216056338410174583
c4: 5161329338979
c5: 202860
skew: 35150350.24883
# lognorm 54.92, E 46.95, alpha -7.96 (proj -1.77), 5 real roots
# MurphyE=3.83902180e-13

rlim: 80000000
alim: 80000000
mfbr: 62
mfba: 62
lpbr: 31
lpba: 31
rlambda: 2.60
alambda: 2.60
lss: 0
[/CODE]

I am back from vacation, is there anything that needs pushing to the queues? I see that 15e is getting a bit short ...

The following posts in this thread contain candidates which have yet to be enqueued

941
940
938
920
910
880
853


There may be others I missed.

I would like to propose the C171 from Aliquot sequence 829332:3638.

Max0526 came up with a number of polys using CADO (see the Polynomial Request Thread, thanks Max!) and the best sieving (0.30 seconds per relation per thread on my i7) was:

[CODE]Y0: -691735415860028161291242601067023
Y1: 25898420289952162105307
c0: 577300829383670786734653724089000359155200
c1: -45090526843823845959056529260126600
c2: -6637850955461852556600436653
c3: 111155248878476001023
c4: 42917566535268
c5: 5418720
skew: 12640532.26887
# MurphyE=3.05653198e-13[/CODE]

I found the following poly using msieve by CPU and it sieves much worse (0.60 seconds per relation per thread):

[CODE]# norm 1.433572e-016 alpha -8.545613 e 3.128e-013 rroots 5
n: 143078471890001396404975722954703592875148935188191068938072316014184174902812459038968421963880118593068060667758149846867638636307227896395788079777289956829055499772249
skew: 718798201.99
c0: -20927250992693086458259129496993713626586796400
c1: 23809337639420727499940642755002298868
c2: 325528092819547637374452732948
c3: -141143903779127307669
c4: -826446704440
c5: 84
Y0: -4428524236781113000924987068997327
Y1: 126683988140215801[/CODE]

I am unsure why the msieve poly sieves so badly compared with the CADO when the MurphyE scores are similar. I am also unsure whether this would be better handled by 14e or 15e. Thanks in advance for considering this number.

[QUOTE=swellman;453462]The following posts in this thread contain candidates which have yet to be enqueued

941
940
938
920
910
880
853


There may be others I missed.[/QUOTE]

853 (C187_141_61) pushed to 15e

880 not pushed - I'm really not happy with three-large-primes-both-sides, for that large a number I would definitely recommend 16e.

910 (C256_127_121) pushed to 15e

938 (C201_137_62) pushed for 14e

941 (a11040:10011) pushed for 14e

I appreciate I have been lazy and only pushed things where there was a code block with the explicit polynomial in ... I have run trivial trial sieving to check I was using the right siever and to get the range about right.

[QUOTE=richs;453484]I would like to propose the C171 from Aliquot sequence 829332:3638[/quote]

Thanks, I'm looking into it. For future advice, it would be useful to post the whole gnfs file (with lpbr and alim values) as well as the range sieved and yield obtained, along with time-per-relation figures, so I can just copy-and-paste the polynomial into the Web interface rather than having to repeat some of the trial sieving myself.

[quote]
I am unsure why the msieve poly sieves so badly compared with the CADO when the MurphyE scores are similar. I am also unsure whether this would be better handled by 14e or 15e. Thanks in advance for considering this number.[/QUOTE]

I think it's a 14e number, the yield-per-Q was something like 7 with 15e which feels a bit big. But I forgot to check the result from the 14e run before going home; I'll finish up in the morning.

This is more a matter of anecdotal observation than science, but I've found that very large skews (and yours is over 2^29) do tend to lead to rather slow sieving.

Tom, thank you for the advice.

[QUOTE=fivemack;453538]

880 not pushed - I'm really not happy with three-large-primes-both-sides, for that large a number I would definitely recommend 16e.

[/QUOTE]

Not sure I understand your comment - we have factored C191 on 15e via GNFS before have we not? Or is the polynomial or the parameters causing problems? I'm not questioning your decision here, just trying to understand the limits of 15e so I don't exceed them. Post 880 is reposted below for viewing convenience.


[quote]
[code]
n: 29460893303338144751360360097976743017149046981259832053501450854362438285630845458294329588136961317820466603439061784124252469966169391148524869909406500896547611862071404959591325864761463
# norm 1.222655e-18 alpha -8.479287 e 1.735e-14 rroots 3
skew: 17653518.44
c0: 826319531224681659341264214653314828053252960
c1: 26940857953335994224321141436849154800
c2: -22688220016211567990602767782164
c3: 15607687492217763886884
c4: 54690847245705303
c5: 1286485200
Y0: -1870545265872388890161243166679811449
Y1: 554791760382776548817
rlim: 450000000
alim: 450000000
lpbr: 33
lpba: 33
mfbr: 66
mfba: 66
rlambda: 3.0
alambda: 3.0
[/code]

Test sieving on the -a side for 10K range at various Q starting values were as follows:

Q_start yield
150M 2.17
300M 2.15
450M 1.81
600M 1.80

alim of 450M seems to work nicely, but perhaps it should be 500M. This factorization is outside my comfort zone.
[/quote]

I have pushed C171_829332_3638 to 14e rather than 15e, despite

[code]
> ../gnfs-lasieve4I15e -a C171_829332_3638.gnfs -f 268000000 -c 1000
total yield: 7103, q=268001011 (0.12773 sec/rel)
> ../gnfs-lasieve4I14e -a C171_829332_3638.gnfs -f 268000001 -c 999
total yield: 3104, q=268001011 (0.19458 sec/rel)
[/code]

because the 14e queue was getting quite empty.

[QUOTE=swellman;453593]Not sure I understand your comment - we have factored C191 on 15e via GNFS before have we not? Or is the polynomial or the parameters causing problems? I'm not questioning your decision here, just trying to understand the limits of 15e so I don't exceed them. Post 880 is reposted below for viewing convenience.[/QUOTE]

I made a mistake, sorry; I saw that you had rlambda=alambda=3.0 and thought that this meant you were trying for three large primes on both sides, which in my experience causes moderately higher yields at the price of vastly longer sieving times. But since you didn't have alim or rlim equal to 96, this isn't what you were doing.

Had you in fact considered and rejected using 32-bit large primes with three on one side?

(Maybe I'm being a bit critical recently; I trust the participants on this bit of the forum to tell me if I am in danger of turning into RDS)

[QUOTE=fivemack;453632]I made a mistake, sorry; I saw that you had rlambda=alambda=3.0 and thought that this meant you were trying for three large primes on both sides, which in my experience causes moderately higher yields at the price of vastly longer sieving times. But since you didn't have alim or rlim equal to 96, this isn't what you were doing.

Had you in fact considered and rejected using 32-bit large primes with three on one side?

(Maybe I'm being a bit critical recently; I trust the participants on this bit of the forum to tell me if I am in danger of turning into RDS)[/QUOTE]

No worries, I was just confused on the 3 LP comment. No, I have not played with 3 on one side - not sure how best to do that. Assuming we want to sieve this polynomial on the -a side, would we make lpba=32 and mfba=96? Or do we make the rational side 32/96?

Or I could test sieve it and learn something in the process...nah that sounds hard.:whistle:

[QUOTE=swellman;453635]No worries, I was just confused on the 3 LP comment. No, I have not played with 3 on one side - not sure how best to do that. Assuming we want to sieve this polynomial on the -a side, would we make lpba=32 and mfba=96? Or do we make the rational side 32/96?

Or I could test sieve it and learn something in the process...nah that sounds hard.:whistle:[/QUOTE]

I think you probably do have to test-sieve: I got, where '32A' means 3 primes on algebraic side, 2 on rational side, sieve on algebraic side, so
[code]
lpbr: 32
lpba: 32
mfbr: 64
mfba: 96
rlambda: 2.6
alambda: 3.6

../gnfs-lasieve4I15e -a C191_3408_1668_a3r2 -f 450000000 -c 1000 2> 32A.t
[/code]

[code]
22A.t total yield: 830, q=450001043 (1.15306 sec/rel)
22R.t total yield: 510, q=450001043 (2.17775 sec/rel)
23A.t total yield: 869, q=450001043 (1.22087 sec/rel)
23R.t total yield: 513, q=450001043 (2.08862 sec/rel)
32A.t total yield: 991, q=450001043 (1.16914 sec/rel)
32R.t total yield: 659, q=450001043 (1.90247 sec/rel)
[/code]

So you really want to sieve on the algebraic side, three algebraic-side primes gets somewhat better yield than three rational-side primes, and the time per relation is basically a wash between 3A2R and 2A2R. I've queued up with three algebraic-side primes and run 50M to 500M. The linear algebra will be a bit of a bear, but I have reasonable bear-hunting equipment.

Thank you for the analysis and explanation. I think I now understand how to approach 3LP sieving. (When to consider it is another question for another day.)

And thanks for adding it to the 15e queue.

Which poly did you end up using for C171_829332_3638?

[QUOTE=richs;453662]Which poly did you end up using for C171_829332_3638?[/QUOTE]

This one:
[CODE]
N 143078471890001396404975722954703592875148935188191068938072316014184174902812459038968421963880118593068060667758149846867638636307227896395788079777289956829055499772249
SKEW 12640532.26887
A0 577300829383670786734653724089000359155200
A1 -45090526843823845959056529260126600
A2 -6637850955461852556600436653
A3 111155248878476001023
A4 42917566535268
A5 5418720
R0 -691735415860028161291242601067023
R1 25898420289952162105307
SRLPMAX 4294967296
SALPMAX 4294967296
FAMAX 268000000
FRMAX 268000000
[/CODE]

Two more for 14e
 

Both are finishing t55 courtesy of yoyo@home.

C201_142_80
[code]
n: 120995239996089669083457692866260337688533647337487351938695070105850965556070387470375584471251348523080226151866932692127422627517183789564535374387267346411032355957325431945088067023994808350857161
# 142^80+80^142, difficulty: 248.76, anorm: 1.42e+039, rnorm: 6.08e+046
# scaled difficulty: 250.03, suggest sieving rational side
# size = 8.704e-013, alpha = 0.000, combined = 1.119e-013, rroots = 0
type: snfs
size: 248
skew: 2.8854
c5: 1
c0: 200
Y1: 5902958103587056517120000000000000000000000000000
Y0: -416997623116370028124580469121
rlim: 134000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.7
alambda: 2.7
[/code]



C202_131_69
[code]
n: 9524599816149157292230178818340396418821256941113740648632660387897518147510730794519251713695587871282984830937364114961224882066422395348373955394386577670494244130032985516715160838388710839910210113
# 131^69+69^131, difficulty: 244.64, anorm: 2.24e+041, rnorm: 3.42e+045
# scaled difficulty: 244.64, suggest sieving algebraic side
# size = 1.134e-012, alpha = 0.000, combined = 1.377e-013, rroots = 0
type: snfs
size: 244
skew: 6.183
c5: 1
c0: 9039
Y1: 645767760190718297889184705014020888804383290681
Y0: -438326915318176225182722457721
rlim: 134000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.7
alambda: 2.7
[/code]

Out of town for 1.5 weeks and everything is caught up!

Using the previous p^19-1 as a template we now have from the [URL=http://www.lirmm.fr/~ochem/opn/t600.txt]t600[/URL] file.
[CODE]n: 5388792835728955147464475071441990735548637250874361350066071879413146964544778832432006808552504514052955962054124335878565007804542802788136376070261154961282201213602489
# 327668647153^19-1 (C172) sieve on algebraic side
lss: 0
skew: 0.012
c6: 327668647153
c0: -1
Y1: -1
Y0: 35180715207538134081393278607450577
rlim: 67000000
alim: 67000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.6
alambda: 2.6[/CODE]

One from the [URL=http://www.lirmm.fr/~ochem/opn/mwrb2000.txt]MWRB[/URL] file.

I'm thinking the Q range should start at 30M or 40M. Just a gut feeling, that's all.

[CODE]n: 693600495620935044655572338270450912117135156197930737067718301354409059255468327401347660629284692518391806089043166967359482513959259888085463917104219530606223322081099474123328596663456811745119411874440079612136714076356517913646921
# 12119^59-1, difficulty: 245.01, skewness: 6.56, alpha: 0.00
# cost: 5.65896e+18, est. time: 2694.74 GHz days (not accurate yet!)
skew: 6.557
c5: 1
c0: -12119
Y1: -1
Y0: 10036942258067831000140923370714018568247151524961
rlim: 134000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.6
alambda: 2.6[/CODE]

Two more from OPN.

[CODE]n: 2004096237006367194767912604936151800191765426316533675282708772484381456984954672759170965799448196354214262159090537588342698416486611267189718320102116485634246725127423560771834949074751593142307814879
# 190101462739418057644741^11-1, difficulty: 232.79, skewness: 1.00, alpha: 2.22
# cost: 2.16925e+18, est. time: 1032.98 GHz days (not accurate yet!)
skew: 1.000
c5: 1
c4: 1
c3: -4
c2: -3
c1: 3
c0: 1
Y1: -190101462739418057644741
Y0: 36138566135666352121670145393805524392164957082
m: 836560160348267662872018125573685043135579153645370278444740772188408633259945407884888892778892206838780389633691977147436700257400027977676868937327678338414375810139044122902975249563976910035860232841
rlim: 67000000
alim: 67000000
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.6
alambda: 2.6[/CODE]

[CODE]n: 136269621321667259521519009150906975040454349830241012545831912816679642031264955010900165188470610369491470024405232450473087790903057879701187762505317300571959972132665442804629366089800287645014517953169
# 103487890442126237477849^11-1, difficulty: 230.15, skewness: 1.00, alpha: 2.22
# cost: 1.75626e+18, est. time: 836.31 GHz days (not accurate yet!)
skew: 1.000
c5: 1
c4: 1
c3: -4
c2: -3
c1: 3
c0: 1
Y1: -103487890442126237477849
Y0: 10709743468161523055918639363539329676765666802
m: 1233326266953286757261854821664829368770307248110687334236443342134924012458729771310316470116698586232772928748565145889993249045071796440516564231418011559940039255024927189922135678554266029995585820289
rlim: 67000000
alim: 67000000
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.6
alambda: 2.6[/CODE]

I have many ready but I don't know what the grid is looking for. I mostly focus on 14e since 15e seems to have plenty. Don't want to hog the 14e queue.

No tasks are available on 14e at the moment.

If 14e needs some, here's a few repunit ones:

SNFS-231
[CODE]n: 989999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
m: 100000000000000000000000000000000000000
deg: 6
c6: 990
c0: -1
skew: 0.32
# Murphy_E = 8.174e-13
type: snfs
lss: 1
rlim: 50000000
alim: 50000000
lpbr: 30
lpba: 30
mfbr: 59
mfba: 59
rlambda: 2.7
alambda: 2.7[/CODE]

SNFS-239
[CODE]n: 50000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000009
m: 5000000000000000000000000000000000000000
deg: 6
c6: 16
c0: 45
skew: 1.19
# Murphy_E = 4.872e-13
type: snfs
lss: 1
rlim: 68000000
alim: 68000000
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.7
alambda: 2.7[/CODE]

SNFS-251
[CODE]n: 5111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111119
m: 100000000000000000000000000000000000000000
deg: 6
c6: 46000
c0: 71
skew: 0.34
# Murphy_E = 1.398e-13
type: snfs
lss: 1
rlim: 105000000
alim: 105000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.8
alambda: 2.8[/CODE]

C202_131_69 queued on 15e

C201_142_80 queued on 14e
C172_327668647153_19 queued on 14e
C204_19...41_11 queued on 14e

C237_12119_59 queued on 14e (it's marginally a 15e job, but the 14e queue was emptier)
51119_250 queued on 14e (same applies)

Just an observation
 

[QUOTE=fivemack;454482]51119_250 queued on 14e (same applies)[/QUOTE]

The poly file for C250_51119 contains both "lss: 0" and "type: snfs" which appears to be contradictory. With the relatively smaller coefficients I would think the sieving would still be on the rational side. Maybe not. Just pointing out a possible abnormally.

Typo: C237_12119_59 should be an SNFS(245) - not 254.

I would like to post process C171_829332_3638 (VBCurtis offered to help me as needed).

Whom do I contact to get access to download the relations once the sieving is complete?

Thanks!

Send a PM to Greg (a.k.a. [B]frmky[/B]) saying you would like to have access to the data for post-processing. He just wants to know who has access.

Any of the regulars in this thread would also help out with questions you might have.

[QUOTE=RichD;454493]The poly file for C250_51119 contains both "lss: 0" and "type: snfs" which appears to be contradictory. With the relatively smaller coefficients I would think the sieving would still be on the rational side. Maybe not. Just pointing out a possible abnormally.

Typo: C237_12119_59 should be an SNFS(245) - not 254.[/QUOTE]

For C250_51119, I did test sieving on both sides and algebraic-side was marginally quicker.

I've fixed the typo; thank you.

[QUOTE=fivemack;454560]For C250_51119, I did test sieving on both sides and algebraic-side was marginally quicker.[/QUOTE]

I review most of these larger jobs as a learning experience. It seems this one would be another potential job for performing part of the sieving on each side but that mechanism is not in place today. :)

14e candidate
 

C203_131_73 - yoyo@Home is just finishing a full t55.

[code]
n: 10810882227815897520984008281274970585668545861189462625432143079805837456519441408931413980657918097312275479438062773211429470957046085353281163688980543941783309986057785956044878431384836332173566873
# 131^73+73^131, difficulty: 245.96, anorm: 1.96e+038, rnorm: 4.59e+046
# scaled difficulty: 247.35, suggest sieving rational side
# size = 1.619e-012, alpha = 0.000, combined = 1.741e-013, rroots = 0
type: snfs
size: 245
skew: 4.6072
c6: 1
c0: 9563
Y1: -25542038069936263923006961
Y0: 98424433237708439716398638596388483974129
rlim: 134000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.7
alambda: 2.7
[/code]

Queued to 14e:

C203_131_73
50009_239
98999_231

I hope we have plenty of post-processing firepower lined up

14e candidate
 

C198_144_122 has completed ECM to t55 courtesy of yoyo@Home, plus I ran a bit more @B1=3e8.

Suggest feeding it to the ever hungry 14e queue, but I will be happy to run the postprocessing regardless of where it's enqueued. Thank you.


[code]
n: 476788411789049981477769193279961082326181657067203278178923212550262738069128275146962918080786805082335128104517077158010385401609297918404550279321293302215813718327214032050105521014849992120289
# 144^122+122^144, difficulty: 257.09, anorm: 3.60e+037, rnorm: 4.35e+048
# scaled difficulty: 258.93, suggest sieving rational side
# size = 1.141e-012, alpha = 0.000, combined = 1.288e-013, rroots = 0
type: snfs
size: 257
skew: 2.6207
c6: 1
c0: 324
Y1: -1752104244195325911739773219841769472
Y0: 7045568477354647704120453346932251277539041
rlim: 250000000
alim: 250000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.8
alambda: 2.8
[/code]