![]() |
[QUOTE=10metreh;171001]I presume you were sieving at the time. Go into the folder aliqueit has created for the ggnfs job. Rename "spairs.out" to "spairs.add". Get the last special q from ".last_spq0" and change the q0 in "test.job" to that value. (Do not change qintsize or q1.) Restart aliqueit with the -e switch. First it will call msieve to do the poly search. As it has already found a poly, it will stop and aliqueit will run factMsieve.pl, resuming from where you left off.[/QUOTE]
Thanks! |
[QUOTE=Andi47;171000]Is there an option / switch to resume a GNFS-factorization when it was interrupted?[/QUOTE]Maybe we could lobby for a switch to re-start automagically....
|
[quote=schickel;171010]Maybe we could lobby for a switch to re-start automagically....[/quote]
Automagically? Was that a typo, or a joke pretending to be a typo? |
Well, if you can live with redoing the last partial sieve segment (I can :smile:), you can just start aliqueit -e and it'll restart sieving from the last completed segment.
|
A multi-core version would still be highly appreciated. In fact, it would only involve multiple instances of ecm, and possibly continuing ecm along yafu. Multicore-ggnfs is already implemented in the Perl-script.
While obviously less effective on some 24h/d- computer, on my laptop which is often swiched on and off, having twice as often a breakpoint for GGNFS without waiting for ECM is an issue. I used to outsource ECM to the database, but given the madness going on there, this is no longer an option. Can this convince you? H. |
[QUOTE=hhh;171588]Can this convince you?[/QUOTE]
Maybe. :smile: I would kinda like it myself too. |
what about date/timestamps in aliqueit.log?
like: [code] [2009-04-30 22:34] c98: running P-1 at B1=1e7... [2009-04-30 22:45] c98: running P+1 x3 at B1=5e6... [2009-04-30 23:12] c98: running 478 ecm curves at B1=1e6... [2009-05-01 00:34] c98: running qs (yafu)... [/code] (note: timings not real) yafu puts it's own timestamps in the log, so no need. and for gnfs like: [code] [2009-05-30 10:34] c104: running gnfs (ggnfs)... [2009-05-30 13:34] *** prp41 = 42908226275010576687094140721438858113571 [2009-05-30 13:34] *** prp63 = 843514729490186966042430055073623774745677929759731469884704651 [/code] |
[QUOTE=kar_bon;171791]what about date/timestamps in aliqueit.log?[/quote]
Yeah, that's a good idea, I've found myself missing that a couple of times as well. |
when a sequence merges
Errh... not a bug that is easily seen (I've been lucky to see it):
if/when a sequence merges, then I'd suggest to make a note in the output and continue running until it makes (let's say) 20 upward steps. It may as well terminate (which it did). It is only for convenience (it is easily done manually), maybe with an extra command-line parameter. E.g. -k (which in makefiles means "keep going" unconditionally). EDIT: :doh!: --Serge |
[QUOTE=Batalov;172489]Errh... not a bug that is easily seen (I've been lucky to see it):
if/when a sequence merges, then I'd suggest to make a note in the output and continue running until it makes (let's say) 20 upward steps. It may as well terminate (which it did). It is only for convenience (it is easily done manually), maybe with an extra command-line parameter. E.g. -k (which in makefiles means "keep going" unconditionally). --Serge[/QUOTE] You can set detect_merge = false in the .ini and it'll keep going. I think that's sufficiently easy to do if indeed you get lucky and need to use it. :smile: edit: I'd like to allow "-detect_merge false" (and any other .ini setting) to be passed on the cmdline as well, but I haven't gotten around to it yet. |
[QUOTE=bsquared;166050]If you don't have access to a linux system then maybe you can't do anything about this, but I have one request. When I try to kill aliqueit when it's running via cntl-c it instead kills the program (yafu/msieve/ecm) that is running at that moment, and aliqueit immediately continues on and launches another factorization. So I have to cntl-z to the background, ps for the process IDs, kill the factorization job, then kill aliqueit, then fg aliqueit. Quite a process to stop the thing from running. Is there a way for aliqueit to intercept the cntl-c and stop it's execution instead?[/QUOTE]
Fiddling around with virtualbox right now, I ran into the same problem. Just spamming ctrl-c by keeping the keys depressed a couple of seconds works for me, but maybe you aren't so lucky? Just a thought. |
| All times are UTC. The time now is 09:57. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.