Using yambo: Getting Started
Check the ingredients
To run yambo, you need
- The yambo executable (should be yambo-X.X.X/bin/yambo)
- 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.
DataBases
To save time in later calculations yambo stores informations in a large number of files:
- [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.
- [db.* (or ndb.*)](e.g. SAVE/db.kindx 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) yambo may decide to save the databse in the folder specified by the job string. This possibility can be used to keep the databases of several different calculations without being forced to recalculate them each time.
- [r*/l*](e.g. r_setup): those are
report files (r*) and log files (l*). The report file is alwasy
created with several informations about the run. The log file
is created only when running in background using
yambo >& /dev/null
- [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
% yamboshould 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 -iIf 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?!
Verbosity
This illustrates an important concept in the running of yambo: verbosity. Turn up the verbosity a little, and try again:
% yambo -i -V 1 [...] setup # [R INI] Initialization MaxGvecs= 411 RL # [INI] Max number of G-vectors planned to use nQptIBZ = 0 # [KPT] N. of Q-points in the IBZ (compatibility) % QptCoord # [KPT] [iku] Q-points coordinates (compatibility) 0.00 | 0.00 | 0.00 | %Now you can see several options for the initialization runlevel, which are normally hidden from you, since you rarely need to change them. 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.
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 1", 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.
You may ask why the number of electrons is provided. Well, this example is for simple solid silicon (8 electrons). Try to force Nelectro=7 and yambo will provide you with a metallic silicon!
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 -y hdit % yambo -o l % yambo -x % yambo -s r [...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!