Msieve with GNFS support

[tmorrow]

I'm using Msieve 1.43 with GGNFS (latest SVN). I am attempting to factor the remaining unfactored part of Phi(87,447), a C130. The factorisation failed in the matrix step (performed by msieve) with return code 65280. Some earlier posts have reported the same error.

I'm not sure what I can do to recover from this error and would be grateful for any advise. Some details follow that may assist.

The last time I did this kind of factoring was a year ago - several C120-C129's with older code bases for both GGNFS and Msieve. None of these factorisations failed. I noticed that the number of relations produced by the latest software far exceeded those of previous factorisations. The C130 factorisation has produced a 2.4GB file with 20353348 relations - based on practical experience from previous runs this seems to be excessive. Here's a tail of the output for the factorisation:

Msieve v. 1.43
Mon Jan 11 17:10:07 2010
random seeds: 16400688 0644920c
factoring 1864377850636345948734518870207312072314484684485538649550519310253452567229329410735639625206737537628271400729107836489370464603 (130 digits)
searching for 15-digit factors
commencing number field sieve (130-digit input)
R0: -5873570358094606850146801
R1:  935455152491
A0: -3103174350143050466814484566844
A1: -2014480651401349310876498
A2:  1940001945847278764412
A3: -5394112547714543
A4:  161585218616
A5:  266700
skew 125552.59, size 1.845507e-012, alpha -7.043312, combined = 8.418720e-011

commencing relation filtering
estimated available RAM is 2048.0 MB
commencing duplicate removal, pass 1
found 2288942 hash collisions in 19776017 relations
added 102 free relations
commencing duplicate removal, pass 2
found 1901572 duplicates and 17874547 unique relations
memory use: 98.6 MB
reading ideals above 8585216
commencing singleton removal, initial pass
memory use: 376.5 MB
reading all ideals from disk
memory use: 319.5 MB
commencing in-memory singleton removal
begin with 17874547 relations and 19011542 unique ideals
reduce to 5783794 relations and 4622391 ideals in 20 passes
max relations containing the same ideal: 35
reading ideals above 100000
commencing singleton removal, initial pass
memory use: 172.3 MB
reading all ideals from disk
memory use: 214.9 MB
keeping 5743998 ideals with weight <= 200, target excess is 30627
commencing in-memory singleton removal
begin with 5783900 relations and 5743998 unique ideals
reduce to 5764854 relations and 5724436 ideals in 12 passes
max relations containing the same ideal: 200
relations with 0 large ideals: 109
relations with 1 large ideals: 66
relations with 2 large ideals: 913
relations with 3 large ideals: 12516
relations with 4 large ideals: 96261
relations with 5 large ideals: 423926
relations with 6 large ideals: 1111089
relations with 7+ large ideals: 4119974
commencing 2-way merge
reduce to 3073431 relation sets and 3034492 unique ideals
ignored 1479 oversize relation sets
commencing full merge
memory use: 96.2 MB
found 60399 cycles, need 631827
too few cycles, matrix probably cannot build
Return value 65280. Terminating...

[jasonp]

This looks like a case where you have slightly too few relations to create a matrix successfully. A few hours of more sieving should be enough to make it work.

[tmorrow]

Thanks Jason, I appreciate your help. Up to now I've been running GGNFS through factMsieve.pl, an automated wrapper script that takes care of all stages of the calculation. I'm not sure how to invoke the sieving alone for a few hours. Does it have anything to do with the commands

"../../bin/gnfs-lasieve4I13e" -k -o spairs.out.T1 -v -n0 -a c130.job.T1
"../../bin/gnfs-lasieve4I13e" -k -o spairs.out.T2 -v -n0 -a c130.job.T2

I found the above in the the program output (I'm running 2 threads).

[jasonp]

The experts on this read the 'running GGNFS' thread. factMsieve.pl looks for a MINRELS.txt file the cause sieving to continue until that many relations have accumulated, exactly for this kind of problem.