A rather surprising result for this number in the t800 file:

[URL="http://www.factordb.com/index.php?query=%2811678983384265232966613390730340859%5E7-1%29%2F11678983384265232966613390730340858"](11678983384265232966613390730340859^7-1) / (p-1)[/URL] = 4201 * p45 * p50 * p108

Presumably some unlucky ECM that didn't catch the p45 at least?

Edit: I believe I have now finished off all numbers of the form p^7-1 in the t800 file where p has <=35 digits.

t2100.txt
 

All the C140s are factored. I am starting with the C141s.

[QUOTE=lavalamp;533263][URL="http://www.factordb.com/index.php?query=%2811678983384265232966613390730340859%5E7-1%29%2F11678983384265232966613390730340858"](11678983384265232966613390730340859^7-1) / (p-1)[/URL] = 4201 * p45 * p50 * p108

Presumably some unlucky ECM that didn't catch the p45 at least?[/QUOTE]

I can see where this can be argued either way. Using 0.21 * SNFS-205 needs a t43 testing level. Or using 2/9 of 205 would need a t45.5.

A few smallish numbers have appeared in the [url=http://www.lirmm.fr/~ochem/opn/t2100.txt]t2100 file[/url] in the mid-C110 range. I have been working the C141 range so no conflict by me. :smile:

Found an P31 for this canidate. [CODE] (8607076653121^47-1)/1409491047619715454786751986299893440[/CODE]
Composite Cofactor [URL="http://www.factordb.com/index.php?id=1100000001439702575"]C542[/URL] survived 430 curves at B1=250K.



Number was found in the t2100 file.

732541^47-1
 

Different perspectives on the above number in [url=https://www.mersenneforum.org/showpost.php?p=407738&postcount=145]this post[/url] and [url=https://www.mersenneforum.org/showpost.php?p=533171&postcount=21]this post[/url].

This is a Most Wanted number with a calculated OPN weight of 2.5Mil. Actually number 11 from the top in the [url=http://www.lirmm.fr/~ochem/opn/mwrb2100.txt]MWRB file[/url]. [B]yoyo[/B] has completed 10K curves at t65 and 9K curves at t70.

I'm game to do another hybrid CADO/15e-queue job with SNFS; we've done GNFS197 and GNFS198 somewhat profitably, and trying an iffy SNFS job seems fine.
I won't have human-time to test params nor yields with CADO until the end of June; if any of the usual suspects wishes to do some yield calcs, please be my guest.
I'd say Q-max of 800M in 15e is a reasonable target. So, what Q should be done in CADO (and should they be done with A=30 or I=16) such that doing the rest of the Q up to 800M yields enough relations?

I'm looking for an answer like "10-150 on CADO A=30, 150-800 on 15e" or "20-100 on I=16, 100-700 on ggnfs". Anyone willing to do such test sieving in a way that tries to minimize total sieve time will find a willing CADO host come 1 july.
I haven't done an SNFS job above 900 bits yet, so I'd also like the param choices to be spelled out so I set up CADO correctly: sieve which side, 3LP on which side, lims. I assume 33LP since we're stretching 15e.

ryanp gave in trying to factor 732541^47-1 due to it running into weird issues with lasieve(random low yield on some q if I remember right). I would suggest doing this one purely CADO would be the most sensible way. I think this one would have been done ages ago if it wasn't for this issue.

At one point in time [B]ryanp[/B] had an interest in working a few OPN. I suppose Real Life[SUP]TM[/SUP] issues came up. This was my last correspondence to him and possibly a starting point for moving forward.

[QUOTE]Finally got time to do some testing. Last month I had a power supply go out after a power outage. That made me behind (over-committed) on projects/assignments. Then I had to shut down for a few days while I relocated. Now I have test sieved on the Linux box with 16e and everything looks good.

I was going to wait until I had the full range tested but I believe I proved we can get enough relations (on or before Q=600M) on the -r side.

[CODE]Trial sieving 2K blocks.
Q Yield
20M 6299 3.15
100M 6080 3.04
200M 5612 2.81

n: 605716904027877980774625455520189647387776352555063757365644672493136637525085152114527251672682055452329862008130550673203343550128250999766605061023948523297828457779191592093682881010498969046911261346842026672855745883554109771998292748069377018429964450347583969787
# 732541^47-1, difficulty: 281.51, skewness: 9.49, alpha: 0.00
# cost: 8.45884e+19, est. time: 40280.21 GHz days (not accurate yet!)
skew: 9.494
c6: 1
c5: 0
c4: 0
c3: 0
c2: 0
c1: 0
c0: -732541
Y1: -1
Y0: 82919274927962023982932249248351337261442889121
m: 82919274927962023982932249248351337261442889121
type: snfs
rlim: 536000000
alim: 1072000000
lpbr: 33
lpba: 33
mfbr: 66
mfba: 96
rlambda: 2.7
alambda: 3.6[/CODE][/QUOTE]

[QUOTE=henryzz;548142]ryanp gave in trying to factor 732541^47-1 due to it running into weird issues with lasieve(random low yield on some q if I remember right). I would suggest doing this one purely CADO would be the most sensible way. I think this one would have been done ages ago if it wasn't for this issue.[/QUOTE]

Now I remember. We/He tried to the run the number 1 Most Wanted Road Block (even as an octic) but ran into the stated problems you mentioned. I think we decided it needed to be run as a 34-bit job but neither one of us could find the appropriate binary at that time. Hence, it was abandon.

Edit: BTW, 6115909044841454629^17-1, SNFS-301 (octic).

[QUOTE=RichD;548117]Different perspectives on the above number in [url=https://www.mersenneforum.org/showpost.php?p=407738&postcount=145]this post[/url] and [url=https://www.mersenneforum.org/showpost.php?p=533171&postcount=21]this post[/url].

This is a Most Wanted number with a calculated OPN weight of 2.5Mil. Actually number 11 from the top in the [url=http://www.lirmm.fr/~ochem/opn/mwrb2100.txt]MWRB file[/url]. [B]yoyo[/B] has completed 10K curves at t65 and 9K curves at t70.[/QUOTE]

I think fivemack was just saying it's too big for 15e on NFS@Home, so would need to be done with 16e. It would be doable though.

Chris