Initialization: Difference between revisions

From The Yambo Project
Jump to navigation Jump to search
 
(24 intermediate revisions by 4 users not shown)
Line 3: Line 3:
== Prerequisites ==
== Prerequisites ==
'''Previous modules'''
'''Previous modules'''
* It is recommended that you first follow the tutorials on generating the Yambo databases for [[Bulk_material:_h-BN|bulk hBN]] and [[2D_material:_h-BN_sheet|2D hBN]].
* It is recommended that you first follow the tutorials on generating the Yambo databases for [[Bulk_material:_h-BN|bulk hBN]].


'''You will need''':
'''You will need''':
* The <code>SAVE</code> databases for bulk hBN and the 2D hBN sheet ('''Download here''')
* The <code>SAVE</code> databases for bulk hBN and the 2D hBN sheet
* The <code>yambo</code> executable
* The <code>yambo</code> executable


== Initialization ==
== Initialization ==
Use the ''SAVE'' folders that are already provided, rather than any ones you may have generated previously.


'''Every Yambo run must start with this step'''. Go to the folder ''containing'' the hBN-bulk <code>SAVE</code> directory:
Every Yambo run '''must''' start with this step. Go to the folder ''containing'' the hBN-bulk <code>SAVE</code> directory:
  $ cd TUTORIALS/hBN/YAMBO
  $ cd YAMBO_TUTORIALS/hBN/YAMBO
  $ ls
  $ ls
  SAVE
  SAVE
and simply launch the code
yambo
This will run the initialization (setup) ''runlevel''. <br>
'''TIP''': do not run yambo from ''inside'' the <code>SAVE</code> folder! It will complain that "databases not found".


Three new elements will appear:
'''TIP''': do not run yambo from ''inside'' the <code>SAVE</code> folder!
'''This is the wrong way .. '''
$ cd SAVE
$ yambo
yambo: cannot access CORE database (SAVE/*db1 and/or SAVE/*wf)
In fact, if you ever see such message:
it usually means you are trying to launch Yambo '''from the wrong place'''.
$ cd ..
 
Now you are in the proper place and
$ ls
SAVE
you can simply launch the code
$ yambo
This will run the initialization (setup) ''runlevel''.
 
===Run-time output===
===Run-time output===
This is typically written to standard output (on screen) and tracks the progress of the run in real time:
This is typically written to standard output (on screen) and tracks the progress of the run in real time:
  <---> [01] CPU structure, Files & I/O Directories
  <---> [01] MPI/OPENMP structure, Files & I/O Directories
  <---> [02] CORE Variables Setup
  <---> [02] CORE Variables Setup
  <---> [02.01] Unit cells
  <---> [02.01] Unit cells
  <---> [02.02] Symmetries
  <---> [02.02] Symmetries
  <---> [02.03] RL shells
  <---> [02.03] Reciprocal space
  <---> Shells finder |########################################| [100%] --(E) --(X)
  <---> Shells finder |########################################| [100%] --(E) --(X)
  <---> [02.04] K-grid lattice
  <---> [02.04] K-grid lattice
  <---> [02.05] Energies [ev] & Occupations
<---> Grid dimensions      :  6  6  2
  <---> [03] Transferred momenta grid
  <---> [02.05] Energies & Occupations
  <---> [03] Transferred momenta grid and indexing
  <---> BZ -> IBZ reduction |########################################| [100%] --(E) --(X)
  <---> BZ -> IBZ reduction |########################################| [100%] --(E) --(X)
  <---> X indexes |########################################| [100%] --(E) --(X)
  <---> [03.01] X indexes
  <---> SE indexes |########################################| [100%] --(E) --(X)
<---> X [eval] |########################################| [100%] --(E) --(X)
  <---> [04] External corrections
<---> X[REDUX] |########################################| [100%] --(E) --(X)
  <---> [05] Game Over & Game summary
  <---> [03.01.01] Sigma indexes
<---> Sigma [eval] |########################################| [100%] --(E) --(X)
<---> Sigma[REDUX] |########################################| [100%] --(E) --(X)
  <---> [04] Timing Overview
  <---> [05] Memory Overview
<---> [06] Game Over & Game summary
Specific runlevels are indicated with numeric labels like [02.02]. <br>
Specific runlevels are indicated with numeric labels like [02.02]. <br>
The hashes (#) indicate progress of the run in Wall Clock time, indicating the elapsed (E) and expected (X) time to complete a runlevel, and the percentage of the task complete.
The hashes (#) indicate progress of the run in Wall Clock time, indicating the elapsed (E) and expected (X) time to complete a runlevel, and the percentage of the task complete.
If Yambo is launched using a script, or as a background process, or in parallel, this output will appear in a log file prefixed by the letter ''l'', in this case as <code>l_setup</code>.
If this log file already exists from a previous run, it will not be overwritten. Instead, a new file will be created with an incrementing numerical label, e.g. <code>l_setup_01, l_setup_02</code>, etc. '''This applies to all files created by Yambo'''.
In the case of parallel runs, CPU-dependent log files will appear inside a <code>LOG</code> folder, e.g.
$ mpirun -np 4 yambo
$ ls LOG
l_setup_CPU_1  l_setup_CPU_2  l_setup_CPU_3  l_setup_CPU_4
This behaviour can be controlled at runtime - see the Parallel tutorial for details.


===New core databases===
===New core databases===
New databases appear in the <code>SAVE</code> folder:
New databases appear in the ''SAVE'' folder:
  $ ls SAVE
  $ ls SAVE
  ns.db1 ns.wf ns.kb_pp_pwscf '''ns.gops ns.kindx'''
  ns.db1 ns.wf ns.kb_pp_pwscf '''ndb.gops ndb.kindx'''
  ns.wf_fragments_1_1 ...
  ns.wf_fragments_1_1 ...
  ns.kb_pp_pwscf_fragment_1 ...
  ns.kb_pp_pwscf_fragment_1 ...
These contain information about the ''G''-vector shells and ''k/q''-point meshes as defined by the DFT calculation.
These contain information about the ''G''-vector shells and ''k/q''-point meshes as defined by the DFT calculation.


'''TIP''': if you launch yambo, but it does not seem to produce anything new, check that these files are present.
In general: a database called ''n'''s'''.xxx'' is a ''static'' database, generated once by <code>p2y</code>, while databases called ''n'''db'''.xxx'' are ''dynamically'' generated while you use <code>yambo</code>.
 
'''TIP''': if you launch <code>yambo</code>, but it does not seem to do anything, check that these files are present.


===Report file===
===Report file===
A report file <code>r_setup</code> is generated in the run directory.  
A report file ''r_setup'' is generated in the run directory.  
This mostly reports information about the ground state system as defined by the DFT run, but also adds information about the band gaps, occupations, shells of G-vectors, IBZ/BZ grids, the CPU structure (for parallel runs), and so on. Some points of note:
This mostly reports information about the ground state system as defined by the DFT run, but also adds information about the band gaps, occupations, shells of G-vectors, IBZ/BZ grids, the CPU structure (for parallel runs), and so on. Some points of note:


   [02.03] RL shells
   [02.03] Reciprocal space
   =================
   ========================
   Shells, format: [S#] G_RL(mHa)
 
   [S217]:3187(0.4380E+5) [S216]:3175(0.4378E+5) [S215]:3163(0.4321E+5) [S214]:3139(0.4321E+5)
   Full and reduced cutoff41477.1      79818.4    [mHa]
   ...
 
   [S4]:11( 1183.) [S3]:5( 532.5123) [S2]:3( 133.1281) [S1]:1( 0.000000)
  nG shells        : 204
  nG charge        : 2987
   nG WFs            :  1477
   nC WFs            : 1016
  G-vecs. in first 204 shells: [ Number ]
    1    3   5  11  13  25  37  39  51
    63  65  71  83  95  107  113  125  127
  139  151  163  175  187  189  201  213  225
    237  249  261  285  287  311  335  347  359
    371  395  401  403  415  427  439  463  475
 


This reports the set of closed reciprocal lattice (RL) shells defined internally that contain G-vectors with the same modulus.  
This reports the set of closed reciprocal lattice (RL) shells defined internally that contain G-vectors with the same modulus.  
The highest number of RL vectors we can use is 3187.  Yambo will always redefine any input variable in RL space to the nearest closed shell.
Yambo will always redefine any input variable in RL units to the nearest closed shell.
 
  [02.05] Energies & Occupations
  ==============================
 
  [X] === General ===
  [X] Electronic Temperature                        :  0.000000  0.000000 [eV K]
  [X] Bosonic    Temperature                        :  0.000000  0.000000 [eV K]
  [X] Finite Temperature mode                      : no
  [X] El. density                                  :  0.46037E+24 [cm-3]
  [X] Fermi Level                                  :  5.111115 [eV]
 
  [X] === Gaps and Widths ===
  [X] Conduction Band Min                          :  3.877635 [eV]
  [X] Valence Band Max                              :  0.000000 [eV]
  [X] Filled Bands                                  :  8
  [X] Empty Bands                                  :    9  100
  [X] Direct Gap                                    :  4.289509 [eV]
  [X] Direct Gap localized at k                    :  7
  [X] Indirect Gap                                  :  3.877635 [eV]
  [X] Indirect Gap between kpts                    :  14  7
  [X] Last valence band width                      :  3.401222 [eV]
  [X] 1st conduction band width                    :  4.266500 [eV]


  [02.05] Energies [ev] & Occupations
  ===================================
  Fermi Level        [ev]:  5.112805
  VBM / CBm          [ev]:  0.000000  3.876293
  Electronic Temp. [ev K]:  0.00      0.00
  Bosonic    Temp. [ev K]:  0.00      0.00
  El. density      [cm-3]: 0.460E+24
  States summary        : Full        Metallic    Empty
                          0001-0008              0009-0100
  Indirect Gaps      [ev]: 3.876293  7.278081
  Direct Gaps        [ev]:  4.28829  11.35409
  X BZ K-points :  72


Yambo recalculates again the Fermi level (close to the value of 5.06 noted in the PWscf SCF calculation). From here on, however, the Fermi level is set to zero, and other eigenvalues are shifted accordingly. The system is insulating (8 filled, 92 empty) with an indirect band gap of 3.87 eV. The minimum and maximum direct and indirect gaps are indicated. There are 72 k-points in the full BZ, generated using symmetry from the 14 k-points in our user-defined grid.
Yambo recalculates again the Fermi level (close to the value of 5.06 noted in the PWscf SCF calculation). From here on, however, the Fermi level is set to zero, and other eigenvalues are shifted accordingly. The system is insulating (8 filled, 92 empty) with an indirect band gap of 3.87 eV. The minimum and maximum direct and indirect gaps are indicated. There are 72 k-points in the full BZ, generated using symmetry from the 14 k-points in our user-defined grid.


NB: You should inspect the report file after ''every'' run for errors and warnings.
'''TIP''': You should inspect the report file after ''every'' run for errors and warnings.
 
===Different ways of running yambo===
We just run Yambo interactively.
 
Let's try to re-run the setup with the command
$ yambo >& /dev/null &
$ ls
l_setup r_setup  r_setup_01  SAVE
 
If Yambo is launched using a script, or as a background process, or in parallel, this output will appear in a log file prefixed by the letter ''l'', in this case as ''l_setup''.
If this log file already exists from a previous run, it will not be overwritten. Instead, a new file will be created with an incrementing numerical label, e.g. ''l_setup_01, l_setup_02'', etc. '''This applies to all files created by Yambo'''. Here we see that l_setup was created for the first time, but r_setup already existed from the previous run, so now we have r_setup_01
If you check the differences between the two you will notice that in the second run yambo is reading the previously created ndb.kindx in place of re-computing the indexes.
Indeed the output inside l_setup does not show the timing for X and Sigma
 
As a last step we run the setup in parallel, but first we delete the ndb.kindx file
$ rm SAVE/ndb.kindx
$ mpirun -np 4 yambo
$ ls
LOG  l_setup  nohup.out  r_setup  r_setup_01  r_setup_02  SAVE
There is now r_setup_02
In the case of parallel runs, CPU-dependent log files will appear inside a ''LOG'' folder, e.g.
$ ls LOG
l_setup_CPU_1  l_setup_CPU_2  l_setup_CPU_3  l_setup_CPU_4
This behaviour can be controlled at runtime - see the Parallel tutorial for details.


==2D hBN==
==2D hBN==
Simply repeat the steps above. Go to the folder ''containing'' the hBN-sheet <code>SAVE</code> directory and launch <code>yambo</code>
Simply repeat the steps above. Go to the folder ''containing'' the hBN-2D ''SAVE'' directory and launch <code>yambo</code>:
  $ cd TUTORIALS/hBN-2D/YAMBO
  $ cd TUTORIALS/hBN-2D/YAMBO
  $ ls
  $ ls
  SAVE
  SAVE
  $ yambo
  $ yambo
Again, inspect the <code>r_setup</code> file, output logs, and verify that <code>ndb.gops</code> and <code>ndb.kpts</code> have been created inside the SAVE folder.
Again, inspect the ''r_setup'' file, output logs, and verify that ''ndb.gops'' and ''ndb.kpts'' have been created inside the SAVE folder.


You are now ready to use Yambo!
You are now ready to use Yambo!


== Links ==
==Summary==
* [[Input_file_generation|Input file generation]]
From this tutorial you've learned:
* [[Tutorials|Back to tutorials menu]]
* How to initialize the Yambo databases
* The Yambo logs and output file structure
 
<br>
{| style="width:100%" border="1"
|style="width:15%; text-align:left"|Prev: [[2D_material:_h-BN_sheet|2D hBN]]
|style="width:70%; text-align:center"|Now: [[Tutorials|Tutorials Home]] --> [[First_steps:_a_walk_through_from_DFT_to_optical_properties|First steps]] --> [[2D_material:_h-BN_sheet|2D hBN]] --> [[Initialization|Initialization]]
|style="width:15%; text-align:right"|Next: [[Input_file_generation_and_command_line_options_5.0|Input file generation and command line options (5.0)]]
|-
|}
 
 
 
[[Category:Modules]]

Latest revision as of 07:55, 16 October 2024

In this tutorial you will learn how to initialize the Yambo databases for bulk hBN.

Prerequisites

Previous modules

  • It is recommended that you first follow the tutorials on generating the Yambo databases for bulk hBN.

You will need:

  • The SAVE databases for bulk hBN and the 2D hBN sheet
  • The yambo executable

Initialization

Use the SAVE folders that are already provided, rather than any ones you may have generated previously.

Every Yambo run must start with this step. Go to the folder containing the hBN-bulk SAVE directory:

$ cd YAMBO_TUTORIALS/hBN/YAMBO
$ ls
SAVE

TIP: do not run yambo from inside the SAVE folder! This is the wrong way ..

$ cd SAVE
$ yambo
yambo: cannot access CORE database (SAVE/*db1 and/or SAVE/*wf)

In fact, if you ever see such message: it usually means you are trying to launch Yambo from the wrong place.

$ cd ..

Now you are in the proper place and

$ ls
SAVE

you can simply launch the code

$ yambo 

This will run the initialization (setup) runlevel.

Run-time output

This is typically written to standard output (on screen) and tracks the progress of the run in real time:

<---> [01] MPI/OPENMP structure, Files & I/O Directories
<---> [02] CORE Variables Setup
<---> [02.01] Unit cells
<---> [02.02] Symmetries
<---> [02.03] Reciprocal space
<---> Shells finder |########################################| [100%] --(E) --(X)
<---> [02.04] K-grid lattice
<---> Grid dimensions      :   6   6   2
<---> [02.05] Energies & Occupations
<---> [03] Transferred momenta grid and indexing
<---> BZ -> IBZ reduction |########################################| [100%] --(E) --(X)
<---> [03.01] X indexes
<---> X [eval] |########################################| [100%] --(E) --(X)
<---> X[REDUX] |########################################| [100%] --(E) --(X)
<---> [03.01.01] Sigma indexes
<---> Sigma [eval] |########################################| [100%] --(E) --(X)
<---> Sigma[REDUX] |########################################| [100%] --(E) --(X)
<---> [04] Timing Overview
<---> [05] Memory Overview
<---> [06] Game Over & Game summary

Specific runlevels are indicated with numeric labels like [02.02].
The hashes (#) indicate progress of the run in Wall Clock time, indicating the elapsed (E) and expected (X) time to complete a runlevel, and the percentage of the task complete.

New core databases

New databases appear in the SAVE folder:

$ ls SAVE
ns.db1 ns.wf ns.kb_pp_pwscf ndb.gops ndb.kindx
ns.wf_fragments_1_1 ...
ns.kb_pp_pwscf_fragment_1 ...

These contain information about the G-vector shells and k/q-point meshes as defined by the DFT calculation.

In general: a database called ns.xxx is a static database, generated once by p2y, while databases called ndb.xxx are dynamically generated while you use yambo.

TIP: if you launch yambo, but it does not seem to do anything, check that these files are present.

Report file

A report file r_setup is generated in the run directory. This mostly reports information about the ground state system as defined by the DFT run, but also adds information about the band gaps, occupations, shells of G-vectors, IBZ/BZ grids, the CPU structure (for parallel runs), and so on. Some points of note:

 [02.03] Reciprocal space
 ========================
 Full and reduced cutoff:   41477.1      79818.4    [mHa]
 nG shells         :  204
 nG charge         :  2987
 nG WFs            :  1477
 nC WFs            :  1016
 G-vecs. in first 204 shells:  [ Number ]
    1    3    5   11   13   25   37   39   51
   63   65   71   83   95  107  113  125  127
  139  151  163  175  187  189  201  213  225
   237   249   261   285   287   311   335   347   359
   371   395   401   403   415   427   439   463   475


This reports the set of closed reciprocal lattice (RL) shells defined internally that contain G-vectors with the same modulus. Yambo will always redefine any input variable in RL units to the nearest closed shell.

 [02.05] Energies & Occupations
 ==============================
 [X] === General ===
 [X] Electronic Temperature                        :  0.000000  0.000000 [eV K]
 [X] Bosonic    Temperature                        :  0.000000  0.000000 [eV K]
 [X] Finite Temperature mode                       : no
 [X] El. density                                   :  0.46037E+24 [cm-3]
 [X] Fermi Level                                   :  5.111115 [eV]
 [X] === Gaps and Widths ===
 [X] Conduction Band Min                           :  3.877635 [eV]
 [X] Valence Band Max                              :  0.000000 [eV]
 [X] Filled Bands                                  :   8
 [X] Empty Bands                                   :    9  100
 [X] Direct Gap                                    :  4.289509 [eV]
 [X] Direct Gap localized at k                     :   7
 [X] Indirect Gap                                  :  3.877635 [eV]
 [X] Indirect Gap between kpts                     :  14   7
 [X] Last valence band width                       :  3.401222 [eV]
 [X] 1st conduction band width                     :  4.266500 [eV]


Yambo recalculates again the Fermi level (close to the value of 5.06 noted in the PWscf SCF calculation). From here on, however, the Fermi level is set to zero, and other eigenvalues are shifted accordingly. The system is insulating (8 filled, 92 empty) with an indirect band gap of 3.87 eV. The minimum and maximum direct and indirect gaps are indicated. There are 72 k-points in the full BZ, generated using symmetry from the 14 k-points in our user-defined grid.

TIP: You should inspect the report file after every run for errors and warnings.

Different ways of running yambo

We just run Yambo interactively.

Let's try to re-run the setup with the command

$ yambo >& /dev/null &
$ ls
l_setup r_setup  r_setup_01  SAVE

If Yambo is launched using a script, or as a background process, or in parallel, this output will appear in a log file prefixed by the letter l, in this case as l_setup. If this log file already exists from a previous run, it will not be overwritten. Instead, a new file will be created with an incrementing numerical label, e.g. l_setup_01, l_setup_02, etc. This applies to all files created by Yambo. Here we see that l_setup was created for the first time, but r_setup already existed from the previous run, so now we have r_setup_01 If you check the differences between the two you will notice that in the second run yambo is reading the previously created ndb.kindx in place of re-computing the indexes. Indeed the output inside l_setup does not show the timing for X and Sigma

As a last step we run the setup in parallel, but first we delete the ndb.kindx file

$ rm SAVE/ndb.kindx
$ mpirun -np 4 yambo 
$ ls
LOG  l_setup  nohup.out  r_setup  r_setup_01  r_setup_02  SAVE

There is now r_setup_02 In the case of parallel runs, CPU-dependent log files will appear inside a LOG folder, e.g.

$ ls LOG
l_setup_CPU_1   l_setup_CPU_2  l_setup_CPU_3  l_setup_CPU_4

This behaviour can be controlled at runtime - see the Parallel tutorial for details.

2D hBN

Simply repeat the steps above. Go to the folder containing the hBN-2D SAVE directory and launch yambo:

$ cd TUTORIALS/hBN-2D/YAMBO
$ ls
SAVE
$ yambo

Again, inspect the r_setup file, output logs, and verify that ndb.gops and ndb.kpts have been created inside the SAVE folder.

You are now ready to use Yambo!

Summary

From this tutorial you've learned:

  • How to initialize the Yambo databases
  • The Yambo logs and output file structure


Prev: 2D hBN Now: Tutorials Home --> First steps --> 2D hBN --> Initialization Next: Input file generation and command line options (5.0)