Discussion related to cado-nfs

[paul zimmermann <Paul.Zimmermann@inria.fr>]

       Greg,

it seems to work with the git version (just fixed the fact that the command
line was not printed in c60.freerel.freerel.stdout.1):

zimmerma@tarte:~/svn/cado-nfs$ ./factor.sh 
90377629292003121684002147101760858109247336549001090677693 
tasks.sieve.freerel.threads=3
...
zimmerma@tarte:~/svn/cado-nfs$ head -1 
/tmp/cado.hDYwnLCKdk/c60.freerel.freerel.stdout.1 
# (747a3bd+) /users/caramel/zimmerma/svn/cado-nfs/build/tarte/sieve/freerel 
-poly /tmp/cado.hDYwnLCKdk/c60.polyselect2.poly -renumber 
/tmp/cado.hDYwnLCKdk/c60.freerel.renumber.gz -lpb0 18 -lpb1 19 -out 
/tmp/cado.hDYwnLCKdk/c60.freerel.freerel.gz -t 3

Please can you check again (with the latest git version) and report here?

Paul

> Date: Sat, 8 Aug 2015 14:05:16 -0500
> From: Greg Marks <marks@member.ams.org>
> 
> Dear Paul,
> 
> Thank you for appended message containing the patch.  I did change
> the dup2.c file as indicated in your message below, and recompiled.
> The program has been sieving successfully for perhaps a month since
> then, and I have not encountered this zero-byte problem again.  So this
> probably means that problem is solved.
> 
> Incidentally, in another message you suggested that one could speed up
> the free relation calculation when restarting a computation in a fresh
> working directory with the command:
> 
>    cadofactor.py ... tasks.sieve.freerel.threads=3
> 
> I've tried this a few times, including with other numbers in place of
> 3, but the freerel routine uses only one core no matter what I try.
> Admittedly this isn't that important, since it's only an extra hour
> or two from time to time in a months-long computation.  (There is a
> sort of psychological reason to want to speed this step along: what's
> usually happened is that I've deleted some corrupted sieving file and
> am anxious to see whether las is going to restart without errors.)
> 
> Sincerely,
> Greg 
> 
>     ------------------------------------------------
>    | Greg Marks                                     |
>    | Department of Mathematics and Computer Science |
>    | St. Louis University                           |
>    | St. Louis, MO 63103-2007                       |
>    | U.S.A.                                         |
>    |                                                |
>    | Phone: (314)977-7206        Fax: (314)977-1452 |
>    | PGP encryption public key ID: 0x53F269E8       |
>    | Web: http://gmarks.org                         |
>     ------------------------------------------------
> 
> Message from paul zimmermann <Paul.Zimmermann@inria.fr>
> of June 29, 2015, 18:03:18 +0200, follows:
> > > The program now terminates with the error message appended at the bottom
> > > of this message.  The file $WORKDIR/c184.duplicates1//0/dup1.1.0000.gz
> > > mentioned in the stderr below turns out to be a 20 byte file, which,
> > > when gunzipped, is a zero byte file.
> > 
> > it is a bug that a zero byte file is not accepted in dup2. I fixed this in
> > commit 73aa354 (review welcome).
> > 
> > Greg, please could you try again with this change?
> > 
> > --- a/filter/dup2.c
> > +++ b/filter/dup2.c
> > @@ -432,11 +432,18 @@ int check_whether_file_is_renumbered(const char * 
> > filename, unsigned int npoly)
> >      unsigned int count = 0;
> >      char s[1024];
> >      FILE *f_tmp = fopen_maybe_compressed (filename, "rb");
> > +
> >      if (!f_tmp) {
> >          fprintf(stderr, "%s: %s\n", filename, strerror(errno));
> >          abort();
> >      }
> >  
> > +    if (feof (f_tmp)) /* file is empty */
> > +      {
> > +        fclose_maybe_compressed (f_tmp, filename);
> > +        return 1; /* an empty file might be considered as renumbered */
> > +      }
> > +
> >      /* Look for first non-comment line */
> >      while (1) {
> >        char *ret = fgets (s, 1024, f_tmp);
> > 
> > Paul
> 
> [2:application/pgp-signature Show Save:signature.asc (819B)]
>