Start by cloning the git-repository
cd ~/path_to_somewhere git clone firstname.lastname@example.org:materials-modeling/storq.git
Next you can either proceed to carry out a standard install via pip
pip install ~/path_to_somewhere/storq
or by manually adding the paths to storq and its associated binaries to your
export PYTHONPATH=$PYTHONPATH:~/path_to_somewhere/storq export PATH=$PATH:~/path_to_somewhere/storq/bin
Next you need to generate a configuration file. storq comes with a command line interface that can take care of the bulk of the configuration for you. To initiate the automatic configuration run
storq configure --auto
The configuration process will alert you as to any settings which could not be automatically detected and hence need to be provided manually.
Note that some settings are optional, in which case only a warning is issued while others are critical for the operation of storq and are hence marked as “fatal”.
Note that it is not uncommon that the automatic setup fails to find the binaries and
POTCAR files since it can be hard to search for many different names across potentially more than one file system.
In particular for the
POTCAR files, storq requires a folder, which contains subdirectories named
<XC> can be
GGA and the subdirectory must contain the corresponding
Naturally, if you wish to use PBE setups exclusively, only
potpaw_PBE needs to exist.
Once you have completed the automatic configuration (and addressed any of its complaints) it might be necessary to set your
mpirun command in order to be able to run calculations.
This is the case if your supercomputing resource uses a wrapped version of the default
mpirun command (e.g.,
mpprun on NSC’s triolith or
aprun on PDC’s beskow).
To change this option access the json configuration file through
storq configure --f vasp
and change the value of the
mpi_command field as needed.
It can furthermore be convenient to add a default allocation for your jobs to run on (you can override this later from your ASE script).
To select an allocation, edit the value of the
batch_account field to the name of your account (e.g.
snic20XX-X-XX on a SNIC resource).
More about configuring storq¶
This section contains a more thorough description of the configuration process and the available options.
The VASP configuration file and its options¶
The automatic configuration process will generate two configuration files named
site.json and place them under
You can access and edit these files at any time using the commands (beware that the files will be opened in the editor pointed to by your
EDITOR environmental variable and that if it is not set the default is
storq configure --f vasp storq configure --f site
The generation of the
site.json file should be completely automatic.
The file itself contains information about the cluster environment (e.g., the number of cores per node).
vasp.json file holds information as to where to find VASP binaries, pseudo potentials etc. and controls the general behavior of the calculator.
All settings found in this file can be overridden from Python but in practice only a few settings (walltime, number of nodes etc.) need to be changed from script to script.
To access and change the storq configuration from within Python use the
Below follows a list of all currently available options for
batch_account: allocation on supercomputing resource to be used
batch_options: space-separated string of additional options passed to the
batch_walltime: walltime of job passed as a string in the format HH:MM:SS
batch_nodes: Number of nodes used for your calculation
user: user name on the supercomputing resource.
vasp_convergence: strictness level of calculators convergence checks; possible values:
vasp_executable_std: path to standard VASP executable
vasp_executable_gam: path to special Gamma-point only VASP executable
vasp_executable_ncl: path to special Non-collinear VASP executable
vasp_mode: “queue” or “run”, should jobs be run directly or submitted via the queue
vasp_potentials: path to
vasp_restart_on: possible values:
vasp_stdout: name of file to which the stdout from VASP is written; default:
vasp_validate: if true keywords passed to the calculator will be type checked
vasp_vdw_kernel: path to
vdw_kernel.bindatfile needed to for calculations using vdW-DF functionals
A note on working with multiple file systems¶
Many supercomputing resources feature multiple file systems. A common setup is having one distributed system and one parallel system (see e.g., Lustre). In this case one needs to be careful when settings up storq to ensure that the necessary files are visible across file systems or, alternatively, located on the same file system.
As a concrete example, consider PDC’s beskow system, which uses a distributed file system called AFS as well as a parallel Lustre system.
The supercomputing center recommends installing software on Lustre while the user home directories reside in AFS.
Hence, even if storq is installed on Lustre, the automatic configuration process will place the configuration files under
$HOME on AFS.
To resolve this situation one can move the
.config folder to Lustre and place a symbolic link in AFS, which points to the new location.
Arguably, in this case a better option is to keep the
.config folder on AFS but move it from
$HOME to a subfolder
$HOME/Public that is set to be visible from Lustre and then place a symbolic link in