Direkt zum InhaltDirekt zur SucheDirekt zur Navigation
▼ Zielgruppen ▼
 

Humboldt-Universität zu Berlin - Mathematisch-Naturwissen­schaft­liche Fakultät - Quantenchemie der Festkörper/ Katalyse

Interfaces

Monalisa consist of interfaces which provide the energy, gradients and hessian matrices of investigated molecule. These are further passed to the runners (e.g. optimizer, md, thermo ect.), which process them.

Interfaces are divided into two main groups:


Leaf Interfaces

Leaf interfaces are objects which are responsible for preparation of the input files for the external QM programs, and are able to read energy, gradient and hessian from the output of external programs. Monalisa provides the following leaf interfaces:


Internal Interfaces

Internal interfaces are functions which are calling the other interfaces, that provide observables (energies, gradients and hessians). This observables are processed to deliver new energy, gradient and hessian. Internal interfaces may process observables from the leaf interfaces or from the other internal interfaces.

Monalisa provides the following leaf interfaces:

 

 


Leaf Interfaces

Orca Interface

ORCA is an ab initio, DFT, and semi-empirical SCF-MO package developed by Frank Neese et al. at the Max Planck Institute for Chemical Energy Conversion.

A unique feature of the Orca is DLPNO method which provides approximate MP2, CCSD and CCSD(T) energies for really big molecules. Orca interface is called by:

interface = orca {}

Orca interface doesn't need any additional keywords. In such a case it will use default settings for keywords. If you want to change the options you put keywords in the curly brackets {}.

 

setup:

Before running calculations one has to setup the system. After this in the appropriate subfolder of toplevel MonaLisa will prepare: energy.setup and hessian.setup file. These files are templates for energy.inp and hessian.inp files, which are created from *.setup files by replacing UPDATECOORD keyword by coordinates which are updated by actual structure of the molecule during the run of MonaLisa. Whatever is changed in *.setup files will affect Orca calculations. In this way one may use some special setting of the program, but one may also spoil the calculations, so beware. 

 

keywords:
keywords = <string> Creates a keyword line which specifies orca calculations type (default: "pbe D2 def2-TZVP def2-TZVP/J")
program = <string> Commad to execute the orca program (when the program is in the $PATH) or the path to the binary of the program (default: "orca")
energyprogram = <string> Path to the binary of the program for energy calculations. If it is not specified it is the same as the program variable (default: the same as program, so "orca")
hessianprogram = <string> Path to the binary of the program for hessian calculations. If not specified - the same as the program variable (default: "orca")
energyonly = <bool> Energy-only calculations. By default orca generates energy and gradient (EnGrad in keywords line). To force the program to run only energy (what is much cheaper in the case of e.g MP2) set: energyonly = true (default: "false")
nprocs = <int> Number of processors used in calculations. Creates the "%PAL NPROCS <int> END" keyword in the orca input file (default: "1")
maxcore = <int> Maximal amount of memory per core (in MB). (default: "")
charge = <int> Charge of the system (default: "0")
multiplicity = <int> Multiplicity of the system (defaiult: "1")
extraline = <string> Line to add in the input file. In this way one may specify some special orca options (default: ""). Note: currently only one extraline available
energyinput = <string> Name of the energy input file. Default value is "energy". The interface creates then energy.inp, and reads energy.out file. Modification will change the input and output file names
hessianprogram = <string> Name of the hessian input file. Default value is "hessian". The interface creates then energy.inp, and reads energy.out file. Modification will change the input and output file names
fullcommand = <bool> Only specified "program" string will be executed. Default value is (false). In the case false program runs: program energy.inp > energy.out. Some libraries may interferr and more involved commands are needed. In such cases one have to put fullcommand = true and specify the advanced command in the "program" variable. One useful example is when sombody wants to load and unload modules before and after running the program: "program = module load ORCA.401; /apps/ORCA/4.0.1/orca energy.inp > energy.out ; module unload ORCA.401"
 
expert keywords:
read_energy = <string> Read energy from specified precalculated file (default: ""). The safest way is to define file with respect to the folder in which Orca calculations are done, i.e. relative path. If keyword is empty it reads standard output of orca . Use this option carefully.
read_model = <string> Dpecify the type of energy which has to be read from output file. Possible keywords: "hf", "mp2", "ccsd", "ccsd(t)".

 

Note:

These both keywords are very usefull in the case of ExtrapolInterface, in which we need both HF and post-HF energies. Since as prerequisite for the post-HF calculations are HF calculations, these two types of jobs are done in one Orca job, and we don't need to run them separately (which requires then twice HF calculations). In such a case one can run firs MP2 calculation in HF job (e.g. scf-X of ExtrapolInterface), read the HF results from the default output file, and then in the MP2 calculation just read MP2 energy from appropriate output file (the one generated by HF job). The same can be done in the case of CCSD(T) calculations, which output contain HF, MP2, CCSD and CCSD(T) results.


VASP Interface

VASP (Vienna Ab initio Simulation Package) is a program for modelling 3D periodic structures (crystals) using plane wave basis sets and pseudopotentials. It performes particulary good for LDA/GGA DFT, however DFT with hybrid functionals, Hartree-Fock and MP2 methods are also supported. The interface is invoked by:

interface = vasp{}

VASP interface doesn't need any additional keywords. In such a case it will use default settings for keywords. If you want to change the options you put the keywords in the curly brackets {}.

setup:

Before running calculations one has to setup the system. After this in the appropriate subfolder of the toplevel/ MonaLisa will prepare: POSCAR_UPDATE file. This file is a template for POSCAR file (structure of the molecule - see VASP internet site), which is created from POSCAR_UPDATE file by replacing UPDATECOORD keyword with coordinates of actual structure of the molecule. These coordinates are updated during the MonaLisa run. Whatever is changed in POSCAR_UPDATE file will affect VASP calculations. In this way one may use some special setting of the program, but one may also spoil the calculations, so beware.

VASP needs also specification of k-points (KPOINTS), calculation settings (INCAR) and pseudopotentials (POTCAR). These three files should be placed manually in respective file folder before run. Please remember to put appropriate settings for the single point calculation in the INCAR file.

An exaple of the INCAR file which should work fine (settings for insulators with D2 disperssion):

#Electronic minimisation
   GGA    = PE          ! density functional
   PREC   = Accurate    ! precision tag
   EDIFF  = 1E-6        ! criterion to end SCF loop
   ENCUT  = 400.0       ! energy cutoff
   NELMIN = 5           ! minimum number of SCF-iterations
   NSW =  1           ! Number of ionic steps
   NELM = 100           ! Number of electronic iterations

#DOS related values
   ISMEAR = 0           ! Gaussian smearing for big cells

#Single point energy calculation
   IBRION = -1         ! job type (-1 for single point)
   NSW    = 1          ! number of ionic steps (1 for single point)
   LVDW   = .TRUE.  ! grimme D2 dispersion

#Do not write huge files - restart options
   LCHARG = .FALSE.     ! do not write charges
   LWAVE  = .FALSE.     ! do not write wavefunction
   ISTART = 0              ! do not read previous SCF guess

#Performance options
   NPAR   = 8          ! adjust to number of node (same number)
   IALGO  = 48          ! RMM-DIIS algorithm for electrons
   LPLANE = .TRUE.    ! data distribution in real space is done plane wise
   LREAL  = Auto        ! do projection in real or reciprocal space

 

For more details see VASP manual.

Beware!!! All coordinates in the VASP's POSCAR are sorted with respect to the atom type, therefore the order of the atoms may be different than in the POSCAR. The pseudopotentials in the POTCAR file have to be in the same order as atoms in the POSCAR, so always check the atom order in POSCAR_UPDATE and compere if the atom order in the POTCAR is the same. If not - you will get unphysical results.

keywords:

program = <string> // The name of the program for energy and gradient calculations (no default value, e.g. "mpirun /apps/VASP/5.3.5/vasp")

hessianprogram = <string> // The name of the program for hessian calculations (no default value, since the same INCAR file is always needed the procedure needs to replace the energy INCAR with special INCAR_hess, and after the calculation copying back the original INCAR_orig to the INCAR, i.e.  "cp INCAR INCAR_orig; cp INCAR_hess INCAR; mpirun /apps/VASP/5.3.5/vasp >vasp_hess.log ; cp INCAR_orig INCAR")

read_hessian = <string> // The name of the output file with the hessian matrix, in the non-empty variable case it does not calculate enything (no default value, e.g.  "./OUTCAR_hess")

read_hessian = <string> // The name of the output file with the energy, in the non-empty variable case it does not calculate enything (no default value, e.g.  "./OUTCAR")

 

hessianprogram


Turbomole Interface

TURBOMOLE is a quantum chemical program package, initially developed in the group of Prof. Dr. Reinhart Ahlrichs at the University of Karlsruhe and at the Forschungszentrum Karlsruhe. Presently TURBOMOLE is one of the fastest and most stable codes available for standard quantum chemical applications. Unlike many other programs, the main focus in the development of TURBOMOLE has not been to implement all new methods and functionals, but to provide a fast and stable code which is able to treat molecules of industrial relevance at reasonable time and memory requirements.

The interface is invoked by:

interface = orca {}

keywords:
energyprogram = <char> Source file of the energy program. Options: "dscf" (default), "ridft", "ricc2", "ricc2_huge" or "ccsdt"
gradientprogram = <char> Source file of the gradient program. Options: "grad" (default), "rdgrad" or "" (for energyprogram = ricc2)
hessianprogram = <char> Source file of the hessian program. Options: "aoforce" (default), "numforce -frznuclei  -central" (numerical hessian)
setupscript = <char> Path to the setup script which define the method of calculations. Default: "" (empty). If not empty it runs the string command in the folder of turbomole calculations
read_energy = <bool> Read energy from specified file. E.g. "./dscf.out" or "/users/mary/results/methane.out"
read_gradient = <bool> Read gradient from specified file. E.g. "./rdgrad.out" or "/users/mary/results/grad.out"
read_hessian = <bool> Read hessian from specified file. E.g. "./aoforce.out"

 


GULP Interface

 


Internal Interfaces

 


 

Embed Interface

It is one of the most important internal interface of the MonaLisa. This interface realize mechanical embedding scheme developed by Sauer and co-workers (J. Comput. Chem. 1997, 18, 463). The total hybrid energy of the system is defined as:

 

E(total) = E(hi_cluster) - E(lo_cluster) + E(lo_host)

 

where E(hi_cluster) represents the energy of the cluster calculated using high level of theory, E(lo_cluster) is the energy of the cluster calculated using low level of theory, whereas E(lo_host) is the energy of the whole system calculated using the low level theory. Note that each of these energies may be provided by leaf interfaces or another internal interfaces. Analogically one can define gradient and hessian.

Embed calculations are only possible if one defines the cluster molecule and hi_cluster, lo_cluster and lo_host interfaces. The informative example of the embed interface is below (# indicates comments which are ignored by program):

 

interface = embed{

cluster_atoms = 1, 2, 9, 10, 17, 18, 27, 37, 39, 69, 72, 78, 80, 84, 97, 98, 105, 106, 113, 114, 149, 157, 165, 175, 179, 181, 183, 193, 194, 201, 202, 209, 210, 245, 249, 253, 261, 267, 275, 279, 281, 289, 290, 297, 298, 305, 306, 307, 315, 316, 321, 322, 329, 330, 349, 371, 381, 385, 386, 393, 394, 401, 402, 411, 412, 421, 422, 431, 432, 447, 457, 473, 501, 504, 515, 536, 540, 558, 560, 574, 577-581 # Numbering of the atoms w.r.t. the input  structure (numbers separated by commas, ranges are indicated by "-" character)

   

# link atoms information
input_format = merged #Definition of the link atoms: "merged" - manual, "auto" - automatic

# Link atoms definition
# atom -- anchoratom (host) -- borderatom (cluster) -- distance to cluster -- atom type (MM)
linker {
  H   435    27   0.961 H1
  H   445    37   0.961 H1
  H   475    39   0.961 H1
  H   514    72   0.961 H1
  H   534    78   0.961 H1
  H   494   157   0.961 H1
  H   491   175   0.961 H1
  H   511   181   0.961 H1
  H   568   245   0.961 H1
  H   451   249   0.961 H1
  H   484   261   0.961 H1
  H   487   267   0.961 H1
  H   525   281   0.961 H1
  H   516   289   0.961 H1
  H   557   298   0.961 H1
  H   474   305   0.961 H1
  H   403   307   0.961 H1
  H   448   315   0.961 H1
  H   535   322   0.961 H1
  H   503   330   0.961 H1
  H   524   371   0.961 H1
  H   541   381   0.961 H1
 }

 

 

hi_cluster{

#definition of the hi_cluster interface
     interface = turbo{

        # turbomole interface (details here)

        energyprogram = ridft
        gradientprogram = rdgrad

     }

}
lo_cluster{

#definition of the lo_cluster interface
     interface = gulp{

         # gulp interface (details here)

         program = gulp
         periodic = 0D
         shells = o1,o2,o3

     }
}
lo_host{

     interface = gulp{

         # gulp interface (details here)

         program = gulp
         periodic = 0D
         shells = o1,o2,o3

     }

}

}

 

In this example we use turbomole as a high-level cluster calculations, whereas low-level calculations of either cluster and host are performed using force-field provide by GULP program.

 

setup:

Before running calculations one has to setup the system. After this in the appropriate subfolder of toplevel MonaLisa will prepare subfolders: hi_cluster, lo_cluster and lo_host (if mode = hionly, only hi_cluster will be created). Program will also prepare files: "cluster.cif" (cluster structure) and "linkers" (information about link atoms). It is always worth to check if the folders are created properly.

 

keywords:
mode = <char> Type of calculations, options: "embed" (default) - embed calculations; "hionly" - calculations for cluster only, useful for testing cluster performance 
cluster_atoms = <list> List of atoms constituing the cluster. Numbering as in the input file. Integers seperated by commas, or range of numbers specified by initial index and final index separated by "-". Eg. "1,2,6,8-13,4,22-45".
input_format = <char> Way of the link atoms definition. Options: "merged" (default) - manual definition of the link atoms (needs linker definition); "auto" - automatic definition of the link atoms. See link atoms section for more details.
linker {<datagroup>} Explicit definition of link atoms. See link atoms section for more details.
periodic_cluster = <bool> Options: "true" (default) - hi- and lo-clusters are treated as periodic systems with unit cell size as in the parent structur; "false" - no unit cell is ascribed to the clusters.

Link atoms:

Creation of the cluster may create dangling bonds. If this is the case these bonds should be saturated by link atoms, which typically are hydrogen atoms. These link atoms should be placed between the border cluster atom and the neighbouring atom which is not included in the cluster (anchor atom). The link atoms are placed on the line between the border atom and the anchor atom at predefined border atom - link atom distance. The link atoms can be defined manually using linker keyword (input_format = merged):

 

# link atom element - anchor atom index - border atom index - border-link distance - MM atom type (optional)

linker {
  H   435    27   0.961 H1
  F   445    37   1.400 F1
  C   475    39   1.510 Csp3

}

 

Link atoms can be also created automatically by MonaLisa. This option is activated by "input_format = auto". In such case the hydrogen link atoms are created between two atoms which are separated less than 1.2 * summ of covalent radii of border and anchor. The border - link distance is defined as the sum of covalent radii of both atoms. This automatic procedure is performed in the beginning of calculations and the link atoms cannot change during optimization.

To have control over this automatic procedure it is good to run first setup, and after this control the "cluster.cif" file. If the different than default border - link distance is required, one should copy the linker definition from the "linkers" file to the input file, adjust the distances and change the format to "input_format = merged"


Extrapol Interface

This interface realize the extrapolation of the basis set according to two point fitting described detailed in the article of Tuma and Sauer (J. Chem. Phys. 143 (2015) 102810).

This approach is sensfull only for calculation based on the HF or post-HF approach.

Calculation with this interface are invoked using the following syntax:

 

interface = extrapol {
      type = scf-corr # type of extrapolation (scf-corr or scf)
      CardinalNum_X  = 3  # cardinal number of the smaller basis set (X)
      CardinalNum_Y  = 4  # cardinal number of the bigger bsisi set (Y)

      # interface to calculate HF (with orca)
      scf-X{
        export keywords = HF cc-pVTZ
        interface = $orca # orca interface should be defined later (see section
      }
      scf-Y{
        export keywords = HF cc-pVQZ
        interface = $orca
      }

      # interfaces to calculate post-HF (with orca)
      corr-X{
        export keywords = RI-MP2 cc-pVTZ
        interface = $orca
      }
      corr-Y{
        export keywords = RI-MP2 cc-pVTZ
        interface = $orca
      }Extrapol Interface
}"

 

keywords:
type = <char> Type of calculations, options: "scf-corr" (default) - extrapolation of HF and correlation part (blocks scf-X,Y and corr-X,Y nedd to be specified); "scf" - HF extrapolation only (blocks scf-X,Y need to be specified)

CardinalNum_X = <real>

CardinalNum_Y = <ral>

Cardinal number of the basis sets. Both need to be specify. No default values. X has to be lower than Y. In the most standard case: aug-cc-pVXZ and cc-pVXZ: D=2, T=3, Q=4.
input_format = <char> Way of the link atoms definition. Options: "merged" (default) - manual definition of the link atoms (needs linker definition); "auto" - automatic definition of the link atoms. See link atoms section for more details.

scf-X{<datagroup>}

scf-Y{<datagroup>}

Definition of the interface used for scf calculations.

corr-X{<datagroup>}

corr-Y{<datagroup>}

Definition of the interface used for post-HF calculations (correlation energy).

Manadatory only for: type = scf-corr


BSSE Interface

Interface for calculation of Basis Set Superposition Error (BSSE) according to approach of Boys and Bernardi (ref).

Calculation with this interface are invoked using the following syntax:

bsse "bsse_general{

# Definition of monomers,separated by semicolon
        domains = 10-20

# Not specified atoms are treated atomatically as complementary monomoer (here monomer2 = 1-9)

        complementary = true 

# Interface used for calculations
        interface $orca

        supermol{
                interface $orca
                export charge = $charge_sm
        }
        monomer1{
                interface $orca
                export charge = $charge_m1
        }
        monomer2{
                export charge = $charge_m2
                interface $orca
        }
        ghost1{
                export charge = $charge_m1
                interface $orca
        }
        ghost2{
                export charge = $charge_m2
                interface $orca
        }
}"

 

keywords:
complementary = <bool> How to specify monomers: "false" (default) - all monomers have to be specified explicitly (see domains keyword). If "true" you need to specify only N-1 monomers. The last one is assumed to be the rest of the molecules atoms.

domains = <string>

Atoms which build monomers in BSSE scheme. By default you need to specify all monomers in the scheme. If the keyword complementary = true you need to specify only N-1 monomoers. Monomers are defined in one string and are seperated by semicollon ";". An example: (without complementary option) "domains = 1,2,5-10; 3,4,11-50" or "domains = 1,2,5-10" (with complementary option).
interface = {<datagroup>} Definition of the interface used for calculations.
monomers_only = <bool> (Default "false") If "true" then calculations are done without ghost atoms. It is no BSSE calculations, but it returns the interaction energy (without BSSE-correction) in one run (without relaxation energy).

ghosts_only = <bool>

(Default "false") If "true" then calculations are done without cluster atoms (ghost molecules only). It no BSSE calculations, but it returns the BSSE-corrected interaction energy in one run (without relaxation energy).