# 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. # 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.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.filter.maxlevel = 15 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, means that all IP # addresses in the range, ..., 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 =,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