| |
|
|
|
This chapter describes the Jaguar input file and how to use it to run Jaguar "by hand," that is, not using the interface. You might want to run Jaguar by hand in order to submit a job at a later time when computers are less busy, to use batch scripts to run multiple jobs in succession, to submit jobs from a non-X terminal, or to automate job submission with input files created by using other programs or by creating and editing input files yourself.
The first section of this chapter describes how to use the jaguar command to submit a single Jaguar job. Most of the rest of the sections in this chapter discuss the Jaguar input file format, describing the general file format first, then describing each section of the input file, starting with the geometry input (zmat) and the keyword (gen) sections. The final section, Section 8.20, describes how to run multiple Jaguar jobs using Jaguar's batch script.
As you already know, you can use the jaguar command to start Jaguar's graphical user interface. You can also use it to
· run a job on any machine at your site, with any version of Jaguar installed in the Jaguar home directory;
If Jaguar is installed on more than one machine at your site, you can use the jaguar command on one machine to run, kill, or list Jaguar jobs on another machine, even if you are not logged in to the second machine.
summarizes how to use the jaguar command. This section describes in more detail how to use the jaguar command.
If Jaguar is installed on several machines at your site, you can use the jaguar command to help determine which host you should use to run your job.
If you don't know which local machines have Jaguar installed, you can find out by entering the command
The hosts listed will be those in the jaguar.hosts file being used by the jaguar command. If you find that the list of hosts in the "jaguar hosts" output is incomplete, you probably need to edit the jaguar.hosts file indicated on the first line of the "jaguar hosts" output. See section 6.1 for a description of the jaguar.hosts file.
If a machine is often heavily used, you may want to check how many Jaguar jobs are running on it already before you submit yours. If perl is installed on your system (contact Schrödinger or your system manager if you need more information), you can do so with the command
for the machine on which you are logged in, or
for another machine, where you substitute a host listed in the "jaguar hosts" output for hostname.
By default, Jaguar looks for the executables available for the machine upon which you want to run a Jaguar job, then uses the most recent Jaguar executables for that machine type. However, if you have several differing sets of Jaguar executables at your site, such as different versions of Jaguar or executables for different machine types, you can choose to run your Jaguar job with a non-default choice of executables.
If you don't know which sets of Jaguar executables are available, you can find out by entering the command
to find out about executables on the current host, or
to find out about executables on another machine (where you substitute a host listed in the "jaguar hosts" output for hostname).
The "jaguar run" command lets you run a Jaguar job using the Jaguar input file you specify. When you use the interface's Run window to select a calculation host and start a Jaguar job running on that machine, the interface starts the job by submitting the appropriate "jaguar run" command. If you want to, you can bypass the interface and submit the "jaguar run" command from your X terminal window instead, using any of the "jaguar run" command options shown in Table 8.1.1 and described below.
To run a Jaguar job, you first need an appropriate Jaguar input file. The file should be named in the form jobname.in, where jobname is whatever name you like. You can either create and edit an input file using your text editor, or you can use the interface to create and save one. See the subsection Saving Input Files in Section 2.7 for more information on using the interface to save input files. If you are hand-editing an input file, make sure its format agrees with that described in the rest of this chapter, especially Section 8.2.
You can run a Jaguar job from the command line with the command
where jobname reflects the name of your input file, jobname.in. With this command, the job will run on the machine upon which you have submitted the command, and will use the most recent version of Jaguar.
To run a Jaguar job on another machine, use a command in this form:
where your input file is named jobname.in and hostname is one of the hosts listed in the output from "jaguar hosts". For instance, if you were logged into a machine named alpha and wanted to run a job named ch4 on a machine named beta, you would enter
To run a Jaguar job on the machine hostname with a particular, non-default set of executables, you can use the command
where version is any string that appears in one of the executable directories listed for that host by the "jaguar versions -h hostname" command.
The "jaguar run" command has several other command line options, as shown in Table 8.1.1. For example,
causes executables to be run with a lower CPU scheduling priority (see man page on "nice") and leaves all temporary files generated during the job in the temporary directory.
If you wish to submit a series of jobs, you can create multiple input files using the Save window in the interface, as described in Section 2.7. You can then write a simple script including jaguar commands like the ones above to run the jobs, or run the jobs with the "jaguar batch" command. Section 8.20 describes how to run multiple jobs with the "jaguar batch" command.
The "jaguar kill" command lets you kill any Jaguar job you are running on any local machine. This command is only available if perl is installed on your system; contact Schrödinger or your system manager if you need more information on perl.
Note that when you use the "jaguar kill" command, the temporary directory for your job will still exist and will contain all files generated during the job, and no output files will be copied back to your output directory.
To kill one of your Jaguar jobs, first enter the command
to kill a job on the machine on which you are logged in, or
to kill a job running on another machine (where hostname is one of the hosts listed in the output from "jaguar hosts"). Your Jaguar jobs on the specified machine will be listed, and you will be prompted to enter the number corresponding to the one you want to kill. To avoid killing any jobs, just hit <return>.
The input file often begins with an optional line indicating the version number of Jaguar, such as "inv0300". The other parts of the input file are either single lines composed of flags in capital letters followed by arguments on the same line; sections describing the molecule and the calculation, whose formats will be described later in this chapter; or comments.
The input file should have the following format, where "[ ... ]" symbols denote optional entries, and entries in italics represent a character string with no spaces:
The first three lines were all necessary in previous versions of Jaguar, but are no longer used or required, and the last six lines are only rarely used. Therefore, generally, your Jaguar input files will take a form as simple as
where only the zmat section, which contains the geometry and will be described later in this chapter, is actually required.
The .basis, .atomig (initial guess information), .daf (dealiasing functions), .grid, .cutoff, and .lewis data files are described in Chapter 9. If you want to use non-default choices for any of these files, you can specify their paths and names on the appropriate lines of the input file. If a file name listed in the input file ends with `.Z' (for example, "BASISFILE: erwin.basis.Z"), Jaguar will copy the file and uncompress it. You can specify a file on another host, or under another account name on that host, by listing the file name in the format <host>:<file path and name on host>, or <user>@<host>:<file path and name on host>.
The GPTSFILE line allows you to use grid points and weights from an input file for any one grid used during the calculation. The file should have a line for each grid point, and each line should list, in order, the x, y, and z Cartesian coordinates (in angstroms) and the weight for that grid point. Grid weights are only used in charge fitting, so if you don't want to use them, use a `0' as a placeholder. For information about how to use this grid in a Jaguar calculation, see the Grid and Dealiasing Function Keywords subsection of Section 8.6.
Comments in the input file are ignored by Jaguar. If an input file was produced using the interface, text entered in the box marked Comment in the Run or Save window generally appears on the fourth line of the input file. If the geometry was symmetrized, as described in Section , a comment indicating the point group to which it was symmetrized appears.
The rest of the input file is composed of named sections. The sections may appear in any order. Character case (upper or lower) is ignored; therefore, either case, or a combination of the two, may be used. Equals signs (`='), commas (`,'), blank spaces (` `), and tabs are all considered spacing characters; however, if you plan to use the interface at all, we suggest that you use equals signs between a keyword and its value, and avoid using them anywhere else. Blank lines, or multiple spacing characters in a row, are equivalent to a single spacing character and thus may be used to improve readability.
The gen section contains a list of the general keywords which control the calculation. Defaults are provided for all unspecified keywords. The other sections contain lists, such as atomic coordinates. The sections currently allowed are shown in Table 8.2.1.
Each section has a distinct format; the formats are described in detail in the rest of this chapter. Keywords in the gen section can have integer, real, or character string values. Generally, valid integer values are limited to a small set which differs for each keyword. Real values can optionally include a `d' or `e' floating point power of ten. Character string keyword values may be limited to a small set, as for a basis set description, or may allow a general string like a file name.
Each section is delineated by a pair of `&' or `$' characters. The section name follows immediately after the first `&' or `$'. Thus, for example, the general keyword section may begin with `&gen' or `$gen' and ends with `&' or `$'. Within the gen section, allowed keywords are followed by numerical arguments giving their values, whose meanings are explained in Section 8.6. At least one spacing character must precede and follow each keyword and each value. For example,
sets the iguess and molchg keywords of the gen section to 0 and 1, respectively. Sections may span multiple lines, and more than one section may appear in a line. However, a gen section keyword and its value must be on the same line. Note that the following example is interpreted in the same way as the gen section example given above:
The molecular geometry must be described in the zmat section. Details on inputting a geometry through the interface can be found in Section 2.2 and Section 2.4. The units for the geometry are set by the iunit keyword of the gen section; by default, these units are Angstroms and degrees.
If the geometry is in Cartesian coordinates, each line must contain four items: an atom name and the (x,y,z) coordinates. Each item should have at most 80 characters. The atomic label should begin with the one- or two-letter elemental symbol, in either uppercase or lowercase characters. Additional alphanumeric characters may be added, as long as the atomic symbol remains clear-for instance, "HE5" would be interpreted as helium atom "5", not hydrogen atom "E5". No more than four characters of the atomic label are kept. A sample Cartesian zmat section for a water molecule is:
A Zmatrix style zmat section should begin with the "&zmat" (or "$zmat") label and end with a & or $ character, should not include a line defining any variables (which are set in the zvar section described in Section 8.4), and should not contain any comment lines, but otherwise should have the same format described in Section 2.2 in the subsections ZMatrix Format for Geometry Input, Variables and Dummy Atoms in ZMatrix Input, and Constraining ZMatrix Bond Lengths or Angles. One additional, optional feature is also available from the input file: you can orient the molecule or system according to a label on the same line as the "&zmat" section label. This orientation label should begin with the word "orient," which is followed by an option in the form ab, ab, ab, or ab, where a and b are each either x, y, or z (for example, "&zmat orient xy"). Jaguar then assumes the first atom in the Zmatrix is at the origin, the second is along the a axis (in the negative direction for a), and the third atom is in the ab plane, in the quadrant determined by the positive or negative signs of a and b.
Zmatrix input is interpreted in the units specified by iunit. Section 2.2 also includes a description of how to specify bond length or angle constraints on the Zmatrix coordinates for geometry optimizations.
To perform counterpoise calculations, you can add counterpoise atoms, which have the usual basis functions for that element but include no nuclei or electrons, by placing an at sign (`@') after the appropriate atoms' labels. For example, to place sodium basis functions at the Cartesian coordinates (0.0, 0.0, 1.0), you could include the following line in a Cartesian input file:
You can also input counterpoise atoms for Zmatrix format geometries.
Finally, if you are optimizing a molecular structure to obtain a minimum-energy structure or a transition state, you may wish to refine the Hessian used for the job. (See section 4.3 for information on the methods used for transition state optimizations, including Hessian refinement.) If you put an asterisk (`*') after a coordinate value, Jaguar will compute the gradient of the energy both at the original geometry and at a geometry for which the asterisk-marked coordinate has been changed slightly, and will use the results to refine the initial Hessian to be used for the optimization. (To request refinement of a coordinate whose value is set using a variable, add an asterisk (`*') to the end of the variable setting in the zvar section line that defines the variables.) For instance, a job run with this zmat section:
that included Hessian refinement would use both O-H bonds and the H-O-H angle in the refinement.
Molecular symmetry or the use of variables, either of which may constrain several coordinate values to be equal to each other, can reduce the number of coordinates actually used for refinement. For instance, for the water input example shown above, only two coordinates will actually be refined (the O-H bond distance, which is the same for both bonds, and the H-O-H angle) if molecular symmetry is used for the job.
Certain types of transition state optimizations require that you enter two or three geometries (see section 4.3 for details). For these jobs, you can input the second and/or third geometries in the zvar2 and zvar3 sections. (Note that the order of atoms in the input must be the same as in the zmat section.) Alternatively, if the changing coordinates in the zmat section are set using variables, you can leave out the zmat2 and zmat3 sections and specify the second and third geometries by adding zvar2 and zvar3 sections, which will be used in combination with the zmat section to define the second and third geometries. See Section 8.4 for details.
The zvar section should contain a list of equations setting the values of any variables in the geometry input in the zmat section, in the same units used for the zmat section. Here is a sample zvar section:
For an optimization, to constrain (freeze) all bond lengths or angles set to a particular variable, you should add a `#' sign to the end of the zvar section equation setting that variable. Similarly, to request Hessian refinement of a coordinate whose value is determined by a variable setting in the zvar section, just add an asterisk (`*') to the end of the equation that sets the variable value in the zvar section.
would, if used in an optimization, freeze all ycoor values to be equal to 0.753108 during the job.
Certain types of transition state optimizations require that you enter two or three geometries (see section 4.3 for details). For these jobs, you can specify variables for the second and/or third geometries in the zvar2 and zvar3 sections. If no zmat2 or zmat3 sections exist, these variables are used in combination with the zmat section to define the second and third geometries.
For some geometry or transition state optimizations, you may want to specify that the optimizer use particular internal coordinates. For example, if you study a bond-forming reaction, you can require Jaguar to use the bond in question as an internal coordinate even when the bond distance is very long. You also may want to generate your own list of internal coordinates for cases that involve multiple separate (unbonded) fragments.
It is often useful to specify internal coordinates for pairs of atoms that are on separate sections of a large floppy molecule, but are close to being in van-der-Waals contact. Otherwise, small changes in a torsional coordinate far away from these atoms can then lead to steep changes in the energy. Adding explicit coordinates for these non-bonded contacts makes it possible for the optimization algorithm to control their approach more effectively.
To control the internal coordinates used in an optimization, you should first make sure that Jaguar is going to generate internal coordinates for the job. Optimization jobs generate and use redundant internal coordinates unless you have set the keyword intopt in the gen section of your input file. (See the subsection Geometry Optimization and Transition State Keywords in Section 8.6 for more details.)
To specify that particular bonds or angles should be included in the internal coordinates generated and used for an optimization, use a coord section. Each line of a coord section should contain a list of atoms used to specify a bond, bond angle, or torsional angle coordinate to be included among the internal coordinates generated by Jaguar. If you want to hold the coordinate fixed at its initial value throughout the job, add the entry `#' to the end of the line (after one or more spacing characters).
As an example, the coord section
requests that the set of internal coordinates include the C1-C2 bond, the C1-C2-C3 bond angle (which is to be held frozen throughout the optimization), and the C1-C2-C3-C4 torsion.
Alternatively, you can use a connect section to specify the bonds used by Jaguar in its generation of internal coordinates. Each line of a connect section should list two atoms by either their atom labels (such as `H2' for a hydrogen) or their atom numbers (such as `3' for the third atom listed in the zmat section input). Here is a sample connect section:
The two atoms on each line of the connect section are then treated as nearest neighbors by the program when it generates redundant internal coordinates for the optimization. Consequently, the internal coordinates generated by Jaguar include the bond between those two atoms and angles between those two atoms and any other atoms that are nearest neighbors to either of them. For the sample connect section above, for instance, the redundant internal coordinates would include the C1-C2 bond, the C2-C3 bond, and the C1-C2-C3 angle in addition to whatever internal coordinates would be generated without the connect section.
The keywords of the gen section allow control over how the calculation is performed. Many of these keywords can be set from the interface. See Chapters 3 and 5 for details.
Throughout this section, the default values for keywords are indicated in bold italics. The keywords for geometry input are described first, followed by those relating to correlation methods, optimization to a minimum-energy structure or transition state, calculations in solution, calculation of various molecular properties, basis sets, SCF methods, and output. These subsections correspond to the order of information in Chapters 3 and 5. Finally, keywords relating to grids and dealiasing functions, cutoff parameters, and memory usage are described.
The keywords iunit and covfac help determine how the geometry input from the zmat section will be interpreted. The iunit keyword, whose default value is 1, describes what units the geometry is assumed to have, as indicated in Table 8.6.1.
The real-valued keyword covfac determines which atoms are considered to be bonded. Two atoms are bonded if they are closer to each other than covfac times the sum of their covalent radii. The default value for this variable is 1.2.
The keywords that describe the input molecule's charge and spin multiplicity are shown in
Table 8.6.4. These keywords correspond to interface options described in Section 2.3.
The keyword massav determines the atomic masses used for any atoms whose masses or isotopes are not specifically set in the atomic section (see Section 8.9). The masses used are from ref. [100].
By default, for most calculations, Jaguar takes advantage molecular symmetry to reduce computing time, as described in Section . Several integer-valued keywords shown in Table 8.6.4
describe how the program uses symmetry. Default values for these keywords are shown in bold italics.
The ihfgvb keyword allows you to specify the initial guess to be used for a generalized valence bond (GVB) calculation. By default, ihfgvb is set to 0. The ihfgvb keyword is described in this section under Initial Guess Keywords.
GVB pairs are set in the gvb section, where pairs to be used in an RCI (restricted configuration interaction) calculation are also specified, and a GVB calculation will be performed any time one or more GVB pairs are described in the input file.
You can find Lewis dot structures by setting the appropriate keywords, and you can also use one of these structures to set GVB pairs automatically. The appropriate keywords are listed in Table 8.6.5
with their default values indicated in bold italics.
The Lewis dot structure code finds several alternative Lewis dot structures for resonant molecules, assigning bonds as single, double, or triple bonds unambiguously. (For instance, it finds two structures for benzene, depending on the assignment of the pi bonds.) For these cases, you may wish to run Jaguar with lewdot = -1 and lewstr = 0, which will cause it to print out all Lewis dot structures it finds, then exit. At that point, you can figure out which structure you want to use to set the GVB pairs, set lewstr, igvball, and igvbsel accordingly, and set lewdot = 1.
If you know there is only one reasonable Lewis dot structure for the molecule, you can simply set igvball and igvbsel. At that point, lewdot and lewstr will be set to 1 by default.
The values for igvbsel are easier to remember if you associate the number 1 with sigma pairs, 2 with pi pairs, and 4 with GVB lone pairs. Then, to print out any combination of these pair types, you set igvbsel to equal the sum of the numbers associated with the pair types you wish to print.
The mp2 keyword allows you to request a local Møller-Plesset perturbation theory (LMP2) calculation. By default, LMP2 is off (mp2 = 0). For more information on the local MP2 method, see Section 3.2 and section 7.4
Please note that Jaguar LMP2 calculations require a basis set that allows the pseudospectral method to be used. See Table 3.8.1 and Table 3.8.2 in Section 3.8 to obtain this basis set information.
Local MP2 calculations use the LMP2 method for all atoms unless the lmp2 section described in Section 8.8 is used to set local LMP2 pairs or unless the keyword iheter is set to 1. The iheter and mp2 keyword settings are described in Table 8.6.6.
For LMP2 calculations, Jaguar needs to obtain localized orbitals. By default, Jaguar uses the Pipek-Mezey method to perform the localization. If Pipek-Mezey localization does not converge for a particular case, you may wish to try Boys localization by changing the settings for the keywords loclmp2c and loclmp2v, as indicated in Table 8.6.6. If you are performing a set of calculations to compare against each other, you should use the same localization method for all of the calculations.
To use density functional theory (DFT) for single point energies, geometry optimizations, or calculations of various other properties, you should set the idft keyword. If you wish to evaluate the (non-self-consistent) energy of the final, post-SCF wavefunction using a particular set of functionals, you can use the jdft keyword. Most DFT options described here are also available from the interface, as described in Section 3.1. For information on setting the keywords associated with grids for DFT calculations, please see the Grid and Dealiasing Function Keywords subsection near the end of this section.
Positive values of idft describe both the exchange and correlation functionals, if any. The value of idft can be broken down in the form idft = 10000*i + 1000*j + 100*k + 10*l + m, or idft = ijklm, where the values of j, k, l, and m determine the exchange and correlation functionals and i specifies particular coefficients for the functionals. The functionals themselves are determined as described in Table 8.6.7
through
Table 8.6.10.
For instance, if idft = 1301, the DFT calculation employs the Slater local exchange functional and the Perdew-Zunger local correlation functional with Perdew's 1986 non-local correlation functional. A typical local density approximation (LDA) calculation could use idft = 101, while idft = 2011 sets a popular NLDA choice typically called BLYP. If you specify the Lee-Yang-Parr functional, which contains local and non-local terms, you may not specify a local correlation functional (i.e. if j = 2, k must be 0) unless you are using the Becke 3 parameter hybrid method, as described below.
If the value of i within idft is 1 or 2, the functionals given by j, k, l, and m are combined using coefficients determined by the appropriate hybrid method, as indicated in Table 8.6.11.
For the half & half hybrids, half of the exact exchange is automatically included with half of the selected exchange functional. The coefficient of any local correlation functional or non-local exchange or correlation functional is also set to 0.5. You must specify a Slater or Xa local exchange functional for a half & half hybrid, and if you use the Lee-Yang-Parr functional, you may not specify a local correlation functional.
For Becke 3 parameter hybrids, you need to specify a Slater or Xa local exchange functional, a non-local exchange functional, a local correlation functional, and a non-local correlation functional (i.e. j, k, l, and m must all be non-zero if i is 2). Even when you use the Lee-Yang-Parr functional in a Becke 3 parameter hybrid, you must list a purely local correlation functional, which will be used to adjust the local correlation contribution. For Becke 3 parameter hybrids that do not include the Lee-Yang-Parr functional, the coefficients of the exact HF exchange and of the local exchange, non-local exchange, local correlation, and non-local correlation functionals are 0.2, 0.8, 0.72, 1.0, and 0.81, respectively. If the Lee-Yang-Parr functional is used in a Becke 3 parameter hybrid, its coefficient is 0.81, and the coefficient of the local correlation functional used is 0.19.
If idft = -1, the values of the keywords xhf, xexl1, xexl9, xexnl1, and xexnl4 determine the contributions of the exact exchange and various exchange functionals, while the keywords xcorl1, xcorl2, xcorl3, xcorl4, xcornl1, xcornl2, and xcornl4 control the contributions of the correlation functionals, as listed in Table 8.6.12.
For example, with the keyword settings idft = -1, xhf = 0.332, xexl1 = 0.575, and xcorl1 = 0.575, and with all other xex and xcor keywords set to zero, the exchange is treated with a combination of the exact exchange and the Slater local functional, while the correlation functional is pure VWN.
Finally, if you wish to evaluate the energy of the final, post-SCF wavefunction using a particular functional or combination of functionals, you should use the keyword jdft. This keyword can take on the same values as idft, and the meanings for each value are the same as those described above for idft. If jdft = -1, you can set up a customized functional using the keywords yhf, yexl1, yexl9, yexnl1, yexnl4, ycorl1, ycorl2, ycorl3, ycorl4, ycornl1, ycornl2, and ycornl4, which correspond to the keywords in Table 8.6.12 (e.g. xexl1). If you do a post-SCF DFT energy evaluation, you should not perform a geometry optimization or calculate the solvation energy, polarizability, or any other properties.
For any DFT job, the Methods keyword vshift is set to 0.2 (for hybrid methods) or 0.3 (for non-hybrid methods) by default, and the Methods keyword idenavg is set to 1 by default, in order to help convergence.
More complete descriptions and references for each DFT functional and hybrid are given in Section 3.1.
Many of the keyword settings for optimization of minimum-energy structures and transition states described in this subsection can be made from the interface, as described in Chapter 4, which also contains more details about the methods used for optimizations.
Table 8.6.13 contains optimization keywords that take on integer values. Most default values for these integer keywords are indicated in bold italics, and only the values listed in the table are allowed. In cases where the default is different for optimizations to minimum-energy structures than it is for transition state optimizations, both defaults are in bold italics, and the cases for which each is a default are explained in the keyword description.
Several real-valued keywords also control optimizations. These keywords are listed in Table 8.6.14 and Table 8.6.15. Note that all keyword values must be greater than or equal to zero.
The real-valued keywords shown in Table 8.6.15 may be used to specify the geometry convergence criteria, or these criteria may be scaled to five times their default values with the keyword setting iaccg = 3 for a quicker, coarser calculation. The first four real-valued keywords listed in Table 8.6.15 have units of Hartrees/bohr, gconv5 and gconv6 have units of bohr, and gconv7 has units of Hartrees.
Please note also that SCF calculations performed for each new structure generated during an optimization are judged to be converged when they meet the criterion for the root mean square of the change in density matrix elements, which is controlled by the keyword dconv; the usual SCF energy convergence criterion (econv) is ignored for optimizations.
Most of the solvation keywords correspond to interface options described in Section 3.5. The allowed values for the integer solvation keywords are described in Table 8.6.16.
Defaults for these keywords are not indicated in bold italics, since the keywords' default values generally depend on other keywords. (By default, Jaguar calculations are performed in the gas phase, so isolv = 0 and all other solvation keywords are irrelevant.)
The real-valued parameters for solvation calculations, which are shown in Table 8.6.17, help describe the solvent and the solute. Section 3.5 contains more details on these parameters. The default values for these parameters correspond to water.
For solvated geometry optimizations, the trust keyword, which is described under Geometry Optimization and Transition State Keywords in this section, takes on a default value of 0.1 instead of its usual default of 0.3.
Various keywords are used to request calculation of molecular properties, including multipole moments and charge fitting properties. Most of the keywords listed in Table 8.6.18 correspond to interface options described in Section 3.6. The default for each integer keyword is indicated in bold italics, and only the values listed in the table are allowed.
The finite field methods corresponding to ipolar > 0 differ in the data they use for numerical differentiation. The 3-point method uses the results from seven SCF calculations: one with no field, one with a field of E (whose input is described below) in the x direction, one with a field of -E in the x direction, and four others with fields of +E and -E, respectively, in the y and z directions, respectively. The 5-point method uses the same data as the 3-point method, as well as data from SCF calculations using fields of +aE and -aE, respectively, in the x, y, and z directions, respectively, where a is some constant. Similarly, the 7-point method uses the same data as the 3-point method, plus data obtained using fields of +aE, -aE, +bE, and -bE in the x, y, and z directions, where a and b are some constants.
All polarizability methods are run with symmetry off-that is, the keyword isymm will be set to 0 automatically if ipolar 0. Similarly, for any polarizability calculation, the Methods keyword econv, which gives the energy convergence criterion, is set by default to 1.0 x 106 (although if the calculation first satisfies the criterion dictated by the Methods keyword dconv, the energy convergence criterion is ignored).
The keywords cfiterr, wispc, denspc, and efield, which are listed in Table 8.6.19, take on real values. When charge fitting is constrained to reproduce multipole moments (that is, when incdip > 0), the keyword cfiterr determines whether the multipole moment constraint is too restrictive to produce adequate charges: if the error in the total resultant charges is more than cfiterr, the charge fitting is rerun with a lower multipole moment constraint. The keyword wispc is used to set the spacing of the rectangular grid for ESP fitting when the grid keyword gcharge = -2. Similarly, the keyword denspc is used to set the spacing of the electron density rectangular grid when ldens = 1 and the grid keyword geldens = -3. The efield keyword allows you to input an electric field for finite field polarizability and hyperpolarizability calculations, as described earlier in this subsection. Its default value shown in Table 8.6.19 applies to all cases when ipolar > 1. For ipolar = 1 (3-point, polarizability-only calculations), efield's default value is 0.006 A.U.
If you want to print out the electrostatic potential at gridpoints which you specify, add the keyword settings gcharge=-6 and ip172=2 to the gen section of your input file. The gcharge=-6 setting causes Jaguar to use the gridpoints and weighting factors in a file whose name and location are specified by the GPTSFILE line in the input file (see Section 8.2). The ip172=2 setting causes Jaguar to write out a file with the name <jobname>.resp containing the ESP data (see the text under Table 8.6.27).
For jobs that include a calculation of vibrational frequencies, various frequency-related properties can also be computed by setting the appropriate keywords. Most of these keywords, which are listed in Table 8.6.20, correspond to interface options described in Section 3.7. Keyword values in bold italics are the default values, and only the values listed in the table are allowed.
The thermochemical properties are listed in cal/mol K and kcal/mol by default. Use the output option ip28 = 2 for output in J/mol K and kJ/mol.
The character string keyword basis allows you to override the default basis set (631G**). This keyword should be a string describing the standard basis and any desired polarization and diffuse functions. The string describing the standard basis should be chosen from the first column of Table 3.8.1 or Table 3.8.2 in Section 3.8. Lowercase or uppercase letters can be used. The polarization and diffuse function options are described by adding *, **, +, or ++ immediately after the basis name. The meaning of these symbols is also described in Section 3.8. Neither polarization nor diffuse functions are used if none of these options are specified. The tables in Section 3.8 list the basis sets and indicate which options and atoms Jaguar currently accepts for each.
The other keyword relating to the basis set, numd, allows you to choose whether to use five or six d functions in each d shell. If you do not set numd explicitly, the number of d functions is set automatically, depending on the basis set, as described in Section 3.8. Possible settings for numd are shown in Table 8.6.21.
Many of the keywords which control the SCF calculation can be set from the Methods window in the interface, as described in Section 3.9. (The other keyword settings corresponding to Methods window settings are described under Initial Guess Keywords and Localization Keywords in this section.)
The two real-valued convergence criterion keywords are econv, the energy convergence criterion, which dictates the maximum difference in energy between one SCF iteration and the next for convergence to be assumed, and dconv, the criterion for the root mean square of the change in density matrix elements. The default value of econv is normally 5.0 x 105 Hartrees. However, for polarizability or hyperpolarizability calculations, econv is 1.0 x 106 Hartrees by default. When the root mean squared change in density matrix elements for a polarizability, hyperpolarizability, or geometry optimization calculation is less than dconv, whose default value is 5.0 x 106, the calculation is considered to have converged.
By default, calculations use a DIIS (or GVB-DIIS) convergence scheme, meaning that every iteration, an estimate of the Fock matrix is produced which is a linear combination of previous Fock matrices, including the one calculated during that iteration. The keyword maxdiis, which has a value of 10 by default, indicates the maximum number of previous Fock matrices that will be used for this scheme during any iteration. The keyword stdiis gives an error criterion; DIIS is started when the largest value of the DIIS error vector is less than the value of stdiis, whose units are hartrees. For standard Hartree-Fock, DFT, LMP2, or GVB-LMP2 calculations, stdiis is 2.0 by default; for GVB calculations (when iconv, listed in Table 8.6.22, is 3 or 4), stdiis is 1.0 by default; and for cases involving transition metals or open shell calculations, or when the initial guess is obtained from the one-electron Hamiltonian (iguess = 0; see the subsection Initial Guess Keywords), its default value is 0.1. In general, after GVB-DIIS starts, any density matrix averaging requested by the keywords iteravg and istavg (explained in Table 8.6.22) will be turned off.
The last real-valued methods keyword, vshift, describes the amount the virtual orbitals' energies are increased before diagonalization, in atomic units. This keyword can be used to reduce mixing of the real and virtual orbitals, which sometimes helps convergence. By default, vshift is zero, except for DFT calculations, when the default is 0.2 (for hybrid methods) or 0.3 (for non-hybrid methods). Non-default values should probably be on the order of 0.1-0.5.
The other integer SCF keywords are described in Table 8.6.22. As usual, the default values are in bold italics.
Note, however, that the keyword settings for convergence are somewhat complicated, and the defaults vary somewhat depending upon the settings of other keywords.
One of the most important keywords in controlling the SCF is iacscf. This keyword should be employed when the SCF fails to converge under the default conditions, especially for transition metal-containing systems or clusters. Start with iacscf = 1 and if that does not work then try iacscf = 4. iacscf = 2 was developed especially for hemes and related molecules, while iacscf = 3 was effective for graphitic systems. Energies obtained with iacscf = 2 can be directly compared to energies obtained without using iacscf. Energies obtained using other values of iacscf are not comparable because they use different grids or cutoffs.
Table 8.6.23 lists the keywords related to the initial guess and the meaning of the integer values each keyword can take on. Most of the keyword values in