mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Aliquot Sequences (https://www.mersenneforum.org/forumdisplay.php?f=90)
-   -   Reserved for MF - Sequence 4788 (https://www.mersenneforum.org/showthread.php?t=11615)

ryanp 2020-11-24 12:59

[CODE]Tue Nov 24 03:35:26 2020 Msieve v. 1.54 (SVN 1030M)
Tue Nov 24 03:35:26 2020 GMP: 6.2.0
Tue Nov 24 03:35:26 2020 random seeds: 7710824f eb6453fb
Tue Nov 24 03:35:26 2020 factoring 125759133460127328613982496656975915643959142551262651270285396027807855006946517223326420972620599474305232427157867109244719422339711835950916082597366895792340601 (165 digits)
Tue Nov 24 03:35:27 2020 no P-1/P+1/ECM available, skipping
Tue Nov 24 03:35:27 2020 commencing number field sieve (165-digit input)
Tue Nov 24 03:35:27 2020 R0: -38123316106011771648286063984900
Tue Nov 24 03:35:27 2020 R1: 79701186361581922693
Tue Nov 24 03:35:27 2020 A0: -25435869054161853863641972030250491872
Tue Nov 24 03:35:27 2020 A1: 12614312849763439576317967549433
Tue Nov 24 03:35:27 2020 A2: 271717740453730429181093774
Tue Nov 24 03:35:27 2020 A3: -10326034577621223843
Tue Nov 24 03:35:27 2020 A4: -40337103848532
Tue Nov 24 03:35:27 2020 A5: 6246720
Tue Nov 24 03:35:27 2020 skew 1.00, size 5.323e-16, alpha -6.634, combined = 8.154e-15 rroots = 5
Tue Nov 24 03:35:27 2020
Tue Nov 24 03:35:27 2020 commencing linear algebra
Tue Nov 24 03:35:28 2020 read 8719485 cycles
Tue Nov 24 03:35:41 2020 cycles contain 26419119 unique relations
Tue Nov 24 03:36:57 2020 read 26419119 relations
Tue Nov 24 03:37:28 2020 using 20 quadratic characters above 4294917295
Tue Nov 24 03:39:26 2020 building initial matrix
Tue Nov 24 03:44:26 2020 memory use: 3659.9 MB
Tue Nov 24 03:44:31 2020 read 8719485 cycles
Tue Nov 24 03:44:32 2020 matrix is 8705896 x 8719485 (3992.3 MB) with weight 1217318554 (139.61/col)
Tue Nov 24 03:44:32 2020 sparse part has weight 941913349 (108.02/col)
Tue Nov 24 03:47:19 2020 filtering completed in 3 passes
Tue Nov 24 03:47:21 2020 matrix is 8591123 x 8591322 (3948.9 MB) with weight 1203466406 (140.08/col)
Tue Nov 24 03:47:21 2020 sparse part has weight 932094316 (108.49/col)
Tue Nov 24 03:47:39 2020 matrix starts at (0, 0)
Tue Nov 24 03:47:40 2020 matrix is 8591123 x 8591322 (3948.9 MB) with weight 1203466406 (140.08/col)
Tue Nov 24 03:47:40 2020 sparse part has weight 932094316 (108.49/col)
Tue Nov 24 03:47:40 2020 saving the first 240 matrix rows for later
Tue Nov 24 03:47:42 2020 matrix includes 256 packed rows
Tue Nov 24 03:47:44 2020 matrix is 8590883 x 8591322 (3577.6 MB) with weight 853232221 (99.31/col)
Tue Nov 24 03:47:44 2020 sparse part has weight 800377649 (93.16/col)
Tue Nov 24 03:47:44 2020 using block size 8192 and superblock size 608256 for processor cache size 25344 kB
Tue Nov 24 03:48:02 2020 commencing Lanczos iteration (64 threads)
Tue Nov 24 03:48:02 2020 memory use: 4950.6 MB
Tue Nov 24 03:48:08 2020 linear algebra at 0.0%, ETA 6h13m
Tue Nov 24 03:48:10 2020 checkpointing every 1230000 dimensions[/CODE]

ryanp 2020-11-24 18:01

Sigh, got the dreaded:

[CODE]Tue Nov 24 03:48:08 2020 linear algebra at 0.0%, ETA 6h13m
Tue Nov 24 03:48:10 2020 checkpointing every 1230000 dimensions
Tue Nov 24 09:46:11 2020 lanczos halted after 33659 iterations (dim = 8590774)
Tue Nov 24 09:46:52 2020 lanczos error: only trivial dependencies found[/CODE]

Will retry with slightly fewer relations.

RichD 2020-12-27 14:15

C173 @ i12568
 
Now sitting with a C173.

swellman 2020-12-27 14:40

Anybody running ECM on this? If not I’ll take it (or help out as circumstances dictate).

charybdis 2020-12-27 14:49

I can throw some curves at it once I'm done with t55 on 3366:i2226. Would be happy to do GNFS if needed too.

EdH 2020-12-27 17:18

I just freed up my ECM cluster. If you give me some values (curves, B1), I can run some ECM for a while today, before I move to other things.

VBCurtis 2020-12-27 17:31

I'd go for curves at B1=15e7. Say, 5000 curves or so?

0.31 * 173 = 53.6; rounding down because CADO is faster than the ggnfs used when this rule-of-thumb was made, half a T55 is called for.

EdH 2020-12-27 17:54

[QUOTE=VBCurtis;567461]I'd go for curves at B1=15e7. Say, 5000 curves or so?

0.31 * 173 = 53.6; rounding down because CADO is faster than the ggnfs used when this rule-of-thumb was made, half a T55 is called for.[/QUOTE]
I've got 2520 curves running on my cluster and for fun, I'm trying to run another 2560 on a Colab GPU session. We'll see if anything makes its way out of the Colab session before it closes.

swellman 2020-12-27 18:28

[QUOTE=charybdis;567448]I can throw some curves at it once I'm done with t55 on 3366:i2226. Would be happy to do GNFS if needed too.[/QUOTE]

Sorry, I went out for awhile this morning after starting ECM and just got back to my machine. Currently running ECM at the t40 level. It should be finished in a few minutes, at which point I’ll bow out.

@charybdis and Ed can negotiate higher ECM between them, noting charybdis was the first to volunteer to take on GNFS (if required).

EdH 2020-12-27 18:54

[QUOTE=swellman;567469]Sorry, I went out for awhile this morning after starting ECM and just got back to my machine. Currently running ECM at the t40 level. It should be finished in a few minutes, at which point I’ll bow out.

@charybdis and Ed can negotiate higher ECM between them, noting charybdis was the first to volunteer to take on GNFS (if required).[/QUOTE]
I just realized that in my haste to get some ECM underway, I forgot that half of my cluster falls asleep at night. I'll have to see how many curves actually get done before the crash.

charybdis 2020-12-27 21:56

Running curves at 15e7 now.

EdH 2020-12-27 23:04

Well, I'm sorry to report that after trying all day, I can't get my cluster to keep from crashing. I'm guessing it's due to memory limits on some of the machines. Different ones fail for different runs and I don't get meaningful error messages. The Colab session is still running, but it hasn't finished stage 1, so I think it will fail before it finishes stage 2. I don't think residues are saved without actuallY adding the -save option, so I think the entire day has been a "bust" for me ECM-wise!

Edit: The Colab session closed without any success, as well. Maybe I'll try it again tomorrow, just to see what it will do. If I do run it tomorrow, I'll try to make sure I can at least capture a save file to run stage two elsewhere. As for my ECM local efforts, even my 48G machine tied itself up and didn't even straighten out for about fifteen minutes after shutting down ecmpi.:sad:

charybdis 2020-12-28 12:17

GNFS underway on the c173.

charybdis 2021-01-02 13:15

Next line has a c159, running GNFS now.

charybdis 2021-01-03 20:37

i12574
 
Now on a c189.
I've run just under half a t50 so far, so if anyone wants to run ECM it would be best to start at the 55-digit level or higher.

charybdis 2021-01-05 19:58

t55 + just over half t60 complete on the c189.

Is there any interest in getting GNFS done? If so, I'll run some CADO polyselect.

VBCurtis 2021-01-05 20:30

Sure!
I'm happy to set it up on my public-facing workstation for a team-CADO job, or we can send it to nfs@home (likely to the 15e queue, it's on the edge of 15e and 16e for GGNFS).

WIth 20 cores, that would take me a couple months without help- so I would use nfs@home if nobody else has interest in sieving.

charybdis 2021-01-05 21:22

I'm happy to leave this one to NFS@home unless there's more interest in a quick team-sieve.

We need a polynomial in any case, so I'm starting a CADO run with P=4M, admax=10M, incr=420. Help is welcome, especially from the GPU folks.

swellman 2021-01-06 01:10

[QUOTE=charybdis;568522]I'm happy to leave this one to NFS@home unless there's more interest in a quick team-sieve.

We need a polynomial in any case, so I'm starting a CADO run with P=4M, admax=10M, incr=420. Help is welcome, especially from the GPU folks.[/QUOTE]

Agreed - let NFS@Home take this sieving job using 15e.

I’m poly searching now using msieve-GPU for a baseline c5 < 1M. Msieve suggests a minimum e-score of 2.27e-14, with an objective e-score > 2.61e-14. The [URL="https://www.mersenneforum.org/showpost.php?p=539610&postcount=161"]record scores found to date[/URL] by MF.org for c189 and c190 are 2.468e-14 and 2.261e-14 respectively.

charybdis 2021-01-06 14:51

Nothing exceptional from CADO, but here are the top 5:

[code]skew: 31667446.08
c0: 635181421872748933108441699486115427125642808
c1: -74986650995391412139123003935796048006
c2: -5961875349757286664581459912419
c3: 124033538748440778455637
c4: 2080272602219742
c5: 18680760
Y0: -2235516949149518804069555918947048165
Y1: 851083597789145288034881
# e 2.335e-14

skew: 6738890.865
c0: 3008176798371571134141560458229782623007552
c1: -226612821899130689881043620942034881
c2: -733488110170332116047824761794
c3: 22864302063104231750729
c4: 8149403279819074
c5: 122533320
Y0: -2264547652597322743355287976870206966
Y1: 18766844300990818857555439
# e 2.324e-14

skew: 22109171.97
c0: -202107342825054844648166957778664214569163920
c1: 29210070866725397928080934163609660957
c2: 1685787361008931207987042692178
c3: -112491810246834689026289
c4: -4182404656009630
c5: 30723000
Y0: -2792332882301416522214996038614961686
Y1: 1264850521390214572621637
# e 2.297e-14

skew: 72790926.102
c0: 537998606088009273834399206094314700384642304
c1: 11403873838887849038978802132395579584
c2: -387595799274961375653764952136
c3: -146542705551392439871246
c4: -126475424055525
c5: 2851380
Y0: -3530821324166114229573825422256974795
Y1: 7269297095861234453870813
# e 2.281e-14

skew: 21852141.769
c0: 1312507633656801500515230865305827575845600
c1: 6568918199323513164095534661559716
c2: -9706996449424689305606176538
c3: -22061016894982017880514
c4: -151472083006355
c5: 4528440
Y0: -2583874558914609615325922449259599871
Y1: 5859566905830776616988543
# e 2.252e-14[/code]

Gimarel 2021-01-07 08:42

My current best poly: [CODE]# norm 2.678191e-18 alpha -8.963268 e 2.857e-14 rroots 5
skew: 87271318.89
c0: -6381367517597696742295702359937525488210006576
c1: 202288237039298283646164033232164328687
c2: 13346320611031566286558670660366
c3: -32289428163110989016897
c4: -1983739878858060
c5: 3603600
Y0: -3106799826410507065935794801180448266
Y1: 1970023755595084066583[/CODE]

swellman 2021-01-07 12:10

[QUOTE=Gimarel;568629]My current best poly: [CODE]# norm 2.678191e-18 alpha -8.963268 e 2.857e-14 rroots 5
skew: 87271318.89
c0: -6381367517597696742295702359937525488210006576
c1: 202288237039298283646164033232164328687
c2: 13346320611031566286558670660366
c3: -32289428163110989016897
c4: -1983739878858060
c5: 3603600
Y0: -3106799826410507065935794801180448266
Y1: 1970023755595084066583[/CODE][/QUOTE]

Nice one!

Anyone planning on further searching? My best so far is < 2.2, not worth reporting.

charybdis 2021-01-07 13:06

[QUOTE=Gimarel;568629]My current best poly: [CODE]# norm 2.678191e-18 alpha -8.963268 e 2.857e-14 rroots 5
skew: 87271318.89
c0: -6381367517597696742295702359937525488210006576
c1: 202288237039298283646164033232164328687
c2: 13346320611031566286558670660366
c3: -32289428163110989016897
c4: -1983739878858060
c5: 3603600
Y0: -3106799826410507065935794801180448266
Y1: 1970023755595084066583[/CODE][/QUOTE]

Very nice!
I won't be doing any more searching.

VBCurtis 2021-01-07 15:12

15% better than the record? Good 'nuff! I'll get the test-sieving done and post it to NFS@home 15e.
Thanks, Gimarel!

EdH 2021-01-07 18:52

Would there be interest in a spin of Gimarel's poly with the same score (per cownoise), but some slightly different coefficients?:
[code]
Y0: -3106799826973484694619713165056005342
Y1: 1970023755595084066583
c0: 6438085155586451094305181312249920006185364100
c1: -194652502066212678819533374835599698159
c2: -13373029993154413720046858814578
c3: 30018896009608567503617
c4: 1988888918754060
c5: -3603600
skew: 64667535.397
[/code]cownoise:
[code]
87179018.38350 2.85703099e-14
[/code]

VBCurtis 2021-03-18 18:14

The C189 from i12574 is factored.
i12575 is a C174 with a T35 complete; I'll have a T45 done in a few hours, and welcome any help at the T50 level.

charybdis 2021-03-18 19:10

Running some curves at the t50 level now. Will move on to t55 if that's unsuccessful.

charybdis 2021-03-19 12:30

Done 10000 curves at 15e7, no factor. Happy to do GNFS unless someone else wants to have a go.

VBCurtis 2021-03-19 15:29

I did 1000@6e7 and 1000@15e7.
This isn't big enough for a team sieve- have at it!

ryanp 2021-03-19 18:30

[QUOTE=charybdis;574114]Done 10000 curves at 15e7, no factor. Happy to do GNFS unless someone else wants to have a go.[/QUOTE]

Before you get too far...

[CODE]********** Factor found in step 2: 614983926378183254322298844615374685204843583001043931929
Found prime factor of 57 digits: 614983926378183254322298844615374685204843583001043931929
Prime cofactor 230563742947515228785129040402111677926368323663842302338164028366442145461025615070606186534878745596682333036963249 has 117 digits[/CODE]

ryanp 2021-03-19 19:37

I'm doing some ECM on the c213 @ i12577 now.

charybdis 2021-03-19 20:14

[QUOTE=ryanp;574142]Before you get too far...

[CODE]********** Factor found in step 2: 614983926378183254322298844615374685204843583001043931929
Found prime factor of 57 digits: 614983926378183254322298844615374685204843583001043931929
Prime cofactor 230563742947515228785129040402111677926368323663842302338164028366442145461025615070606186534878745596682333036963249 has 117 digits[/CODE][/QUOTE]

Thanks for the helping hand! I was only ~10% in so not too much damage done.

ryanp 2021-03-20 15:18

I did 70,000 curves @ B1=85e7 on the c164 blocker. Starting GNFS now.

ryanp 2021-03-24 21:42

[QUOTE=ryanp;574193]I did 70,000 curves @ B1=85e7 on the c164 blocker. Starting GNFS now.[/QUOTE]

[CODE]Info:Linear Algebra: krylov: N=73216 ; ETA (N=244736): Thu Mar 25 11:38:36 2021 [0.293 s/iter][/CODE]

charybdis 2021-03-31 14:39

[QUOTE=ryanp;574512][CODE]Info:Linear Algebra: krylov: N=73216 ; ETA (N=244736): Thu Mar 25 11:38:36 2021 [0.293 s/iter][/CODE][/QUOTE]

Ryan, are you working on the c199 from the next line?

ryanp 2021-03-31 15:43

[QUOTE=charybdis;574848]Ryan, are you working on the c199 from the next line?[/QUOTE]

Not currently, no.

charybdis 2021-03-31 16:47

[QUOTE=ryanp;574858]Not currently, no.[/QUOTE]

How much ECM did you run on it?

ryanp 2021-03-31 17:53

[QUOTE=charybdis;574864]How much ECM did you run on it?[/QUOTE]

Sorry, I realize I had a factor in my log that I failed to report. That index is fully factored now -- I'll move on a bit, and will post when I release the sequence.

ryanp 2021-04-01 23:07

Releasing back to the forum -- I've run 24K curves @ B1=26e7 on the current c172 blocker.

charybdis 2021-04-01 23:30

I can do the c172 if need be, but I won't be able to make a start for a couple of days, so if anyone would like to run polyselect (and/or everything else!) then go ahead.

Gimarel 2021-04-03 07:36

I have run polyselect. The best poly isn't probably the best for sieving[CODE]# norm 1.481342e-16 alpha -7.325643 e 3.311e-13 rroots 3
skew: 119080733.61
c0: -18145408366926326121017458043186624915628300
c1: 613588499137548423627075662512029720
c2: 6298580196776904564193151927
c3: -107283991807035062410
c4: -662868650868
c5: 2520
Y0: -4969776720988546109243500885401761
Y1: 261734777461987068581[/CODE]The best poly with an acceptable skew:[CODE]# norm 1.409095e-16 alpha -6.687145 e 3.236e-13 rroots 3
skew: 10334283.54
c0: 1519482932385250815299198478654429901789
c1: -483822951033341406439293222184413
c2: -850928413485779224902952349
c3: -37718773699801760337
c4: -3420252671210
c5: 138600
Y0: -3076532042702437514482451573485164
Y1: 6179641869367432006021[/CODE]

charybdis 2021-04-03 18:20

Thanks Gimarel! I've started sieving with your second poly.

charybdis 2021-04-07 02:43

i12589
 
Next line has a c201, t45 is complete and I've set t50 to run overnight. Others are welcome to run curves at the t55 level.

charybdis 2021-04-11 17:40

The c191 at line 12590 has survived ~half a t60 so far and will soon be ready for GNFS; it's probably OK for the usual suspects to start poly selection now.

I suppose this is near the crossover between NFS@home 15e and 16e-small? Or perhaps ryanp will factor it before we even decide which queue to send it to :smile:

VBCurtis 2021-04-11 20:01

For sieving time, I'm pretty sure it'll be faster on f-small. I'll be test-sieving it there, at any rate.
No poly select for me until Tuesday.

Gimarel 2021-04-15 07:00

Poly for i12590
 
Is this poly good enough?[CODE]# norm 1.631703e-18 alpha -7.844265 e 2.103e-14 rroots 5
skew: 15787707.53
c0: -12457606607293791983436376764155893116902090
c1: 1234654372800758634221295200055389121
c2: 2139303531353548167032164487634
c3: -47403491719130311302977
c4: -9497633635754160
c5: 18018000
Y0: -5975112266012861977670291001047638864
Y1: 21388440107514220977823[/CODE]

VBCurtis 2021-04-15 16:23

Looks good to me- fits the trendline for C190 and C192 (never mind the outlier huge score posted for a previous C191, better than the C190 record).

I'm still busier than I like at work, too many cheating cases; I doubt I'll test-sieve until the weekend.

Gimarel 2021-04-16 11:51

Poly for i12590
 
A poly with an almost identical score, so there is choice:[CODE]# norm 1.605668e-18 alpha -8.679931 e 2.105e-14 rroots 1
skew: 31007883.18
c0: 110959553355656567543356858499151578955792060
c1: -38940462646278760204606159044462028312
c2: 7067916544661517449417744835111
c3: 75597863525990589208009
c4: -3827132791134024
c5: 64864800
Y0: -4175569023201610477430743076651843101
Y1: 9301402025178661764203[/CODE]

charybdis 2021-05-16 16:27

[QUOTE=VBCurtis;575964]Looks good to me- fits the trendline for C190 and C192 (never mind the outlier huge score posted for a previous C191, better than the C190 record).

I'm still busier than I like at work, too many cheating cases; I doubt I'll test-sieve until the weekend.[/QUOTE]

I'm guessing you never got a chance to test-sieve this? I know the NFS@home queue is a bit busy but would be nice for this not to be forgotten.

VBCurtis 2021-05-16 20:05

Correct! {sigh}
I doubt I'll have time in the next 4-5 days; if anyone else wishes to do the test-sieve, be my guest. If no one does, I should be able to by the end of the week.

Or maybe I'll feel guilty enough to do it after I finish my taxes today...

swellman 2021-05-17 12:16

[QUOTE=VBCurtis;578534]Correct! {sigh}
I doubt I'll have time in the next 4-5 days; if anyone else wishes to do the test-sieve, be my guest. If no one does, I should be able to by the end of the week.

Or maybe I'll feel guilty enough to do it after I finish my taxes today...[/QUOTE]

I will test sieve it on 16f_small tomorrow if VBCurtis doesn’t get to it by then.

VBCurtis 2021-05-17 14:25

I won't get to it. Thanks!

swellman 2021-05-21 10:52

I’ve finished test sieving and will post the job this weekend. [URL="https://www.mersenneforum.org/showpost.php?p=575992&postcount=2958"]Gimarel’s second poly[/URL] was the better choice. A 16f_small/31-bit configuration seemed best.

swellman 2021-07-13 11:10

Releasing 4788, now at i12591 with a C198. No ECM has been run. Have at it.

charybdis 2021-07-13 12:26

There is a c220 at line 12596 :shock::help:

Let's hope ECM can crack this. t45 is done and I'm now running t50, ETA ~4 hours.

charybdis 2021-07-13 16:31

Moving on to t55...

bsquared 2021-07-13 17:04

[QUOTE=charybdis;583116]Moving on to t55...[/QUOTE]

I will also run some t55 curves.

charybdis 2021-07-14 12:36

Done 12000@15e7. Now running curves at 40e7 and 42e7.

bsquared 2021-07-14 21:39

I ran 9000@11e7

charybdis 2021-07-18 23:13

I've run 11400@40e7, 13900@42e7 and 1100@1e9, which together with the curves already done adds up to just over t60. That's it for now.

Where do people want to go with this? Unless Ryan gets involved, we're looking at an enormous amount of ECM (2t65? 0.5t70?) followed by kindly asking Greg whether he can put this in the NFS@home queue if a factor doesn't turn up.

swellman 2021-07-19 00:10

[QUOTE=charybdis;583497]I've run 11400@40e7, 13900@42e7 and 1100@1e9, which together with the curves already done adds up to just over t60. That's it for now.

Where do people want to go with this? Unless Ryan gets involved, we're looking at an enormous amount of ECM (2t65? 0.5t70?) followed by kindly asking Greg whether he can put this in the NFS@home queue if a factor doesn't turn up.[/QUOTE]

I can enqueue it with Yoyo@Home for the maximum number of curves allowed per run (12,000 curves) @B1=85e7. Rinse, repeat…

If that doesn’t crack it, perhaps go to up to (2x) 9900 curves @B1=29e8? Yoyo can handle B1=76e8 as well, though progress at that level is VERY slow. I’m not sure what the max number of curves per pass, perhaps 5000?

This is a huge job. The above ECM work will take months.

charybdis 2021-07-19 16:47

[QUOTE=swellman;583499]I can enqueue it with Yoyo@Home for the maximum number of curves allowed per run (12,000 curves) @B1=85e7. Rinse, repeat…[/QUOTE]

I'd say go ahead. After all, a journey of a thousand miles begins with a single step (or rather 12,000 steps...)

ryanp 2021-07-19 21:53

[QUOTE=swellman;583499]I can enqueue it with Yoyo@Home for the maximum number of curves allowed per run (12,000 curves) @B1=85e7. Rinse, repeat…

If that doesn’t crack it, perhaps go to up to (2x) 9900 curves @B1=29e8? Yoyo can handle B1=76e8 as well, though progress at that level is VERY slow. I’m not sure what the max number of curves per pass, perhaps 5000?

This is a huge job. The above ECM work will take months.[/QUOTE]

FYI, I hit this with 44K curves @B1=85e7 over the weekend. May try to run more later in the week.

ryanp 2021-08-02 22:40

[QUOTE=ryanp;583570]FYI, I hit this with 44K curves @B1=85e7 over the weekend. May try to run more later in the week.[/QUOTE]

I have now run 91K curves at B1=29e8 against the c220 blocker.

charybdis 2021-08-02 23:22

[QUOTE=ryanp;584660]I have now run 91K curves at B1=29e8 against the c220 blocker.[/QUOTE]

Wow, thank you! That should be enough ECM to move on to GNFS...

Is there any chance you'll run the GNFS yourself? If not, it should be within range of NFS@home if Greg is happy to queue it, though of course that requires finding a polynomial first.

swellman 2021-08-03 00:24

This poly search will be “challenging”. :max: I’ll help but it will take a group effort. And Gimarel, who has found many record polys, is on a hiatus until the hot season passes.

Maybe we should wait on this search until autumn? Just a suggestion.

charybdis 2021-08-03 00:34

[QUOTE=swellman;584669]Maybe we should wait on this search until autumn? Just a suggestion.[/QUOTE]

Don't have a problem with that, as long as we don't completely forget about it. It'll take a while for NFS@Home to sieve 2,2174L/M so there's no rush.

ryanp 2021-08-03 21:48

[QUOTE=charybdis;584663]Wow, thank you! That should be enough ECM to move on to GNFS...

Is there any chance you'll run the GNFS yourself?[/QUOTE]

Possibly, if there's a good poly found. But I'd also be happy for others to run the GNFS for this one :smile:

VBCurtis 2021-08-03 23:39

I'll be doing a couple weeks of CADO poly select on this, starting mid-August.

swellman 2021-08-04 00:57

[QUOTE=VBCurtis;584746]I'll be doing a couple weeks of CADO poly select on this, starting mid-August.[/QUOTE]

What CADO parameters are suggested for a C220?

ETA: Presumably a sextic, correct?

bur 2021-08-10 06:56

How are group poly searches organized? If someone could walk me through it, I'd gladly participate.

VBCurtis 2021-08-10 13:30

Poly searches are organized by leading coefficient and software used.
In CADO, that's admin and admax; in msieve the coefficient range can be specified on the command line.

Suggested CADO settings:
incr of 210 or 420 for small leading coeff's, 2310 or 4620 for larger ones (a totally arbitrary cutoff of 10e6 is "large" to me for sextics). If I used nq=7776, I'd use a smaller incr.

nq of 7776 or 46656- note that 46656 will take 5-6x longer than 7776. These numbers are 6^5 and 6^6- CADO authors suggest powers of the poly degree for this setting, but it's not required. You could try e.g. 20000 to split the difference, but I've never tried.

P of whatever CADO default is for C220 should be fine. root-opt-effort should be set quite high, like 50; the root-opt portion of the search is so much shorter than size-opt searching that we may as well tell CADO to "work hard" on root-opt. You don't have to root-opt many candidates- maybe 20 per thread-week of size-opt searching?

Reserving 0-1e6 on CADO; I'll get started late Wednesday after a matrix finishes.

bur 2021-08-12 05:27

So I'd use tasks.sieve.run=false and the respective admin/admax, incr/nq and root-opt-effort settings and just invoke cado as usual?

And a few specific questions:
[LIST][*] If I understand the incr setting correctly, polysearch time decreases linearly with it? Small values are more thorough but take longer? Since I have no idea, which would you choose, 210 or 420?[*] For nq I'd go with 7776, or has the 46656 an advantage that warrants to 5-6 fold increase in time?[*] How much core-time is usually required per coefficient range?[*] size-opt-effort is kept at 0?[/LIST]

VBCurtis 2021-08-12 14:33

These are great questions, and pretty thorough!

nq, is in some way, how many candidates are tried for each leading coefficient. I don't know in which way this "how hard to try" is different from the size-opt-effort "how hard to try", but limited experimentation has not yielded success when playing with size-opt-effort. We haven't done enough searches with degree 6 (used for, roughly, 212+ digit jobs) to learn whether the extra time for nq=6^6 yields better polys than 6^5; I can say with some certainty that 6^5 is better than 6^4, though.

Similarly, one could use nq=78125 rather than 15625 for 5th degree searches on other jobs; again, I haven't conclusively ruled out the higher setting as inferior, but I'm pretty certain 15625 is better than 3125. If you try 46656 on this search, try it on a small coeff range (say, 1e6 to 11e5), since it will take a while; you can compare lognorm (the score reported from size-opt before root-opt takes place) of a 100k run at 46656 and a 600k run at 7776 to see if the higher setting has merit.

The reason to use a smaller incr is that small coeff values tend to yield good polys more often, so we wish to search more of them. So, I'm going to use incr=210 for 0-4e5 and incr=420 for 4e5-1e6 (two separate runs, I mean). For runs above 1e6, I think I'll use incr=420; once we get above 2e7 I'd change to 2310 or 4620 (adding in 11 as a factor "should" yield good polys a bit more often, but the 11 seems relatively less important than trying more small coeffs, so we only use it once coeffs aren't "small", with "small" really quite arbitrary).

Gimarel 2021-08-12 15:12

In my experience lower leading coefficients lead to better polys on average. I'd say the higher nq the better. But cado polyselect seems to have a bug, polyselect sometimes stops to output polys for a specific leading coefficient but still uses 100% cpu. So you risk to loose a lot of time if you use a high nq with cado.

charybdis 2021-08-12 15:34

[QUOTE=Gimarel;585487]But cado polyselect seems to have a bug, polyselect sometimes stops to output polys for a specific leading coefficient but still uses 100% cpu.[/QUOTE]

Sounds like this should be reported to the CADO mailing list if this is actually a bug?

bur 2021-08-13 05:35

Ok, thanks everybody. What about adrange? Should I keep it at the default 5e3? Does it even matter besides less frequent ETA updates?


[QUOTE]I'd say the higher nq the better.[/QUOTE]So 6^6 would yield that much better results to make the increase in time useful?


And about root-opt-effort, is it possible that for small test ranges 50 is a bit high? I test-searched 1e6 to 1.01e6 and size-opt took about 10 minutes, but root-opt is also still going after 10 minutes. I can't imagine it should have that time ratio for larger ranges?


And finally: does the time per range scale linearly? I want to estimate a suitable range to start with so it doesn't take a month.

Gimarel 2021-08-13 08:18

[QUOTE=charybdis;585488]Sounds like this should be reported to the CADO mailing list if this is actually a bug?[/QUOTE]
I'm not sure. It could be bad parameter selection on my side. I have to do more testing when I have time.

Gimarel 2021-08-13 08:31

[QUOTE=bur;585540]So 6^6 would yield that much better results to make the increase in time useful?[/QUOTE]
I have done a short test with[CODE]polyselect -n 5272066026958413205513021090082556639441277154855572268239336980532402881465013381219738819137405617219594641652778228990107677072837959240400905630530715435664638237254654768053674178165309345879869729405448588458952991 -d 6 -t 1 -admin 120 -admax 180 -incr 60 -nq <6^[4567]> -v -P 10000000[/CODE][CODE]nq discarded size-optimized time time/poly
6^4 4 1 19.12s 3.824s
6^5 20 8 107.95s 3.855s
6^6 85 92 661.50s 3.737s
6^7 473 464 4041.48s 4.313s[/CODE]So 6^6 seems to be best.

bur 2021-08-13 08:46

That nq result is very interesting, so we should really use 6^6?


And to get me started, can anyone give a short estimate on range vs time/core? Can I just use the result from 1e6 to 1.01e6? That would indicate that vbcurtis range would only take half a day on a ten core. Is that correct?


And about root-opt-effort, is it possible that for small test ranges 50 is a bit high? I test-searched 1e6 to 1.01e6 and size-opt took about 10 minutes, but root-opt is also still going after 10 minutes. I can't imagine it should have that time ratio for larger ranges?


(sorry for reposting, but sometimes things get lost after a few posts)

charybdis 2021-08-13 13:06

[QUOTE=bur;585548]And about root-opt-effort, is it possible that for small test ranges 50 is a bit high? I test-searched 1e6 to 1.01e6 and size-opt took about 10 minutes, but root-opt is also still going after 10 minutes. I can't imagine it should have that time ratio for larger ranges?[/QUOTE]

The time taken for rootopt does not depend at all on the size of the range searched. The top "nrkeep" polynomials from sizeopt are fed to rootopt, and it generally only takes a very small range to find this many polynomials (the default c220.params has nrkeep=200), so rootopt for a 10k range will take just as long as rootopt for a 10M range. If you're only searching a small range, I would reduce nrkeep rather than ropteffort. While the 100th best sizeopt hit in your range could produce the best poly *in your range* after rootopt, it's extremely unlikely it would be one of the best polys found in the entire search.

Can't answer the other questions as I've never done degree-6 poly searching before.

bur 2021-08-13 15:17

Thanks for the explanation. For the start I only want a 24 h or so search to catch errors early on. Since I have no idea what nrkeep value would be useful for that amount of time, I'll wait if vbcurtis has some idea.

VBCurtis 2021-08-13 15:26

I'm using nrkeep of 24 for my small experiments. I ran 1260 to 5e4 with nq = 6^6 and incr 210, took a few hours. Root-opt wasn't timed but was maybe 25% of the size-opt step.
Edit: poly score was 2.45e-16; I think 3.0+ are worth reporting, and we'd like 3.5 or better.
Next I ran 5e4 to 35e4 with the same params. That's about 36hr on 30 threads for size-opt (of a dual-10-core Ivy Bridge, with the other 10 threads solving an msieve matrix).
Finally, 35e4 to 1e6 is running on nq = 6^5 but sizeopteffort=2. Done tonight on a different machine, I'll see if that flag had much effect.

My next reservation will use incr 420 and nq = 6^6, and probably not use sizeopteffort.

EDIT2: adrange should be an even multiple of incr; I use 4 * incr, as that guarantees each thread in a process two coefficients to process per workunit. If you use a round number such as 1e4 instead, workunits will vary in length which isn't a big deal but is maybe a tiny bit less efficient (when a workunit has an odd number of multiples of incr, it will run single-threaded for quite a while).

charybdis 2021-08-13 18:33

[QUOTE=VBCurtis;585579]Root-opt wasn't timed but was maybe 25% of the size-opt step.[/QUOTE]

Nitpicking a bit, but the sizeopt step is only a small part of what the polyselect binary does. Most of the time is just spent searching for polynomials, and size optimization (the bit that's controlled by sopteffort) only takes a short time. You can see this by looking at the output files from polyselect, which end with something like

[code]# Stat: total phase took 1115.95s
# Stat: size-optimization took 37.47s[/code]

...and this is from a c182 GNFS, *after* setting sopteffort=10!

I haven't done any testing to see what's actually best, but sizeopt takes proportionally less time for larger numbers (at least while we're still using degree 5) so it may make sense to increase it for bigger jobs.

VBCurtis 2021-08-13 21:32

You know, I've only played with sizeopteffort on degree 6 jobs, and it seems on those jobs it takes proportionally longer than on deg 5 jobs- so I thought it was controlling effort on that entire first step.

My time with msieve reminds me of the *three* phases of poly select, and my failure to consider that CADO combines phases 1 and 2 together into the first step.

So, nq is a sort of search depth per coefficient for finding candidate polys, while size-optimizing (and sizeopteffort) is to "polish" those found polys.

Thanks for the correction and amplification!

swellman 2021-08-14 01:01

[QUOTE=VBCurtis;585579]I'm using nrkeep of 24 for my small experiments. I ran 1260 to 5e4 with nq = 6^6 and incr 210, took a few hours. Root-opt wasn't timed but was maybe 25% of the size-opt step.
Edit: poly score was 2.45e-16; [B]I think 3.0+ are worth reporting, and we'd like 3.5 or better.[/B][/quote]

For a GNFS 220, msieve is looking for an e-score between 2.98e-16 and 3.42e-16+, regardless of poly degree(?). Not sure how many data points they used to establish these guidelines or if it was based on extrapolation.

[URL="https://www.mersenneforum.org/showpost.php?p=569227&postcount=177"]Cooperstown[/URL] lists 3.36e-16 to 3.884e-16 for a G-220 poly with degree 6.

My feeling is polys with e-scores of >3.0e-16 are worth reporting as VBCurtis suggests - spin may ultimately help a bit too. 3.9+ is a hard stop, however unlikely it may be.

ETA: I am ignoring degree 5 polys for a composite of this size. Also ignoring msieve-GPU for this effort - just too big a job unless one uses advanced techniques like Gimarel.

VBCurtis 2021-08-14 03:26

[QUOTE=VBCurtis;585579]Finally, 35e4 to 1e6 is running on nq = 6^5 but sizeopteffort=2. Done tonight on a different machine, I'll see if that flag had much effect.[/QUOTE]

1.44M thread-seconds for stage 1, 20k thread-seconds for root-opt of top 24 polys. Best poly was 13% better than my first run, using CADO's score:
# MurphyE (Bf=1.718e+10,Bg=1.718e+10,area=3.221e+17) = 1.179e-09

So maybe a 2.8, I'm too lazy to cownoise it. Stage 1 E-score was 54.64 for 24th place.

I'll leave 1e6-2e6 for bur; taking 2e6-5e6 with nq=46656 and incr=420. EDIT: I'm using P=12e6 so far, haven't tried any other settings.

bur 2021-08-14 09:25

Here are test results for nq=46656 vs nq=7776

Other settings:
[CODE]tasks.polyselect.P = 10000000
tasks.polyselect.admin = 1000000
tasks.polyselect.admax = 1016800
tasks.polyselect.adrange = 1680
tasks.polyselect.incr = 420
tasks.polyselect.nrkeep = 24
tasks.polyselect.sopteffort = 0
tasks.polyselect.ropteffort = 50
[/CODE]nq=46656
[CODE](size optimized): raw lognorm (nr/min/av/max/std): 3524/66.240/77.238/78.270/1.005
(size optimized): optimized lognorm (nr/min/av/max/std): 3273/61.250/65.599/68.080/0.904
(size optimized): Total time: 51126.6

(root optimized): Total time: 13715
(root optimized): Rootsieve time: 13714.8

# MurphyE (Bf=3.436e+10,Bg=1.718e+10,area=8.590e+17) = 1.401e-09
cownoise: 2.63300493e-16
[/CODE]nq=7776
[CODE](size optimized): raw lognorm (nr/min/av/max/std): 617/73.240/77.332/78.260/0.891
(size optimized): optimized lognorm (nr/min/av/max/std): 541/61.510/65.602/68.080/1.095
(size optimized): Total time: 8491.2

(root optimized): Total time: 13530.4
(root optimized): Rootsieve time: 13530.2

# MurphyE (Bf=3.436e+10,Bg=1.718e+10,area=8.590e+17) = 1.160e-09
cownoise: 2.02216808e-16[/CODE]That's an almost 25% larger e-score for a 6-fold increase in time. I don't know if this was just coincidence, but it agrees with Gimarel's results (though I am not sure what they specifically mean tbh).


If my settings are generally sound, then I'll start a search for the full 1e6-2e6 range with nq=46656. I noticed default cado has P=10e6, while vbcurtis wrote he used 12e6. Should I keep it consistent or doesn't it matter?

VBCurtis 2021-08-14 14:12

[QUOTE=bur;585616]If my settings are generally sound, then I'll start a search for the full 1e6-2e6 range with nq=46656. I noticed default cado has P=10e6, while vbcurtis wrote he used 12e6. Should I keep it consistent or doesn't it matter?[/QUOTE]

It may matter, and we don't know which is better, so may as well stick with what you've been running.

bur 2021-08-14 15:45

Ok, I did that. ETA for size opt of 1e6 - 2e6 is Aug 18th.


I couldn't find the file where the priority polymers are written to, any idea where that is? Or isn't it a single file?

swellman 2021-08-14 16:25

What about wutimeout, which my notes say is required for deg 6 rootsieve? Factory value for a C220 is 24000.

Is it still required? I presume it’s a deadman timer to eventually move past bad polys that don’t play nice with CADO(?)

I am planning to search in the higher ranges, starting at 40-41M, with P=10M, nq=46656, incr=4620 and adrange=18480, with a ropteffort value of 100, strike that it’s 35. nrkeep is 100.

sopteffort=10 just because.

Planning to start on Monday.

bur 2021-08-14 17:20

I think wutimeout is how long cado waits for an individual slave to return a result. If exceeded it's canceled.

charybdis 2021-08-14 17:48

[QUOTE=bur;585632]I couldn't find the file where the priority polymers are written to, any idea where that is? Or isn't it a single file?[/QUOTE]

The priority queue is kept in the sqlite3 database (the .db file) rather than a separate file. You could also find high scoring polys by running a grep command in the .upload directory.

The default for wutimeout is 10800, or 3 hours. From the looks of it, individual rootopt tasks are finishing much more quickly than that, so I doubt it needs changing, but there shouldn't be any problem setting it to a higher value unless your clients have a tendency to go down without taking the server with them.

I'll probably join in with the search towards the end of next week.

bur 2021-08-15 06:09

The polynomials are apparently in the table polyselect1_bestpolynomials, but I can't figure out how they are sorted. The exp_E values don't seem to show any order.


The columns are rowid, kkey, type and value. Rowid is just that, kkey was always rowid-1, type is always 0 and value is the polynomial with only #exp_E as score.

bur 2021-08-17 10:20

I was wondering, when going through a poly range, is it possible to entirely miss good polynomials? I.e. if someone would search the range again with smaller incr or yet larger nq or sopt-effort, could a significantly higher scoring polynomial be found or will it just result in slightly better scores?

Besides, this short script returns the highest scoring polynomial from the database (I don't know if the multiple grepping is really elegant, but it works). Just execute it with the db file as argument:
[QUOTE]
cp $1 ./save.db
sqlite3 -header -csv save.db "SELECT * FROM polyselect1_bestpolynomials;" > data.csv
cat data.csv | grep "exp" | sort | head -1 | grep -f - data.csv -B 10
rm save.db
rm data.csv[/QUOTE]

charybdis 2021-08-17 12:37

[QUOTE=bur;585852]I was wondering, when going through a poly range, is it possible to entirely miss good polynomials? I.e. if someone would search the range again with smaller incr or yet larger nq or sopt-effort, could a significantly higher scoring polynomial be found or will it just result in slightly better scores?[/QUOTE]

Yes, you can completely miss good polys. This is less likely with sopteffort which improves polys that have already been found, as opposed to incr and nq which affect the range that is searched in stage 1.

bur 2021-08-17 14:21

So is it really worthwhile if I search a range with my moderate incr/nq combination? How likely is it that the range should be redone later on with more demanding parameters? Or is incr=420 and nq=46656 considered good enough for good?

I think about that especially in light of users with a lot of ressources who could easily do the range with nq=6^7.


All times are UTC. The time now is 18:08.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.