Running GGNFS

[Mini-Geek]

I added the relations from another 100k chunk of q (total almost 5M raw relations, reduced to 691682 relations and 663113 ideals, 205020 cycles) and it finished without a problem. c103=p49*p54
Thanks.

[Andi47]

gnfs-lasieve4I12e just crashed on a c88:

 This is client 1 of 1
 Using 2 threads
 Working with NAME=test...
 Selected default factorization parameters for 88 digit level.
 Selected lattice siever: F:/Wissenschaft/Mathe/GGNFS/BIN/gnfs-lasieve4I12e.exe
 Creating param file to detect parameter changes...
 Q0=360001, QSTEP=10000.
 makeJobFile(): q0=360000, q1=370000.
 makeJobFile(): Adjusted to q0=360001, q1=370000.
 Lattice sieving algebraic q-values from q=360001 to 370000.
 "F:/Wissenschaft/Mathe/GGNFS/BIN/gnfs-lasieve4I12e.exe" -k -o spairs.out.T1 -v -n0 -a test.j
.T1
 "F:/Wissenschaft/Mathe/GGNFS/BIN/gnfs-lasieve4I12e.exe" -k -o spairs.out.T2 -v -n0 -a test.j
.T2
"F:/Wissenschaft/Mathe/GGNFS/BIN/cat.exe" spairs.out.T1 >> spairs.out
"F:/Wissenschaft/Mathe/GGNFS/BIN/cat.exe" spairs.out.T2 >> spairs.out
 Return value 130560. Updating job file and terminating...
"F:/Wissenschaft/Mathe/GGNFS/BIN/cat.exe" spairs.out >> spairs.add
 makeJobFile(): q0=360000, q1=370000.
 makeJobFile(): Adjusted to q0=360001, q1=370000.
***crash***

edit: after the crash, I got a windows error message that there has been a problem with gnfs-lasieve4I12e and the job has to be terminated.

Polynomial is:

n: 2442895043335315532241384991110259348565485108389595693855451132244907689766065727669961
m: 
Y0: -923404484710773674886
Y1: 190201825129
c0: -6095776657859982538195471
c1: -14427067949801133934
c2: 13273075276639
c3: -89656634
c4: 3360
skew: 269617.07
rlim: 600000
alim: 360000
lpbr: 25
lpba: 25
mfbr: 43
mfba: 43
rlambda: 2.2
alambda: 2.2
q0: 360001
qintsize: 4999
#q1:365000

(resp. with q0=365000 for the second part of the job, at least one of these just crashed.)

BTW: It is NOT a disk full issue, as I have 4 GB free disk space.

[Batalov]

No crash with the linux binary. Jeff may help esting the windows binary crash.

I suggest repeating (just to see if it crashes again), and then skipping the subrange (you only need to edit test.job.T1, set q0 to 370001, and start factMsieve.pl again; when factors are found, restart aliqueit -f ...) and forgetting about it.

[Andi47]

Originally Posted by Batalov

No crash with the linux binary. Jeff may help esting the windows binary crash.

I suggest repeating (just to see if it crashes again), and then skipping the subrange (you only need to edit test.job.T1, set q0 to 370001, and start factMsieve.pl again; when factors are found, restart aliqueit -f ...) and forgetting about it.

For me it crashed again after repeating (windowd binary on a P4).
These kind of crashes seem to happen quite frequently (with the windows binaries) for composites <c90, so I prefer to set the crossover point in aliqueit.ini (I am doing automated factorizations using aliqueit.exe.) to c90 rather than c85 when I am NOT around to recover the run from crashes.

(if you want to have more testing cases: go to the subproject thread over there in the aliqueit forum, reserve a sequence or two and let them run for a day with the crossover point between MPQS and GNFS set to c85 in the aliqueit.ini.)

[Andi47]

Another test case which seems to crash reproducibly (at least when I try to factor it with factmsieve.pl) which a windows exception message concerning gnfs-lasieve4I12e

n: 326038543709470087296096782349895406069109369957419965789980768092711144124260014949595783289
m: 
Y0: -19198498542350696153230
Y1: 1231688614399
c0: -3374692143493600413536451
c1: 290889882624121690652
c2: -214715152886731
c3: -978296298
c4: 2400
skew: 446522.96
rlim: 1200000
alim: 350000
lpbr: 25
lpba: 25
mfbr: 45
mfba: 45
rlambda: 2.4
alambda: 2.4
q0: 350000
qintsize: 49999

[Jeff Gilchrist]

Originally Posted by Andi47

Another test case which seems to crash reproducibly (at least when I try to factor it with factmsieve.pl) which a windows exception message concerning gnfs-lasieve4I12e

How long did it take to crash? I'm testing this out now on a Win32 P4 system to see if it does for me.

Jeff.

[Andi47]

Originally Posted by Jeff Gilchrist

How long did it take to crash? I'm testing this out now on a Win32 P4 system to see if it does for me.

Jeff.

I attempted to factor this number by factmsieve.pl (started from aliqueit.exe after ecm had found no factors); if I have seen correctly, it crashed almost immediatly after starting the range of q=350k - 390(?)k.

When I tried to restart again, it crashed again almost immediately.

[smh]

Just try increasing q0 to 360K or so

[Andi47]

Originally Posted by smh

Just try increasing q0 to 360K or so

...or factoring with MPQS (msieve or yafu); both works.

the problem is not that a factorization would become "inpossible", the problem is that if it crashes, and I am not around for quite some time (i.e. some days), the CPU would be idle. (and when I come back to that PC and expect a finished task I find out that it got stuck at the beginning - just an hour before I had left for weekend.)

[Jeff Gilchrist]

Originally Posted by Andi47

I attempted to factor this number by factmsieve.pl (started from aliqueit.exe after ecm had found no factors); if I have seen correctly, it crashed almost immediatly after starting the range of q=350k - 390(?)k.

When I tried to restart again, it crashed again almost immediately.

Not sure what is going on with your system, mine just completed fine with this:

prp34 factor: 1499584989766220246253035078939017
prp60 factor: 217419183263696371366953971030857366769285808426067018460017

No crash at all. Are you sure your system is stable? I will try your previous example and see what happens there. <- Ok your first example is crashing for me, not sure why yet.

[ltd]

Are you sure that everything is OK with your executable?
I have tried your number with my self compiled siever version and everything worked without any problems.

I used factmsieve.pl from within cygwin and used a windows 32Bit version of the siever compiled with VS2008 and MPIR instead of GMP. (P4 assembly routines).