Lausanne 2017Version 4 out and rockingYambo-pyFLASH-IT

Main menu

HomeNewsPeopleDownloadRun the code
Overview Parallel Structure Databases Getting started Command line Runlevels Yambo-py
Input fileTutorialsDocumentationPublicationsEventsContactsRobots Forum

The Wikipedia Page of Yambo Yambo@Wiki

Fortran cafe The Fortran Cafe'

Bethe-Salpeter wine The Bethe-Salpeter-Equation (BSE) wine

A street entitled to Yambo in Rome
A bar entitled to Yambo in Rome
A bar entitled to Yambo in Rome Yambo road, bar & restaurant

Using yambo: Getting Started

Check the ingredients

To run yambo, you need

  1. The yambo executable (should be yambo-X.X.X/bin/yambo)
  2. A ./SAVE directory, containing the input databases s.db1/s.wf or ns.db1/ns.wf (if yambo is compiled with the NETCDF support)

Input file

yambo does not need precompiled input files. The main yambo driver is written in C and linked to the GNU getopt.c command line interpreter. yambo works like a standard unix command and the possible action to be taken is selected using the command line options.


To save time in later calculations yambo stores informations in a large number of files:

  1. [s.* (or ns.*)](e.g. SAVE/s.db1): Input files created by the yambo interfaces. Stored in SAVE folder. Contain KS wavefunctions and many other Ground state informations. Those files are created by the yambo interfaces.
  2. [db.* (or ndb.*)](e.g. SAVE/db.kindx, or TEST/db.X): Those files contains selected informations about calculated quantities. For example we have the database containing the K-points table (db.kindx) or the Reciprocal Space vectors table (db.gops). Those databases are stored in SAVE. Depending on the parameters provided in the input file yambo can re-calculate and overwrite a given database. If a job string is provided (-J option, e.g. -J TEST) yambo may decide to save the databse in the folder specified by the job string (i.e. TEST/db.X). This possibility can be used to keep the databases of several different calculations without being forced to recalculate them each time.
  3. [r*/l*](e.g. r_setup): those are report files (r*) and log files (l*). The report file is always created with several informations about the run. The log file is created only when running in background using
    yambo >& /dev/null
    or if the code is submitted through a batch script.
  4. [o*](e.g. o.eps-q001_rpa): those are output files that can be plotted.

First steps

yambo is pretty easy to run. Assuming for clarity that the yambo executable lies in your $PATH, type:

% yambo

(or if you are forced to run in parallel, try % yambo -N to switch off MPI)

With a bit of luck, the code should run, give a few report messages about the sections and their timing, create a report file r_setup, and stop (we'll drop the header from now on for clarity):

% yambo


 <---> [01] Game Summary
 <---> [02] Input variables setup
 <02s> RL-shells |####################| [100%] 02s(E) 02s(X)
 <02s> [02.01] K-grid lattice
 <02s> [02.02] Input (E)nergies[ev] & Occupations
 <02s> [03] Transferred momenta grid: Indexes
 <02s> [04] Game Over & Game summary

Most importantly, however, the run will create two new databases in the ./SAVE directory: db.kindx, db.gops. Such is the yambo philosophy: a run must create at least one database file!

Well, this is not so interesting (you might browse r_setup, but there's nothing to plot!), but every code has to start somewhere. In fact, you have just run the default setup runlevel, which is called at the beginning of every yambo run. Next time, however, the job will be much faster: running

% yambo
should take only a few seconds, as the new databases are scanned and checked.

Input file generation

Let's try to modify the options in the setup runlevel. First, delete the SAVE/ndb.* files (NOT the *.db/*.wf input databases!), and First run

% yambo -i
If the interactive call to your editor (e.g. vi) worked, you should now be looking at the contents of the yambo.in file. If interactive runs are not supported on your system, the yambo.in file will be generate and the code will stop: you can edit it directly yourself:
% vi yambo.in

setup                        # [R INI] Initialization
Not much help, is it?!


This illustrates an important concept in the running of yambo: verbosity. Turn up the verbosity a little by specifying an appropriate option, and try again, e.g.:

% yambo -i -V RL


setup                        # [R INI] Initialization
MaxGvecs=  411           RL  # [INI] Max number of G-vectors planned to use

Now you can see an extra option for the initialization runlevel, which is normally hidden from you, since you rarely need to change it. However, if you needed a large number of G vectors when running your DFT code, for example, you might not need to use all these G vectors to calculate an optical spectrum, say. Reducing the number will also speed up the setup runlevel, and reduce it to a few minutes maximum.

Move down the file and lower the MaxGvecs number by 50%, save the yambo.in file and run the code again (without the "-i -V RL", or you will be back editing the file again!). yambo should run again, a little faster this time. SAVE/db.gops will be overwritten with the new value of MaxGvecs saved.

For explanation of the various verbosity flags, see the verbosity page for details.

Minimalist input file generation!

Hopefully this illustrates to you the intelligent input file parsing of yambo. At all stages, yambo will try to generate for you the minimum amount of information that you need to run the code, taking into account the contents of the SAVEd databases, and will remember what options you last specified manually via yambo.in. There are so many input variables to modify in yambo that it would be easy to get lost or disheartened if you met them all at the first go!

In case you haven't figured it out by now, running any of

% yambo 
% yambo -N
% yambo -J jobname
% mpirun -np 4 yambo
[...other upper case options...]
will actually run the code executable based on the content of yambo.in (or will rerun just the setup runlevel if that file is not present), while
% yambo -i
% yambo -o b -k w -y h
% yambo -o c -k h
% yambo -x
[...other lower case options...]
(see the full list of commands) will not run the full executable, but instead run the input file parser for the specified runlevel.

Hopefully you now understand the basic usage of the code: you should now be ready to proceed to the next stage and calculate something useful. Choose a runlevel!