mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   CADO-NFS (https://www.mersenneforum.org/forumdisplay.php?f=170)
-   -   Executing "las" stand-alone (https://www.mersenneforum.org/showthread.php?t=25654)

RichD 2020-06-19 22:40

Executing "las" stand-alone
 
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.
[CODE]# () ./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[/CODE]

The poly file and fb1 are the same file. Both which needs to be provided, apparently.
[CODE]n: 605716904027877980774625455520189647387776352555063757365644672493136637525085152114527251672682055452329862008130550673203343550128250999766605061023948523297828457779191592093682881010498969046911261346842026672855745883554109771998292748069377018429964450347583969787
skew: 9.494
c6: 1
c5: 0
c4: 0
c3: 0
c2: 0
c1: 0
c0: -732541
Y1: -1
Y0: 82919274927962023982932249248351337261442889121[/CODE]

The only clue I get is in stdout to the console.
[CODE]# fb_read: prime is not an integer on line 1[/CODE]

I have no idea what needs to be corrected.

charybdis 2020-06-19 23:58

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
[code]./makefb -poly 732541-47.txt -lim 536000000 -maxbits 16 -out 732541-47.fb.gz -t <num_threads>[/code]
(substitute lim1 and I for 536000000 and 16 in general)

RichD 2020-06-20 20:59

I mis-read [url=https://www.mersenneforum.org/showpost.php?p=514507&postcount=364]this post[/url] 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 [B]charybdis[/B].

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

RichD 2020-06-22 02:38

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 2020-06-22 03:08

From the output of [C]las -h[/C]:

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

-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.


All times are UTC. The time now is 03:35.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.