Executing "las" stand-alone

[RichD]

I am trying to perform test sieving by executing the las program by passing the parameters in the command line.

The output file, which contains the command line syntax, provides no clues.

# () ./las -v -poly 732541-47.txt -out 20M.txt -I 16 -q0 20000000 -nq 5000 -sqside 0 -lim0 536000000 -lim1 536000000 -lpb0 33 -lpb1 33 -mfb0 66 -mfb1 96 -fb1 732541-47.txt
# List of modified files in working directory and their SHA1 sum:
# (tarball extracted)
# Compiled with gcc 7.4.1 20190905 [gcc-7-branch revision 275407]
# Compilation flags (C) -std=c99 -g -W -Wall -O2  -msse3 -mssse3 -msse4.1 -mpopcnt -mavx -mpclmul
# Compilation flags (C++) -std=c++11 -Wno-c++11-compat -g -W -Wall -O2  -Wno-literal-suffix -msse3 -mssse3 -msse4.1 -mpopcnt -mavx -mpclmul
# las.c flags: LOGNORM_GUARD_BITS=1.00
# Interpreting -I 16 as meaning -A 31
# No -t option found, running single-threaded.
# Getting rid of sieve_shared_data structure [rss=4884.00 k]
# Applying binding machine,1,1 with hwloc disabled
# 1 jobs in parallel
# 1 threads per job
# Expected memory usage per binding zone for the factor base: 0.89 GB
# Expected memory usage per subjob for logI=16: 7.48 GB
# Expected memory use per subjob (max reached for logI=16): 7.48 GB
# Expected memory use for 1 binding zones and 1 1-threaded jobs per zone, counting 24 MB of base footprint: 8.40 GB
# Using default value powlim0=ULONG_MAX
# Creating side-0 rational factor base for polynomial f0(x) = 82919274927962023982932249248351337261442889121-1*x
# including primes up to 536000000 and prime powers up to 18446744073709551615 using threadpool of 1 threads.
# Creating side-0 rational factor base took 7.7s (9.9s real)
# Using default value powlim1=ULONG_MAX
# Reading side-1 factor base from disk for polynomial f1(x) = -732541+x^6
# Reading side-1 factor base from 732541-47.txt

The poly file and fb1 are the same file. Both which needs to be provided, apparently.

n: 605716904027877980774625455520189647387776352555063757365644672493136637525085152114527251672682055452329862008130550673203343550128250999766605061023948523297828457779191592093682881010498969046911261346842026672855745883554109771998292748069377018429964450347583969787
skew: 9.494
c6: 1
c5: 0
c4: 0
c3: 0
c2: 0
c1: 0
c0: -732541
Y1: -1
Y0: 82919274927962023982932249248351337261442889121

The only clue I get is in stdout to the console.

# fb_read: prime is not an integer on line 1

I have no idea what needs to be corrected.

[charybdis]

I think the problem is that you haven't made the factor base yet - that's what -fb1 is supposed to be pointing to. You can construct it by a command like

./makefb -poly 732541-47.txt -lim 536000000 -maxbits 16 -out 732541-47.fb.gz -t <num_threads>

(substitute lim1 and I for 536000000 and 16 in general)

[RichD]

I mis-read this post thinking the output was the same as the poly file without the parameters. It (las) seems to be generating something now. Thanks for your help charybdis.

BTW, makefb generates a large file. Nearly 350MB in this case.

[RichD]

Now it seems 100s of thousands of relations are being generated. Either the -nq switch is not the same as the -c switch in the GGNFS suite or I am using the wrong one. The next step for me is to download a later copy of CADO-NFS and pick a smaller number for testing. It seems there are reciprocal parameters between the two packages. CADO generates many more relations but also needs many more relations to build a matrix. Any advice is welcome. There are many moving parts (parameters) that control the relations gathering and the goal is to minimize the elapse time to completion.

[charybdis]

From the output of las -h:

    -q0        left bound of special-q range
    -q1        right bound of special-q range
...
    -nq        Process this number of special-q's and stop

-nq does not specify the size of the range like the GGNFS -c does: it specifies the number of special-q that are sieved. Since only primes are used as special-q, -nq 5000 will sieve a much larger range than -c 5000; I've tested and this does indeed happen. It's better to use -q1 instead.