Actually, NFS postprocessing has no lower limit but poly selection and sieving are still limited to 97 digits and above. I think the crossover point between QS and NFS is not very interesting right now, because at that size NFS should really be using degree 4 polynomials, which only the (old, quite bad) GGNFS polyselect code can produce. I'm also planning on handling polynomial degrees other than 5 someday, in which case the lower limit for NFS should drop to maybe 90 digits (QS only takes 1-2 hours at that size)

It seems the "too many line iterations" problem is still present in 140b2.

Using the 32-bit exe you posted:
[code]
>msieve140beta2.exe -np -v 20891943471592467423795610573210232950695056287897022892160098568550927550133706394539114201705909104421


Msieve v. 1.40
Tue Mar 10 14:37:44 2009
random seeds: f6793590 c9627390
factoring 20891943471592467423795610573210232950695056287897022892160098568550927550133706394539114201705909104421 (104 digits)
searching for 15-digit factors
commencing number field sieve (104-digit input)
commencing number field sieve polynomial selection
time limit set to 0.46 hours
searching leading coefficients from 1 to 4885
deadline: 30 seconds per coefficient
coeff 60-600 128985 167680 167681 217985 lattice 2684
p 76322 100000 281170 368400 lattice 954
batch 2046 109090
save 6.170058e-010 -5.083187 59889.488923 1.963899e-009

[goes on normally for about a minute, and then starts spewing:]
too many line iterations
too many line iterations
too many line iterations
too many line iterations
too many line iterations
too many line iterations
[...]
[/code]

I've run into some more poly-find problems with your posted v1.40 beta 2 32-bit:

[code]
>msieve -np -v 1733805981578761204920864123010686254287041632499130903286156560892925922059062806393480116353959941049609979580276355537

Msieve v. 1.40
Fri Mar 13 01:43:28 2009
random seeds: f0b57e50 85c5b194
factoring 1733805981578761204920864123010686254287041632499130903286156560892925922059062806393480116353959941049609979580276355537 (121 digits)
searching for 15-digit factors
commencing number field sieve (121-digit input)
commencing number field sieve polynomial selection
time limit set to 4.24 hours
searching leading coefficients from 5717 to 34263
deadline: 100 seconds per coefficient
coeff 5760-8700 2243436 2916466 2916467 3791407 lattice 243146
p 74069 100000 85057844 114835956 lattice 286
batch 573 106836
save 1.130153e-011 -6.552244 241197.278371 2.267635e-010
save 1.073106e-011 -4.961577 134717.641059 2.205641e-010
[b]integrator failed 1.004741e-012 1.545584e-018
error: size score computation failed[/b]

[worked fine for half an hour or so next, then:]

[b]integrator failed 2.101375e-017 1.361967e-018
error: size score computation failed[/b]
p 19948 43826 194080785 426397858 lattice 55
batch 569 43853

[again no problems for some time, then the final few lines:]

save 1.068632e-011 -6.102501 236601.112815 2.194072e-010
p 2001 19947 426419235 4250766862 lattice 11
batch 488 19949
[/code]

... at which point msieve crashed altogether. It did manage to find what seems like a decent polynomial in the middle of all that though, so all's not woe. :)

I think a fix for the bug in post #57 didn't make it into the compiled binary but is in my development sources.

Numerical integration errors should start appearing again because latter-day versions are doing 10x as many integrations. They're unfortunate but should be harmless. Don't know about the crash though.

Curious timings with msieve 140b2 (your 32-bit .exe):

[code]
>msieve -v -np 100378419527480999899044779204345556263090439070175192953406475175547792359862668840341621883334064517492609

[...]
time limit set to 0.74 hours
[...]
elapsed time 01:01:20
[/code]

msieve.exe did indeed take >60 cpu minutes.

The deadline is really quite approximate; most of the time if the deadline is for inputs over ~100 digits then the actual time taken is up to an hour too low.

It's another thing to fix eventually. The size of the deadline is also something that I really don't have much of a feel for; it's a lot easier to take too long than 'long enough' to find something decent. As it stands, pol5 finishes a lot quicker because its search space is a lot smaller; whether msieve's search space needs to be smaller, or just need to be searched more efficiently, is something I just don't know right now.

Another crash with msieve 1.40b2 32-bit .exe. This one after 2h5m cpu time with a printed time limit of 1.83 hours so maybe the problem is at the very end somewhere? Then again, I think my earlier crash was more like in the middle so maybe not... Hopefully they're reproducible at least.

[code]
>msieve -v -np 2048253506063359683468604901451208133279970056377888237602046515054939723510615041312172014682636212580102547051741

Msieve v. 1.40
Mon Mar 16 15:30:41 2009
random seeds: 746ea638 1fd72974
factoring 2048253506063359683468604901451208133279970056377888237602046515054939723510615041312172014682636212580102547051741 (115 digits)
searching for 15-digit factors
commencing number field sieve (115-digit input)
commencing number field sieve polynomial selection
time limit set to 1.83 hours
searching leading coefficients from 1 to 17316
deadline: 50 seconds per coefficient
coeff 60-600 680416 884541 884542 1149904 lattice 23477
[...]
[/code]

Btw, the two best polys found were:

[code]
# norm 5.641999e-011 alpha -7.955251 e 5.525e-010
skew: 156754.32
c0: -243184674863126800390485638477
c1: -3654399418468931114475397
c2: 5393203987110080813
c3: 738051875778985
c4: 624567576
c5: 5940
Y0: -12809112492950701768716
Y1: 578701971523
[/code]
and
[code]
# norm 5.799237e-011 alpha -4.921763 e 5.702e-010
skew: 34516.73
c0: -38776818791255331661281972
c1: 26564144020061341318792
c2: 3104868435625216117
c3: -22306326057476
c4: -2166655734
c5: 15300
Y0: -10600839209281611323185
Y1: 1544465777087
[/code]

I'm going with the latter one. Is that one clearly superior?

Test-sieve them. Sieve 1000 Q (or more for a better estimate) and see which gives you relations faster.

And yet another crash. Am I the only one experiencing this? It doesn't happen every time I try to polyfind with msieve (1.40b2, haven't tried other ones much), but pretty often.

[code]
>msieve -v -np 20493991335415901037500979455292676825755924368723647467628058002854629686090424866093917817865467011184015072469372207

Msieve v. 1.40
Mon Mar 16 17:17:25 2009
random seeds: a631dad0 1c0376a4
factoring 20493991335415901037500979455292676825755924368723647467628058002854629686090424866093917817865467011184015072469372207 (119 digits)
searching for 15-digit factors
commencing number field sieve (119-digit input)
commencing number field sieve polynomial selection
time limit set to 3.38 hours
searching leading coefficients from 1 to 27444
deadline: 50 seconds per coefficient
[...]
[/code]

This one happened about halfway through the time limit.

Do you have any more recent build I could try, or do you want me to run a special debug version or something?

My development sources (with the 'too many iterations' fix) get through this one without trouble; the best poly found was
[code]
R0: -79434702840962992515445
R1: 4621472204057
A0: 200243038335944609118245517216
A1: 15073693512127291964407896
A2: 2316465524962022114
A3: -691419478158527
A4: 42686184
A5: 6480
skew 207145.06, size 2.564796e-011, alpha -6.486605, combined = 3.619637e-010
[/code]

lanczos error: submatrix is not invertible
 

Unusual error (in msieve 1.40b2). Haven't seen before.
[code]commencing number field sieve (207-digit input)
R0: -100000000000000000000000000000000000
R1: 1
A0: 53
A1: 0
A2: 0
A3: 0
A4: 0
A5: 0
A6: 10
skew 1.32, size 2.860367e-10, alpha -1.280380, combined = 7.030164e-12
memory use: 1287.4 MB
read 3350200 cycles
matrix is 3349280 x 3350200 (994.2 MB) with weight 299201108 (89.31/col)
sparse part has weight 223767223 (66.79/col)
filtering completed in 3 passes
matrix is 3328278 x 3328478 (990.1 MB) with weight 297862205 (89.49/col)
sparse part has weight 222943171 (66.98/col)
read 3328478 cycles
matrix is 3328278 x 3328478 (990.1 MB) with weight 297862205 (89.49/col)
sparse part has weight 222943171 (66.98/col)
saving the first 48 matrix rows for later
matrix is 3328230 x 3328478 (945.0 MB) with weight 235248839 (70.68/col)
sparse part has weight 214444072 (64.43/col)
matrix includes 64 packed rows
using block size 65536 for processor cache size 6144 kB
## apparently this on a Phenom 940 ##
commencing Lanczos iteration (4 threads)
memory use: 993.3 MB
lanczos error: submatrix is not invertible

lanczos halted after 547 iterations (dim = 34526)
linear algebra failed; retrying...
commencing Lanczos iteration (4 threads)
memory use: 993.3 MB
lanczos error: submatrix is not invertible

lanczos halted after 163 iterations (dim = 10240)
linear algebra failed; retrying...
commencing Lanczos iteration (4 threads)
memory use: 993.3 MB
lanczos error: submatrix is not invertible

lanczos halted after 111 iterations (dim = 6937)
linear algebra failed; retrying...
commencing Lanczos iteration (4 threads)
memory use: 993.3 MB
lanczos error: submatrix is not invertible

lanczos halted after 32 iterations (dim = 1954)
linear algebra failed; retrying...
commencing Lanczos iteration (4 threads)
[/code]The dump shows that the matrix is OK (non-degenerate; you know what I mean). Will proceed with msieve 1.39.

EDIT: msieve 1.39 also failed @1.5% done.

OK. Will sieve some more; it's probably a marginal matrix. For the same size I usually sieved just a bit more. Tonight started with 46M raw relns, usually sieve to 50-52M. This is a 29-bit project.