The Octopus Manual
The Octopus Manual
The Octopus Manual
Version 4.1.2
(From the OctopusWiki)
Alberto Castro
Angel Rubio
Carlo Andrea Rozzi
Florian Lorenzen
Heiko Appel
Micael Oliveira
Miguel A. L. Marques
Xavier Andrade
- David A. Strubbe
The_Octopus_Manual
Contents
1 About This Manual
1.1 Copying
1.2 Reading this manual
1.3 Getting help
1.4 Contributing
2 About Octopus
2.1 Developers
2.2 Introduction
2.3 History
2.4 Contributing to Octopus
2.5 The Octopus Copying Conditions
3 Installation
3.1 Instructions for Specific Architectures
3.2 Dowloading
3.2.1 Binaries
3.2.2 Source code
3.3 Building
3.3.1 Quick instructions
3.3.2 Slow instructions
3.3.3 Long instructions
3.3.3.1 Requirements
3.3.3.2 Optional libraries
3.3.3.3 Unpacking the sources
3.3.3.4 Development version
3.3.3.5 Configuring
3.3.3.6 Compiling and installing
3.3.3.7 Testing your build
4 Basics
4.1 The input file
4.1.1 Input file
4.1.2 Scalar Variables
4.1.3 Mathematical expressions
4.1.4 Predefined variables
4.1.5 Blocks
4.1.6 Comments
4.1.7 Default values
4.1.8 Documentation
4.1.9 Experimental features
4.1.10 Good practices
4.2 Running Octopus
4.2.1 Input
4.2.2 Executing
4.2.3 Output
4.2.4 Clean Stop
4.2.5 Restarting
4.3 Units
Contents
The_Octopus_Manual
The_Octopus_Manual
5.2.3 Eigensolver
5.2.4 LCAO
5.3 Unoccupied states
5.4 Time-Dependent
5.4.1 Time evolution
5.4.1.1 Propagators for the
time-dependent Kohn-Sham equations
5.4.1.1.1 Splitting techniques
5.4.1.1.2 Midpoint rules
5.4.1.1.3 Magnus expansions
5.4.1.1.4
Time-reversal-symmetry based
propagation
5.4.1.2 Approximations to the
exponential of an operator
5.4.1.2.1 Polynomial expansions
5.4.1.2.2 Krylov-subspace
projection
5.4.1.2.3 Splitting techniques
5.4.2 Performing a time-propagation
5.4.3 External fields
5.4.3.1 Delta kick: Calculating an
absorption spectrum
5.4.3.2 Lasers
5.4.4 Symmetries
5.5 Casida Linear Response
5.6 Sternheimer Linear Response
5.6.1 Ground state
5.6.2 Input
5.6.3 Output
5.6.4 Finite differences
5.7 Optimal Control
5.8 Theoretical Introduction
5.9 Population target: scheme of Zhu, Botina and
Rabitz
5.10 The asymmetric double well: preparing the states
5.11 Running octopus in QOCT mode
5.12 Analysis of the results
5.13 References
5.14 Geometry Optimization
6 Advanced ways of running Octopus
6.1 Parallel Octopus
6.1.1 Parallel in States
6.1.2 Parallel in Domains
6.1.3 Problems with parallelization
6.1.4 Compiling and running in parallel
6.2 Multi-Dataset Mode
6.3 Passing arguments from environment variables
Contents
The_Octopus_Manual
6.3.1 Examples
7 Utilities
7.1 oct-atomic_occupations
7.1.1 Options
7.1.2 Examples
7.2 oct-casida_spectrum
7.2.1 NAME
7.2.2 SYNOPSIS
7.2.3 DESCRIPTION
7.2.4 AUTHOR
7.2.5 REPORTING BUGS
7.2.6 COPYRIGHT
7.2.7 SEE ALSO
7.3 oct-center-geom
7.3.1 NAME
7.3.2 SYNOPSIS
7.3.3 DESCRIPTION
7.3.4 AUTHOR
7.3.5 REPORTING BUGS
7.3.6 COPYRIGHT
7.3.7 SEE ALSO
7.4 oct-propagate_spectrum
7.4.1 NAME
7.4.2 SYNOPSIS
7.4.3 DESCRIPTION
7.4.4 AUTHOR
7.4.5 REPORTING BUGS
7.4.6 COPYRIGHT
7.4.7 SEE ALSO
7.5 oct-display_partitions
7.5.1 NAME
7.5.2 SYNOPSIS
7.5.3 DESCRIPTION
7.5.4 AUTHOR
7.5.5 REPORTING BUGS
7.5.6 COPYRIGHT
7.5.7 SEE ALSO
7.6 oct-harmonic-spectrum
7.6.1 NAME
7.6.2 SYNOPSIS
7.6.3 DESCRIPTION
7.6.4 AUTHOR
7.6.5 REPORTING BUGS
7.6.6 COPYRIGHT
7.6.7 SEE ALSO
7.7 oct-vibrational_spectrum
7.8 oct-rotatory_strength
7.8.1 NAME
Contents
The_Octopus_Manual
7.8.2 SYNOPSIS
7.8.3 DESCRIPTION
7.8.4 AUTHOR
7.8.5 REPORTING BUGS
7.8.6 COPYRIGHT
7.8.7 SEE ALSO
7.9 oct-run_periodic_table
7.9.1 NAME
7.9.2 SYNOPSIS
7.9.3 DESCRIPTION
7.9.4 EXAMPLES
7.9.5 AUTHOR
7.9.6 REPORTING BUGS
7.9.7 COPYRIGHT
7.9.8 SEE ALSO
7.10 oct-run_regression_test.pl
7.10.1 NAME
7.10.2 SYNOPSIS
7.10.3 DESCRIPTION
7.10.4 EXAMPLES
7.10.5 AUTHOR
7.10.6 REPORTING BUGS
7.10.7 COPYRIGHT
7.10.8 SEE ALSO
7.11 oct-run_testsuite
7.11.1 NAME
7.11.2 SYNOPSIS
7.11.3 DESCRIPTION
7.11.4 EXAMPLES
7.11.5 AUTHOR
7.11.6 REPORTING BUGS
7.11.7 COPYRIGHT
7.11.8 SEE ALSO
7.12 oct-xyz-anim
7.12.1 NAME
7.12.2 SYNOPSIS
7.12.3 DESCRIPTION
7.12.4 AUTHOR
7.12.5 REPORTING BUGS
7.12.6 COPYRIGHT
7.12.7 SEE ALSO
7.13 Visualization
7.13.1 dx
7.13.2 XCrySDen
7.13.3 CUBE
7.14 Deprecated Utilities
7.14.1 octopus_cmplx
7.14.2 oct-sf
Contents
The_Octopus_Manual
The_Octopus_Manual
OpenCL
10.3.3 Selecting the OpenCL device
10.3.4 The block-size
10.3.5 StatesPack
10.3.6 The Poisson solver
10.4 Appendix: Specific architectures
11 Generic Ubuntu 10.10
12 Generic MacOS
13 United States
13.1 Sequoia/Vulcan (IBM Blue Gene/Q)
13.2 Stampede
13.3 Edison
13.4 Hopper
13.5 Titan
13.6 Kraken
13.7 Lonestar
13.8 Lawrencium
14 Europe
14.1 Curie
14.1.1 PFFT 1.0.5 and BigDFT 1.6.0
14.1.2 PFFT 1.0.7 and BigDFT 1.7.0
14.2 Fermi/Juqueen
14.3 Hydra
14.4 Jugene
14.5 Finis Terrae
14.6 MareNostrum II
14.7 MareNostrum III
14.8 Green
14.9 Corvo
14.10 LaPalma
14.11 Appendix: Porting Octopus and Platform
Specific Instructions
14.11.1 General information and tips about
compilers
14.11.2 SSE2 support
14.11.3 Operating systems
14.11.3.1 Linux
14.11.3.2 Solaris
14.11.3.3 Tru 64
14.11.3.4 Mac OS X
14.11.3.5 Windows
14.11.4 Compilers
14.11.4.1 Intel Compiler for
x86/x86_64
14.11.4.2 Intel Compiler for Itanium
14.11.4.3 Open64
14.11.4.4 Pathscale Fortran Compiler
14.11.4.5 NAG compiler
Contents
The_Octopus_Manual
Contents
The_Octopus_Manual
Copyright 2006 Miguel A. L. Marques, Xavier Andrade, Alberto Castro and Angel Rubio
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free
Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no
Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
Getting help
If you need help using Octopus, you have any doubts about the content of this manual or you want to contact us for
any reason, please do it so through the octopus users mailing list.
Contributing
This manual is developed using a Wiki, this means that you can directly cooperate with it. You can always find the
original version in http://www.tddft.org/programs/octopus/wiki/index.php/Manual.
Previous Manual - Next Manual:About Octopus
About This Manual
10
The_Octopus_Manual
About Octopus
Octopus is a software package for density-functional theory (DFT), and time-dependent density functional theory
(TDDFT).
Developers
The main developing team of this program is composed of:
Alberto Castro ([email protected])
Angel Rubio ([email protected])
Carlo Andrea Rozzi ([email protected])
Florian Lorenzen ([email protected])
Heiko Appel ([email protected])
Micael Oliveira ([email protected])
Miguel A. L. Marques ([email protected])
Xavier Andrade ([email protected])
David Strubbe ([email protected])
Other contributors are:
Sebastien Hamel
parallel version of oct-excite.
Eugene S. Kadantsev ([email protected])
Initial linear-response code
Introduction
Octopus is a pseudopotential real-space package aimed at the simulation of the electron-ion dynamics of one-,
two-, and three-dimensional ?nite systems subject to time-dependent electromagnetic ?elds. The program is based
on time-dependent density-functional theory (TDDFT) in the Kohn-Sham scheme. All quantities are expanded in a
regular mesh in real space, and the simulations are performed in real time. The program has been successfully used
to calculate linear and non-linear absorption spectra, harmonic spectra, laser induced fragmentation, etc. of a
variety of systems. The fundamentals of DFT and TDDFT can be found, e.g., in the books [1]and [2]. All
information about the octopus package can be found in its homepage, http://www.tddft.org/programs/octopus/, and
in the articles [3]and [4].
The main advantage of real-space methods is the simplicity and intuitiveness of the whole procedure. First of all,
quantities like the density or the wave-functions are very simple to visualize in real space. Furthermore, the method
is fairly simple to implement numerically for 1-, 2-, or 3-dimensional systems, and for a variety of different
boundary conditions. For example, one can study a finite system, a molecule, or a cluster without the need of a
super-cell, simply by imposing that the wave-functions are zero at a surface far enough from the system. In the
same way, an infinite system, a polymer, a surface, or bulk material can be studied by imposing the appropriate
cyclic boundary conditions. Note also that in the real-space method there is only one convergence parameter,
namely the grid-spacing, and that decreasing the grid spacing always improves the result.
About Octopus
11
The_Octopus_Manual
Unfortunately, real-space methods suffer from a few drawbacks. For example, most of the real-space
implementations are not variational, i.e., we may find a total energy lower than the true energy, and if we reduce
the grid-spacing the energy can actually increase. Moreover, the grid breaks translational symmetry, and can also
break other symmetries that the system may possess. This can lead to the artificial lifting of some degeneracies, to
the appearance of spurious peaks in spectra, etc. Of course all these problems can be minimized by reducing the
grid-spacing.
History
Octopus is based on a fixed-nucleus code written by George F. Bertsch and K. Yabana to perform real-time
dynamics in clusters [5]and on a condensed matter real-space plane-wave based code written by A. Rubio, X. Blase
and S.G. Louie [6]. The code was afterwards extended to handle periodic systems by G.F. Bertsch, J.I. Iwata, A.
Rubio, and K. Yabana [7]. Contemporaneously there was a major rewrite of the original cluster code to handle a
vast majority of finite systems. At this point the cluster code was named tddft.
This version was consequently enhanced and beautified by A. Castro (at the time Ph.D. student of A. Rubio),
originating a fairly verbose 15,000 lines of Fortran 90/77. In the year 2000, M. Marques (aka Hyllios, aka Antnio
de Faria, corsrio portugus), joined the A. Rubio group in Valladolid as a postdoc. Having to use tddft for his
work, and being petulant enough to think he could structure the code better than his predecessors, he started a
major rewrite of the code together with A. Castro, finishing version 0.2 of tddft. But things were still not perfect:
due to their limited experience in Fortran 90, and due to the inadequacy of this language for anything beyond a
HELLO WORLD program, several parts of the code were still clumsy. Also the idea of GPLing the almost 20,000
lines arose during an alcoholic evening. So after several weeks of frantic coding and after getting rid of the
Numerical Recipes code that still lingered around, Octopus was born.
The present released version has been completely rewritten and keeps very little relation to the old version (even
input and output files) and has been enhanced with major new flags to perform various excited-state dynamics in
finite and extended systems. The code will be updated frequently and new versions can be found here.
If you find the code useful for you research we would appreciate if you give reference to this work and previous
ones.
Contributing to Octopus
If you have some free time, and if you feel like taking a joy ride with Fortran 90, just drop us an email. You can
also send us patches, comments, ideas, wishes, etc. They will be included in new releases of octopus.
If you found a have a bug, please report it to our Bug Tracking System:
http://www.tddft.org/trac/octopus/newticket
12
The_Octopus_Manual
source code or else can get it if you want it, that you can change this program or use pieces of them in new free
programs, and that you know you can do these things.
To make sure that everyone has such rights, we have to forbid you to deprive anyone else of these rights. For
example, if you distribute copies of the program, you must give the recipients all the rights that you have. You
must make sure that they, too, receive or can get the source code. And you must tell them their rights.
Also, for our own protection, we must make certain that everyone finds out that there is no warranty for this
program. If these programs are modified by someone else and passed on, we want their recipients to know that
what they have is not what we distributed, so that any problems introduced by others will not reflect on our
reputation.
The precise conditions of the license are found in the General Public Licenses that accompany it.
Please note that Octopus distribution normally comes with some external libraries that are not covered by the GPL
license, please see the Copying Appendix for the copying conditions or these packages.
1. ? A Primer in Density Functional Theory, C. Fiolhais, F. Nogueira, and M.A.L. Marques (editors), Springer
Berlin Heidelberg New York, (2006), ISBN: 3-540-03082-2
2. ? Time-dependent Density Functional Theory, M. A. L. Marques and C. A. Ullrich and F. Nogueira and A.
Rubio and K. Burke and E. K. U. Gross (editors), Springer Berlin Heidelberg New York, (2006), ISBN:
3-540-35422-0
3. ? M.A.L. Marques, A. Castro, G. F. Bertsch, and A. Rubio, octopus: a first principles tool for excited states
electron-ion dynamics, Comp. Phys. Comm. 151 60 (2003)
4. ? A. Castro, H. Appel, M. Oliveira, C. A. Rozzi, X. Andrade, F. Lorenzen, M.A.L. Marques, E. K. U.
Gross, and A. Rubio, octopus: a tool for the application of time-dependent density functional theory, Phys.
Stat. Sol. (b) 243 2465 (2006)
5. ? G.F. Bertsch and K. Yabana, Time-dependent local-density approximation in real time, Phys. Rev. B 54
4484 (1996)
6. ? A. Rubio, X. Blase, and S.G. Louie, Ab Initio Photoabsorption Spectra and Structures of Small
Semiconductor and Metal Clusters, Phys. Rev. Lett. 77 247 (1996)
7. ? G.F. Bertsch, J.I. Iwata, A. Rubio, and K. Yabana, Real-space, real-time method for the dielectric
function, Phys. Rev. B 62 7998 (2000)
Previous Manual:Octopus - Next Manual:Installation
Back to Manual <p class=newpage>
Installation
Maybe somebody else installed Octopus for you. In that case, the files should be under some directory that we can
call PREFIX/, the executables in PREFIX/bin/ (e.g. if PREFIX/=/usr/local/, the main Octopus
executable is then in /usr/local/bin/octopus); the pseudopotential files that Octopus will need in
PREFIX/share/octopus/PP/, etc.
However, you may be unlucky and that is not the case. In the following we will try to help you with the still rather
unfriendly task of compiling and installing the octopus.
Installation
13
The_Octopus_Manual
Dowloading
The main download page for Octopus is http://www.tddft.org/programs/octopus/download/4.1.2
Binaries
If you want to install Octopus in a Linux box which is deb- or rpm-based, you might not need to compile it; we
release binary packages for some platforms. Keep in mind that these packages are intended to run on different
systems and are therefore only moderately optimized. If this is an issue you have to compile the package yourself
with the appropriate compiler flags and libraries (see below).
For Debian-based systems (Debian, Ubuntu), download the appropiate .deb file and install it with the
command (you need root access for this):
$ dpkg -i octopus_package.deb
For rpm-based distributions (RedHat, Fedora, SuSe, Mandriva, etc.) download the .rpm file and issue the
following command line as root:
$ rpm -i octopus_package.rpm
Source code
If you have a different system from those mentioned above or you want to compile Octopus you need to get the
source code file (.tar.gz file) and follow the compilation instructions below.
Building
Quick instructions
For the impatient, here is the quick-start:
$ gzip -cd octopus-4.1.2.tar.gz
$ cd octopus-4.1.2
$ ./configure
$ make
$ make install
This will probably not work, so before giving up, just read the following paragraphs.
14
The_Octopus_Manual
Slow instructions
There is an appendix with detailed instructions on how to compile Octopus and the required libraries from the
scratch -- you only need to do this if you are unable to install from a package manager or use pre-built libraries.
Long instructions
The code is written in standard Fortran 90, with some routines written in C (and in bison, if we count the input
parser). To build it you will need both a C compiler (gcc works just fine and it is available for almost every piece
of silicon), and a Fortran 90 compiler. You can check in the Compilers Appendix which compilers Octopus has
been tested with. This appendix also contains hints on potential problems with certain platform/compiler
combinations and how to fix them.
Requirements
Slow instructions
15
The_Octopus_Manual
Finally someone had the nice idea of making a public scientific library! GSL still needs to grow, but it is
already quite useful and impressive. Octopus uses splines, complex numbers, special functions, etc. from
GSL, so it is a must! If you don't have it already installed in your system, you can obtain GSL from the
GSL site. You will need version 1.9 or higher. Version 4.0 of Octopus (and earlier) can only use GSL 1.14
(and earlier). A few tests will fail if you use GSL 1.15 or later.
Perl
During the build process Octopus runs several scripts in this language. It's normally available in every
modern Unix system.
Optional libraries
There are also some optional packages; without them some parts of Octopus won't work:
MPI
If you want to run Octopus in multi-tentacle (parallel) mode, you will need an implementation of MPI.
MPICH or Open MPI work just fine in our Linux boxes.
PFFT
We rely on this great library to perform highly scalable parallel Poisson solver, based on Fast Fourier
Transforms (FFTs). You may grab it from the M. Pippig's site. You require FFTW version 3.3.2 compiled
with MPI and with a small patch by M. Pippig (also available there).
NetCDF
The Network Common Dataform library is needed for writing the binary files in a machine-independent,
well-defined format, which can also be read by visualization programs such as OpenDX
GDLib
A library to read graphic files. See Tutorial:Particle in an octopus. (The simulation box in 2D can be
specified via BoxShapeImage.) Available from http://www.libgd.org/
SPARSKIT
Library for sparse matrix calculations. Used for one propagator technique.
ETSF I/O
An input/output library implementing the ETSF standardized formats, requiring NetCDF, available at [2].
Versions 1.0.2, 1.0.3, and 1.0.4 are compatible with Octopus (though 1.0.2 will produce a small
discrepancy in a filesize in the testsuite). It must have been compiled with the same compiler you are using
with octopus. To use ETSF_IO, include this in the configure line, where $DIR is the path where the
library was installed:
--with-etsf-io-prefix="$DIR"
Requirements
16
The_Octopus_Manual
LibISF
(version 4.2.0 and later) To perform highly scalable parallel Poisson solver, based on BigDFT 1.7.6, with a
cheap memory footprint. You may grab it from the BigDFT site. You require BigDFT version 1.7.6
compiled with MPI, following these instructions: installation instructions . Probably, you have to manually
copy the files "libwrappers.a" and "libflib.a" to the installation "/lib" directory. To configure Octopus, you
have to add this configure line:
--with-isf-prefix="$DIR"
17
The_Octopus_Manual
$ svn co http://www.tddft.org/svn/octopus/trunk
Before running the configure script, you will need to run the GNU autotools. This may be done by executing:
$ cd trunk
$ autoreconf -i
Note that you need to have working recent versions of the automake and autoconf. In particular, the configure
script may fail in the part checking for Fortran libraries of mpif90 for autoconf version 2.59
or earlier. The solution is to update autoconf to 2.60 or later, or manually set FCLIBS in the configure
command line to remove a spurious apostrophe.
Please be aware that the development version may contain untested changes that can affect the execution and the
results of Octopus, especially if you are using new and previously unreleased features. So if you want to use the
development version for production runs, you should at least contact Octopus developers.
You can also use the current release branch, which is the released version with only important bugfixes added, and
is the source of minor revision numbers (e.g. 4.0.1).
http://www.tddft.org/programs/octopus/download/octopus-night.4.1.x.tar.gz or
$ svn co http://www.tddft.org/svn/octopus/branches/4.1.x
Configuring
Before configuring you can (should) set up a couple of options. Although the configure script tries to guess your
system settings for you, we recommend that you set explicitly the default Fortran compiler and the compiler
options. Note that configure is a standard tool for Unix-style programs and you can find a lot of generic
documentation on how it works elsewhere.
For example, in bash you would typically do:
$ export FC=abf90
$ export FCFLAGS="-O -YEXT_NAMES=LCS -YEXT_SFX=_"
Development version
18
The_Octopus_Manual
You can use a fair amount of options to spice Octopus to your own taste. To obtain a full list just type
./configure --help. Some commonly used options include:
--prefix=PREFIX/
Change the base installation dir of Octopus to PREFIX/. PREFIX/ defaults to the home directory of the
user who runs the configure script.
--with-fft-lib=<lib>
Instruct the configure script to look for the FFTW library exactly in the way that it is specified in the
<lib> argument. You can also use the FFT_LIBS environment variable.
--with-pfft=pfft
Instruct the configure script to use PFFT.
--with-pfft-lib=<lib>
Instruct the configure script to look for the PFFT library exactly in the way that it is specified in the <lib>
argument. You can also use the PFFT_LIBS environment variable.
--with-blas=<lib>
Instruct the configure script to look for the BLAS library in the way that it is specified in the <lib>
argument.
--with-lapack=<lib>
Instruct the configure script to look for the LAPACK library in the way that it is specified in the <lib>
argument.
--with-gsl-prefix=DIR/
Installation directory of the GSL library. The libraries are expected to be in DIR/lib/ and the include
files in DIR/include/. The value of DIR/ is usually found by issuing the command gsl-config
--prefix.
--with-libxc-prefix=DIR/
Installation directory of the LibXC library.
If you have problems when the configure script runs, you can find more details of what happened in the file
config.log in the same directory.
Compiling and installing
Run make (this may take sometime) and then make install. If everything went fine, you should now be able
to taste Octopus.
Depending on the value given to the --prefix=PREFIX/ given, the executables will reside in PREFIX/bin/, and
the auxiliary files will be copied to PREFIX/share/octopus. The sample input files will be copied to
PREFIX/share/octopus/samples.
Configuring
19
The_Octopus_Manual
which will start running the tests, informing you whether the tests are passed or not. For examples of job scripts to
run on a machine with a scheduler, please see Manual:Specific_architectures.
If all tests fail, maybe there is a problem with your executable (like a missing shared library).
If only some of the tests fail, it might be a problem when calling some external libraries (typically blas/lapack).
Normally it is necessary to compile all Fortran libraries with the same compiler. If you have trouble, try to look for
help in the octopus mailing list.
Basics
<p class=newpage>
Input file
Input options should be in a file called inp, in the directory Octopus is run from. This is a plain ASCII text file, to
create or edit it you can use any text editor like emacs, vi, jed, pico, gedit, etc. For a fairly comprehensive example,
just look at the tutorial page Tutorial:Nitrogen_atom.
Basics
20
The_Octopus_Manual
At the beginning of the program, the parser reads the input file, parses it, and generates a list of variables that will
be read by Octopus (note that the input is case independent). There are two kind of variables: scalar values (strings
or numbers), and blocks (that you may view as matrices).
Scalar Variables
A scalar variable var can be defined by:
var = exp
var can contain any alphanumeric character plus _, and exp can be a quote-delimited string, a number (integer,
real, or complex), a variable name, or a mathematical expression.
Mathematical expressions
The parser can interpret several expressions in the input file and assign the result to the variable. The arguments
can be numbers or other variables. All arithmetic operators are supported (a+b, a-b, a*b, a/b; for
exponentiation the syntax a^b is used), and the following functions:
sqrt(x)
The square root of x.
exp(x)
The exponential of x.
log(x) or ln(x)
The natural logarithm of x.
log10(x)
Base 10 logarithm of x.
logb(x, b)
Base b logarithm of x.
{x, y}
The complex number x + iy.
arg(z)
Argument of the complex number z, arg(z), where < arg(z) < = .
abs(z)
Magnitude of the complex number z, | z | .
abs2(z)
Magnitude squared of the complex number z, | z | 2.
logabs(z)
Natural logarithm of the magnitude of the complex number z, log | z | . It allows an accurate evaluation of
log | z | when | z | is close to one. The direct evaluation of log(abs(z)) would lead to a loss of precision
in this case.
conjg(z)
Complex conjugate of the complex number z, z * = x iy.
inv(z)
Inverse, or reciprocal, of the complex number z,
Input file
21
The_Octopus_Manual
These mathematical operations are all based on the GSL library and are defined in symbols.c and grammar.y.
Some references:
https://www.gnu.org/software/gsl/manual/html_node/Properties-of-complex-numbers.html
https://www.gnu.org/software/gsl/manual/html_node/Complex-arithmetic-operators.html
https://www.gnu.org/software/gsl/manual/html_node/Error-Function.html
Predefined variables
There are some predefined constants for your convenience:
pi
3.141592653589793. What else is there to say?
e
The base of the natural logarithms.
false or f or no
False in all its flavors.
true or t or yes
The truthful companion of false.
i
The imaginary unit i.
Blocks
Blocks are defined as a collection of values, organised in row and column format. The syntax is the following:
Mathematical expressions
22
The_Octopus_Manual
%var
exp | exp | exp | ...
exp | exp | exp | ...
...
%
Rows in a block are separated by a newline, while columns are separated by the character | or by a tab. There may
be any number of lines and any number of columns in a block. Note also that each line can have a different number
of columns. Values in a block don't have to be of the same type.
Comments
Everything following the character # until the end of the line is considered a comment and is simply cast into
oblivion.
Default values
If Octopus tries to read a variable that is not defined in the input file, it automatically assigns to it a default value
(there are some cases where Octopus cannot find a sensible default value and it will stop with an error). All
variables read (present or not in the input file) are output to the file status/out.oct. If you are not sure of
what the program is reading, just take a look at it.
We recommend you to keep the variables in the input file to a minimum: do not write a variable that will be
assigned its default value. The default can change in newer versions of Octopus and old values might cause
problems. Besides that, your input files become difficult to read and understand.
Documentation
Each input variable has (or should have) its own documentation explaining what it does and the valid values it may
take. This documentation can be obtained online or it can also be accessed by the oct-help command.
Experimental features
Even in the stable releases of Octopus there are many features that are being developed and are not suitable for
production runs. To protect users from inadvertly using these parts they are declared as Experimental.
When you try to use one of these experimental functionalities Octopus will stop with an error. If you want to use it
you need to set the variable ExperimentalFeatures to yes. Now Octopus will only emit a warning.
By setting ExperimentalFeatures to yes you will be allowed to use parts of the code that are not complete
or not well tested and most likely produce wrong results. If you want to use them for production runs you should
contact the Octopus developers first.
Good practices
In order to ensure compatibility with newer versions of Octopus and avoid problems, keep in mind the following
rules of good practice when writing input files:
Blocks
23
The_Octopus_Manual
Although input variables that take an option as an input can also take a number, the number representation
makes the input file less readable and it is likely to change in the future. So avoid using numbers instead
of values. For example
Units = ev_angstrom
Do not include variables that are not required in the input file, especially declarations of values that are
just a copy of the default value. This makes the input file longer, less readable and, since defaults are likely
to change, it makes more probable that your input file will have problems with newer versions of Octopus.
Instead rely on default values.
Avoid duplicating information in the input file. Use your own variables and the
mathematical-interpretation capabilities for that. For example, you should use:
m = 0.1
c = 137.036
E = m*c^2
instead of
m = 0.1
c = 137.036
E = 1877.8865
In the second case, you might change the value of m (or c if you are a cosmologist) while forgetting to update E,
ending up with an inconsistent file.
Previous Manual:Installation - Next Manual:Running Octopus
Back to Manual <p class=newpage>
Running Octopus
Input
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.
Good practices
24
The_Octopus_Manual
Executing
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.
Output
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 oct.out 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
If you create a file called stop in the running directory, Octopus will exit gracefully after finishing the current
iteration. May not work for gcm, invert_ks, casida, td_transport, one_shot 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:
#PBS -l walltime=4:10:00
mpirun $HOME/octopus/bin/octopus_mpi &> output &
sleep 4h
touch stop
wait
MIN=`qstat -a $PBS_JOBID | awk '{wall=$9} END {print $9}' | awk -F: '{min=($1*60)+$2; print min}
sh ~/sleep_stop.sh stop $((MIN-10))m > sleepy &
mpirun $HOME/octopus/bin/octopus_mpi &> output
Executing
25
The_Octopus_Manual
echo "Usage: sleep_stop.sh FILENAME TIME"
else
echo "Time until $1 created: $2"
rm -f $1
sleep $2
touch $1
fi
Restarting
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:
If Octopus is stopped without finishing by some reason, it can restart from where it was without having to
do all work again.
If after the calculation is done (or even if it was stopped), the user wants to do the same simulation with
some different parameters, Octopus can save some work by starting from the restart information.
There are some calculations that require the results of other type of calculation as an input; in this case it
uses the files written in restart/ by the previous calculation (we will discuss this case later, when we
talk about the different calculation modes).
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.
Previous Manual:Input file - Next Manual:Units
Back to Manual <p class=newpage>
Units
Before entering into the physics in Octopus we have to address a very important issue: units. There are different
unit systems that can be used at the atomic scale: the most used are atomic units and what we call "convenient"
units. Here we present both unit systems and explain how to use them in Octopus.
Atomic Units
Atomic units are a Gaussian system of units (by "Gaussian" it means that the vacuum dielectric constant has no
dimensions and is set to be
), in which the numerical values of the Bohr radius, the electronic charge,
the electronic mass, and the reduced Planck's constant are set to one:
This simplifies formulae (although some may feel it presents a serious hazard for dimensional analysis,
interpretation and understanding of formulae, and physics in general. But this is just a personal taste). This sets
directly two fundamental units, the atomic units of length and of mass:
Clean Stop
26
The_Octopus_Manual
Since the squared charge must have units of energy times length, we can thus set the atomic unit of energy
which is called Hartree, Ha. And, since the energy has units of mass times length squared per time squared, this
helps us get the atomic unit of time:
Now the catch is: what about Planck's constant? Its dimensions are of energy times time, and thus we should be
able to derive its value by now. But at the beginning we set it to one! The point is that the four physics constants
used (
In this way, we could actually have derived the atomic unit of time in an easier way, using Planck's constant:
Convenient Units
Much of the literature in this field is written using ngstrms and electronvolts as the units of length and of
energy, respectively. So it may be "convenient" to define a system of units, derived from the atomic system of
units, in which we make that substitution. And so we will call it "convenient".
The unit mass remains the same, and thus the unit of time must change, being now
, with
Units in Octopus
By default Octopus reads and writes atomic units; you can switch to convenient units by setting the variable
Units to ev_angstrom. If you prefer different units for input and output, there are the variables UnitsInput
and UnitsOutput.
Atomic Units
27
The_Octopus_Manual
Mass Units
An exception for units in Octopus is mass units. When dealing with the mass of ions, always atomic mass units
(amu) are used. This unit is defined as 1 / 12 of the mass of the 12C atom. In keeping with standard conventions in
solid-state physics, effective masses of electrons are always reported in units of the electron mass (i.e. the atomic
unit of mass), even in the eV- system.
Charge Units
In both unit systems, the charge unit is the electron charge e (i.e. the atomic unit of charge).
Unit Conversions
Converting units can be a very time-consuming and error-prone task when done by hand, especially when there are
implicit constants set to one, as in the case of atomic units. That is why it's better to use as specialized software like
Gnu Units.
In some fields, a very common unit to express the absorption spectrum is Mb. To convert a strength function from
1/eV to Mb, multiply by
, with
Physical System
The first thing that octopus has to know is the physical system you want to treat. To do this you have specify a
group of species and their positions.
Dimensions
Octopus can work in a space with 1, 2 or 3 dimensions. You can select the dimension of your system with the
Dimensions variable.
Species
An Octopus species is very generic and can be a nucleus (represented by pseudopotentials or by the full Coulomb
potential), a jellium sphere or even a user-defined potential. The information regarding the atomic species goes into
the Species block.
Pseudopotentials
The many-electron Schroedinger equation can be greatly simpli?ed if electrons are divided in two groups: valence
electrons and inner core electrons. The electrons in the inner shells are strongly bound and do not play a signi?cant
Mass Units
28
The_Octopus_Manual
role in the chemical binding of atoms, thus forming with the nucleus an inert core. Binding properties are almost
completely due to the valence electrons, especially in metals and semiconductors. This separation implies that
inner electrons can be ignored, reducing the atom to an inert ionic core that interacts with the valence electrons.
This suggests the use of an e?ective interaction, a pseudopotential, that gives an approximation to the potential felt
by the valence electrons due to the nucleus and the core electrons. This can signi?cantly reduce the number of
electrons that have to be dealt with. Moreover, the pseudo wave functions of these valence electrons are much
smoother in the core region than the true valence wave functions, thus reducing the computational burden of the
calculations.
Modern pseudopotentials are obtained by inverting the free atom Schroedinger equation for a given reference
electronic con?guration, and forcing the pseudo wave functions to coincide with the true valence wave functions
beyond a certain cuto? distance. The pseudo wave functions are also forced to have the same norm as the true
valence wave functions, and the energy pseudo eigenvalues are matched to the true valence eigenvalues. Di?erent
methods of obtaining a pseudo eigenfunction that satis?es all these requirements lead to di?erent non-local, angular
momentum dependent pseudopotentials. Some widely used pseudopotentials are the Troullier and Martins [9]
potentials, the Hamann [10] potentials, the Vanderbilt [11] potentials and the Hartwigsen-Goedecker-Hutter [12]
potentials. The default potentials used by octopus are of the Troullier and Martins type, although you can also opt
for the HGH potentials.
Octopus comes with a package of pseudopotentials and the parameters needed to use them. If you want to have a
look you can find them under PREFIX/share/octopus/PP. These pseudopotentials serve to define many
species that you might wish to use in your coordinates block, e.g. a helium atom, "He". If you are happy to use
these predefined pseudopotentials, you do not need to write a species block.
However it is also possible to define new species to use in your coordinates block by adding a Species block.
You can check the documentation of that variable for the specific syntax. With this block you may specify the
format of your file that contains a pseudopotential and parameters such as the atomic number, or you may define
an algebraic expression for the potential with the user-defined potential. A user defined potential should be finite
everywhere in the region where your calculation runs.
If you want to create other pseudopotentials, you can do it in the pseudopotentials generator. Save the file in the
same directory as the inp file and specify the format of the file with the species block.
All-Electron Nucleus
The potential of this species is the full Coulomb potential
First we assume that atoms are located over the closest grid point.
Then we calculate the charge density associated with the nucleus: a delta distribution with the value of the
charge at this point and zero elsewhere.
Now we solve the Poisson equation for this density.
Pseudopotentials
29
The_Octopus_Manual
In this way we get a potential that is the best representation of the Coulomb potential for our grid (we will discuss
about grids later) and is continuous in
with the grid point).
(the value is the average of the potential over the volume associated
The main problem is that the requirement of having atoms over grid points is quite strong: it is only possible for a
few systems with simple geometries and you can't move the atoms. Also the Coulomb potential is very hard, which
means you will need a very small spacing, and as you have to consider both core and valence electrons, this species
is only suitable for atoms or very small molecules.
User Defined
It is also possible to define an external, user-defined potential in the input file. All functions accepted by the parser
can be used. Besides that, one can use the symbols x, y, z, and r. In this way it is trivial to calculate model systems,
like harmonic oscillators, quantum dots, etc.
Coordinates
For each instance of a species (even for user-defined potentials), you have to specify its position inside the
simulation box. To do this you can use Coordinates block which describes the positions inside of the input file
or one of the XYZCoordinates or PDBCoordinates variables, that specify an external file, in xyz or PDB
format respectively, from where the coordinates will be read.
Before using a geometry with octopus you have to center it, for this you can use the oct-center-geom utility.
Velocities
If you are going to do ion dynamics you may want to have an initial velocity for the particles. You have several
choices for doing this:
Don't put anything in the input file; particles will have zero initial velocity.
Give them a random velocity according to a temperature (in degrees Kelvin) given by the
RandomVelocityTemp variable.
Explicitly give the initial velocity for each particle, either through the Velocities block or from a
pseudo-xyz file detailed by the variable XYZVelocities.
Number of Electrons
Each species adds enough electrons to make the system neutral. If you want to add or remove electrons you can
specify the total charge of your system with the ExcessCharge variable (a negative charge implies to add
electrons).
Previous Manual:Units - Next Manual:Hamiltonian
Back to Manual <p class=newpage>
All-Electron Nucleus
30
The_Octopus_Manual
Hamiltonian
Octopus is based upon Density Functional Theory in the Kohn-Sham formulation. The Kohn-Sham Hamiltonian is
the main part of this formulation; in this section we describe how the Hamiltonian is treated in octopus and what
are the variables that control it.
Introduction
Although the Hohenberg-Kohn theorem states that DFT is exact, the Kohn-Sham method of reducing an
interacting many-particle problem to a non-interacting single-particle problem introduces an approximation: the
exchange-correlation term.
Ground-State DFT
The Kohn-Sham method of DFT assumes that, for each interacting ground-state density n(r), there exists a
non-interacting electron system with the same ground-state density. The interacting ground state is obtainable
through the solution of the Kohn-Sham equations
The notation vKS[n] means that the Kohn-Sham potential, vKS, has a functional dependence on n, the electronic
density, which is defined in terms of the Kohn-Sham wave-functions by
The potential vKS is defined as the sum of the external potential (normally the potential generated by the nuclei),
the Hartree term, and the exchange-correlation (xc) potential
Due to the functional dependence on the density, these equations form a set of nonlinear coupled equations. The
standard procedure to solve it is iterating until self-consistency is achieved.
The total energy of the electronic system is given by
where Ts[n] is the non-interacting kinetic energy, vext is the external potential, and Ex,c[n] are the exchange (x) and
correlation (c) energies. The second term is called the "external energy" in the code. In practice, from the solution
of the Kohn-Sham equations, we can evaluate the energy via the eigenvalues as
Hamiltonian
31
The_Octopus_Manual
where vxc[n] is the exchange-correlation potential. To find the total energy of the entire system, we additionally
include ion-ion interaction and ionic kinetic energy.
Exc = Ex + Ec is an unknown object and includes all the non-trivial many-body e?ects required to make KS theory
exact. Several approximations to Exc have been proposed. The most used is the local density approximation (LDA).
In this approximation Exc[n(r)] is taken to be the exchange and correlation energy of a homogeneous electron gas
with density n = n(r). Although there exists an exact expression for the exchange energy in this model, the exact
value of the correlation energy is known only in the limit of very high densities. Ceperley and Alder [6] did a
Monte Carlo simulation of the homogeneous electron gas at several densities. Several parameterizations of the
correlation energy for any density [7, 8] were then obtained interpolating the Monte Carlo results. One particularly
simple parameterization was proposed by Perdew and Zunger [7], and this option may be used by octopus. You
can, of course, choose other xc functionals (XCFunctional), via the extensive library provided by libxc.
Time-dependent DFT
Time-dependent density-functional theory (TDDFT) extends the basic ideas of ground-state density-functional
theory (DFT) to the treatment of excitations and of more general time-dependent phenomena. TDDFT can be
viewed as an alternative formulation of time-dependent quantum mechanics but, in contrast to the normal approach
that relies on wave-functions and on the many-body Schrdinger equation, its basic variable is the one-body
electron density, n(r,t). The advantages are clear: The many-body wave-function, a function in a 3N-dimensional
space (where N is the number of electrons in the system), is a very complex mathematical object, while the density
is a simple function that depends solely on the 3-dimensional vector r. The standard way to obtain n(r,t) is with the
help of a fictitious system of non-interacting electrons, the Kohn-Sham system. The final equations are simple to
tackle numerically, and are routinely solved for systems with a large number of atoms. These electrons feel an
effective potential, the time-dependent Kohn-Sham potential. The exact form of this potential is unknown, and has
therefore to be approximated.
The time-dependent Kohn-Sham equations are
The density of the interacting system can be obtained from the time-dependent Kohn-Sham orbitals
The time-dependent Kohn-Sham equations, having the form of a one-particle equation, is fairly easy to solve
numerically. We stress, however, that the Kohn-Sham equation is not a mean-field approximation: If we knew the
exact Kohn-Sham potential, vKS, we would obtain the exact Kohn-Sham orbitals, and from these the correct density
of the system. The Kohn-Sham potential is conventionally separated in the following way
Ground-State DFT
32
The_Octopus_Manual
The first term is again the external potential. The Hartree potential accounts for the classical electrostatic
interaction between the electrons
The time-dependence of the exchange and correlation potential introduces the need for an approximation beyond
the one made in the time-independent case. The simplest method of obtaining a time-dependent xc potential
consists in assuming that the potential is the time-independent xc potential evaluated at the time-dependent density,
i.e.,
This is called the adiabatic approximation. If the time-independent xc potential chosen is the LDA, then we obtain
the so-called adiabatic local density approximation (ALDA). This approximation gives remarkably good excitation
energies but su?ers from the same problems as the LDA, most notably the exponential fall-o? of the xc potential. If
a strong laser pushes the electrons to regions far from the nucleus, ALDA should not be expected to give an
accurate description of the system. Other options for the time-dependent xc potential are orbital-dependent
potentials like the exact exchange functional (EXX) (usually in the Krieger-Li-Iafrate (KLI) approximation).
Occupations
You can set the occupations the orbitals by hand, using the Occupations.
External Potential
You can add an external uniform and constant electric or magnetic field, set by the StaticElectricField or
StaticMagneticField. If you want to add a more general potential, you can do it using a user-defined
Species.
If you got the coordinates from a PDB file, you can add the potential generated by the point charges defined there
by setting the ClassicPotential variable to yes.
Electron-Electron Interaction
You can neglect this term by setting TheoryLevel = independent_particles variable. This implies
that both the Hartree and exchange-correlation terms will not be calculated.
33
The_Octopus_Manual
used to build an adiabatic exchange and/or correlation action functional in the following way:
meta-GGA rung:
OEP rung: This is the family of functionals which are defined in terms of the occupied Kohn-Sham orbitals,
. These are in fact the only non-local functionals. The name of the rung, OEP, stands for
"optimized-effective-potential", the reason being that in general this is the method used to derive the
potential from the energy functional (direct functional derivation is in this case not possible). A more
suitable name would be orbital-dependent functionals.
Octopus comes with several Exchange and Correlation potentials, including several flavours of LDA, GGA and
Exchange and correlation potential
34
The_Octopus_Manual
OEP. You can choose your favorites by setting the variable XCFunctional. (Note that until Octopus <= 2.1 the
exchange-correlation functional was chosen with the variables XFunctional and CFunctional.)
When using OEP Exchange, the variable OEP_level controls the level of approximation required.
You can also include Self-Interaction Correction (SIC), controlled by the variable SICCorrection.
Relativistic Corrections
The variable RelativisticCorrection allows one to choose the relativistic correction to be used. Up to
now only spin-orbit coupling (RelativisticCorrection = spin_orbit) is implemented.
Spin-orbit Coupling
The spin-orbit coupling as it is implemented in octopus is included in the pseudo-potentials. These can either be
HGH pseudo-potentials or Troullier-Martins-like pseudo-potentials. In the later case the pseudo-potentials need to
be generated from fully relativistic calculations and their fully separable form is given by:
Discretization
Besides all the approximations we have to do, no computer can solve an infinite continuous problem. We have to
discretize our equations somehow. Octopus uses a grid in real space to solve the Kohn-Sham equations. That is,
functions are represented by their value over a set of points in real space. Normally the grid is equally spaced, but
also non-uniform grids can be used. The shape of the simulation region may also be tuned to suit the geometric
configuration of the system.
Relativistic Corrections
35
The_Octopus_Manual
Grid
In Octopus functions are represented by a set of values that correspond to the value of the function over a set of
points in real space. By default these points are distributed in a uniform grid, which means that the distance
between points is a constant for each direction. It is possible to have grids that are not uniform, but as this is a bit
more complex we will discuss it later.
In this scheme, the separation between points, or spacing, is a critical value. When it becomes large the
representation of functions gets worse and when it becomes small the number of points increases, increasing
memory use and calculation time. This value is equivalent to the energy cutoff used by plane-wave representations.
In Octopus you can choose the Spacing of your simulation by the Spacing variable. If you set this as a single
value it will give the same spacing for each directions (for example Spacing=0.3). If you want to have different
spacings for each coordinate you can specify Spacing as a block of three real values.
If you are working with the default pseudopotential species of Octopus they come with a recommended Spacing
value and you don't need to give it in the input file. Normally this default values are around 0.4 [b] (~0.2 []), but
you may need smaller spacing in some cases. Do not rely on these default values for production runs.
Box
We also have to select a finite domain of the real space to run our simulation, which is known as the simulation
box. Octopus can use several kinds of shapes of box. This is controlled by the variable BoxShape. Besides
standard shapes Octopus can take shapes given by a user-defined function or even by an image.
The way to give the size of the simulation box changes for each shape, but for most of them it is given by the
variable Radius.
36
The_Octopus_Manual
Output
At first you may be quite happy that you have mastered the input file, and octopus runs without errors. However,
eventually you (or your thesis advisor) will want to learn something about the system you have managed to
describe to Octopus.
Ground-State DFT
Octopus sends some relevant information to the standard output (which you may have redirected to a file). Here
you will see energies and occupations of the eigenstates of your system. These values and other information can
also be found in the file static/info.
However Octopus also calculates the wavefunctions of these states and the positions of the nuclei in your system.
Thus it can tell you the density of the dipole moment, the charge density, or the matrix elements of the dipole
moment operator between different states. Look at the values that the Output variable can take to see the
possibilities.
For example, if you include
Output = wfs_sqmod + potential
in your inp file, Octopus will create separate text files in the directory static with the values of the square
modulus of the wave function and the local, classical, Hartree, and exchange/correlation parts of the Kohn-Sham
potential at the points in your mesh.
You can specify the formatting details for these input files with the OutputHow variable and the other variables
in the Output section of the Reference Manual. For example, you can specify that the file will only contain
values along the x, y, or z axis, or in the plane x=0, y=0, or z=0. You can also set the format to be readable by the
graphics programs OpenDX, gnuplot or MatLab. OpenDX can make plots of iso-surfaces if you have data in
three-dimensions. However gnuplot can only make a 3-d plot of a function of two variables, i.e. if you have the
values of a wavefunction in a plane, and 2-d plots of a function of one variable, i.e. the value of the wavefunction
along an axis.
Time-Dependent DFT
Optical Properties
A primary reason for using a time-dependent DFT program is to obtain the optical properties of your system. You
have two choices for this, linear-response theory a la Jamorski, Casida & Salahub [1], or explicit time-propagation
of the system after a perturbation, a la Yabana & Bertsch [2]. You may wish to read more about these methods in
the paper by Castro et al.[3]
Linear-Response Theory
Linear-response theory is based on the idea that a small (time-dependent) perturbation in an externally applied
electric potential v(r,) will result in a (time-dependent) perturbation of the electronic density (r,) which is
Zero boundary conditions
37
The_Octopus_Manual
Casida's equations are a full solution to this problem (for real wavefunctions). The Tamm-Dancoff approximation
uses only occupied-unoccupied transitions. The Petersilka approximation uses only the diagonal elements of the
Tamm-Dancoff matrix, i.e. there is no mixing of transitions.[4]It takes only a little more time to calculate the whole
matrix, so Petersilka is provided mostly for comparison.
These methods are clearly much faster (an order of magnitude) than propagating in time, but it turns out that they
are very sensitive to the quality of the unoccupied states. This means that it is very hard to converge the excitation
energy, because one requires a very large simulation box (much larger than when propagating in real time).
Electronic Excitations by Means of Time-Propagation
See Manual:Time_Dependent#Delta_kick:_Calculating_an_absorption_spectrum.
References
1. ? Christine Jamorski, Mark E. Casida, and Dennis R. Salahub, Dynamic polarizabilities and excitation
spectra from a molecular implementation of time-dependent density-functional response theory: N2 as a
case study, J. Chem. Phys. 5134-5147 (1996)
2. ? K. Yabana, G. F. Bertsch, Time-dependent local-density approximation in real time, Phys. Rev. B 4484 4487 (1996)
3. ? Alberto Castro, Heiko Appel, Micael Oliveira, Carlo A. Rozzi, Xavier Andrade, Florian Lorenzen, M. A.
L. Marques, E. K. U. Gross, Angel Rubio, octopus: a tool for the application of time-dependent density
functional theory, physica status solidi (b) 243 2465-2488 (2006)
4. ? Petersilka, M. and Gossmann, U. J. and Gross, E. K. U., Excitation Energies from Time-Dependent
Density-Functional Theory, Phys. Rev. Lett. 76 1212--1215 (1996)
Linear-Response Theory
38
The_Octopus_Manual
Troubleshooting
If Octopus works properly on your system (i.e. you can recreate the results in the tutorial) but you have troubles
using it for your own work, here are some things to try. Please feel free to add your own ideas here.
Read parser.log
If you look at the file exec/parser.log, it will tell you the value of the variables that you set with the inp
file, as well as all the variables which are taking their default value. This can sometimes be helpful in
understanding the behavior of the program.
Use OutputDuringSCF
If you add OutputDuringSCF = yes to your input file, you can examine the results of each iteration in the Self
Consistent Field calculation. So if you also have the variable Output set to Output = density +
potential, both the electron density and the Kohn-Sham, bare, exchange-correlation and Hartree potentials will
be written to a folder (called, e.g., scf.0001) after each SCF iteration.
Set DebugLevel
Set the variable DebugLevel to 1 for some extra diagnostic info and a stack trace with any fatal error, 2 to add a
full stack strace, and 99 to get a stack trace from each MPI task when running in parallel.
Previous Manual:Output - Next Manual:Symmetry
Back to Manual <p class=newpage>
Symmetry
There is not much use of symmetry in Octopus.
In finite systems, you will get an analysis just for your information, but which will not be used anywhere in the
code. It is of this form (e.g. for silane):
***************************** Symmetries *****************************
Symmetry elements : 4*(C3) 3*(C2) 3*(S4) 6*(sigma)
Symmetry group
: Td
**********************************************************************
Many symmetries will in fact be broken by the real-space mesh. Since it is always orthogonal, it will break
three-fold rotational symmetry of benzene, for example.
In periodic systems, you will also get an analysis, e.g like this for bulk silicon in its 8-atom convention cell:
***************************** Symmetries *****************************
Space group No.227
International: Fd -3 m
International(long): Fd -3 m _1
Schoenflies: Oh^7
Troubleshooting
39
The_Octopus_Manual
Multiplicity: 192
Point group
International: m -3 m
Schoenflies: Oh
Identity has a fractional translation
0.500000
0.500000
0.000000
Identity has a fractional translation
0.500000
0.000000
0.500000
Identity has a fractional translation
0.000000
0.500000
0.500000
Disabling fractional translations. System appears to be a supercell.
Info: The system has
24 symmetries that can be used.
**********************************************************************
The analysis is done by the library spglib. The comments on fractional translations and supercell are due to the use
of the conventional cell, since the 2-atom primitive cell does not have orthogonal lattice vectors and therefore
cannot be used in Octopus currently.
For large systems, the symmetry analysis might be very time-consuming; in rare cases, the symmetry analysis
might crash and stop the calculation. In either situation, you can use the variable SymmetriesCompute to turn
off the symmetry analysis. You can manually identify a direction in which symmetry is broken with
SymmetryBreakDir, which is appropriate for the case that an external field is applied in a particular direction.
Symmetries are used in two ways for periodic systems: first, to reduce the set of k-points needed. This behavior is
controlled by KPointsUseSymmetries. For high-symmetry systems, this can make a dramatic reduction in the
time required for a calculation. For example, in our silicon example, if we set
%KPointsGrid
4
| 4
| 4
0.5 | 0.5 | 0.5
%
|
|
|
|
|
weight
0.125000
0.375000
0.375000
0.125000
|
|
|
|
|
0.125000
0.125000
0.375000
0.375000
coordinates
0.125000
0.125000
0.375000
0.375000
0.125000
0.375000
0.125000
0.375000
|
|
|
|
|
The density and other scalar quantities are straightforwardly computed from the density due to each k-point and the
weight; the same has been done for some vector quantities such as the gradients used in GGA functionals and the
forces.. Note, however, that the proper calculation of more complicated tensorial properties such as the response
functions in the Sternheimer calculation modes have not been implemented with symmetry. You can also use the
symmetry operations to symmetrize the density, via SymmetrizeDensity. In general, you should beware of
use of symmetries for partially periodic systems (e.g. wire or sheet geometry) for which some problems have been
found.
The use of symmetry for reducing the number of calculations needed for obtaining absorption spectra by
time-propagation is discussed here: Tutorial:Optical_Spectra_from_TD:Symmetries
Symmetry
40
The_Octopus_Manual
Calculations
<p class=newpage>
Ground State
The ground-state electronic density in a Kohn-Sham (KS)-based electronic-structure code such as octopus is
obtained after a self-consistent process that attempts to solve the KS equations.
KS eigenfunctions
, eigenvalues
and density , which determines a KS ?input? Hamiltonian. By
diagonalizing this Hamiltonian, one obtains the corresponding ?output? eigenfunctions, eigenvalues, and density.
This density (or, alternatively, the corresponding Kohn-Sham potential) is then used to build a new input
Hamiltonian, that will be diagonalized in the next iteration step. This cycle is considered to be closed, and the
solution achieved, when the input and output are similar enough that some convergence criterion is fulfilled. In our
case, we have allowed for four different criteria, to be defined below. The self-consistent procedure will stop either
when the first of the convergence criterions is fulfilled, or when a maximum number of iterations has been
performed.
Mixing
The output density (or potential) of a given iteration is not used directly to construct the Kohn-Sham potential for
the following iteration. Instead, it is "mixed" with some densities (or potentials) of previous iteration steps. The
manner in which this mixing is produced is determined by the variables TypeOfMixing, Mixing, MixField
and MixNumber.
Convergence
After each iteration Octopus checks whether some convergence criterion is met. One criterion is that the error in
the electron density be smaller than some threshold. Of course, the true electron density is not known, so this
"error" is really the change in the density since the last iteration:
this criterion ConvAbsDens.
We call
However, since the density is proportional to the number of electrons N, this absolute criterion is not very
transferable between different system sizes. Therefore the default criterion to use is ConvRelDens, in which the
relative density,
Calculations
By
41
The_Octopus_Manual
threshold.
ConvRelEv: The eigenvalues are scaled by the number of electrons, otherwise as above.
To use them, set the relevant variable equal to a number indicating your desired error. Set the other three
convergence variables to zero.
Eigensolver
In each iteration of the self-consistency problem described above, Octopus must diagonalize the Kohn-Sham input
Hamiltonian to obtain the output eigenfunctions and eigenvalues. This diagonalization is done by the eigensolver,
also an iterative procedure. There are several options for the iterative scheme used to diagonalize the Hamiltonian,
which are specified in the documentation for the variable EigenSolver. You may specify the threshhold for
considering this iterative diagonalization finished with the variable EigenSolverTolerance. The variable
EigenSolverMaxIter sets a maximum number of steps in the diagonalization, so that if it is reached, the
diagonalization is considered finished even if some of the eigenvectors are not fully converged.
During each self-consistent field cycle iteration Octopus reports the eigenvalues it has obtained by diagonalizing
the Hamiltonian, and how many of those eigenvectors are fully converged.
*********************** SCF CYCLE ITER #
3 ************************
etot = 4.52092631E+00 abs_ev
= 7.91E+02 rel_ev
= 4.28E+01
abs_dens = 5.16E-01 rel_dens = 1.43E-02
Matrix vector products:
3669
Converged eigenvectors:
6
Eigenvalues [H]
#st Spin
Eigenvalue
Occupation
Error
1
--1.288198
2.000000
(7.2E-07)
2
--0.830676
2.000000
(1.0E-06)
3
--0.826885
2.000000
(8.8E-07)
4
--0.808297
2.000000
(6.2E-07)
...
It is not too important whether the eigenvectors are not converged in the SCF steps, only whether they are
converged at the end.
Convergence
42
The_Octopus_Manual
LCAO
Since the solution of the ground-state problem is done iteratively, we need an initial guess; a set of initial
Kohn-Sham orbitals. If we are doing the calculation with pseudopotentials (as opposed to model potentials defined
by the user), we can use the pseudo-orbitals that are used to generate the pseudopotential. By default, the program
will fill the initial guess states with pseudo-orbitals. Whether or not this is done is determined by the variable
LCAOStart. The guess density is the sum of the atomic densities.
Note, however, that those pseudo-orbitals are not passed directly to the iterative cycle. Instead, the code performs
an initial diagonalization with the Hamiltonian generated by the guess density. Therefore, the SCF cycle is started
with the linear combination of those atomic orbitals, with the coefficients that result of that diagonalization (LCAO
stands for linear combination of atomic orbitals). In other words, the first step of the SCF cycle is performed inside
the LCAO subspace, whereas the following steps are performed in the full space.
This diagonalization will typically be done with a number of pseudo-orbitals that is larger than the number that will
be used later in the KS SCF cycle. Once we diagonalize that LCAO matrix, we take the lowest lying eigenstates to
proceed with the calculation. There is some default number of pseudo-orbitals that will be used, but one can
change it making use of variable LCAODimension.
If you set SCFinLCAO, the LCAO calculation will be performed self-consistently. Or, in other words, the whole
SCF cycle will be done inside the LCAO subspace.
Unoccupied states
This is CalculationMode =unocc. The purpose of this run mode is to calculate higher lying Kohn-Sham
orbitals. For that purpose, it reads the restart information from a converged previous ground-state calculation, and
builds the corresponding Hamiltonian. Then, it calculates the unoccupied eigenvalues and eigenfunctions. The
number of unoccupied orbitals calculated is given by the ExtraStates.
Previous Manual:Symmetry - Next Manual:Time-Dependent
Back to Manual <p class=newpage>
Time-Dependent
Time evolution
When CalculationMode = td, the code performs the time-propagation of the electronic orbitals and if
required the ionic positions. The latter task does not pose major algorithmical problems (the usual Verlet
algorithms deal with that task); however the best way to propagate a Schrdinger-like equation is still unclear. Due
to this fact, we provide with a rather excessive selection of possibilities for that purpose. Before describing the set
of variables necessary to specify the way in which the time evolution is to be performed, it is worth making a brief
introduction to the problem.
We are concerned with a set of Schrdinger-like equations for the electronic orbitals
LCAO
:
43
The_Octopus_Manual
Because this equation is linear (the time derivative and the Hamiltonian are both linear operators), one may
formally define a linear ?evolution? operator,
time :
Moreover, there is the formally exact expression for the evolution operator
where
If the Hamiltonian commutes with itself at different times, we can drop the time-ordering product, and leave a
simple exponential. If the Hamiltonian is time-independent, which makes it trivially self commuting, the solution is
simply written as:
Unfortunately, this is not the case for TDDFT when the system is exposed to external time-dependent perturbations
like electric and magnetic fields or pulsed lasers. But even without an external time-dependency, there remains the
intrinsic time-dependency of the Kohn-Sham Hamiltonian, which is built self-consistently from the varying
electronic density.
The first step to tackle this problem is to split the propagation of the long interval
utilizing the group property
into
smaller steps by
Time evolution
44
The_Octopus_Manual
where
,
,
the short-time propagation:
: if
for
and
Approximate
Propagate
Calculate
.
from the orbitals
4.
.
.
In Octopus, however, the above scheme is dropped for performance reasons and only step 1 is implemented, via a
second-order extrapolation, except for the first two steps where the extrapolation obviously cannot be trusted.
Propagators for the time-dependent Kohn-Sham equations
45
The_Octopus_Manual
Splitting techniques
Splitting techniques exploit the fact that the Hamiltonian is composed of two terms,
, the
first kinetic term being diagonal in Fourier space, and the second potential term diagonal (or almost diagonal) in
real space.
The Split Operator (TDEvolutionMethod=split) is defined as
with
.
In the above expression, the density
the orbitals
to
The two kinetic terms are evaluated in Fourier space by the aid of the Fast Fourier Transform algorithm.
The Split Operator method in this realization is of second order in
The
are a suitably chosen set of real numbers related to the
by
.
The potential at times
is extrapolated in order to get a proper fourth-order method. This method allows for
comparativey large timesteps, but each time step takes roughly five times longer than for the second-order Split
Operator.
Midpoint rules
Splitting techniques
46
The_Octopus_Manual
The calculation of the matrix fraction is transformed into the solution of the linear system
and
Magnus expansions
Midpoint rules
47
The_Octopus_Manual
where
In Octopus we have implemented a fourth-order Magnus expansion, which means that the operator series is
truncated to second order and the integrals are calculated by a second-order quadrature formula. The resulting
operator is
Note that only the nonlocal components of the Kohn-Sham Hamiltonian contribute to the commutator and,
furthermore, that we make the assumption that the nonlocal potential
the interval
. This nonlocal component stems from the ionic pseudopotentials. Consequently, its
variation is caused by the ionic movement, which is negligible on the electronic time scale determining
.
Time-reversal-symmetry based propagation
starting from
starting from
should lead to
48
The_Octopus_Manual
at time
is not extrapolated, but rather built from the density
turn, is calculated from the orbital estimate
, which, in
, to get
Polynomial expansions
(TDExponentialMethod=standard):
49
The_Octopus_Manual
The standard polynomial basis is not the only possibility; Octopus also implements the expansion of the
exponential in the Chebyshev basis:
with
The truncation
for both these expansions can be set by the input variable ExpOrder.
Krylov-subspace projection
and vector
is defined as
with
being an orthonormal basis of
procedure. To get rid of the exponential, the approximation
in a least-squares
and
The_Octopus_Manual
controlled by TDLanczosTol is met or the order exceeds the maximum allowed order controlled by
TDExpOrder. In the latter case, a warning is written. Care should be taken in choosing the convergence
parameter small enough to avoid faulty evolutions.
Splitting techniques
Splitting techniques can also be used to calculate the exponential of the Hamiltonian
(TDExponentialMethod=split) which work in the same way as described in the previous section for the
propagator. Higher-order splitting schemes (TDExponentialMethod=suzuki_trotter) are also available.
Performing a time-propagation
To actually perform a time-propagation, a necessary prerequisite is to have the ground-state density (see Ground
State of the system under consideration.
Then, the CalculationMode has to be set to td.
Besides the already mentioned input variables concerning the propagation method, two more important parameters
have to be set: TDTimeStep and TDMaximumIter. The first one sets
, the second sets the number of
iterations. It is convenient to define these two variables like this:
T = 0.1
dt = 0.002
# Length of propagation.
# Length of time step.
TDMaximumIter = T/dt
TDTimeStep = dt
In the absence of a perturbation, the system's total energy should be a constant. This check to determine a
reasonable time step has to be done before any other calculation.
The relevant parts of Octopus' output might look like
Iter
1
2
3
.
.
.
48
49
50
Time
0.002000
0.004000
0.006000
Energy
-541.542073
-541.542073
-541.542073
0.096000
0.098000
0.100000
-541.542073
-541.542073
-541.542073
Elapsed Time
4.800
4.560
3.880
7.420
7.620
7.490
The energy is printed in the third column and should remain constant. In general, larger time steps are desirable to
shorten computational propagation time but keep in mind that the size of the time step limits to the maximum
frequency you will be able to observe, and, consequently, also any external perturbation to which you might wish
to expose the system.
Krylov-subspace projection
51
The_Octopus_Manual
External fields
Delta kick: Calculating an absorption spectrum
To obtain the linear optical absorption spectrum of the system, we follow the scheme proposed by Yabana and
Bertsch, and excite all frequencies of the system by giving some small momentum (
) to the electrons. This is
achieved by transforming the ground-state wavefunctions according to:
and then propagating these wavefunctions for some (finite) time. The spectrum can then be obtained from the
expression for the dipole strength function S():
where the dynamical polarizability, (), is essentially the Fourier transform of the dipole moment of the system
d(t):
With this definition, the Thomas-Reiche-Kuhn f-sum rule for the number of electrons, N, is given by the integral:
This sum rule can be used to check the quality of the calculations. Another check is energy conservation, which
TDDFT respects when no external field is applied.
To obtain a spectrum with such a recipe in Octopus one has to follow the steps:
1. Choose a system of linearly independent (can be non-orthogonal) axes (defined by the variable
TDPolarization). The defaults are the 3 Cartesian axes.
2. Add an electric kick using the variable TDDeltaStrength. Its value should be small so that we remain
in the linear regime, but large enough to avoid numerical errors.
3. Run a time-dependent simulation for the 3 independent directions. This involves running Octopus 3 times,
changing the value of TDPolarizationDirection each time. After each run, move the file
td.general/multipoles to td.general/multipoles.X<tt>, where <tt>X is 1, 2, or 3.
4. Run the utility oct-propagate_spectrum.
Lasers
To calculate non-linear optical properties, we follow the evolution of the system under the influence of a laser field
that is treated in the dipole approximation (although this constraint can be removed). The harmonic emission
spectrum can then be calculated from the acceleration of the dipole moment:
External fields
52
The_Octopus_Manual
During the propagation, charge density is absorbed at the boundaries of the simulation region, either by an
imaginary absorbing potential or a mask function. In the first case, we add to the Kohn-Sham potential a term
where Vabs is zero in the inner region of the simulation box, and rises smoothly till the edges. By adjusting both the
height and the shape of the potential, we can select which momenta are absorbed and prevent the unwanted
reflections at the boundary. When using a mask, the wavefunction is multiplied in each time-step by a function
which is 1 in the inner simulation region and gradually goes to 0 at the borders:
The absorbed charge can be interpreted as an ionization probability and can be used to estimate the photo-electron
spectra. The box size has to be big enough so that the physical system is not perturbed by the absorbing
boundaries. Note that the wavefunctions are no longer normalized as the system slowly gets charged.
Symmetries
The dynamic polarizability (trivially related to optical absorption) is, in its most general form, a 3x3 tensor. The
reason is that we can shine light on the system polarized in any of the three Cartesian axes, and for each of these
three cases measure how the dipole of the molecule oscillates along the three Cartesian axes. This usually means
that to obtain the full dynamic polarizability of the molecule we usually need to apply 3 different perturbations
along
, by setting TDPolarizationDirection to 1, 2, or 3.
However, if the molecule has some symmetries, it is in general possible to reduce the total number of calculations
from 3 to 2, or even 1. This is explained in detail here. To use this formalism in Octopus, you can use the variables
TDPolarization, TDPolarizationDirection, TDPolarizationEquivAxis, and
TDPolarizationWprime. The block TDPolarization defines a basis (not necessarily orthogonal) chosen
to maximize the number of equivalent axes, and TDPolarizationDirection, and
TDPolarizationWprime are vectors specified in that basis. Let us give a couple of examples.
The methane molecule has Td symmetry, which means that the response is identical for all directions. This means
that we only need one propagation to obtain the whole tensor. This propagation can be performed in any direction
we wish. So we could use the input
%TDPolarization
1 | 0 | 0
0 | 1 | 0
0 | 0 | 1
%
TDPolarizationDirection = 1
TDPolarizationEquivAxis = 3
%TDPolarizationWprime
Lasers
53
The_Octopus_Manual
0 | 0 | 1
%
Note that we could have omitted the blocks TDPolarization and TDPolarizationWprime in the previous
input file, as these are their default values.
Now let us look at a linear molecule. In this case, you might think that we need two calculations to obtain the
whole tensor, one for the direction along the axis of the molecule, and another for the axis perpendicular to the
molecule. The fact is that we need only one, in a specially chosen direction, so that our field has components both
along the axis of the molecule and perpendicular to it. Let us assume that the axis of the molecule is oriented along
the x-axis. Then we can use
%TDPolarization
1/sqrt(2) | -1/sqrt(2)
1/sqrt(2) | 1/sqrt(2)
1/sqrt(2) | 0
%
TDPolarizationDirection
TDPolarizationEquivAxis
%TDPolarizationWprime
0 | 0 | 1
%
| 0
| 0
| 1/sqrt(2)
= 1
= 3
You should try to convince yourself that the three axes are indeed equivalent and linearly independent.
Finally, let us look at a general planar molecule (in the xy plane). In principle we need only two calculations
(reduced to one if more symmetries are present, as for benzene). In this case we chose one of the polarization axes
on the plane, and the other two rotated 45 degrees out of plane:
%TDPolarizationDirection
1/sqrt(2) | 0 | 1/sqrt(2)
1/sqrt(2) | 0 |-1/sqrt(2)
0
| 1 | 0
%
TDPolarizationEquivAxis = 2
In this case, we need two runs, one for TDPolarizationDirection equal to 1, and another for it equal to 3.
Note that if there are fewer than 3 equivalent axes, TDPolarizationWprime is irrelevant.
Symmetries
54
The_Octopus_Manual
To perform a Casida calculation you first need a ground-state calculation and a calculation of unoccupied states;
then you run the code with CalculationMode=casida.
This is an input file for a linear-response calculation of the nitrogen dimer, found at
SHARE/testsuite/linear_response/01-casida.*.
%CalculationMode
gs | unocc | casida
"ground_state_" | "unocc_states_" | "lrtddft_"
1 | 2 | 3
%
FromScratch = yes
bond_length = 2.0744
%Coordinates
"N" | -bond_length/2 |
"N" |
bond_length/2 |
%
0.0 |
0.0 |
0.0 | no
0.0 | no
%Species
"N" | 14.0067000 | tm2 | 7 | 2 | 0
%
BoxShape = sphere
Radius = 12.0
Spacing = 0.36
SpinComponents = unpolarized
XFunctional = lda_x
CFunctional = lda_c_vwn
MaximumIter = 200
ConvRelDens = 1e-5
LCAOStart = lcao_full
LCAODimension = 18
EigenSolver = cg_new
EigenSolverInitTolerance = 1e-2
EigenSolverFinalTolerance = 1e-5
EigenSolverFinalToleranceIteration = 6
EigenSolverMaxIter = 20
unocc_states_EigenSolverMaxIter = 1000
TypeOfMixing = broyden
NumberUnoccStates = 9
PoissonSolver = fft_corrected
55
The_Octopus_Manual
The first thing we will need for linear response is a Ground State calculation. Unlike other techniques, when using
the Sterheimer equation you needn't do a unoccupied-states calculation. To improve the convergence of the
linear-response calculation, it is better to use tightly converged wavefunctions. For example, you can add these
parameters to your gs calculation:
EigenSolverFinalTolerance = 1e-10
ConvAbsDens = 1e-9
Input
The CalculationMode for polarizability calculations is em_resp. The main parameter you have to specify is
the frequency of the perturbation, given by the EMFreqs block. You can also add an imaginary part to the
frequency by setting the variable EMEta. Adding a small imaginary part is required if you want to get the
imaginary part of the polarizability or to calculate polarizabilities near resonance; a reasonable value is 0.1 eV.
To get the hyperpolarizabilties, you also have to specify the variable EMHyperpol with the three coefficients
with respect to the base frequency; the three values must sum to zero.
Output
After running, for each frequency in the input file, Octopus will generate a subdirectory under em_resp/. In each
subdirectory there is a file called alpha that contains the real part of the polarizability tensor ij and the average
polarizability
The imaginary part is written to file eta. If > 0, there is also a file called cross_section_tensor that
contains the photo-absorption cross section tensor for that frequency, related to the imaginary part of the
56
The_Octopus_Manual
polarizability (
).
The hyperpolarizability will be in a file called beta at the base frequency, containing all the 27 components and
some reduced quantities:
Optimal Control
If you set CalculationMode = opt_control, you will be attempting to solve the Quantum Optimal Control
Theory (QOCT) equations. This tutorial introduces the basic theoretical concepts of QOCT, as well as the
procedure to perform basic QOCT calculations with octopus.
If you already know QOCT, you can skip the Theoretical Introduction.
Theoretical Introduction
The QOCT can be formulated in the following way:
We consider a quantum mechanical system, governed in a temporal interval [0,T] by the Hamiltonian
Output
to a final state
, according to
57
The_Octopus_Manual
J1[] is the objective functional. In this basic tutorial, we will be concerned with the case in which it
depends only on the value of the state at the end of the propagation, (T). Moreover, the functional is the
expectation value of some positive-definite operator
should constrain the values of the control parameter. Typically, the idea is to maximize the
objective J1 while minimizing the fluence:
Theoretical Introduction
58
The_Octopus_Manual
As observed by Zhu, Botina and Rabitz[1], for this case one can use an alternative definition of J3:
This alternative definition has the virtue of decoupling the equations for and :
These are the equation that we are concerned with in the present example.
59
The_Octopus_Manual
CalculationMode = gs
Dimensions = 1
fromScratch = yes
BoxShape = sphere
Spacing = 0.1
Radius = 8.0
TheoryLevel = independent_particles
%Species
"AWD1D" | 1 | spec_user_defined | 1 | "1/64*(x)^4-1/4*(x)^2+1/256*(x)^3"
%
%Coordinates
"AWD1D" | 0
%
ExtraStates = 1
EigenSolverInitTolerance = 1.0e-6
EigenSolverFinalTolerance = 1.0e-6
EigenSolverMaxIter = 1000
Mixing = 1.0
TypeOfMixing = linear
Fig. 1. Black curve: external potential defining the asymmetric double well used in this example. Red and green:
ground state and excited state, respectively, corresponding to this system
Note that we have set "ExtraStates=1" because we want to get the first excited state, in order to be able to do
QOCT later (the objective will be the maximum population of this state).
In this way we obtain the first two (single particle) states for this system. It is useful to make a plot with the results,
together with the potential. If you do this, you should the curves depicted in Fig. 1. Observe how the ground state is
localized in the left well (which is, not surprisingly, deeper), whereas the first excited state is localized in the right
The asymmetric double well: preparing the states
60
The_Octopus_Manual
well. We are going to attempt to transfer the wavepacket from one side to the other. The energies of these two
states are -0.6206 a.u. and -0.4638, respectively.
Note that, in order to plot the functions, you will have to add to the inp file the variables Output and
OutputHow.
61
The_Octopus_Manual
ampl = 0.06
freq = 0.157
%TDExternalFields
electric_field | 1 | 0 | 0 | freq | "envelope_function"
%
%TDFunctions
"envelope_function" | tdf_cw | ampl
%
#---------------------------# Output
#----------------------------Output = wfs
OutputHow = axis_x
TDOutput = laser + td_occup
is smaller than OCTEps. Note that this may never happen; there is no convergence guarantee.
4. OCTPenalty sets the penalty parameter described previously.
5. OCTInitialState should specify the initial states from which the propagation starts. In most cases this
will just be the ground state of the system -- this is the case for this example. The value
"oct_is_groundstate" means that.
6. OCTTargetOperator sets which kind of target operator ( , with the notation used above) will be
used. As mentioned before, for this example we will be using a very common kind of target: the projection
onto a target state:
. This is set by doing OCTTargetOperator =
oct_tg_gstransformation. This means that the target state is constructed by taking a linear combination of
the spin-orbitals that form the ground state. The particular linear combination to be used is set by the block
OCTTargetTransformStates.
62
The_Octopus_Manual
7. OCTTargetTransformStates. This is a block. Each line of the code refers to each of the spin orbitals
that form the state the system; in this example we have a one-particle problem, and therefore one single
spin-orbital. This spin orbital will be a linear combination of the spin-orbitals calculated in the previous
ground-state run; each of the columns will contain the corresponding coefficient. In our case, we calculated
two spin-orbitals in the ground state run, therefore we only need two columns. And our target state is
simply the first excited state, so the first column (coefficient of the ground state orbital) is zero, and the
second column is one.
8. OCTDoubleCheck simply asks the code to perform a final propagation with the best field it could find
during the QOCT iterative scheme, to check that it is really working as promised.
The next section ("Laser field = Initial guess") simply specifies which is the initial laser field to be used as
"initial guess". It is mandatory, since it not only provides with the initial guess for the "control parameter"
(which is simply a real function
that specifies the temporal shape of the time-dependent external
perturbation), but also specifies what kind of external perturbation we are talking about: an electric field
with x, y or z polarization, a magnetic field, etc.
Finally, we would like to do cute plots with our results, so we add an "Output" section. This only applies if
we have set OCTDoubleCheck=yes, since the code does not plot anything during the propagations
performed in the QOCT iterations. The variables given will permit us to plot the shape of the wavefunction
during the propagation, as well as the time-dependent electric field and the projection of the propagating
wave function onto the ground state and first excited state.
Even if this is a simple one-dimensional system, the run will take a few minutes because we are doing a lot of
propagations. You will see how, at each iteration, some information is printed to standard output, e.g.:
****************** Optimal control iteration #
12 ******************
=> J1
=
0.87422
=> J
=
0.54580
=> J2
=
-0.32842
=> Fluence =
0.32842
=> Penalty =
1.00000
=> D[e,e'] =
1.66E-04
**********************************************************************
The meaning of each number should be clear from the notation that we have introduced above. By construnction,
the algorithm is "monotonously convergent", meaning that the value of J should increase. This does not guarantee
that the final value of J1 will actually approach one, which is our target (full overlap with the first excited state),
but we certainly hope so.
At the end of the run it will do a "final propagation with the best field" (usually the one corresponding to the last
iteration). For this example, you will get something like:
*************** Final propagation with the best field ****************
=> J1
=
0.94924
=> J
=
0.61497
=> J2
=
-0.33427
=> Fluence =
0.33427
**********************************************************************
63
The_Octopus_Manual
Fig. 3. Initial and target states (red and green). In blue, the final propagated state corresponding to the last iteration
field.
The run will create a directory called opt-control (among others). In it there is a file called convergence
that contains the convergence history of the QOCT run, i.e. the values of the relevant functionals at each QOCT
iteration. It is useful to make a plot with these values; you can see the result of this in Fig. 2. Observe the
monotonous increase of J. Also, in this case, the functional J1 (which is, in fact, the one we are really interested in)
grows and approaches unity -- although the final limit will not be one, but in this case something close to 0.95.
Analysis of the results
64
The_Octopus_Manual
In the directory opt-control there are also some subdirectories called PsiT.0xx (xx running from 01 to 50,
and laser.0xx. The former contain plots of the wavefunction at the end of the propagation, (T), at each of the
QOCT iterative steps, while the latter contain the corresponding control parameter (it is called laser because it will
almost always represent a laser field).
The amount and type of information contained in each Psi.0xx directory will depend on the values that you set
for the variables Output and OutputHow. For our example, in the example that we have just run, it will contain
the wavefunctions of the states (only one in our case) along the x axis (since it is just a one dimensional system).
If you perform many iterations, the amount of disk space needed to save all those files may be large, and you may
want to disable the writing of all the information corresponding to the intermediate iterations. This can be turned
on and off through the variable OCTDumpIntermediate.
There is also a directory called initial, useful to plot the initial state; a directory called target, that contains
the target state; and a directory called final that contains the state at the end of the propagation corresponding to
the last QOCT iteration. Fig. 3 is a plot constructed with the information contained in these directories. Note that
while the initial and target states have no imaginary part, the final propagated wavefunction is complex, and
therefore we have to plot both the real and the imaginary part.
In the directories laser.0xx you will find a file called cp which contains the control parameter for the
corresponding QOCT iteration. Another file, called fluence informs about the corresponding fluence. The
format of file cp is simple: first column is time, second and third column are the real and imaginary part of the
control parameter. Since
is defined to be real in our formulation, the last column should be null. Finally, the
directory laser.bestJ1 will obviously contain the control parameter corresponding to the iteration that
produced the best J1.
References
1. ? 1.0 1.1 W. Zhu, J. Botina and H. Rabitz, J. Chem. Phys. 108, 1953 (1998)
Previous Tutorial:Geometry optimization - Next Tutorial:Open boundaries
Back to Tutorial <p class=newpage>
Geometry Optimization
To perform a geometry optimization with octopus one should set the CalculationMode to go. octopus uses the
minimization routines from GSL. The method to be used should be set using the variable GOMethod.
The stopping criteria can be set with the variables GOTolerance and GOMinimumMove . Then minimization
will be stopped when all forces on ions are smaller than GOTolerance or when all species coordinates change
less than GOMinimumMove during on minimization step. If none of the previous criteria is matched after a
number of minimization steps equal to GOMaxIter then the minimization will be stopped with an error message.
After each minimization step taken by the GSL algorithms octopus will write the current geometry to a file named
go.XXXX.xyz (XXXX is the iteration number) in the directory geom. As an extra information, the title of the
xyz file (second line) contains the total energy.
References
65
The_Octopus_Manual
Note that octopus is not particularly efficient in performing geometry optimizations and many times, if the
stopping criteria are too small, the GSL routines will return an error message stating that they were unable to
improve the solution.
At the end of the run, if the minimization was successful, the minimized geometry will be written to a file named
min.xyz in the working directory. <p class=newpage>
Parallel in States
The first strategy is parallel in states. This means that each processor takes some states and propagates them
independently of the others.
To use this include
ParallelizationStrategy = par_states
Parallel in Domains
When running parallel in "domains", octopus divides the simulation region (the box) into separate regions
(domains) and assigns each of of these to a different processor. This allows it not only to speed up the calculation,
but also to divide the memory among the different processors. The first step of this process, the splitting of the box,
is in general a very complicated process. Note that we are talking about a simulation box of an almost arbitrary
shape, and of an arbitrary number of processors. Furthermore, as the communication between processors grows
proportionally to the surface of the domains, one should use an algorithm that divides the box such that each
domain has the same number of points, and at the same time minimizes the total area of the domains. Octopus uses
the METIS library to make this domain decomposition of the space, METIS is included in the source code of
Octopus and will be used by default.
So for example, if you are planning to run the ground state of Na there's only one choice:
ParallelizationStrategy = par_domains
66
The_Octopus_Manual
Octopus will then partition the real-space mesh and compute the resulting pieces on different nodes. Later when
you plan to do time propagations you have more choices at hand. You could run only parallel in states
ParallelizationStrategy = par_states
or in domains (as above), or you can decide to employ both parallelization strategies
ParallelizationStrategy = par_domains + par_states
Warning:
From node =
0
I have less elements in a parallel group than recommended.
Maybe you should reduce the number of nodes
It is wise to also set the FCFLAGS, as octopus cannot tell which fortran compiler you are using if you compile with
mpif90.
3) Now you just have to run octopus in parallel (this step depends on your actual system, you may have to use
mpirun or mpiexec to accomplish it).
Parallel in Domains
67
The_Octopus_Manual
In some run modes (e.g., td), you can use the multi-level parallelization, i.e., to run in parallel in more than one
way at the same time. In the td case, you can run parallel in states and in domains at the same time. In order to
fine-tune this behavior, please take a look at the variables ParallelizationStrategy and
ParallelizationGroupRanks. In order to check if everything is OK, take a look at the output of octopus in
the "Parallelization" section. This is an example:
************************** Parallelization ***************************
Octopus will run in *parallel*
Info: Number of nodes in par_states group:
8 (
62)
Info: Octopus will waste at least 9.68% of computer time
**********************************************************************
In this case, Octopus runs in parallel only in states, using 8 processors (for 62 states). Furthermore, some of the
processors will be idle for 9.68% of the time (this is not that great, so maybe a different number of processors
would be better in this case).
Multi-Dataset Mode
You can perform multiple runs with a single input file by using CalculationMode as a block. This is typically
done for convenience to combine runs in different modes whose input files differ by only a few lines.
The first line is a list of calculation modes, the second is labels (optional; default is dsXX_ where XX=01, 02, ...),
and the third is the order for the runs (optional; default is the order listed). The labels will be used as prefixes for
the output directories such as restart, static, td... etc., and can also be used as prefixes to variables to
indicate that they apply only to that dataset's calculation.
An example from testsuite/finite_system_1d/01-hydrogen.01-ground_state.inp:
%CalculationMode
gs
| unocc
"ground_state_" | "excited_states_"
1
| 2
%
excited_states_RestartDir = "ground_state_restart"
excited_states_ExtraStates = 9
After that, to pass an input variable to octopus, you must prepend the name of the variable by 'OCT_', for
example:
$ export OCT_Radius=10
68
The_Octopus_Manual
If you set a variable both from the input file and as a environment variable, the environment variable takes
precedence. Be careful with this behaviour. Blocks are not supported (suggestions as how to elegantly put a block
inside of environment variables are welcome).
There is an additional environment variable OCTOPUS_SHARE that can be set to specify the location of the
variables file used by the parser. If this environment variable is not set, the default is as set by the configure
script, namely prefix/share/octopus. You can set this to something else if necessary, for example to
handle moving an executable from one machine to another, where the original path does not exist on the new
machine.
Examples
For example this is a simple script that helps to determine the optimal Radius of the simulation box (an inp file
with the rest of the parameters has to be provided):
export OCT_PARSE_ENV=1
for OCT_Radius in `seq 5 16`
do
export OCT_Radius
octopus >& out-$OCT_Radius
energy=`grep Total static/info
echo $OCT_Radius $energy
done
Utilities
<p class=newpage>
oct-atomic_occupations
This script prints out to standard output the electronic configuration of a given atom, and the way in which this
electronic configuration should be reflected in the Occupations block of a corresponding Octopus input file.
Options
-s species
species should be the atomic symbol (e.g. Na, Au, etc).
Utilities
69
The_Octopus_Manual
-h
Show a brief summary of command line options.
Examples
$ oct-atomic_occupations -s Na
$ oct-atomic_occupations -s Ti_sc
$ for x in \$(cat /usr/share/octopus/PP/defaults | awk '{print \$1}')
> do oct-atomic_occupations -s $x
> done
oct-casida_spectrum
NAME
oct-casida_spectrum - Broadens the linear-response spectra from the Casida run mode.
SYNOPSIS
oct-casida_spectrum
[oct-casida_spectrum does not read standard input: all standard input will be simply ignored. An input file named
inp must be present in the running directory. Also, oct-casida_spectrum accepts no command line arguments,
since there is not a standard way to do this with Fortran 90.]
DESCRIPTION
This program is one of the Octopus utilities.
It post-processes the files casida/casida, casida/petersilka and casida/eps_diff, that contain
the excitation energies and oscillator strengths.
The parameters of the spectrum can be set using the variables CasidaSpectrumBroadening,
CasidaSpectrumMinEnergy, CasidaSpectrumMaxEnergy, and CasidaSpectrumEnergyStep.
The man pages of Octopus and of the auxiliary Octopus sub-programs (oct-something) are not intended to contain
the documentation of the programs, but only their basic description. For where to find more documentation, see the
SEE ALSO section below.
Options
70
The_Octopus_Manual
AUTHOR
Written by M. A. L. Marques, A. Castro, A. Rubio, C. A. Rozzi, F. Lorenzen, H. Appel and X. Andrade.
REPORTING BUGS
Report bugs through the <[email protected]> mailing list.
COPYRIGHT
Copyright (C) 2006 M. A. L. Marques, A. Castro, A. Rubio, C. A. Rozzi, F. Lorenzen, H. Appel and X. Andrade.
This is free software; see the source for copying conditions. There is NO warranty; not even for
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
SEE ALSO
The largest source of documentation is expected to be at the Octopus wiki:
http://www.tddft.org/programs/octopus/wiki/.
At the usual standard locations, you will also find an info file octopus.info.
Previous Manual:External utilities:oct-atomic_occupations - Next Manual:External utilities:oct-center-geom
Back to Manual <p class=newpage>
oct-center-geom
NAME
oct-center-geom - Centers a molecule's geometry
SYNOPSIS
oct-center-geom
[oct-center-geom does not read the standard input: all standard input will be simply ignored. An input file named
inp must be present in the running directory. Also, oct-center-geom accepts no command-line arguments, since
there is not a standard way to do this with Fortran 90.]
DESCRIPTION
This program is one of the Octopus utilities.
It reads the coordinates defined in the inp file, and constructs an output xyz file, that will be called
adjusted.xyz file, that describes the same system but in which the atomic coordinates are centered, and
(optionally) has the axes aligned.
AUTHOR
71
The_Octopus_Manual
To control the orientation of the centered molecule there are two parameters: MainAxis and AxisType.
Do not forget then to change your input file to use this file instead of your old geometry (by changing
XYZCoordinates='adjusted.xyz').
Be careful with units, this utility honours the Units, UnitsInput and UnitsOutput variables, so the
adjusted.xyz file will be in the specified output units.
The man pages of Octopus and of the auxiliary Octopus sub-programs (oct-something) are not intended to contain
the documentation of the programs, but only their basic description. For where to find more documentation, see the
SEE ALSO section below.
AUTHOR
Written by M. A. L. Marques, A. Castro, A. Rubio, C. A. Rozzi, F. Lorenzen, H. Appel and X. Andrade.
REPORTING BUGS
Report bugs through the <[email protected]> mailing list.
COPYRIGHT
Copyright (C) 2006 M. A. L. Marques, A. Castro, A. Rubio, C. A. Rozzi, F. Lorenzen, H. Appel and X. Andrade.
This is free software; see the source for copying conditions. There is NO warranty; not even for
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
SEE ALSO
The largest source of documentation is expected to be at the Octopus wiki:
http://www.tddft.org/programs/octopus/wiki/.
At the usual standard locations, you will also find an info file, octopus.info.
Previous Manual:External utilities:oct-casida_spectrum - Next Manual:oct-propagate_spectrum
Back to Manual <p class=newpage>
oct-propagate_spectrum
NAME
oct-propagate_spectrum - Calculates the absorption cross section tensor from the results of a time-propagation run.
DESCRIPTION
72
The_Octopus_Manual
SYNOPSIS
oct-propagate_spectrum
[oct-propagate_spectrum does not read the standard input: all standard input will be simply ignored. An input file
named inp must be present in the running directory. Also, oct-propagate_spectrum accepts no command line
arguments, since there is not a standard way to do this with Fortran 90.]
DESCRIPTION
This program is one of the Octopus utilities.
The man pages of Octopus and of the auxiliary Octopus sub-programs (oct-something) are not intended to contain
the documentation of the programs, but only their basic description. For where to find more documentation, see the
SEE ALSO section below.
This utility generates the dipole strength function of the given system. Its main input is the td.general/multipoles
file. Output is written to a file called spectrum. This file is made of two columns: energy (in eV or a.u., depending
on the units specified in the input file), and dipole strength function (in 1/eV, or 1/a.u., idem).
In the input file, the user may set the PropagationSpectrumTransform (this should be set to ?sine? for
proper use), the PropagationSpectrumDampMode (recommended value is ?polynomial?, which ensures
fulfilling of the N-sum rule), the PropagationSpectrumStartTime, the
PropagationSpectrumEndTime, the PropagationSpectrumEnergyStep, and the
PropagationSpectrumMaxEnergy.
AUTHOR
Written by M. A. L. Marques, A. Castro, A. Rubio, C. A. Rozzi, F. Lorenzen, H. Appel and X. Andrade.
REPORTING BUGS
Report bugs through the <[email protected]> mailing list.
COPYRIGHT
Copyright (C) 2006 M. A. L. Marques, A. Castro, A. Rubio, C. A. Rozzi, F. Lorenzen, H. Appel and X. Andrade.
This is free software; see the source for copying conditions. There is NO warranty; not even for
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
SEE ALSO
The largest source of documentation is expected to be at the Octopus wiki:
http://www.tddft.org/programs/octopus/wiki/.
At the usual standard locations, you will also find an info file, octopus.info.
SYNOPSIS
73
The_Octopus_Manual
oct-display_partitions
NAME
oct-display_partitions - Graphical representation of the mesh partitions.
SYNOPSIS
oct-display_partitions
[oct-display_partitions does not read the standard input: all standard input will be simply ignored. Also,
oct-display_partitions accepts no command line arguments.]
DESCRIPTION
This program is one of the octopus utilities.
It is a script to use gnuplot to plot the partitioning of the mesh. The files TO DO mesh_partition.??? as
produced in debug/mesh_partition by the Octopus debug mode have to be present in the current working
directory when this script is invoked. The plot can be found in the file mesh_partitions.png. This script
generates a gnuplot-script called mesh_partitions_index.gp which is stored in the current working
directory and can be loaded into gnuplot manually. With:
$ gnuplot> load mesh_partitions_index.gp
$ gnuplot> set term x11
$ gnuplot> replot
the plot can be reproduced and shown on the screen so that rotating and zooming is possible.
The man pages of Octopus and of the auxiliary Octopus sub-programs (oct-something) are not intended to contain
the documentation of the programs, but only their basic description. For where to find more documentation, see the
SEE ALSO section below.
AUTHOR
Written by H. Appel.
REPORTING BUGS
Report bugs through the <[email protected]> mailing list.
SEE ALSO
74
The_Octopus_Manual
COPYRIGHT
Copyright (C) 2005 H. Appel.
This is free software; see the source for copying conditions. There is NO warranty; not even for
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
SEE ALSO
The largest source of documentation is expected to be at the Octopus wiki:
http://www.tddft.org/programs/octopus/wiki/.
At the usual standard locations, you will also find an info file, octopus.info.
Previous Manual:oct-propagate_spectrum - Next Manual:External utilities:oct-harmonic-spectrum
Back to Manual <p class=newpage>
oct-harmonic-spectrum
NAME
oct-harmonic-spectrum - Calculates the harmonic spectrum.
SYNOPSIS
oct-harmonic-spectrum
[oct-harmonic-spectrum does not read the standard input: all standard input will be simply ignored. An input file
named inp must be present in the running directory. Also, oct-harmonic-spectrum accepts no command line
arguments, since there is not a standard way to do this with Fortran 90.]
DESCRIPTION
This program is one of the Octopus utilities.
TO DO MISSING SHORT DESCRIPTION OF THE PROGRAM
The man pages of Octopus and of the auxiliary Octopus sub-programs (oct-something) are not intended to contain
the documentation of the programs, but only their basic description. For where to find more documentation, see the
SEE ALSO section below.
AUTHOR
Written by M. A. L. Marques, A. Castro, A. Rubio, C. A. Rozzi, F. Lorenzen, H. Appel and X. Andrade.
COPYRIGHT
75
The_Octopus_Manual
REPORTING BUGS
Report bugs through the <[email protected]> mailing list.
COPYRIGHT
Copyright (C) 2006 M. A. L. Marques, A. Castro, A. Rubio, C. A. Rozzi, F. Lorenzen, H. Appel and X. Andrade.
This is free software; see the source for copying conditions. There is NO warranty; not even for
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
SEE ALSO
The largest source of documentation is expected to be at the Octopus wiki:
http://www.tddft.org/programs/octopus/wiki/.
At the usual standard locations, you will also find an info file, octopus.info.
Previous Manual:External utilities:oct-display_partitions - Next Manual:External utilities:oct-vibrational_spectrum
Back to Manual <p class=newpage>
oct-vibrational_spectrum
1. REDIRECT Manual:oct-vibrational spectrum
<p class=newpage>
oct-rotatory_strength
NAME
oct-rotatory_strength - Calculates the circular dichroism spectrum from a time-propagation run.
SYNOPSIS
oct-rotatory_strength
[oct-rotatory_strength does not read the standard input: all standard input will be simply ignored. An input file
named inp must be present in the running directory. Also, oct-rsf accepts no command line arguments, since there
is not a standard way to do this with Fortran 90.]
DESCRIPTION
This program is one of the octopus utilities.
REPORTING BUGS
76
The_Octopus_Manual
AUTHOR
Written by M. A. L. Marques, A. Castro, A. Rubio, C. A. Rozzi, F. Lorenzen, H. Appel and X. Andrade.
REPORTING BUGS
Report bugs through the <[email protected]> mailing list.
COPYRIGHT
Copyright (C) 2006 M. A. L. Marques, A. Castro, A. Rubio, C. A. Rozzi, F. Lorenzen, H. Appel and X. Andrade.
This is free software; see the source for copying conditions. There is NO warranty; not even for
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
SEE ALSO
The largest source of documentation is expected to be at the Octopus wiki:
http://www.tddft.org/programs/octopus/wiki/.
At the usual standard locations, you will also find an info file, octopus.info.
Previous Manual:oct-vibrational_spectrum - Next Manual:External utilities:oct-run_periodic_table
Back to Manual <p class=newpage>
oct-run_periodic_table
NAME
oct-run_periodic_table - run octopus for atoms
SYNOPSIS
oct-run_periodic_table [ option ] ...
DESCRIPTION
This script is one of the octopus utilities.
Simple script to run octopus for all atoms in the periodic table for which pseudopoentials are available.
DESCRIPTION
77
The_Octopus_Manual
-h
Show this message
-n
Run in dry run mode (show what would be executed)
-s species
Run octopus for given species.
-a
Run octopus for all atoms
-r
Do a restart, i.e. do not use fromScratch=yes.
-t temperature
Run with electronic temperature.
-e no_states
Use extra states
-x octopus_executable
-d defaults_file_for_pseudopotentials
The man pages of Octopus and of the auxiliary Octopus sub-programs (oct-something) are not intended to contain
the documentation of the programs, but only their basic description. For where to find more documentation, see the
SEE ALSO section below.
EXAMPLES
The following command would run the octopus executable to calculate the He atom.
$
oct-run_periodic_table -s He -x octopus
AUTHOR
Written by H. Appel.
DESCRIPTION
78
The_Octopus_Manual
REPORTING BUGS
Report bugs to <[email protected]>.
COPYRIGHT
Copyright (C) 2005 H. Appel.
This is free software; see the source for copying conditions. There is NO warranty; not even for
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
SEE ALSO
The largest source of documentation is expected to be at the Octopus wiki:
http://www.tddft.org/programs/octopus/wiki/.
At the usual standard locations, you will also find an info file, octopus.info.
Previous Manual:External utilities:oct-rotatory_strength - Next Manual:External utilities:oct-run_regression_test.pl
Back to Manual <p class=newpage>
oct-run_regression_test.pl
NAME
oct-run_regression_test.pl - Script to create and run octopus regression tests
SYNOPSIS
oct-run_regression_test.pl [ option ] ... [ file ] ...
DESCRIPTION
This script is one of the octopus utilities.
This script can be used to generate and run the octopus regression tests.
The man pages of octopus and of the auxiliary octopus sub-programs (oct-something) are not intended to contain
the documentation of the programs, but only their basic description. For where to find more documentation, see the
"SEE ALSO" section below.
-n
Dry run. Don't run the test. Only print what would be executed.
-v
REPORTING BUGS
79
The_Octopus_Manual
EXAMPLES
To create a template for a regression test run e.g.
$ oct-run_regression_test.pl -c finite_systems_3d/sodium.test
If a test run fails it might be useful for bug tracing to preserve the working directory of this run and to print out the
input file
$ oct-run_regression_test.pl -pi -f finite_systems_3d/sodium.test
DESCRIPTION
80
The_Octopus_Manual
AUTHOR
Written by H. Appel.
REPORTING BUGS
Report bugs to <[email protected]>.
COPYRIGHT
Copyright (C) 2005 H. Appel.
This is free software; see the source for copying conditions. There is NO warranty; not even for
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
SEE ALSO
The largest source of documentation is expected to be at the Octopus wiki:
http://www.tddft.org/programs/octopus/wiki/.
Previous Manual:External utilities:oct-run_periodic_table - Next Manual:External utilities:oct-run_testsuite
Back to Manual <p class=newpage>
oct-run_testsuite
NAME
oct-run_testsuite - Script to run the octopus testsuite.
SYNOPSIS
oct-run_testsuite [ option ] ...
DESCRIPTION
This script is one of the octopus utilities.
This script runs the octopus testsuite.
The man pages of Octopus and of the auxiliary Octopus sub-programs (oct-something) are not intended to contain
the documentation of the programs, but only their basic description. For where to find more documentation, see the
SEE ALSO section below.
-h
Prints out a short help message.
AUTHOR
81
The_Octopus_Manual
-n
Run in dry mode (show what would be executed).
-f
Run full testsuite.
-l
Local run.
-p prefix
Installation prefix [default: /usr]
-m address Mail report to address
EXAMPLES
TO DO MISSING EXAMPLES
AUTHOR
Written by H. Appel.
REPORTING BUGS
Report bugs to <[email protected]>.
COPYRIGHT
Copyright (C) 2005 H. Appel.
This is free software; see the source for copying conditions. There is NO warranty; not even for
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
SEE ALSO
The largest source of documentation is expected to be at the Octopus wiki:
http://www.tddft.org/programs/octopus/wiki/.
Previous Manual:External utilities:oct-run_regression_test.pl - Next Manual:External utilities:oct-xyz-anim
Back to Manual <p class=newpage>
DESCRIPTION
82
The_Octopus_Manual
oct-xyz-anim
NAME
oct-xyz-anim - Constructs an "animated" xyz file from a time-propagation file where the atoms were allowed to
move
SYNOPSIS
oct-xyz-anim
[oct-xyz-anim does not read the standard input: all standard input will be simply ignored. An input file named inp
must be present in the running directory. Also, oct-xyz-anim accepts no command line arguments, since there is
not a standard way to do this with Fortran 90.]
DESCRIPTION
This program is one of the Octopus utilities. It reads out the td.general/coordinates file, and makes a
movie in XYZ format, called 'movie.xyz'.
The man pages of Octopus and of the auxiliary Octopus sub-programs (oct-something) are not intended to contain
the documentation of the programs, but only their basic description. For where to find more documentation, see the
SEE ALSO section below.
AUTHOR
Written by M. A. L. Marques, A. Castro, A. Rubio, C. A. Rozzi, F. Lorenzen, H. Appel and X. Andrade.
REPORTING BUGS
Report bugs through the <[email protected]> mailing list.
COPYRIGHT
Copyright (C) 2006 M. A. L. Marques, A. Castro, A. Rubio, C. A. Rozzi, F. Lorenzen, H. Appel and X. Andrade.
This is free software; see the source for copying conditions. There is NO warranty; not even for
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
SEE ALSO
The largest source of documentation is expected to be at the Octopus wiki:
http://www.tddft.org/programs/octopus/wiki/.
At the usual standard locations, you will also find an info file, octopus.info.
Previous Manual:External utilities:oct-run_testsuite - Next Manual:External utilities:Visualization
oct-xyz-anim
83
The_Octopus_Manual
Visualization
Every given number of time iterations, or after ground-state calculations, some of the functions that characterise
the system may be written to disk so that they may be analized. Files are written within static/ output directory
after the self-consistent field, or within td.x/ directories, during evolution, where ?x? stands for the iteration
number at which each write is done.
The function that you want to plot is selected by the Output variable and the output format is chosen by the
OutputHow.
dx
This is an OpenDX network, aimed at the visualization of wavefunctions. To be able to use it, you need to have
properly installed the OpenDX program, as well as the Chemistry extensions developed at the Cornell Theory
Center (http://www.tc.cornell.edu/Services/Visualization/). Please take a look here to see how to obtain and install
this software.
Once these are working, you may follow the tutorial for the benzene molecule.
XCrySDen
Atomic coordinates (finite or periodic), forces, and functions on a grid can be plotted with the free program
XCrySDen. Its XSF format also can be read by V_Sim and Vesta. Beware, these all probably assume that your
output is in Angstrom units, so use UnitsOutput = eV_Angstrom, or your data will be misinterpreted by the
visualization software.
CUBE
The Gaussian cube format (http://paulbourke.net/dataformats/cube/) can be output, and can be read by VMD,
XCrysDen, Avogadro, and other software. Beware: these all seem to assume the output is in atomic units, so use
UnitsOutput = atomic, or your data will be misinterpreted by the visualization software. This is despite the fact that
the CUBE specification has a way of identifying the units used. VMD ignores it
(http://www.ks.uiuc.edu/Research/vmd/plugins/molfile/cubeplugin.html) and will actually (version 1.9) will crash
with a memory allocation error if it sees the negative number of voxels that marks the file as using Angstroms.
Previous Manual:External_utilities:oct-xyz-anim - Next Manual:Deprecated_Utilities
Back to Manual <p class=newpage>
Deprecated Utilities
Some utilities present in older version of octopus have superseded by other utilities or integrated into the main
code, in this section you can find how to replace them.
SEE ALSO
84
The_Octopus_Manual
octopus_cmplx
Not exactly a utility, now there is no complex version of the code, the main executable octopus can calculate
real or complex wavefunctions depending of the requirements of input file.
oct-sf
This utility was replaced by oct-cross-section.
oct-rs *
deprecated
Previous Manual:Deprecated Utilities - Next Manual:External utilities:oct-excite
Back to Manual <p class=newpage>
oct-excite *
Calculates the excitation spectrum within linear response. This utility can output just the difference of eigenvalues
by setting LinEigenvalues, the excitations using M. Petersilka formula (LinPetersilka), or M. Casida (LinCasida).
This utility requires that a calculation of unoccupied states (CalculationMode = unocc) has been done before, and it
outputs the results to the sub-directory "linear". The states entering the calculation can be chosen with the variable
ExciteStates
In later versions oct-excite no longer exists because the linear-response formalism calculations are now done by the
main code, by making use of the "casida" run mode. See Manual:Calculation Modes:Casida
Previous Manual:External utilities:oct-rs - Next Manual:External utilities:oct-make-st
Back to Manual <p class=newpage>
oct-make-st *
deprecated
make_st reads tmp/restart.static and replaces some of the Kohn-Sham states by Gaussians wave packets. The states
which should be replaced are given in the %MakeStates section in the input file and written to
octopus_cmplx
85
The_Octopus_Manual
tmp/restart.static.new. (You probably want to copy that file to tmp/restart.static and use then CalculationMode=5
or 6.)
%MakeStates
ik | ist | idim | type | sigma | x0 | k
%
The next items depend on the type chosen. For a Gaussian wave packet, defined as
psi(x) = 1/sigma sqrt(1/2pi) exp(ik(x-x0)) exp(-(x-x0)^2/(2 sigma^2)),
they are:
* \sigma the width of the Gaussian
* k: the k vector. In 3D use k1|k2|k3.
* x_0: the coordinate where the Gaussian is initially centred. In 3D use x01|x02|x03
oct-convert *
Name
oct-convert - Octopus utility to read obj files and write in many different file formats
Description
This executable gives the ability to read files written during the ground-state or time-dependent execution
Example
You can run ground-state and time-dependent execution of the benzene example.
Then, we have to add this to the inp file, if we want to have the ground state density in DX format:
Output = density
OutputHow = dx
ConvertFolder = 'restart/gs'
ConvertFilename = 'density'
ConvertIterateFolder = no
oct-make-st *
86
The_Octopus_Manual
If we want to convert the densities of the time-dependent executions, from files td.0000001 to td.0000010:
Output = density
OutputHow = dx
ConvertIterateFolder = yes
ConvertStart = 1
ConvertEnd
= 10
<p class=newpage>
oct-help
Oct-help is a utility to helps you to write input files. It has been available since version 3.0. Oct-help has two
modes:
search
$ oct-help search string
In this mode oct-help will print all variable names that contain string in their name.
show
$ oct-help show variable
In this mode oct-help will print the documentation for the indicated variable.
Previous Manual:External utilities:oct-make-st - Next Manual:Examples:Hello world
Back to Manual <p class=newpage>
Examples
<p class=newpage>
Examples
87
The_Octopus_Manual
Hello World
As a first example, we will take a sodium atom. With your favourite text editor, create the file inp.
CalculationMode = gs
%Coordinates
'Na' | 0.0 | 0.0 | 0.0
%
so that the output is stored in out file. If everything goes OK, out should look like:
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
___
.-'
`'.
/
\
|
;
|
|
___.--,
_.._
|0) ~ (0) |
_.---'`__.-( (_.
__.--'`_.. '.__.\
'--. \_.-' ,.--'`
`""`
( ,.--'`
',__ /./;
;, '.__.'`
__
_`) ) .---.__.' / |
|\
\__..--"" """--.,_
`---' .'.''-._.-'`_./ /\ '. \ _.-~~~````~~~-._`-.__.'
| | .' _.-' | | \ \ '.
`~---`
\ \/ .'
\ \
'. '-._)
\/ /
\ \
`=.__`~-.
jgs / /\
`) )
/ / `"".`\
, _.-'.'\ \
/ /
( (
/ /
`--~`
) )
.-'.'
'.'. | (
(/`
( (`
) ) '-;
`
'-;
(-'
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
Hello World
88
The_Octopus_Manual
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Running octopus, version 2.1pre1
build time - Wed Jun 28 18:15:19 CEST 2006
svn revision: 2252 [td_write.F90 2006-06-28]
Compiler: ifort
Compiler flags: -u -zero -fpp1 -nbs -pc80 -pad -align -unroll -O3 -ip -tpp7 -xN
The octopus is swimming in ddraig (Linux)
Hello World
89
The_Octopus_Manual
**********************************************************************
[RelativisticCorrection = non_relativistic]
[TDGauge = length]
[AbsorbingBoundaries = no_absorbing]
[RestartFileFormat = restart_plain]
Hello World
90
The_Octopus_Manual
*********************** SCF CYCLE ITER #
3 ************************
etot = -1.84248966E-01 abs_ev
= 1.15E-04 rel_ev
= 1.12E-03
abs_dens = 2.06E-04 rel_dens = 2.06E-04
Matrix vector products:
23
Converged eigenvectors:
1
Eigenvalues [H]
#st Spin
Eigenvalue
Occupation
Error
1
--0.103504
1.000000
(9.9E-07)
**********************************************************************
Take now a look at the working directory. It should include the following files:
-rw-r--r-drwxr-xr-x
drwxr-xr-x
drwxr-xr-x
Hello World
1
2
2
3
xavier
xavier
xavier
xavier
xavier
84 2006-06-29 14:21
xavier 4096 2006-06-29 14:21
xavier 4096 2006-06-29 14:21
xavier 4096 2006-06-29 14:21
inp
static
status
tmp
91
The_Octopus_Manual
Besides the initial file (inp) and the out file, three new directories appear. In static/, you will find the file info,
with information about the static calculation (it should be hopefully self-explanatory, otherwise please complain to
the authors). In tmp/, you will find the restart_gs directory that contains restart information about the
ground-state, which is used if, for example, you want to start a time-dependent calculation afterwards. Finally, the
status/ directory has information about the run of octopus, inside the out.oct contains all the input variables
parsed by octopus.
Exercises
Study how the total energy and eigenvalue of the sodium atom improve with the mesh spacing.
Calculate the static polarizability of the sodium atom (CalculationMode = em_resp). A
em_resp/alpha will be created, this files contains the static polarizability tensor.
Calculate a few unoccupied states (CalculationMode = unocc). The eigenspectrum will be in the file
static/eigenvalues. Why don't we find a Rydberg series in the eigenspectrum?
Repeat the previous calculation with different exchange and correlation functionals like PBE, LB94, and
exact exchange.
Perform a time-dependent evolution (CalculationMode = td), to calculate the optical spectrum of the
Na atom. Use a TDDeltaStrength = 0.05, polarised in the x direction. The multipole moments of the
density are output to the file td.general/multipoles. You can process this file with the utility
oct-propagate_spectrum to obtain the optical spectrum. If you have computer time to waste, re-run
the time-dependent simulation for some other xc choices.
Previous Manual:oct-help - Next Manual:Examples:Benzene
Back to Manual <p class=newpage>
Benzene
Well, the sodium atom is a bit too trivial. Let's try something harder: benzene. you will just need the geometry for
benzene to be able to play. Here it is (in ):
C
C
C
C
C
C
H
H
H
H
H
H
0.000
1.209
1.209
0.000
-1.209
-1.209
0.000
2.147
2.147
0.000
-2.147
-2.147
1.396
0.698
-0.698
-1.396
-0.698
0.698
2.479
1.240
-1.240
-2.479
-1.240
1.240
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
Follow now the steps of the previous example. Carbon and Hydrogen have a much harder pseudo-potential than
Sodium, so you will probably have to use a tighter mesh. It also takes much more time...
Previous Manual:Examples:Hello world - Next Manual:Appendix:Porting Octopus and Platform Specific
Instructions
Exercises
92
The_Octopus_Manual
Variables
<p class=newpage>
td_occup
When performing a time-dependent run, the variable TDOutput may be set to TDOutput =td_occup, which,
according to the manual, outputs the projections of the time-dependent Kohn-Sham wavefunctions onto the static
(zero-time) wavefunctions to the file td.general/projections.XXX.
This will fail if you are running Octopus "parallel in states", since information is dispersed over many nodes. You
may run in serial mode or "parallel in domains".
In my experience, Octopus writes these projections to the file td.general/projections, in the format:
Iteration Time Re{Projection 1,1} Im{Projection 1,1} Re{Projection 1,2} ...
Rather than the different timesteps getting separate files as described in the manual, after "OutputEvery"
timesteps, the projections (preceded by the iteration number and time) will be appended to the file
td.general/projections.
Projections are a complex number, with real and imaginary parts between -1 and 1. Even if the ground state wave
functions are real, the time evolved ones are complex.
Previous Manual - Next Manual
Back to Manual <p class=newpage>
Appendix
<p class=newpage>
This version requires libxc 2.0.0 or higher, so it might be necessary to update libxc before installing Octopus.
Appendix
93
The_Octopus_Manual
Restart files
Casida restart file is incompatible with that generated by version 4.0. The new format avoids problems with
restarting with a different number of states.
Octopus 4.0
Installation
Libxc is now an independent library. To compile Octopus 4.0.0 you will have to compile libxc 1.1.0 first.
These are the short instructions to compile it (we assume that libxc will be installed in $DIR, this can be the
same directory where Octopus is going to be installed):
tar -xvzf libxc-1.1.0.tar.gz
cd libxc-1.1.0
./configure --prefix=$DIR
make
make install
Some variables changed name or change format. If an obsolete variable is found, Octopus will stop and will tell
you the variable that replaces it.
Units, UnitsInput and UnitsOutput now take a named option as argument instead of a string. So
Units = "eVA"
should be replaced by
Units = ev_angstrom
94
The_Octopus_Manual
.
TDLasers was replaced by TDExternalFields.
Some options for CalculationMode were renamed.
Output directories
Some directories in octopus output were renamed, restart files now are stored under restart/ instead of tmp/.
Files previously found under status/ are now located in exec/.
Restart file format
Octopus writes restart files in a binary format, this format has been updated and improved. As a result Octopus is
no longer able to restart automatically the calculation of a run performed with older versions.
Recovering old restart files
If you really need to recover your old restart files, first you have to generate NetCDF restart files with your old
version of Octopus. Then you will have to rename the tmp/ directory to restart/ and remove the restart_
prefix from its subdirectories, for example tmp/restart_gs/ now should be called restart/gs/.
Now you can run Octopus 3.0 and it will find your restart information. <p class=newpage>
Prerequisites
You will need the following:
A standard Unix/Linux system, where you want to install Octopus.
A basic knowledge on how to use the system (manage files, edit text files, extract tar archives, etc.).
A directory where we will install the created binaries, this can be a specially created directory or even your
$HOME. From now, we will assume that the directory is <basedir>, whenever it appears you should
Input variables
95
The_Octopus_Manual
replace it with the actual directory you are using. Note that the files that you will download and the
directories with the sources, including the ones of Octopus, don't need to be placed in this directory.
A working C compiler, gcc is the ideal choice for x86/x86_64 systems. For other platforms you might want
to choose a compiler that produces more optimized code. We will assume that the command to run the
compiler is <cc>.
A working Fortran 95 compiler, if you don't have one you can probably get gfortran or g95. We will
assume that the command to run the Fortran compiler is <fc>.
If you are compiling for a dual 32/64 bits architecture, it is a good idea to tell the compilers explicitly what
type of binaries you want, many problems are caused by unadvertedly mixing 32 and 64 bits code. For
Octopus normally you will want a 64 bits binary (-m64 flag in most compilers). Since this flag should be
passed always we recommend you to include it in the compiler command used in this guide (sometimes
optimization flags are left out), so for example <cc> could be gcc -m64.
Compiler flags
Since probably you want Octopus to run fast, you will probably would to set optimization flags for both the C and
Fortran compilers on your system (at least -O3). In general Octopus should run fine with aggressive optimization
options. We will assume now that you have found a set of flags for <cc> and <fc>, we will call them <cflags>
and <fcflags>. For example <cflags> could be -O3 -march=native.
Note: if <cc>, <fc>, <cflags> or <fcflags> contain spaces you should not enclose them in "". We will put
the "" explicitly when it is necessary.
Compilation of libraries
First we will compile and install the libraries required by Octopus.
BLAS
The first library we will compile is blas. We will use the generic reference implementation, this version is not
highly optimized but it is free software and simple to install. So after you have a working version of Octopus you
may want to use a more optimized blas implementation as libgoto, ATLAS, MKL, ACML, ESSL, etc.
Download the package from the netlib site: http://www.netlib.org/blas/blas.tgz
Extract the package and enter into the newly created BLAS directory.
Edit the make.inc file and modify the definition of the fortran compiler that now should be:
FORTRAN
OPTS
DRVOPTS
NOOPT
LOADER
LOADOPTS
=
=
=
=
=
=
<fc>
<fcflags>
$(OPTS)
<fc>
Prerequisites
96
The_Octopus_Manual
Note: the generated file librrary will be always called blas_LINUX.a independently of the operating system you
are using, this is just a name.
LAPACK
We will use the open source reference implementation of Lapack.
Get the Lapak package from netlib: http://www.netlib.org/lapack/lapack.tgz
Extract the archive and enter the newly created lapack directory.
Copy make.inc.example to make.inc:
cp make.inc.example make.inc
Edit make.inc to indicate the compiler the will be used. The relevant part of the file should look like:
FORTRAN
OPTS
DRVOPTS
NOOPT
LOADER
LOADOPTS
=
=
=
=
=
=
<fc>
<fcflags>
$(OPTS)
<fc>
FFTW 3
Get the sources for the latest version of FFTW, currently http://www.fftw.org/fftw-3.3.4.tar.gz .
Extract the archive and enter the newly created directory.
Configure:
BLAS
97
The_Octopus_Manual
./configure
LibXC
Get libxc, currently http://www.tddft.org/programs/octopus/down.php?file=libxc/libxc-2.2.0.tar.gz .
Extract the archive and enter the newly created directory.
tar -xvzf libxc-2.2.0.tar.gz
cd libxc-2.2.0
Configure:
./configure --prefix=<basedir> CC="<cc>" CFLAGS="<cflags>" FC="<fc>" FCFLAGS="<fcflags>"
Compilation of Octopus
After compiling the libraries, now we are ready to compile Octopus. These are the steps you have to follow:
Download the last version of Octopus:
http://www.tddft.org/programs/octopus/down.php?file=4.1.2/octopus-4.1.2.tar.gz
Extract the file and enter the newly created directory.
Define the following environment variables to be used by the configure script (we assume that you are
using bash, if you are using another shell, the commands should be modified accordingly):
export LIBS_BLAS=<basedir>/lib/libblas.a
export LIBS_LAPACK=<basedir>/lib/liblapack.a
export LIBS_FFT=<basedir>/lib/libfftw3.a
If everything went fine, you should have Octopus installed in the <basedir> directory, this means that
the executables are in <basedir>/bin/. You may want to add this last directory to your path to run
octopus commands directly, otherwise you will have to give the full path.
FFTW 3
98
The_Octopus_Manual
To test the compilation is correct, you can run the testsuite of Octopus, that compares the results obtained
with the created version against reference values. To do it, run
make check-full
All tests should be passed if the compilation is correct. If all of them fail, there is probably a problem with your
executable, typically missing dynamic libraries. If just some fail, there might be a more serious problem, we
recommend you to look for help in the Mailing lists. <p class=newpage>
Compilation of Octopus
99
The_Octopus_Manual
You can run the OpenCL version of Octopus on CPUs, however this is much slower than running Octopus directly.
Activating GPU support
Octopus has GPU support since version 4.0; to activate it you need a version compiled with OpenCL support
enabled (see the manual for details). If your version of Octopus was compiled with OpenCL support you should
see that 'opencl' among the configuration options:
Running octopus
Version
Revision
Build time
Configuration options
Optional libraries
:
:
:
:
:
superciliosus
Thu Feb 14 22:19:10 EST 2013
max-dim=3 openmp opencl sse2 avx
netcdf clamdfft clamdblas
Ideally your Octopus version should also be compiled with the optional libraries 'clamdfft' and 'clamdblas', that are
part of the AMD APPML package (these libraries work on hardware from other vendors too, including Nvidia).
By default Octopus will use the first platform. You can select a different platform with the OpenCLPlatform
variable. You can select the variable by name, for example:
OpenCLPlatform = amd
or you can use numeric values that select the platform by its index in the list:
OpenCLPlatform = 1
The first form should be preferred as it is independent of the order of the platforms.
Each OpenCL platform can contain several devices, the available devices on the selected platform are printed by
Octopus, like this:
Info: Available CL devices: 2
Supported GPUs
100
The_Octopus_Manual
Device 0 : Tahiti
Device 1 : Intel(R) Core(TM) i7-3820 CPU @ 3.60GHz
Each OpenCL device has a certain type that can be 'cpu', 'gpu', or 'accelerator'. By default Octopus tries to use the
first device of type 'gpu', if this fails Octopus tries to use the default device for the system, as defined by OpenCL
implementation. To select a different device you can use the OpenCLDevice variable, you can select the device
by its index or by its type ('cpu', 'gpu', or 'accelerator').
Note: the Octopus OpenCL implementation is currently designed to execute efficiently on GPUs. Octopus will run
on CPUs using OpenCL, but it will be slower than using the CPU directly.
After Octopus has selected an OpenCL device it will print some information about it, for example:
Selected CL device:
Device vendor
Device name
Driver version
Compute units
Clock frequency
Device memory
Max alloc size
Device cache
Local memory
Constant memory
Max. workgroup size
Extension cl_khr_fp64
Extension cl_amd_fp64
:
:
:
:
:
:
:
:
:
:
:
:
:
The block-size
To obtain good peformance on the GPU (and CPUs), Octopus uses blocks of states as the basic data object. The
size of these blocks is controlled by the StatesBlockSize variable. For GPUs the value must be a power of 2
(the default is 32) and for optimal performance must be as large as possible, the catch is that for large values you
might run out of GPU memory.
StatesPack
The Poisson solver
If you want to used a GPU-accelerated Poisson solver, you need to use the 'fft' solver and to have the 'clamdfft'
library support compiled. To select the solver, just add
PoissonSolver = fft
FFTLibrary = clfft
101
The_Octopus_Manual
* Required: gfortran, gcc, make, automake, m4, libtool, libgsl0-dev, libblas-dev, liblapack-dev,
* Optional: mpi-default-dev, libgd2-xpm-dev, libsparskit-dev, libnetcdf-dev, libtrilinos-dev
[Unfortunately you should not use libblacs-mpi-dev, libscalapack-mpi-dev packages because they
can give incorrect results. To use BLACS and ScaLAPACK (optional) you must build them yourself.]
First download libxc from Libxc:download, extract with tar xzf, enter the resulting directory, and execute:
./configure --prefix=`pwd`/.. CC=gcc FC=gfortran FCCPP="/lib/cpp -ansi" FCFLAGS=-O3 CFLAGS=-O3 make install
For octopus, download and extract, and execute the following (inserting the path where you put libxc):
If you are using MPI, replace the compilers by CC=/usr/bin/mpicc FC=/usr/bin/mpif90 and add
--enable-mpi and --enable-utils.
To build ETSF_IO, libnetcdf-dev is required.
Generic MacOS
Octopus is now available in MacPorts. For more info, and how to build by hand with MacPorts libraries, see
Compiling_octopus_in_OS_X.
Generic MacOS
102
The_Octopus_Manual
United States
Sequoia/Vulcan (IBM Blue Gene/Q)
Supercomputers at Lawrence Livermore National Laboratory based on the IBM Blue Gene/Q architecture. This
was tested in Vulcan, but it should work on Sequoia as well.
https://computing.llnl.gov/tutorials/bgq/
export LIBS_BLAS="-L/usr/local/tools/essl/5.1/lib/ -lesslsmpbg"
export LIBS_LAPACK="/usr/local/tools/lapack/lib/liblapack.a"
export LIBS_FFT="-L/usr/local/tools/fftw-3.3.3/lib/ -lfftw3_omp"
export FC_INTEGER_SIZE=4
export CC_FORTRAN_INT=int
export CC=mpixlc_r
export FC=mpixlf95_r
export LDFLAGS="-qsmp=omp"
export CFLAGS="-g -O3"
export FCFLAGS=$CFLAGS" -qxlf90=autodealloc -qessl"
./configure --with-libxc-prefix=$HOME --prefix=$HOME --host=powerpc32-unknown-linux-gnu
--build
Stampede
10 PFLOPS (PF) Dell Linux Cluster based on 6,400+ Dell PowerEdge server nodes, each outfitted with 2 Intel
Xeon E5 (Sandy Bridge) processors and an Intel Xeon Phi Coprocessor (MIC Architecture). Texas Advanced
Computing Center, University of Texas, Austin, USA.
https://portal.tacc.utexas.edu/user-guides/stampede
For libxc:
./configure --prefix=`pwd` CC=mpicc FC=mpif90 FCFLAGS="-O3" CFLAGS="-O3"
make -j 6 install
make check
United States
103
The_Octopus_Manual
Edison
Cray XC30 at National Energy Research Scientific Computing Center (NERSC), Lawrence Berkeley National
Laboratory, USA
http://www.nersc.gov/nusers/systems/
module load gsl/1.15
module load netcdf/4.3.0
For libxc:
./configure --prefix=`pwd` CC=cc FC=ftn FCFLAGS="-fast" CFLAGS="-fast"
make -j 4 install
For octopus:
Hopper
Cray XE6 at National Energy Research Scientific Computing Center (NERSC), Lawrence Berkeley National
Laboratory, USA
http://www.nersc.gov/nusers/systems/
Octopus 4.1.2 is available as a module.
Edison
104
The_Octopus_Manual
module load gsl/1.15
module load fftw/3.3.0.4
module load netcdf/4.3.0
For libxc:
./configure --prefix=`pwd` CC=cc FC=ftn FCFLAGS="-fast" CFLAGS="-fast"
make -j 4 install
For octopus:
Titan
Cray XK7 at Oak Ridge Leadership Computing Facility (OLCF), Oak Ridge National Laboratory, USA
This build does not use GPUs. Only will work for 4.1 pre-release version. The code must be installed in
/tmp/work/$USER (scratch) not $HOME, or else the code will not be able to read data such as variable info,
pseudopotentials, testsuite files, etc. during the run, as $HOME is not accessible from compute nodes.
http://www.olcf.ornl.gov/support/system-user-guides/titan-user-guide/
For libxc:
Hopper
105
The_Octopus_Manual
For octopus:
-N
-m
-q
-l
-l
-V
pulpo
ae
debug
walltime=1:00:00,nodes=2
gres=widow2%widow3
export TEMPDIRPATH=/tmp/work/$USER/tmp
if [ ! -d $TEMPDIRPATH ]; then
mkdir $TEMPDIRPATH
fi
cd /tmp/work/$USER/octopus
export MPIEXEC=`which aprun`
export OCT_TEST_NJOBS=10
make check-full &> makecheck
Kraken
Cray XT5 at National Institute for Computational Sciences (NICS), University of Tennessee-Knoxville / Oak
Ridge National Laboratory, USA
Part of National Science Foundation's TeraGrid
http://www.nics.tennessee.edu/computing-resources/kraken Do NOT use PGI 11.4.0.
module
module
module
module
module
load
load
load
load
load
gsl
fftw
netcdf
gdlib
parmetis
To run the testsuite in parallel: (the code must be compiled and installed in $SCRATCH, not $HOME)
Titan
106
The_Octopus_Manual
#!/bin/bash
#PBS -l size=12,walltime=0:30:00
#PBS -V
cd $SCRATCH/octopus
export MPIEXEC=`which aprun`
export TEMPDIRPATH=$SCRATCH/tmp
make -e check &> $PBS_O_WORKDIR/makecheck
(2 May 2011)
Lonestar
Dell Linux cluster at Texas Advanced Computing Center (TACC), University of Texas, Austin, USA
Part of National Science Foundation's TeraGrid
http://services.tacc.utexas.edu/index.php/lonestar-user-guide
To build ETSF_IO:
-N test_pulpo
-cwd
-pe 6way 12
-q development
-l h_rt=00:45:00
-V
cd $HOME/octopus
export TEMPDIRPATH=$SCRATCH/tmp
Kraken
107
The_Octopus_Manual
if [ ! -d $TEMPDIRPATH ]; then
mkdir $TEMPDIRPATH
fi
export MPIEXEC=`which ibrun`
export OCT_TEST_NPROCS=1
make check &> makecheck
(2 May 2011)
Lawrencium
Dell Linux cluster at Lawrence Berkeley National Laboratory, USA
Cluster available only to Lawrence Berkeley National Laboratory researchers
http://lrc.lbl.gov/html/Lawrencium.html
module
module
module
module
module
module
module
module
module
module
load
load
load
load
load
load
load
load
load
load
icc/10.1.018
ifort/10.1.018
mkl/2011.1.107
openmpi/1.4.3-intel
netcdf/4.0-intel
fftw/3.1.2-intel
autoconf/2.65
gsl/1.13-intel
gdlib/2.0.35
libtool/2.2.6b
./configure --prefix=`pwd` CC=mpicc FC=mpif90 CFLAGS="-O3" FCFLAGS="-O3 -check bounds" --enable--with-blas="-L$MKLROOT/lib/intel64 -Wl,--start-group -lmkl_intel_lp64 -lmkl_sequential -lmkl_co
--with-fft-lib="-L/global/software/centos-5.x86_64/modules/fftw/3.1.2-intel/lib -lfftw3" --with--with-libxc-prefix=`pwd` --with-blacs="$MKL_DIR/lib/intel64/libmkl_blacs_openmpi_lp64.a" --with
To build ETSF_IO:
Europe
Curie
PFFT 1.0.5 and BigDFT 1.6.0
The Curie supercomputer, owned by GENCI and operated into the TGCC by CEA, is the first French Tier0 system
open to scientists through the French participation into the PRACE research infrastructure.
Europe
108
The_Octopus_Manual
Curie is offering 3 different fractions of x86-64 computing resources for addressing a wide range of scientific
challenges and offering an aggregate peak performance of 2 PetaFlops.
General information: http://www-hpc.cea.fr/en/complexe/tgcc-curie.htm
Compilation with PFFT version 1.0.5 and LibISF taken from BigDFT 1.6.0 (previously compiled):
#!/bin/bash
module
module
module
module
module
load
load
load
load
load
c/intel
fortran/intel
bullxmpi
mkl
gsl/1.14
WPREFIX=$WORKDIR/software
PREFIX=$HOME/software
export ISF_HOME="$WORKDIR/software/libisf"
export
export
export
export
CC=mpicc
CFLAGS="-xHost -O3 -m64 -ip -prec-div -static-intel -sox -I$ISF_HOME/include"
FC=mpif90
FCFLAGS="-xHost -O3 -m64 -ip -prec-div -static-intel -sox -I$PREFIX/fftw/3.3/include -I$I
export LIBS_BLAS="${MKL_LIBS}"
export LIBS_FFT="-Wl,--start-group -L$PREFIX/pfft/1.0.5/lib -L$PREFIX/fftw/3.3/lib -lpfft -lfftw
export LDFLAGS=$LDFLAGS" -L$ISF_HOME/lib -lisfsolver -lrt"
../configure --prefix=$WPREFIX/octopus/superciliosus_pfft \
--disable-openmp --with-libxc-prefix=$WPREFIX/libxc/2.0.x \
--disable-gdlib --with-gsl-prefix=/usr/local/gsl-1.14 \
--enable-mpi --enable-newuoa \
--with-pfft-prefix=$PREFIX/pfft/1.0.5
load
load
load
load
load
c/intel
fortran/intel
bullxmpi
mkl
gsl/1.14
109
The_Octopus_Manual
WPREFIX=$WORKDIR/poisson/software
WLPREFIX=$WORKDIR/poisson/local
export ISF_HOME="$WLPREFIX/libisf"
export FFTW_HOME="$WLPREFIX/fftw-3.3.3"
export PFFT_HOME="$WLPREFIX/pfft-1.0.7-alpha"
export
export
export
export
CC=mpicc
CFLAGS="-xHost -O3 -m64 -ip -prec-div -static-intel -sox -I$ISF_HOME/include"
FC=mpif90
FCFLAGS="-xHost -O3 -m64 -ip -prec-div -static-intel -sox -I$FFTW_HOME/include -I$ISF_HOM
export LIBS_BLAS="${MKL_LIBS}"
export LIBS_FFT="-Wl,--start-group -L$PFFT_HOME/lib -L$FFTW_HOME/lib -lpfft -lfftw3 -lfftw3_mpi
export LDFLAGS=" -L/usr/lib64 -L$ISF_HOME/lib -lPSolver-1 -lrt"
export LD_LIBRARY_PATH=$ISF_HOME/lib:$LD_LIBRARY_PATH
../configure --prefix=$WPREFIX/octopus/superciliosus_pfft \
--disable-openmp --with-libxc-prefix=$WPREFIX/libxc/11066 \
--disable-gdlib --with-gsl-prefix=/usr/local/gsl-1.14 \
--enable-mpi --enable-newuoa \
--with-pfft-prefix=$PFFT_HOME
LibISF compilation:
#!/bin/bash
module
module
module
module
module
load
load
load
load
load
c/intel
fortran/intel
bullxmpi
mkl
gsl/1.14
export FC=mpif90
110
The_Octopus_Manual
> cp ../fftw-$FFTW_VERSION.tar.gz .
876c883
< ./configure --prefix=$INSTALLDIR --enable-mpi --enable-openmp --enable-shared \
--> ./configure --prefix=$INSTALLDIR --enable-mpi --enable-openmp --enable-shared --disable-shared
Fermi/Juqueen
IBM Blue Gene/Q, Cineca, Italy
General information: http://www.hpc.cineca.it/content/ibm-fermi-user-guide
The exactly the same script has been tested in the Juqueen, Forschungszentrum Jlich, Jlich Supercomputing
Centre (JSC), Jlich, Germany. General information:
http://www.fz-juelich.de/ias/jsc/EN/Expertise/Supercomputers/JUQUEEN/JUQUEEN_node.html
#/bin/bash
module
module
module
module
load
load
load
load
gsl
lapack
blacs
scalapack
export PFFT_HOME="$HOME/local/pfft-threads-1.0.5-alpha"
export FFTW3_HOME="$HOME/local/fftw-threads-3.3.2"
export LD_LIBRARY_PATH=$PFFT_HOME/lib:$FFTW3_HOME/lib:$LD_LIBRARY_PATH
export
export
export
export
export
export
export
export
FC_INTEGER_SIZE=8
CC_FORTRAN_INT=int
CC=mpicc
CFLAGS="-g -Wl,-relax -O3 -I$PFFT_HOME/include -I$FFTW3_HOME/include"
FC=mpif90
FCFLAGS=$CFLAGS" -qxlf90=autodealloc -qessl -qsmp=omp "
LIBS_BLAS="-lesslsmpbg -L/opt/ibmmath/essl/4.4/lib -lesslbg"
LIBS_LAPACK="-L$LAPACK_LIB -llapack"
Fermi/Juqueen
111
The_Octopus_Manual
export LIBS_FFT="-L$FFTW3_HOME/lib/ -lfftw3_mpi -lfftw3 -lm"
echo "GSL DIR = $GSL_HOME "
echo "PFFT DIR = $PFFT_HOME "
export LDFLAGS=$LDFLAGS" -R/opt/ibmcmp/lib/bg/bglib \
-L/bgsys/drivers/V1R4M2_200_2010-100508P/ppc/gnu-linux/powerpc-bgp-linux/lib \
-L/bgsys/drivers/V1R4M2_200_2010-100508P/ppc/gnu-linux/lib/gcc/powerpc-bgp-linux/4.1.2 \
-L/opt/ibmcmp/xlf/bg/11.1/bglib \
-L/opt/ibmcmp/xlmass/bg/4.4/bglib \
-L/opt/ibmcmp/xlsmp/bg/1.7/bglib \
-L/bgsys/drivers/V1R4M2_200_2010-100508P/ppc/runtime/SPI \
-L/bgsys/drivers/V1R4M2_200_2010-100508P/ppc/comm/sys/lib \
-L/bgsys/drivers/V1R4M2_200_2010-100508P/ppc/comm/default/lib \
-L/usr/local/zlib/v1.2.3/lib \
-L/bgsys/drivers/ppcfloor/runtime/SPI \
-L$PFFT_HOME/lib -L$FFTW3_HOME/lib \
-lpfft -lfftw3_mpi -lfftw3 -lm \
-ldl -lxl -lxlopt -lrt -lpthread"
SVN_VERS=$(svn info .. | grep Revision | awk '{print $2}')
echo $SVN_VERS
../configure --prefix=$HOME/software/octopus_omp \
--with-libxc-prefix=$HOME/software/libxc_new \
--with-fft-lib="$FFTW3_HOME/lib/libfftw3.a $FFTW3_HOME/lib/libfftw3_omp.a" \
--host=powerpc32-unknown-linux-gnu \
--build=powerpc64-unknown-linux-gnu \
--disable-gdlib \
--disable-f90-forall \
--with-blas="-L/opt/ibmmath/lib64 -lesslbg" \
--with-lapack="-L$LAPACK_LIB -llapack" \
--with-gsl-prefix=$GSL_HOME \
--enable-mpi --enable-openmp
To build FFTW3. Small changes are made to the script taken from M. Pippig web site
http://www-user.tu-chemnitz.de/~mpip/software.php?lang=en It has a patch and is build with MPI and
multithreaded (multithreaded may not work in Juqueen):
#!/bin/sh -e
myprefix=$HOME/local
FFTW_VERSION="3.3.2"
INSTALLDIR="$myprefix/fftw-threads-${FFTW_VERSION}"
TMP="tmp-mine-fftw-${FFTW_VERSION}"
# bash check
if [ -d $TMP
echo
read
if [
if directory exists
]; then
"Directory $TMP already exists. Delete it? (y/n)"
answer
${answer} = "y" ]; then
rm -rf $TMP
else
echo "Program aborted."
exit 1
fi
fi
mkdir $TMP && cd $TMP
Fermi/Juqueen
112
The_Octopus_Manual
wget http://www.fftw.org/fftw-$FFTW_VERSION.tar.gz
gzip -dc fftw-$FFTW_VERSION.tar.gz | tar xvf cd fftw-$FFTW_VERSION
# fix bug in fftw alltoall routine that causes deadlocks
patch -b -p0 <<\EOF
--- mpi/transpose-alltoall.c
+++ mpi/transpose-alltoall.c
@@ -223,8 +223,8 @@
sbo[pe] = (int) (pe * (b * p->tblock) * vn);
rbs[pe] = (int) (db * bt * vn);
rbo[pe] = (int) (pe * (p->block * bt) * vn);
if (sbs[pe] != (b * p->tblock) * vn
|| rbs[pe] != (p->block * bt) * vn)
+
if (dbt != p->tblock
+
|| db != p->block)
equal_blocks = 0;
}
pln->send_block_sizes = sbs;
EOF
./configure --build=powerpc64-bgq-linux-gnu --host=powerpc64-bgq-linux \
--prefix=$INSTALLDIR --enable-mpi --enable-openmp --enable-threads --disable-shared \
CC=mpixlc_r F77=mpixlf90_r MPICC=mpixlc_r MPICXX=mpixlcxx_r MPIFC=mpixlf90_r MPILIBS=" " \
CFLAGS='-O3 -g' \
FCFLAGS='-O3 -g' \
make -j 4
make install
if directory exists
]; then
"Directory $TMP already exists. Delete it? (y/n)"
answer
${answer} = "y" ]; then
rm -rf $TMP
else
echo "Program aborted."
exit 1
fi
fi
mkdir $TMP && cd $TMP
wget http://www.tu-chemnitz.de/~mpip/software/pfft-$PFFT_VERSION.tar.gz
gzip -dc pfft-$PFFT_VERSION.tar.gz | tar xvf -
Fermi/Juqueen
113
The_Octopus_Manual
cd pfft-$PFFT_VERSION
./configure --build=powerpc64-bgq-linux-gnu --host=powerpc64-bgq-linux \
--prefix=$INSTDIR --with-fftw3=$FFTWDIR \
MPICC=mpif90 MPICXX=mpicxx MPIFC=mpif90 CC=mpicc FC=mpif90 \
CFLAGS='-O3 -g -qmaxmem=-1' \
FCFLAGS='-O3 -g -qmaxmem=-1' \
--disable-shared
make -j 4
make install
Hydra
Hydra is a supercomputer located at the RZG/MPG. More information:
http://www.rzg.mpg.de/services/computing/hydra/about-the-system
Instruction that work with version 13307
#!/bin/bash
. /etc/profile.d/modules.sh
module
module
module
module
module
module
module
purge
load intel/14.0
load mkl/11.1
load mpi.ibm/1.3.0
load gsl
load fftw
load netcdf-serial
CC=mpiicc
CFLAGS="-g -O3 -xHost -openmp -I$FFTW_HOME/include"
FC=mpiifort
FCFLAGS="-g -O3 -xHost -openmp -I$FFTW_HOME/include"
Hydra
114
The_Octopus_Manual
Jugene
FZJ-JSC IBM Blue Gene/P, JLICH SUPERCOMPUTING CENTRE (JSC), Germany
May also work on other Blue Gene/P computers
General information: http://www.fz-juelich.de/jsc/jugene
Usage information: http://www.fz-juelich.de/jsc/jugene/usage/
module load gsl;
module load lapack;
autoreconf -i;
export FC_INTEGER_SIZE=4;
export CC_FORTRAN_INT=int;
export CC=mpixlc_r;
export CFLAGS='-g -O3 -qarch=450d';
export FC=mpixlf90_r;
export FCFLAGS='-g -O3 -qarch=450d -qxlf90=autodealloc -qessl -qsmp=omp';
export LIBS_BLAS="-lesslsmpbg -L/opt/ibmmath/essl/4.4/lib -lesslbg";
export LIBS_LAPACK="-L$LAPACK_LIB -llapack";
export LIBS_FFT="-L/bgsys/local/fftw3/lib/ -lfftw3 -lm";
./configure --prefix=$outdir \
--host=powerpc32-unknown-linux-gnu \
--build=powerpc64-unknown-linux-gnu \
--disable-gdlib \
--with-gsl-prefix=$GSL_DIR \
--enable-mpi --enable-openmp;
To run you have to change to $WORK directory and run LoadLeveler. Below is an example of the tutorial
(http://www.tddft.org/programs/octopus/wiki/index.php/Tutorial:Benzene_molecule) executing in 32 nodes in the
SMP mode (4 threads per chip). The execution mode is hybrid; OpenMP/MPI.
Here is a example job input script:
# @ job_name = Octopus_Sample_1
# @ comment = "BGP Job by Size"
# @ error = $(job_name).$(jobid).out
# @ output = $(job_name).$(jobid).out
# @ environment = COPY_ALL;
# @ wall_clock_limit = 00:30:00
# @ notification = error
# @ notify_user = [email protected]
# @ job_type = bluegene
# @ bg_size = 32
# @ queue
mpirun -exe $OCTOPUS_HOME/bin/octopus_mpi -mode SMP -verbose 1
Jugene
115
The_Octopus_Manual
Finis Terrae
Finis Terrae Itanium computer installed at CESGA (Galicia, Spain), is an integrated system with shared memory
nodes with an SMP NUMA architecture.
http://www.cesga.es/content/view/917/115/lang,en/
Script to build ETSF_IO-1.0.2 under bash:
#!/bin/bash
module load ifort/11.0.074 netcdf/4.0
export F77="ifort"
export FFLAGS="-O3 -ip -ftz"
export FC="ifort"
export FCFLAGS="-O3 -ip -ftz"
./configure --prefix=/dir/install/etsf_io-1.0.2 \
--with-netcdf-module-path="/dir/install/netcdf-4.0/include" --with-netcdf-ldflags="-L/dir/insta
#!/bin/bash
module load gsl/1.12 icc/11.0.074 ifort/11.0.074 fftw/3.1.2 mkl/10.1.0 impi/3.2.0.011 netcdf/4.0
export CC="icc"
export CFLAGS="-O2 -ip -ftz"
export LDFLAGS="-lguide -lpthread -lm"
export F77="ifort"
export FFLAGS="-O2 -ip -ftz"
export FC="ifort"
export FCFLAGS="-O2 -ip -ftz"
# without MPI
./configure --prefix=/dir/install/octopus-3.2.0 --disable-python --disable-gdlib \
--with-blas="-L/dir/install/intel/intel11.0/Compiler/11.0/069/mkl/lib/64 -lmkl -lguide -lpthrea
--with-lapack="-L/dir/install/intel/intel11.0/Compiler/11.0/069/mkl/lib/64 -lmkl_lapack -lguide
--with-fft=fftw3 \
--with-etsf_io="-L/dir/install/etsf_io-1.0.2/lib/ -letsf_io -letsf_io_utils -I/dir/install/etsf
--with-netcdf="-L/dir/install/netcdf-4.0/lib -lnetcdf -lnetcdff -lnetcdf_c++ -I/dir/install/net
--with-sparskit="-L/dir/install/SPARSKIT-2/lib -lskit"
116
The_Octopus_Manual
#!/bin/bash
module load gsl/1.12 icc/11.0.074 ifort/11.0.074 fftw/3.1.2 mkl/10.1.0 impi/3.2.0.011 netcdf/4.0
export CC="mpiicc"
export CFLAGS="-O2 -ip -ftz"
export LDFLAGS="-lguide -lpthread -lm"
export F77="mpiifort"
export FFLAGS="-O2 -ip -ftz"
export FC="mpiifort"
export FCFLAGS="-O2 -ip -ftz"
# with MPI
./configure --prefix=/dir/install/octopus-3.2.0-mpi --disable-python --disable-gdlib --enable-mp
--with-blas="-L/dir/install/intel/intel11.0/Compiler/11.0/069/mkl/lib/64 -lmkl -lguide -lpthrea
--with-lapack="-L/dir/install/intel/intel11.0/Compiler/11.0/069/mkl/lib/64 -lmkl_lapack -lguide
--with-fft=fftw3 \
--with-etsf_io="-L/dir/install/etsf_io-1.0.2/lib/ -letsf_io -letsf_io_utils -I/dir/install/etsf
--with-netcdf="-L/dir/install/netcdf-4.0/lib -lnetcdf -lnetcdff -lnetcdf_c++ -I/dir/install/net
--with-sparskit="-L/dir/install/SPARSKIT-2/lib -lskit"
Maybe you must set the MPIEXEC variable to mpirun instead fo mpiexec and you must use a SHARED directory:
#!/bin/bash
module load gsl/1.12 icc/11.0.074 ifort/11.0.074 fftw/3.1.2 mkl/10.1.0 impi/3.2.0.011 netcdf/4.0
mkdir -p $HOMESFS/tmp
export TEMPDIRPATH=$HOMESFS/tmp
echo TEMPDIRPATH: $TEMPDIRPATH
export MPIEXEC=`which mpirun`
echo MPIEXEC: $MPIEXEC
make check
It seems to work:
Passed: 34 / 38
Skipped: 3 / 38
Failed: 1 / 38
testfile
# failed testcases
-------------------------------------------------------------------finite_systems_3d/21-lobpcg.test
2
Finis Terrae
117
The_Octopus_Manual
MareNostrum II
MareNostrum is a supercomputer in Europe, the most powerful in Spain. This is one of the seven supercomputers
of the Spanish Supercomputing Network. The supercomputer consists of 2,560 JS21 blade computing nodes, each
with 2 dual-core IBM 64-bit PowerPC 970MP processors running at 2.3 GHz for 10,240 CPUs in total. The
computing nodes of MareNostrum communicate primarily through Myrinet.
You may need to compile GSL and FFTW libraries before starting then installation.
Here is a script to build Octopus:
#!/bin/bash
export LD_LIBRARY_PATH=/usr/lib
export CC=mpicc
export FC=mpif90
As you can see in the script the --with-gsl-prefix has to point to your GSL and --with-fft-lib to your FFTW. You
should compile those with the same CFLAGS and FCFLAGS. Here is an example of configuring GSL (we use
GSL-1.11):
./configure --prefix=$outdirGSL CC=gcc -m64 --enable-static --disable-shared
Recently Marenostrum has changed to the SLURM manager. To execute a job you have to submit it with
jobsubmit (more details in the User's Guide).
MareNostrum III
MareNostrum III is a supercomputer based on Intel SandyBridge processors, iDataPlex Compute Racks, a Linux
Operating System and an Infiniband interconnection. More information:
http://www.bsc.es/marenostrum-support-services/mn3
module load MKL
module load GSL
MareNostrum II
118
The_Octopus_Manual
export PREFIX=$HOME/Software
export FFTW3_HOME=$HOME/local/fftw-3.3.2
export PFFT_HOME=$HOME/local/pfft-1.0.5-alpha
export
export
export
export
export
export
export
MKL_LIBS=$MKL_HOME/lib/intel64
MKLROOT=$MKL_HOME
MKL_LIBS="-L$MKLROOT/lib/intel64 -lmkl_scalapack_lp64 -lmkl_intel_lp64 -lmkl_intel_thread
CC=mpicc
CFLAGS="-xHost -O3 -m64 -ip -prec-div -static-intel -sox -I$ISF_HOME/include -openmp -I$
FC=mpif90
FCFLAGS="-xHost -O3 -m64 -ip -prec-div -static-intel -sox -I$FFTW3_HOME/include -openmp
export LIBS_BLAS="${MKL_LIBS}"
export LIBS_FFT="-Wl,--start-group -L$PFFT_HOME/lib -L$FFTW3_HOME/lib -lpfft -lfftw3 -lfftw3_mpi
../configure --prefix=$PREFIX/octopus/ \
--enable-openmp --with-libxc-prefix=$PREFIX/libxc \
--disable-gdlib --with-gsl-prefix=/apps/GSL/1.15 \
--enable-mpi --enable-newuoa \
--with-pfft-prefix=$PFFT_HOME
Green
Green is a cluster in the "Universit catholique de Louvain" (Belgium) it has 880 cores, mainly Xeon @ 2.50GHz.
Include this into your .bashrc
source /usr/local/intel/Compiler/11.1/073/bin/ifortvars.sh intel64
source /usr/local/intel/Compiler/11.1/073/bin/iccvars.sh intel64
Basic downloads
cd {HOME}
mkdir local-octopus
mkdir local-octopus/src
cd local-octopus/src
wget http://www.tddft.org/programs/octopus/down.php?file=4.0.0/octopus-4.0.0.tar.gz
wget http://www.tddft.org/programs/octopus/down.php?file=libxc/libxc-1.1.0.tar.gz
wget http://www.unidata.ucar.edu/downloads/netcdf/ftp/netcdf-4.1.2.tar.gz
wget http://www.etsf.eu/system/files/etsf_io-1.0.3.tar.gz
wget http://www-users.cs.umn.edu/~saad/software/SPARSKIT/SPARSKIT2.tar.gz
tar -zxvf netcdf-4.1.2.tar.gz
tar -zxvf libxc-1.1.0.tar.gz
tar -zxvf etsf_io-1.0.3.tar.gz
tar -zxvf octopus-4.0.0.tar.gz
tar -zxvf SPARSKIT2.tar.gz
Compiling Libxc
cd ${HOME}/local-octopus/src/libxc-1.1.0
mkdir tmp_intel
cd tmp_intel
MareNostrum III
119
The_Octopus_Manual
../configure CC=icc FC=ifort --prefix=/home/pcpm/${USER}/local-octopus/
make
make install
There is not version of netCDF compiled with intel compilers so we have to compile also NetCDF using the
following commands:
cd ${HOME}/local-octopus/src/netcdf-4.1.2
mkdir tmp_intel
cd tmp_intel
../configure CC=icc FC=ifort CXX=icpc F77=ifort --disable-dap --prefix=${HOME}/local-octopus
make
make install
cd ${HOME}/local-octopus/src/etsf_io-1.0.3
mkdir tmp_intel
cd tmp_intel
../configure FC=ifort --prefix=${HOME}/local-octopus/ --with-netcdf-module-path=${HOME}/local-o
make
make install
Finally we can compile octopus (Excluding support for PFFT and Libfm, maybe next time :-) )
cd ${HOME}/local-octopus/src/octopus-4.0.0
mkdir tmp_intel
cd tmp_intel
../configure CC=icc FC=ifort \
--prefix=${HOME}/local-octopus/ \
--with-netcdf-include=${HOME}/local-octopus/include \
--with-netcdf-prefix=${HOME}/local-octopus \
--with-etsf-io-prefix=${HOME}/local-octopus \
Green
120
The_Octopus_Manual
--with-etsf-io-include=${HOME}/local-octopus/include \
--with-libxc-include=${HOME}/local-octopus/include \
--with-libxc-prefix=${HOME}/local-octopus \
--with-blas="-L/usr/local/intel/Compiler/11.1/073/mkl/lib/em64t -lmkl_intel_lp64 -lmkl_intel_thr
--with-sparskit=/home/pcpm/franco/local-octopus/lib/libskit.a
make
make check
Green
121
The_Octopus_Manual
finite_systems_3d/26-nlcc.test
Corvo
Corvo is the computational cluster of the Nano-bio Spectroscopy Group. It consists of 1504 processor cores and
5284 GiB of RAM connected by an Infiniband network.
Script to build LIBFM library included in the Scafacos library (modified Scafacos svn version 1920, this is valid
since version 9887 of Octopus):
./configure --enable-fcs-solvers=fmm,direct --enable-fcs-fmm-comm=armci \
--enable-fcs-fmm-unrolled --enable-fcs-fmm-max-mpol=40 \
CFLAGS=-O3 CXXFLAGS=-O3 FCFLAGS=-O3 --disable-doc CXX=mpic++ CC=mpicc \
FC=mpif90 --prefix=$HOME/Software/scafacos \
LDFLAGS=-L/opt/scalapack/1.8.0/lib -L/opt/blacs/1.1/lib \
-L/opt/gotoblas2/1.08/lib -L/opt/netcdf/4.0.1/lib -L/opt/lapack/3.2/lib \
-L/opt/etsf_io/1.0.2/lib --enable-fcs-int=int --enable-fcs-float=double \
--enable-fcs-integer=integer --enable-fcs-real=real*8
make
make install
Corvo
122
The_Octopus_Manual
patch -b -p0 <<\EOF
--- mpi/transpose-alltoall.c
+++ mpi/transpose-alltoall.c
@@ -223,8 +223,8 @@
sbo[pe] = (int) (pe * (b * p->tblock) * vn);
rbs[pe] = (int) (db * bt * vn);
rbo[pe] = (int) (pe * (p->block * bt) * vn);
if (sbs[pe] != (b * p->tblock) * vn
|| rbs[pe] != (p->block * bt) * vn)
+
if (dbt != p->tblock
+
|| db != p->block)
equal_blocks = 0;
}
pln->send_block_sizes = sbs;
EOF
./configure --prefix=$INSTALLDIR --enable-mpi --enable-openmp --enable-threads --disable-shared
CC="mpicc" F77="mpif90" MPICC="mpicc" \
CFLAGS="-O3" FFLAGS="-O3" \
MPILIBS=" "
make -j 4
make install
#!/bin/sh -e
myprefix=/home/local
PFFT_VERSION=1.0.5-alpha
FFTW_VERSION=3.3.2
INSTDIR=$myprefix/pfft/$PFFT_VERSION
FFTWDIR=$myprefix/fftw/$FFTW_VERSION
TMP="tmp-pfft-$PFFT_VERSION"
module unload fftw/3.2.2
# bash check if directory exists
if [ -d $TMP ]; then
echo "Directory $TMP already exists. Delete it? (y/n)"
read answer
if [ ${answer} = "y" ]; then
rm -rf $TMP
else
echo "Program aborted."
exit 1
fi
fi
mkdir $TMP && cd $TMP
export CC=mpicc
export FC=mpif90
wget http://www.tu-chemnitz.de/~mpip/software/pfft-$PFFT_VERSION.tar.gz
gzip -dc pfft-$PFFT_VERSION.tar.gz | tar xvf cd pfft-$PFFT_VERSION
./configure --prefix=$INSTDIR --with-fftw3=$FFTWDIR --disable-shared
make install
Corvo
123
The_Octopus_Manual
This is the scrip to compile Octopus with PFFT and FMM support (through Scafacos library):
module
module
module
module
module
module
module
module
module
module
add
add
add
add
add
add
add
add
add
add
gcc
ifort
gsl
etsf_io
lapack
netcdf
gotoblas2
mpibull2
blacs
scalapack
export CC=mpicc
export FC="mpif90"
LIBFM_HOME="$HOME/Software/scafacos"
PFFT_HOME="$HOME/local/pfft-1.0.5-alpha"
FFTW3_HOME="$HOME/local/fftw-3.3.2"
LIBS_PFFT="-L$PFFT_HOME/lib -L$FFTW3_HOME/lib -lpfft -lfftw3_mpi -lfftw3"
CFLAGS=" -I$PFFT_HOME/include -I$FFTW3_HOME/include -I$LIBFM_HOME/include"
LDFLAGS=$LDFLAGS" -L$LIBFM_HOME/lib -L$PFFT_HOME/lib -L$FFTW3_HOME/lib -lpfft -lfftw3_mpi
FCFLAGS=$CFLAGS
CPPFLAGS=" -I$LIBFM_HOME/include "
LD_LIBRARY_PATH=$LIBFM_HOME/lib:$LD_LIBRARY_PATH
LaPalma
LaPalma is a supercomputer of the IAC. It is a part of the old MareNostrum II computer. It was not possible to
compile with XL compilers, so GNU 4.6.1 version is used.
Previously to Octopus, Libxc (2.2), FFTW (3.3.4), GSL (1.16) and OpenBLAS (0.2.13) were required to compile.
GSL
export LD_LIBRARY_PATH=/usr/lib:/gpfs/apps/MPICH2/slurm-2.5.6/64/lib/:/gpfs/apps/GCC/4.9.2/lib64
export CC="/gpfs/apps/MPICH2/mx/default/64/bin/mpicc -cc=/gpfs/apps/GCC/4.9.2/bin/gcc"
export FC="/gpfs/apps/MPICH2/mx/default/64/bin/mpif90 -fc=/gpfs/apps/GCC/4.9.2/bin/gfortran"
./configure --prefix=$HOME/local/gsl/gnu --enable-static --disable-shared
OpenBLAS
Libxc
LaPalma
124
The_Octopus_Manual
export PATH=/gpfs/apps/MPICH2/mx/default/64/bin:$PATH
export LD_LIBRARY_PATH=/gpfs/apps/MPICH2/mx/default/64/lib:/gpfs/apps/MPICH2/slurm/64/lib
export LD_LIBRARY_PATH=/gpfs/apps/GCC/4.6.1/lib64/:$HOME/local/openblas/lib:$LD_LIBRARY_PATH
export CC="/gpfs/apps/MPICH2/mx/default/64/bin/mpicc -cc=/gpfs/apps/GCC/4.6.1/bin/gcc"
export FC="/gpfs/apps/MPICH2/mx/default/64/bin/mpif90 -fc=/gpfs/apps/GCC/4.6.1/bin/gfortran"
export CFLAGS="-m64 -O3"
export FCFLAGS=$CFLAGS
./configure --prefix=$HOME/local/libxc/gnu/4.6.1/2.2
Octopus
export PATH=/gpfs/apps/MPICH2/mx/default/64/bin:$PATH
export LD_LIBRARY_PATH=/gpfs/apps/MPICH2/mx/default/64/lib:/gpfs/apps/MPICH2/slurm/64/lib
export LD_LIBRARY_PATH=/gpfs/apps/GCC/4.6.1/lib64/:$HOME/local/openblas/4.6.1/lib:$LD_LIBRARY_PA
export CC="/gpfs/apps/MPICH2/mx/default/64/bin/mpicc -cc=/gpfs/apps/GCC/4.6.1/bin/gcc"
export FC="/gpfs/apps/MPICH2/mx/default/64/bin/mpif90 -fc=/gpfs/apps/GCC/4.6.1/bin/gfortran"
export CFLAGS="-m64 -O2 -I $PWD/external_libs/isf/wrappers "
export FCFLAGS=$CFLAGS
../configure
\
--with-blas=$HOME/local/openblas/4.6.1/lib/libopenblas.so.0 \
--with-lapack=/gpfs/apps/LAPACK/lib64/liblapack.a \
--disable-gdlib \
--with-gsl-prefix=$HOME/local/gsl/gnu \
--with-fft-lib=$HOME/local/fftw/3.3.4/lib/libfftw3.a \
--with-libxc-prefix=$HOME/local/libxc/gnu/4.6.1/2.2 \
--prefix=/gpfs/projects/ehu31/software/octopus/gnu/4.6.1 \
--enable-mpi --disable-f90-forall
<p class=newpage>
125
The_Octopus_Manual
The Fortran // concatenation operator is sometimes recognized as a C++-style comment and the
preprocessor gives erroneous results: sometimes it doesn't expand macros after it or simply eliminates what
comes after. To solve this problem, use the preprocessor with the -C (keep comments) and -ansi or
equivalent options (in ANSI C // is not a comment).
If you are compiling in dual 32/64-bit architectures like PowerPC, UltraSparc or AMD64 systems here are
some tips:
A 64-bit version of Octopus is only needed if you are going to use more than 2-3 Gb of physical
RAM.
Some operating systems have 64 bits kernels and 32 bits userspace (Solaris, OS X); if you want a
64-bit Octopus there, you have to compile all required libraries in 64-bit (normally a 64-bit libc is
available).
Typically Linux distributions for AMD64 have a 64-bit userspace, so you will get a 64-bit
executable there.
SSE2 support
We have some SSE2 code written using compiler primitives that can give an important increase in
perfomance. For this you need hardware support (AMD Opteron/Athlon 64/Sempron/Turion or Intel
Pentium 4 or newer) and compiler support, supported compilers are GCC and pathcc. For gcc you need to
put the correct -march flags (for example -march=opteron or -march=pentium4).
Besides this, for x86 (32 bits) you have to link dynamically because we have to use a tweaked malloc
function that doesn't work with static linking. For x86_64 (64 bits) this is not needed.
Operating systems
Linux
The main development operating system for Octopus.
Solaris
Octopus compiles correctly either with sun compilers or gcc/gfortran. By default Solaris doesn't have GNU
coreutils, so some test won't run.
Tru 64
It works.
Mac OS X
It works. Don't try to compile static binaries, they are not supported by the OS.
Windows
Toy operating systems are not supported for the moment, sorry.
126
The_Octopus_Manual
Compilers
Intel Compiler for x86/x86_64
status: ok
Version 9 and version 7.1 Build 20040901Z are ok. Versions 8 and 8.1 can be problematic.
Recommended flags: FCFLAGS="-u -zero -fpp1 -nbs -pc80 -pad -align -unroll -O3 -ip -tpp7 -xW"
Intel artificially blocks their compilers from using certain optimization in non-Intel processors.
With Octopus 3.2.0, use of the flags -check all -traceback with ifort 10.1.018 will cause an
internal compiler segmentation fault while compiling src/grid/mesh_init.F90.
Intel Compiler for Itanium
status: ok
Version: 8.1.033 (older 8 releases and version 9 are reported to cause problems), version 10 works but it is
much slower than 8.1.
Recommended flags:
FCFLAGS="-O3 -tpp2 -ip -IPF_fp_relaxed -ftz -align all -pad"
CFLAGS="-O3 -tpp2 -ip -IPF_fp_relaxed -ftz"
Open64
This is an open source compiler based on the liberated code of SGI MIPSpro compiler. It is available for x86,
x86_64 and Itanium architectures.
Pathscale Fortran Compiler
Versions tested: 2.2, 2.3 and 2.5
Architecure: x86, AMD64
Recommended flags:
FCFLAGS="-Wall -O3 -march=auto -mcpu=auto -OPT:Ofast -fno-math-errno"
Issues:
Everything works.
It's necessary to compile blas/lapack with the same compiler.
NAG compiler
AMD64:
FCFLAGS="-colour -kind=byte -mismatch_all -abi=64 -ieee=full -O4 -Ounroll=4"
Compilers
127
The_Octopus_Manual
Version: gcc version 4.1.1 or newer. (4.1.0 does not work) For the parallel version you need at least
gfortran 4.3.
You may also need to compile blas, lapack and fftw3 using that specific gfortran version.
Some recommended flags: -march=athlon64 -msse2 -mfpmath=sse -malign-double
-funroll-loops -O3
g95
Status: works
Tested architectures: x86/Linux, PowerPC/Darwin
Version: version 4.0.3 (g95 0.91!) May 24 2007
G95 doesn't recognize the linemarkers created by the preprocessor, so it's necessary to pass the -P flag to
cpp.
Flags:
FC=g95
FCFLAGS="-O3 -funroll-loops -ffast-math"
FCCPP="cpp -ansi-P"
There may be problems with versions 0.92 or 0.93, depending on the underlying version of gcc. See G95 for info
on building version 0.94 with gcc 4.2.4.
Portland 6
Flags:
FCFLAGS="-fast -mcmodel=medium -O4"
Known problems:
The following problem with the PGI compiler version 6.0 and MPICH version 1.2.6 on x86_64 has been reported:
The MPI detection during the configure step does not work properly. This may lead to compilation failures on
e. g. the file par_vec.F90. This problem is considered a bug in either the PGI compiler or the MPICH
implementation. Please apply the following change by hand after running configure:
In the file config.h, replace the line
/* #undef MPI_H */
by
#define MPI_H 1
128
The_Octopus_Manual
Portland 7, 8, 9
Flags (tested on Cray XT4):
FCFLAGS="-O2 -Munroll=c:1 -Mnoframe -Mlre -Mscalarsse -Mcache_align -Mflushz"
The configure script may fail in the part checking for Fortran libraries of mpif90 for
autoconf version 2.59 or earlier. The solution is to update autoconf to 2.60 or later, or manually set FCLIBS
in the configure command line to remove a spurious apostrophe.
Portland 10
For Octopus 3.2.0, the file src/basic/lookup.F90 is incorrectly optimized yielding many segmentation
faults in the testsuite. With PGI 10.5 the optimization flag should be -O2 or less; with PGI 10.8 the optimization
flag should be -O1 or less. Note that -fast and -fastsse are between -O2 and -O3. For later versions of
Octopus, a PGI pragma compels this file to be -O0 regardless of what is specified in FCFLAGS, so you may safely
set FCFLAGS to -fast.
Portland 11
11.4 does not work and will crash with glibc memory corruption errors. 11.7 is fine.
Portland 12
12.5 and 12.6 cannot compile due to an internal compiler errors of this form:
PGF90-S-0000-Internal compiler error. sym_of_ast: unexpected ast
Flags amd64/em64t:
FCFLAGS="-O3 -mcmodel=medium -m64 -cpu:host -YEXT_NAMES=LCS -YEXT_SFX=_"
Compaq compiler
FCFLAGS="-align dcommons -fast -tune host -arch host -noautomatic"
Xlf
Status: works
-bmaxdata:0x80000000 -qmaxmem=-1 -qsuffix=f=f90 -Q -O5 -qstrict -qtune=auto -qarch=auto -qhot -qipa
Portland 7, 8, 9
129
The_Octopus_Manual
Because of the exotic mixture of MAC OS and BSD, this system is not very standard. Compiling Octopus
can be problematic.
OS X doesn't support static linking of binaries, so don't try.
SGI MIPS
-O3 -INLINE -n32 -LANG:recursive=on
Sun Studio
You can download this compiler for free, it supports Linux and Solaris over x86, amd64 and sparc. A very fast
compiler but quite buggy.
Flags:
CFLAGS="-fast -xprefetch -xvector=simd -D__SSE2__"
FCFLAGS=$FLAGS
MPI Implementations
OpenMPI
MPICH2
SGI MPT
Intel MPI
Sun HPC ClusterTools
MVAPICH
NetCDF
Octopus uses the Fortran 90 interface of netCDF, this means that it's likely that you will have to compile it using
the same compiler you will use to compile Octopus. You can get the sources and follow installation instructions
from the NetCDF site.
Xlf
130
The_Octopus_Manual
AMD ACML
This is the AMD Mathematical Library optimized to run in Athlon and Opteron processors. You can get a free
copy from http://developer.amd.com/acml.jsp .
ATLAS
Compaq CXML
[GOTO BLAS]
Probably the fastest implementation of blas, source code is available and it can be compiled in many architectures.
Intel MKL
See https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor for MKL's advice on the proper way to
link. Here is an example, in which --with-lapack is left blank because it is included in --with-blas.
MKL_DIR=/opt/intel/mkl/lib/lintel64
--with-blas="-L$MKL_DIR -Wl,--start-group -lmkl_intel_lp64 -lmkl_sequential -lmkl_core -Wl,--end
--with-blacs="$MKL_DIR/libmkl_blacs_intelmpi_lp64.a" --with-scalapack="$MKL_DIR/libmkl_scalapack
Netlib
The reference implementation of BLAS and Lapack. It is available in most linux distributions. You can get the
source code from http://www.netlib.org/blas http://www.netlib.org/lapack .
Previous Manual:Examples:Benzene - Next Manual:Appendix:Reference Manual
Back to Manual <p class=newpage>
Appendix: Copying
INTRODUCTION
The real-space TDDFT code octopus ("octopus") is provided under the GNU General Public License ("GPL"),
Version 2, with exceptions for external libraries that are contained solely for convenience in this distribution.
You can find a copy of the GPL license here.
AMD ACML
131
The_Octopus_Manual
LICENSE EXCEPTIONS
Octopus provides several external libraries, which are located in the "external_libs" subdirectory of the octopus
source distribution. The GNU General Public License does not apply to these libraries. Separate copyright notices
can be found for each library in the respective subdirectories of "external_libs". Copyright notices are also
contained in this document.
Currently the following external libraries are provided:
Expokit
Roger B. Sidje
Department of Mathematics, University of Queensland
Brisbane, QLD-4072, Australia
Email: [email protected]
WWW: http://www.maths.uq.edu.au/expokit/
Copyright: http://www.maths.uq.edu.au/expokit/copyright
Metis 4.0
George Karypis
Department of Computer Science & Engineering
Twin Cities Campus
University of Minnesota, Minneapolis, MN, USA
Email: [email protected]
WWW: http://www-users.cs.umn.edu/~karypis/metis/index.html
METIS COPYRIGHT NOTICE
The ParMETIS/METIS package is copyrighted by the Regents of the University of Minnesota. It can be freely
used for educational and research purposes by non-profit institutions and US government agencies only. Other
organizations are allowed to use ParMETIS/METIS only for evaluation purposes, and any further uses will require
prior approval. The software may not be sold or redistributed without prior approval. One may make copies of the
software for their use provided that the copies, are not sold or distributed, are used under the same terms and
conditions.
As unestablished research software, this code is provided on an ``as is basis without warranty of any kind, either
expressed or implied. The downloading, or executing any part of this software constitutes an implicit agreement to
these terms. These terms and conditions are subject to change at any time without prior notice.
qshep
Robert Renka
University of North Texas
INTRODUCTION
132
The_Octopus_Manual
(817) 565-2767
qshep
133
The_Octopus_Manual
6. This agreement will terminate immediately upon User's breach of, or non-compliance with, any of its terms.
User may be held liable for any copyright infringement or the infringement of any other proprietary rights in the
Software that is caused or facilitated by the User's failure to abide by the terms of this agreement.
7. This agreement will be construed and enforced in accordance with the law of the state of New York applicable
to contracts performed entirely within the State. The parties irrevocably consent to the exclusive jurisdiction of the
state or federal courts located in the City of New York for all disputes concerning this agreement.
Commercial Use
Any User wishing to make a commercial use of the Software must contact ACM at [email protected] to
arrange an appropriate license. Commercial use includes (1) integrating or incorporating all or part of the source
code into a product for sale or license by, or on behalf of, User to third parties, or (2) distribution of the binary or
source code to third parties for use with a commercial product sold or licensed by, or on behalf of, User.
Revised 6/98
Previous Manual:Appendix:Reference Manual - Next Manual
Back to Manual
Back to Documentation
134