Running Octopus


In order to run, Octopus requires an input file that ‘‘must’’ be called inp . Depending on your input file there are other files that you might need, like pseudopotentials or coordinate files (we will discuss this later in this manual).

The rest of the files that are required are part of the Octopus installation; if Octopus is correctly installed they should be available and Octopus should know where to find them. With Octopus you can’t just copy the binary between systems and expect it to work.


To run Octopus you just have to give the octopus command in the directory where you have your input file. While running, Octopus will display information on the screen. If you want to capture this information you can send the output to a file, let’s say out.log , by executing it like this:

octopus > out.log

This captures only the normal output. If there is a warning or an error, it will be still printed on the screen. To capture everything to a file, run

octopus >& out.log

If you want to run Octopus in the background, append & to the last command.


While running, Octopus will create several output files, all of them inside subdirectories in the same directory where it was run. The files that contain the physical information depend on what Octopus is doing and they will be discussed in the next chapter.

One directory that is always created is exec/ , this file contains information about the Octopus run. Here you will find the parser.log file, a text file that contains all the input variables that were read by Octopus, both the variables that are in the input file and the variables that took default values; in the second case they are marked by a comment as -default. This file is very useful if you want to check that Octopus is correctly parsing a variable or what are the default values that it is taking.

Clean Stop

Octopus allows to stop the code gracefully after finishing the current iteration. These may not work for gcm, invert_ks, casida run modes. You can use this to prevent possible corruption of restart information when your job is killed by a scheduler, by preemptively asking Octopus to quit automatically in a job script like this:

This can be done by creating a file called stop in the running directory:

 -PBS -l walltime=4:10:00
 mpirun $HOME/octopus/bin/octopus &> output &
 sleep 4h
 touch stop

or more sophisticatedly like this:

 MIN=`qstat -a $PBS_JOBID | awk '{wall=$9} END {print $9}' | awk -F: '{min=($1*60)+$2; print min}'`
 sh ~/ stop $((MIN-10))m > sleepy &
 mpirun $HOME/octopus/bin/octopus &> output

with auxiliary script

 if [ $- -ne 2 ]; then
    echo "Usage: FILENAME TIME"
    echo "Time until $1 created: $2"
    rm -f $1
    sleep $2
    touch $1
Since version 10, a second way is to use the input Walltime variable, which sets the time (in minutes) before which the code is gracefully stopped.


Another directory that will created is restart/ ; in this directory Octopus saves the information from the calculation that it is doing. This information can be used in the following cases:

Sometimes it’s not desired to restart a calculation, but to start it from the very beginning. Octopus can be instructed to do so by setting the input variable fromScratch to yes.