parameters

# Parameters form a tree structure. 
# A parameter of the form
# foo.bar.baz = 42
# is said to have path "foo.bar", key "baz", and value "42".

# All quotes in the comments in this file are for emphasis and not part of
# the parameters.

# Objects of the Python scripts that take parameters from the parameter file 
# have a path associated with them; for example, the Sieving task uses path
# "tasks.sieve", and the las siever run in the Sieving task uses
# "tasks.sieve.las". When looking for a parameter, we start at the object's 
# path, then work towards to root of the tree until the key is found.
#
# Note that an automatically generated, and by construction comprehensive
# list of the recognized parameters can be obtained by starting (and
# quickly aborting, if needed) the cado-nfs.py script with the
# --verboseparam option. It will do a couple of things, but it will also
# print this list.

# Some variable substitution occurs in the values specified in a parameter file:
# A string of the form "${FOO}" is substituted by the value of the shell
# environment variable "$FOO".
# A string of the form "$(foo)" is substituted by the value of the parameter
# with key "foo", where the search starts at the path where "$(foo)" occurred.


# name: The name of the factorization project. Will be used as part of file
# names, among other things, so probably should be alphanumeric.
# Everything needs to know the name of the factorization, so this should be
# specified at the root of the parameter tree.

name = test_run


# N: The number to be factored

N = 90377629292003121684002147101760858109247336549001090677693


# Adjust sourcedir to point to the root of your CADO source directory. 
# This parameter is not actually used by cadofactor directly, but it is 
# referenced as $(sourcedir) further down in the parameter file.

sourcedir=${HOME}/git/cado-nfs


# Adjust builddir to point to the root of your CADO build directory
# Not used directly, either, but referenced, too.
# This default value here points to the default build directory of
# CADO, but a problem is that HOSTNAME may not be an exported variable
# of the shell. In that case, the "${HOSTNAME}" here needs to be
# replaced, or the HOSTNAME variable needs to be exported manually.

builddir=$(sourcedir)/build/${HOSTNAME}


# Parameters for the various tasks performed during the factorization

# workdir: the path of the working directory; if a relative path is
# specified, it is relative to the CWD from which cadofactor is run.
# All the output files of sieving, filtering, etc., are stored under the
# working directory.
# In principle it is possible to specify a different working directory for
# each task, which may be beneficial to use disk space across several file
# systems, or to let filtering tasks read from one hard drive while writing
# to another, improving throughput.

tasks.workdir = /tmp/work/


# execpath: Specify the search path for binary programs that should be run.
# Each binary program that is run can be specified with "execpath",
# "execsubdir", and "execbin" parameters; the script looks for the binary
# executable as "execpath/execsubdir/execbin" and "execpath/execbin", in this
# order. Defaults for these parameters are defined for each program in
# cadoprograms.py.
# The Program instances use parameter path, e.g., "tasks.sieve.las", or
# "tasks.filter.merge", but of course can find their parameter from
# further up the parameter tree, such as in "tasks".

tasks.execpath=$(builddir)
# Example: if you wanted to use a debugging-enabled binary for las which
# is in "${HOME}/build/cado-nfs/debug", you could specify
# tasks.sieve.las.execpath=${HOME}/build/cado-nfs/debug


# verbose: Verbosity of program output. Many programs accept a -v (or
# similar) command line flag; this parameter specified whether verbose
# output should be enabled. Has no effect on cadofactor itself, just on the
# sub-programs.

tasks.verbose = 1
# An example of overriding the tasks.verbose=1 for the polyselect task
# tasks.polyselect.verbose = 0


# lim0, lpb0, mfb0, lambda0, lim1, lpb1, mfb1, lambda1: The sieving
# parameters. Also used by several other Tasks and Programs, so best
# specified at path "tasks" where everyone can find them.

tasks.lim0=50000
tasks.lim1=100000
tasks.lpb0=22
tasks.lpb1=22
tasks.mfb0=22
tasks.mfb1=22
tasks.lambda0=1.2
tasks.lambda1=1.2
tasks.I = 11


# threads: number of threads to use in sub-programs.
# For programs that support multi-threading (e.g., polynomial selection,
# sieving, linear algebra), this specifies the number of threads to use.

tasks.threads=2


# For tasks that use the client/server set-up, set a time-out in seconds
# after which assigned workunits for which no result was returned get 
# cancelled and re-submitted to the database, so that other clients can 
# (hopefully) finish them

# Workunits for this test factorization are quite short, 120s is ok
tasks.wutimeout = 120

# After a total of maxtimedout workunits have timed out, the factorization
# is aborted, as such a large number of timed out workunits may indicate a
# problem with the clients. The default is 100. For large factorization on
# unreliable machines which can be stopped/restarted frequently, this limit
# is probably too small and should be increased.

tasks.maxtimedout = 100


# P, degree, admin, admax, adrange: Parameters for the polynomial search
tasks.polyselect.P = 420
tasks.polyselect.degree = 4
tasks.polyselect.admin = 0
tasks.polyselect.admax = 10000
tasks.polyselect.adrange = 5000
# nrkeep: Keep the 20 best size-optimized polynomials from polyselect 
# phase 1 and rootsieve them in polyselect phase 2
tasks.polyselect.nrkeep = 20
# batch: how many polynomial to put in each WU in the rootsieve phase
tasks.polyselect.batch = 10                              

# define tasks.sieve.sqside to select the side where to put the special-q's.
# By default the largest norm is on side 1, so sqside=1 is to be chosen
# in general.
tasks.sieve.sqside=1

tasks.sieve.rels_wanted = 122540
tasks.sieve.qrange = 2000
tasks.filter.nslices_log=1
tasks.filter.keep = 160
tasks.filter.skip = 32
tasks.filter.target_density = 170
tasks.linalg.m = 64
tasks.linalg.n = 64
tasks.linalg.verbose = 0
tasks.linalg.nchar = 64
# tasks.linalg.bwc.threads can be of the form 2x3 or in the form 6, in the
# latter case the splitting is chosen automatically
tasks.linalg.bwc.threads = 2x2

# address: The server of the client/server set-up will listen at this
# address. Note that listening on address "localhost" will allow only
# clients running on the same machine to connect. If not specified, the
# computer's hostname will be used, which usually resolves to a network-
# visible address so clients on other machines can connect.

# server.address = localhost


# port: The server of the client/server set-up will listen at this
# port. It can be useful to specify a different value (8001, 8002, ...)
# to be able to run several factorizations on the same machine.

server.port = 8012


# ssl: whether to use SSL for client/server communication.
# Without SSL authentication and encryption, it is possible for an attacker
# on the same network to modify workunits sent to clients and so effect
# execution of malicious code on the client machines. With SSL, clients
# are started with the server's certificate fingerprint as a command line
# argument, and verify the certificate when first connecting. The
# certificate is then used for all subsequent communication.
# The default is yes.

# server.ssl = yes


# whitelist: a comma separated list of IP ranges that should be allowed to
# contact the server. The IP ranges are given in CIDR format: an IP address,
# optionally followed by a slash and the number of most significant bits
# that need to match. For example, 192.168.0.0/24 means that all IP
# addresses in the range 192.168.0.0, ..., 192.168.0.255 are allowed.
# Here, hostnames can also be used in place of the IP address, their name
# will be resolved to an IP address.
# Note that the hostnames on which cadofactor starts clients, i.e., the
# hostnames in the slaves[...].hostnames parameters, are always added to the
# whitelist. You should have to whitelist addresses manually only if you
# want to start clients manually.

# server.whitelist = 192.168.0.0/24,localhost


# Clients which cadofactor should start are specified under "slaves".
# We look for any path under "slaves" with a "hostnames" key, then for each 
# hostname specified (comma separated list, with multiplicity), one slave is
# launched on that host.
# If the hostname is of the form "@filename", then the host names are read
# from the file "filename", one host name per line, with the same
# multiplicity rule.
# Note: if the hostname for a client is "localhost", then the client is
# started directly as sub-processes of the cadofactor script; if it is not
# "localhost", then clients are started through SSH. This affects the
# client's current working directory: if the client is started as a
# sub-process, its CWD is the same as that of the cadofactor script; if it
# is started through SSH, its CWD is the CWD after an SSH login (usually the
# user's home directory).

slaves.hostnames = localhost
# Example with multiple hostnames. This launches one client on localhost,
# two on otherhost1, and one on otherhost2, assuming there is no nrclients 
# parameter (see below) that would override the multiplicity
# slaves.hostnames = localhost, otherhost1, otherhost1, otherhost2


# Modifies the behaviour of the hostnames list: if nrclients is specified,
# then multiplicity in the hostnames list is ignored, and "nrclients" client
# scripts are launched on each unique host name.

slaves.nrclients = 2


# scriptpath: The path to the cado-nfs-client.py scripts, on the slave's file
# system.

slaves.scriptpath = $(sourcedir)


# downloadretry: Number of seconds a client should wait between failed
# download attempts from the server

slaves.downloadretry = 10


# basepath: defines the base directory under which cado-nfs-client.py creates its
# download and working directories. It is permissible to let all clients of
# the same factorization to use the same download directory; files are
# protected by locking to prevent download races. If the download directory
# is on a shared file system, then this filesystem must support locking.
# The working directories should probably be unique; the default choice for
# the working directory includes the clientid which should ensure uniqueness.

slaves.basepath = /tmp/work/$(name).wuclient


# If you want to launch clients on multiple groups of slave machines, with
# different parameters per group, you can group them by different parameter
# paths, like so:

# slaves.downloadretry = 10
# slaves.basepath = /tmp/wuclient
# slaves.home.hostnames = localhost
# slaves.home.nrclients = 1
# slaves.home.scriptpath = $(sourcedir)/scripts/cadofactor
# slaves.work.desktop.hostname = workstation1, workstation2
# slaves.work.desktop.scriptpath = /path/to/scripts/cadofactor
# slaves.work.cluster.hostname = clusternode1, clusternode2, clusternode3
# slaves.work.desktop.scriptpath = /other/path/to/scripts/cadofactor
## Use 4 slaves on all "work" slaves, both "desktop" and "cluster"
# slaves.work.nrclients = 4

# Here, "home", "work", "workstation", and "cluster" are arbitrary 
# alphanumeric strings; their sole purpose is to create different nodes in 
# the parameter tree. 

# A slightly advanced feature is prefixing the command line that is used on
# the client machine to run cado-nfs-client.py by a word of your choosing. This
# could be a shell wrapper that sets up the execution environment, or a
# particular choice of Python interpreter, etc.
# For the slave machines specified in "slaves.hostnames", the "runprefix"
# parameter is searched in "slaves.cado_nfs_client.runprefix" (and therefore, if
# not present there, in "slaves.runprefix", then in "runprefix"). For 
# slaves specified in slaves.work.desktop.hostname, the search starts in
# "slaves.work.desktop.cado_nfs_client.runprefix".

# This example uses the debugging-enabled Python 3.2 interpreter to run
# cado-nfs-client.py.
# slaves.cado_nfs_client.runprefix = /usr/bin/python3.2-dbg

# If you want to do computations with slaves on machines with different
# operating systems or CPU architectures, then the binaries to run cannot
# be distributed by the server, as currently there is no mechanism in
# cadofactor for distributing different binaries to different slaves.
# A work-around to this is to copy the correct binary (for las and
# polyselect) manually into the different slaves' download/ directories,
# and disabling the SHA1 check for downloaded files so that the clients
# use the supplied files without checking their SHA1 against the hash
# supplied in the workunit. Disabling the SHA1 check can be effected with
# the --nosha1check option to cado-nfs-client.py, which can be enabled in the
# parameter file by setting:
# slaves.cado_nfs_client.nosha1check = True

# If the "--bindir path/to/executables/" parameter for cado-nfs-client.py is
# specified, it does not try to download any executable files, but
# uses the executables in the directory path/to/executables/ (where
# they must exist, i.e., you need to copy them there). Their SHA1
# checksum is not verified against the value in the workunit, so
# machine-specific binaries can be used.
# slaves.cado_nfs_client.bindir = /usr/local/bin