Each user has a set of permissions for each space they have access to. They are as follows:
Can the user create new spaces within the given space?
Can the user remove any spaces within the given space?
Can the user create new jobs in the given space?
Can the user remove jobs from the given space?
Can the user bring new users into the given space?
Can the user remove existing non-leaders from the given space?
Can the user upload or copy benchmarks into the given space?
Can the user remove benchmarks from the given space?
Can the user upload or copy solvers into the given space?
Can the user remove solvers from the given space?
Space leader: In addition to the permissions defined above, a user can be a space leader. This gives him or her all the permissions above by default. Space leaders can also set the space's default permissions (see below) or remove the space. The creator of a space is that space's leader by default. Space leaders are designated by other space leaders and can not be removed by fellow leaders, not even the original creator of the space. A leader can change non-leaders' permissions by modifying them in the tool tip that appears when the mouse hovers over a user in the user table on the space explorer page.
As you can see in the script above,
$1 is a special environment variable whose value is passed to your run script when it is executed. Here is a list of arguments and environment variables your script can utilize (more will be added in the future).
The absolute path to the benchmark input file
The absolute path to the StarExec output directory. Any files written here will be saved by StarExec so you can download them after the job is complete. Files written elsewhere are removed after each job run.
The wall clock time limit in seconds before your job pair is terminated. This can be set at job creation time, and has a global cap at 259,200 seconds (3 days).
The CPU time limit in seconds before your job pair is terminated. This can be set at job creation time, and has a global cap at 259,200 seconds (3 days).
The maximum amount of memory in megabytes (without any suffix like "MB"; just a single number) which your job pair can consume before being terminated. This is user configurable and has a current limit of half the physical memory of the compute node (it is half because we hope to run two jobs per node at some point soon). For nodes in the execution queue all.q, half the memory is 128GB. For those in all2.q it is 64GB.
The maximum amount of writable disk space your job pair can consume before being terminated. This is not user configurable and has a current limit of 20GB.
Benchmarks are single text files that are fed to solvers when jobs are created. The name of a benchmark can be any legal file name in Linux, with a maximum length of 255 characters.
Select the file to upload from your local machine. Like solvers, benchmarks must be uploaded as a
tar.gzarchive file. The archive can contain multiple files and directories. Every file contained in the archive will be treated as a benchmark. Please remove any readme files or metadata files before uploading your benchmarks to StarExec or they will be added to StarExec as a benchmark.
- upload source
You can chose to upload either a local archive or one on the web. In the second case you must provide the archive's URL.
As mentioned previously, your archive may contain directories in addition to files. StarExec has two methods of dealing with directories.
- Convert directory structure to space structure
For every directory (and subdirectory) in your archive, StarExec will create a space whose name is the directory's name. It will then place all files within that directory into that space as benchmarks. Any files that are in the top level directory of the archive are placed into your chosen destination space.
- Place all benchmarks in space
This method ignores directories and recursively finds all files within the archive and adds them into the selected destination space. This option essentially flattens your archive.
- Convert directory structure to space structure
- default (permissions)
If you selected the option, you will need to set the default permissions for all spaces that are created as a result of the benchmark upload (see default permission for spaces above for more details).
- benchmark type
This is the type of benchmark you are uploading. The benchmark will be validated by the benchmark processor created by a community leader for that type. See Benchmark types below for more details.
Select yes to allow other users who can see your benchmarks to download the benchmarks you are uploading (or otherwise see their contents). Otherwise, select no.
Select yes if this set of benchmarks might be dependent on a previously uploaded set of benchmarks --- such as a set of axioms.
- dependency root space
This is the space containing the benchmarks that yours dependent on. These benchmarks must be in the space tree rooted at this space. The paths that reference benchmarks in this tree must begin with this space or a direct child of it.
- first directory in path corresponds to dependent bench space
If you have chosen a space called
Axiomsas your dependency root space and the references to this space are of the form
include('Axioms/SETTHEORY/Choice.ax'), then click yes. In contrast, if you have include statements like
include('Geometry/ParallelP.ax')then choose no. In the latter case,
SETTHEORYmust be subspaces of the dependency root space you selected.
Note: Python 2.7 is available on the head node and compute nodes. However, if you want to use it you have to load that version explicitly using the Linux modules system. Just add these lines to the start of a wrapper shell script before calling your solver:
source /usr/share/Modules/init/sh module load python/python27
GCC 7.2 can be enabled by adding the following to a solver build script:
scl enable devtoolset-7 bash