| |
|
|
|
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
Table 8.6.23 correspond to interface options described in Section 3.9. Default choices are indicated in bold italics.
For any Jaguar job, the final wavefunction can be localized after it is computed. (Localization can also be used to provide localized orbitals for the LMP2 method; see LMP2 Keywords in this section for details.) The keywords in Table 8.6.24 describe the available options for final wavefunction localization. See Final Localization of the Orbitals in Section 3.9 for a description of the localization methods and the interface settings related to localization.
When the keyword ixtrboy described in Table 8.6.24 is set to 1, an additional procedure is added on to the Boys localization process. Because the Boys orbitals may be unphysical for multiple bonds, since they create multiple "banana" bonds between pairs of atoms rather than forming sigma-like, pi-like, and related orbitals, the Boys orbitals for multiple bonds may be diagonalized using the one-electron Hamiltonians. The output for this procedure begins with a table of the Mulliken populations for each orbital on each atom, which reveals multiple bonds, as described in the following table. Every "bond pair space" made up of all orbitals with significant Mulliken populations on the same pair of atoms is diagonalized, and the output indicates the number of these bond pair spaces found and the ordering of the new orbitals by their one-electron Hamiltonian values. If you choose to print out Boys orbitals by setting the print keyword ip107 to 2, it is these final orbitals which are printed.
You can call the program Babel [24] from Jaguar to generate output in any of a variety of formats, although the files produced by Babel will contain only geometries, omitting any calculation settings. The output can be generated at the end of each iteration in a geometry optimization or at the end of any job. To generate such an output file, you must first know the extension that corresponds to the appropriate file type (for instance, "spar" for Spartan). The extensions and file types supported are shown in Table 8.6.25.
If you want to generate an output file in a particular format only at the end of a job, you should use a keyword setting of the form babel = outext, where outext is one of the possible output extensions listed in Table 8.6.25. You can set babel more than once (using separate babel = outext assignments) if you want to generate several files.
To generate output files at the end of all iterations in a minimum-energy structure or transition state optimization as the optimization proceeds, set the babelg keyword to the appropriate output extension string or strings. Like the babel keyword, the babelg keyword can be set more than once to generate files in several formats.
As files are generated with Babel during Jaguar runs, they are immediately copied back to the relevant output directory. Files generated from jobs with babel keyword settings have names of the form jobname.outext (for instance, "h2o.spar"), where jobname is the usual job name and outext is an output extension, as described above; files generated from geometry optimizations with babelg settings have names of the form jobname#.outext, where # is a four-digit number corresponding to the iteration number (for example, 0001 for the first geometry iteration), and all letters in the job name are converted to lower case by Babel. Note that you can use a babelg keyword setting to output structures generated during an optimization as the optimization proceeds.
For either babel or babelg keyword settings, you can use an optional extra extension for the file name by setting babel (or babelg) to a keyword in the form outext.opt, where opt is any extension you wish to use. For instance, if you made the setting babel = g.g92 in a Jaguar input file called h2o.in, the resulting job would create a Gaussian input file called h2o.g.g92.
The keywords listed in Table 8.6.26 are the standard printout options. They are all set to 1 by default, and the result is that none of the information that the keywords access is output. Many of the printout options can be turned on from the interface, as described in section 5.4.
The keyword setting ip6=3 provides much more detailed timing information that the setting ip6=2. Similarly, the keyword setting ip192=3 provides more detailed output than ip192=2; the ip192=3 setting includes the hessian.
The keyword setting kesep=1, which is normally part of a solvation calculation (see Table 8.6.16), will cause the virial ratio, -V/T, to be printed out at the end of each SCF.
The files output keywords are the printout options which cause files other than the usual log and output files to be created. All but one of these keywords are set to 1 by default, generally indicating that ordinarily none of this information is output.
The files output keyword ip151 controls whether or not a Jaguar restart file is written. It is the only files output keyword whose default value of 1 indicates that it is on. When ip151 is set to 1, the file restart.in is created in the temp directory for the job at the end of the last completed Jaguar program, writing over any previously generated restart.in file for the job. The restart.in file contains the results from the run, including the new geometry if the run that produced it was a geometry optimization. This input file can therefore be used to restart the calculation. At the end of the job, the restart input file is copied to your local job directory (under the name <jobname>.01.in, unless that file already exists, otherwise <jobname>.02.in or <jobname>.03.in, and so on). To turn off ip151, you must set it to 0.
The other files output keywords control whether files for various other programs such as GAMESS are written out during a Jaguar job. The effect of setting each of these keywords to 2 is shown in Table 8.6.27. Many of these printout options can be turned on from the interface, as described in section 5.5.
Additional settings are available for ip160 and ip165. When ip165 is 3, the SPARTAN 4.0 archive file is written to the local job directory as jobname.arc. When ip160 equals 3, an initial guess is included in the .g92 file generated by the run (by default, .g92 files generated for GVB calculations include initial guesses, but those for other calculations do not). If SCF iterations are performed, the initial guess for the .g92 file will be obtained from the resulting wavefunction; otherwise, it will be generated from the appropriate Jaguar initial guess routine. When ip160 equals 5, the basis set is included explicitly within the .g92 file, rather than just the basis set name. When it equals 4, the trial wavefunction and the basis set are included.
The format of the .resp file created with the ip172 keyword is as follows. The first line contains the number atoms in the molecule and the number of gridpoints at which the ESP was evaluated, respectively. Then the cartesian coordinates of the atoms, in bohrs, are given. Each of the remaining lines contains the ESP (in hartrees), the coordinates of the gridpoint (in bohrs) at which the ESP was evaluated, and, if ip172=3, the grid weights.
The information in Table 8.6.28 concerns output which can be printed out every SCF iteration if the keyword is set to 2. section 5.6 describes how to turn on these settings from the interface. Once again, setting these keywords to 1 generally indicates that the information will not be printed.
The option ip152 is the only one whose default value of 1 indicates that it is on. When ip152 is set to 1, the file restart.in is created in the temp directory for the job at the end of the last completed iteration (overwriting the restart.in file created from the previous iteration). This input file can then be used to restart the calculation. To turn off ip152, you must set it to 0.
Orbital information can be printed out as well. The orbital keywords determine what orbitals are printed in the output, at what stage they are printed, and the format in which the orbital output appears.
The keyword ipvirt determines how many of the virtual orbitals are printed in the output file and in the restart (new input) file. Virtual orbitals are printed in order of increasing energy. The virtual orbitals are obtained by diagonalizing
, where f is the occupation of each orbital (1 for a closed shell). If ipvirt = -1, all virtual orbitals are printed in the output and restart files; otherwise, ipvirt virtual orbitals are printed (if that many virtual orbitals exist). By default, ipvirt = 10.
Several possible formats and levels of information can be requested for each other keyword determining the orbitals printed. The choice of keywords, which are listed in Table 8.6.29, determines the stage (or stages) at which orbitals are printed;
the keyword values determine which orbitals are printed and the format of the printing. These settings can generally also be made from the interface, as described in section 5.7.
Table 8.6.30 explains the possible values for the orbital output options, aside from 1, the default, which turns off printing. The variable n in the table can be either 0, 5, or 10. If it is 0, all occupied orbitals, including GVB natural orbitals, are printed. If n is 5, all occupied orbitals and ipvirt virtual orbitals are printed (or all virtuals if ipvirt = -1). Setting n to 10 causes only the GVB non-orthogonal orbitals to be printed.
For example, `ip106 = 10' would mean that all orbitals were to be printed in FORTRAN f8.5 format after the GVB initial guess was created. The options ip105 12 are not valid; use ip100 instead. In canonical orbital space, the atom and function type labels are meaningless. If a keyword is set to 4, 5, 9, or 10, the results are suitable for input in the guess section or for input to Gaussian (guess=cards) or GVB2P5.
When the orbital output is in table form, each function's coefficient for each orbital is shown, with the functions shown in numbered rows and the orbitals in numbered columns. When it is in list form, each orbital is listed in turn, with the function coefficients listed in order. When ipx = 2 + n, only coefficients larger than a particular value (generally .05) are listed, and the atom identifiers (for instance, h2) and function types (for instance, S for s, Z for pz, or XX for dxx) are shown. When ipx = 4 + n or ipx = 5 + n, all coefficients are listed, in order but without numbering.
For examples of the output that shows up in the output file for a calculation of water with a 631G** basis set for various values of ip104, see the five examples given at the end of section 5.7. The five examples correspond to ip104 = 2, ip104 = 3, ip104 = 4, ip104 = 5, and ip104 = 6, in that order. Only the first two occupied orbitals are shown in each case, and not all functions are shown; those gaps are indicated by [...].
The grid and dealiasing function keywords allow the user to select from among the various sets of grids and dealiasing functions available in the grid and dealiasing (.grid and .daf) input files, which are described in section 9.3 and section 9.4, and from the grids generated within Jaguar. These keywords are used to specify which grid or dealiasing sets correspond to particular descriptions; this correspondence is often indicated by keyword values depending on the order of sets in the grid and dealiasing input files.
For density functional theory calculations, the grid keywords gdftmed, gdftfine, and gdftgrad determine the point density for the DFT grids used for the SCF and gradient calculations, respectively. If these keywords are set to -10, -11, and -12, respectively, the standard, default grid is used. A value of -13 corresponds to a finer grid.
Table 8.6.31 shows the types of grids that can be specified for portions of the calculation that do not involve density functional theory. Generally, these grid types are used for pseudospectral SCF iterations or for charge fitting.
The grid-related keywords and their allowed and default values are described in Table 8.6.32, where name corresponds to one of the grid types listed in Table 8.6.31.
As an example, `gmedium = 2' indicates that the medium grid to be used for the calculation is the second one listed in the .grid file, while `geldens = -3' indicates that an electron density calculation should use a cubic grid.
You can input your own set of grid points and weights by using the gname = -6 option and the GPTSFILE line of the input file, which is described in Section 8.2.
Some of the memory usage for the program can be controlled through keywords. These keywords may be particularly useful if you are experiencing problems running jobs due to memory-related failures, as described in the troubleshooting information in section 10.3.
Memory usage keywords are listed in Table 8.6.33, along with their default values and a description of their uses.
Users who want to change some memory usage but who do not have a detailed knowledge of the code should probably not change the variables mxpr or mxrwr.
Finally, the iq keywords allow you to choose when to compute the full least-squares fitting matrix Q from the smaller matrix
and whether to store it on disk. Names and default values (in bold italics) for these keywords are indicated in Table 8.6.34.
If a grid is used only once per calculation, as the fine, ultrafine and gradient grids generally are, setting its iqname value to 0 saves disk space and costs no cpu time. Setting the iqname values for other grids to 0 will add some cpu cost, but will save some disk space.
The gvb section, whose interface equivalent is described in Section 3.3, is not keyword based. The section should contain the pair settings, in any order, unless you are using the Lewis dot structure keywords described in the GVB and Lewis Dot Structure Keywords subsection of Section 8.6. Each line describing a bond pair should contain three integers, which specify the type of bond (1 for sigma, 2 for pi, 3 for a second pi in a triple bond) and the atom number labels of the two atoms in the GVB pair. Each line describing a lone pair should contain a number identifying the lone pair, followed by the number or atom label of the atom associated with the lone pair, and the same atom number or label repeated once more. Either all or none of the lone pairs on an atom should be specified as GVB lone pairs, and these GVB lone pairs should be identified by consecutive numbers starting with 101. Thus, if the molecule had one lone pair on atom 2 and two on atom 5, the lines describing them would contain the numbers `101 2 2,' `101 5 5,' and `102 5 5,' respectively.
Three more entries may be added onto the ends of all of the lines specifying the pairs; these entries will show up in new input files generated during or after calculations. The first value, if it is present, is either 0 or 1, where a 1 entry indicates that a restricted configuration interaction (RCI) calculation including that pair will be performed. (By default, the pair will not be included in an RCI calculation.) The next two values, if they exist, indicate the CI coefficients for the first and second GVB natural orbitals in each pair. The first coefficient should always be positive, and its magnitude should always be greater than that of the second coefficient, which should always be negative. These coefficients are included in new input files so that if you restart the calculation with the new input file, the contributions of each GVB natural orbital will be known.
The sample gvb section which follows sets a sigma bond pair with RCI on between atom 1 and atom 2 and two lone pairs on atom 1.
The lmp2 section, whose interface equivalent is described in Section 3.2, is not keyword based. The section should contain a line for each atom pair describing atoms to be treated at the LMP2 level. Each line describing an LMP2 pair should begin with two atom numbers of labels, which specify the two atoms in the pair. Pairs can be listed in any order.
The sample lmp2 section which follows instructs Jaguar to treat the atoms listed sixth, ninth, and tenth in the zmat section at the LMP2 level and all other atoms at the Hartree-Fock level. Atom 9 is bonded to atoms 6 and 10.
You can also use the lmp2 section of the Jaguar input file to list particular LMP2 pairs and request that they be delocalized over listed atoms. With LMP2 delocalization, the space of correlating virtual orbitals for an LMP2 occupied orbital is extended to include orbitals on nearby atoms.
To delocalize a bond pair on two particular atoms over a space including orbitals on a set of other atoms, add a line to the lmp2 section listing the atom labels or numbers of the two atoms upon which the bond pair is located by default, followed by the atom numbers or labels of any atoms over which the pair is to be delocalized. Next, set the keyword idelocv in the gen section to 1 (if you want to treat all LMP2 pairs in the system) or 2 (if you want to perform a "local local" MP2 calculation with only the pairs listed in the lmp2 section treated at the LMP2 level). For example, the following gen and lmp2 sections request a local local MP2 calculation with the C2-C3 bond pair delocalized over C1 and C4 (as well as over C2 and C3):
For QST-guided transition state searches with LMP2 wavefunctions, LMP2 delocalization will automatically be performed over neighboring atoms for any bonds present in one structure and not in another, unless the input file contains the gen section keyword setting idelocv = 0.
The atomic section allows you to specify different calculation properties for different atoms in a molecule. These properties can include basis sets for each individual atom, or atomic masses, a feature that allows isotope calculations. You can also use the atomic section to define groups of atoms called "fragments," where each fragment can then be converted to dummy atoms or counterpoise atoms or used to define a part of the system for which you want to compute a numerical Hessian. Restart files may include atomic sections as well, in order to keep information about charge fitting or other properties calculated previously.
In addition, atomic sections can be used to supply information about transition-metal-containing systems that can then be used to generate high-quality initial guesses for these systems. See Organometallics and Other Difficult-to-Converge Systems in section 6.3 for more information on using atomic sections in this manner.
After the `&atomic' (or `$atomic') line, the atomic section should list sets of atomic input values. Each of these sets consists of a list of input types (which could include, for example, the atomic keywords for atomic masses and for van der Waals radii for solvation calculations) and lists of corresponding values for these input types for each relevant atom. For instance, in the following atomic section:
the input types are atom (indicating the atom label or number), mass (indicating the nuclear mass in amu), and vdw2 (indicating the van der Waals radii for a solvation calculation), and the lines for the atoms H1 and H2 indicate that these atoms have a nuclear mass of 2.00 amu (deuterium) and van der Waals radii of 1.2 Å for solvation purposes, while the line for atom O indicates a solvation van der Waals radius of 1.55 Å for this atom. It is not necessary to list information for atoms which are to be treated in the usual, default manner. Input type labels are case insensitive (for example, "MASS" and "mass" are interpreted the same way), and input types can be listed in any order in an input type list. All entries in a row should be separated by one or more spaces or tabs, but columns do not need to be lined up precisely.
The input type atom must be included in every set of atomic input values. The corresponding atom identifiers in the lists following each input type list can be either atom labels (such as "H1" or "O" in the example above) or atom numbers (such as "2" for the second atom listed in the zmat input). Atom label input is case sensitive.
If an input type from the input type list above an atom's description is not one you want to set for that atom, you may use a "?" or "-" to indicate that the default value should be used. Alternatively, if the last input type or types in the input type list are not relevant for that atom, you may leave the end of the line blank. For instance, either the section
has the same result as the first atomic section example listed above.
Atoms may be described in more than one set of atomic input values, but if data for the same input type is entered twice for the same atom, the first value will be ignored.
To print an atomic section in the job's restart file that contains information for all atoms, not just some, set the output keyword ip29 to 2. If an atomic section exists or if ip29 = 2 in a job's input file, the atomic section will be echoed in the output from the program pre.
The atomic input types that specify physical properties of atoms are listed and defined in Table 8.9.1. Values for these input types may appear in restart files.
The formal column is useful for solvation jobs (because the van der Waals radii are adjusted according to the chemical structure found by Jaguar) and for generating an improved initial guess for transition-metal-containing systems (along with the multip column). Please see the subsection Organometallics and Other Difficult-to-Converge Systems in section 6.3 for more information on using this improved initial guess method.
The esp column can be used to tell Jaguar to freeze the charge on an atom to a particular value while fitting charges to other atoms, leave an atom out of charge fitting, or fit a charge to a dummy atom. If the esp column entry for an atom is set to a real number, the atomic charge for that atom will be held fixed to that number during charge fitting. If the esp column entry for an atom is set to "n" or "no" (or 0, of course), the atom will not be included in charge fitting. If the esp column entry for a dummy atom is "y" or "yes", it will be included in the charge fit.
Several warnings apply to the use of the esp column. First, the esp settings must not be inconsistent with the symmetry used for the rest of the job. Second, you should be careful not to overconstrain the charge fitting job. Third, if you are including any dummy atoms in the charge fitting, it may be advisable to perform the charge fitting in a separate job (based on the restart file), for which the charge fitting grid has been altered to include points around the dummy atom(s) by including a grid column in the atomic section, with "y" or "yes" entries for the dummy atoms, as described below.
The basis input type allows you to specify the basis sets used to treat particular atoms. The string provided to describe the basis set should be chosen from the first column of the table in Section 3.8. Lowercase or uppercase letters can be used. Polarization and diffuse functions can be added by appending *, **, +, or ++ immediately after the basis name. The meaning of these symbols is also described in Section 3.8.
Please note that if you use an atomic section to specify a different basis set (or sets) for one or more atoms than the basis set used for the other atom(s) in the input, you should not change any basis set assignments if you later restart that job. For instance, if you ran a job whose input file, mixmol.in, contained an atomic section that specified different basis sets for different atoms, you could generate a new input file (restart file) called mixmol.01.in from the job, but if you used this input file for a second job (restarting the old calculation), you would not be able to change the atomic section at all; otherwise, the program would misinterpret the initial guess specified in mixmol.01.in's guess section. (Alternatively, you could delete the guess section completely and then change the atomic section however you wanted.)
Three other input types shown in Table 8.9.2 allow you to specify whether to include grid points, dealiasing functions, or nuclear charges for listed atoms. The input values "n", "no", "none", and "only" are not case sensitive. Note that you can use the atomic section to specify counterpoise atoms, and that settings in the atomic section take precedence over Zmatrix counterpoise input. In the atomic section, counterpoise atoms are indicated by using an entry of "n" in the column entitled "charge" (see Table 8.9.2). Also, note that any other word or letter, such as the "Y" entries that may appear in restart files, indicates that the grid, dealiasing function, or charged particles for that atom are included (the usual default for the grid, daf, and charge input types).
You can use the frag input type in the atomic section to specify that all atoms with the same frag entry be treated in the same fragment. You can then request that all the atoms in one fragment be treated as dummy atoms or counterpoise atoms, or used as the only atoms for which numerical frequencies will be calculated (where Hessian elements for other atoms are zero).
The default frag value for each atom is 0, meaning it is not considered part of any fragment. To assign a group of atoms to the same fragment, in the frag column of the atomic section, enter the same value for each atom.
To treat all atoms in a fragment as counterpoise atoms, make the keyword setting icpfrag = fragno in the gen section of the input file, where fragno is the integer in the frag column of the atomic section for each of the atoms in question. To treat them all as dummy atoms, make the keyword setting idelfrag = fragno in the gen section. To compute partial frequencies for a particular fragment, make the setting freqfrag = fragno in the gen section of a frequency input file.
If an input file has a non-empty hess section, the keyword inhess in the gen section will be set to 2 automatically, and a Hessian will be read in from the hess section. Since for a Hessian H, Hij = Hji, only the elements with j £ i are read in, and the program symmetrizes the matrix itself later.
Since the Hessian has dimensions of 3Nx3N, where N is the number of atoms (including dummy atoms), it may be large, so files listing all elements in each row by order of rows could be unwieldy and difficult for the user to read. Therefore, the Hessian is assumed to be presented in blocks composed of five columns each (with the last block possibly having fewer than five columns, if 3N is not a multiple of five). The format used for the hess section is the same as that used in Gaussian files or BIOGRAF (.hes) files. All Hessian elements for dummy atoms should be set to 0 (as they are in Jaguar output).
Each set of elements from a block of five columns should be preceded by a line containing one or more arbitrary integer labels; for instance, column labels could be convenient for keeping track of the elements when looking at the hess section. All of the elements within a five-column block for which j (the column indicator) is less than or equal to i (the row indicator) are then read in, one row at a time. Each of these rows containing five or fewer matrix elements starts with an integer which is read first; this integer is not used in the program, but can be used to label the matrix elements for convenience in looking over the file. When the relevant matrix elements from that entire five-column block have been read in, the next block is read in in the same way, until all of the matrix elements for the bottom triangular half of the matrix have been entered.
For example, in the unlikely event that you wished to enter this Hessian:
11 21 31 41 51 61 71 81 91
21 22 32 42 52 62 72 82 92
31 32 33 43 53 63 73 83 93
41 42 43 44 54 64 74 84 94
51 52 53 54 55 65 75 85 95
61 62 63 64 65 66 76 86 96
71 72 73 74 75 76 77 87 97
81 82 83 84 85 86 87 88 98
91 92 93 94 95 96 97 98 99
you would need to input the elements from the bottom triangle of the Hessian (shown in bold text above) in the following way:
where the i's and j's indicate integer labels not actually used by the program. In fact, the lines containing j's can contain more than one integer, as described above.
If an input file has a non-empty guess section, the keyword iguess in the gen section is set to 1, and an initial guess for the wavefunction will be read in from the guess section. The coefficients contained in the guess section are interpreted as coefficients for functions from the basis set indicated with the label basgss, if this label exists. For instance, a guess section might begin
If no basgss setting is listed, the guess section wavefunction's basis set is assumed to be the same as the basis keyword setting in the gen section.
This next line of the section should begin with a set of coefficients describing the contribution of each function in the basis set to the first molecular orbital, and continue on with similar coefficient sets for each molecular orbital. A single line, whose content is unimportant, should precede each molecular orbital's set of coefficients. If you like, you can use this line to label the molecular orbital for your own convenience.
If you choose to output the occupied orbitals, or occupied and virtual orbitals, from one run and use them in the guess section for another run, you must make sure to choose a proper format. From the interface's Orbitals window, whose button is found under the Output heading, you could select occupied orbitals or all orbitals from the What option menu and all elements as f19.15, in list or all elements as f8.5, in list from the How option menu for the original run, as described in section 5.7, and the resulting orbital output could be copied from the output file into the guess section of the input file for the next run. Similarly, you could set the relevant orbital output keyword to 4, 5, 9, or 10 in the gen section of the first run's input file, as described in the subsection Orbital Output Keywords in Section 8.6, and use the resulting output file's orbital output in the next run's input file's guess section.
If your input file has a non-empty guess section and no basgss label, or if basgss is set to "non_standard", you should make certain that the initial guess included there is for the same basis set specified by the keyword basis in the gen section, since poor results will obviously be obtained if the initial guess is described with coefficients corresponding to a different basis set than that actually used. Similarly, the ordering of the basis functions within the set being used must be the same as that used for the ordering of coefficients in the guess section.
A sample guess section for water with an STO3G basis set follows. The oxygen is atom 1, and for each molecular orbital, coefficients for the oxygen's 1s, 2s, 2px, 2py, and 2pz orbitals are input. The 1s coefficient for the first hydrogen atom follows, followed by the 1s coefficient for the second hydrogen.
The pointch section describes the locations and magnitudes of a set of point charges. Up to 20,000 point charges may be used.
Each line of the pointch section should contain four real numbers, the first specifying the point charge in atomic units, and the next three specifying its (x,y,z) coordinates in the same units used for the geometry (Angstroms by default, but bohr if the iunit keyword in the gen section is set to 0 or 2; see the Geometry Input Keywords subsection of Section 8.6 for more information).
The sample pointch section below puts one point charge of charge +1 at location (0, 0, -0.2) and another of charge -1 at location (0, 0, 0.4).
Note that point charges should not contribute to the value of the net molecular charge, molchg, given in the gen section.
If you include a non-empty pointch section in the input file for a job, the output from the program pre will include a table of fixed charge information describing the point charges. This table will appear in the output file immediately after the molecular geometry output.
If you would like to calculate wavefunctions or molecular properties in the presence of an electric field, you may use the efields section to describe this field. The x, y, and z components of the electric field should be specified, in atomic units, on the same line. The requested properties will then be calculated for the molecule in the presence of this field. The scf output will also include nuclear-electric field and electron-electric field terms.
The convention used in Jaguar for electric fields is to add a term of
to the no-field Fock matrix, where
is the electric field and
is the electron position. The contribution due to the interaction between the field and each nucleus of position
and charge qi is
.
The efields section can contain more than one line, describing several different fields. In that case, the calculations for each given field will be performed in turn. Up to 100 electric fields can be specified.
By using the ham section and setting the gen section calculation keyword ihamtyp to 3, you can specify the exact coefficients used to calculate the electronic energy for open shell calculations. The electronic energy is given by the equation
where the sums are over orbitals [20]. The number of electron pairs per orbital in each orbital i is indicated by fi, which can be listed in the ham section, and the one-electron Hamiltonian for that orbital is given by hii. The terms aij and bij are coefficients which can also be specified in the ham section, and the Jij and Kij terms are Coulomb and exchange terms for pairs of orbitals i and j. Orbitals which have the same aij and bij coefficients and number of electron pairs fi are considered to be in the same shell.
The first line in the ham section should indicate the number of core orbitals for the molecule. Next, each shell is described in turn. The first line of each shell description should contain two numbers, the first an integer indicating the number of orbitals in that shell, and the second a real number indicating fi, the number of electron pairs in each orbital of that shell. The next line should contain the aij terms for any orbital in the shell, where j < i and j is not a core orbital. The last line describing the shell lists all bij terms for any orbital in the shell, where j < i and j is not a core orbital.
The orbman section allows you to reorder orbitals, or to form linear combinations of orbitals. To do so, you can use the orbman section command `hfiglcmo' (for Hartree-Fock initial guess/linear combination of molecular orbitals), which manipulates the orbitals immediately after the HF initial guess has been generated. The command is used in the following way:
where i, j, k, and l are integers indicating the ith, jth, kth and lth orbitals before mixing (i.e. ci, cj, ck, and cl), and a and b are angles (in degrees) indicating the degree of mixing. The command hfiglcmo then mixes the orbitals to form orbitals
,
,
, and
according to the following equations:
Note that an angle of 90 permutes the two orbitals, reversing the sign of one.
Each combination operation is performed independently, and the operations are performed in the order they are listed in the orbman section. Each rotation involving a previously altered orbital uses the new, transformed orbital generated by the earlier operations. After all manipulations have been specified, the word `end' should be included.
For UHF wave functions, the syntax is modified slightly, and the alpha and beta spin-orbitals are designated by hfiglcmoa and hfiglcmob, respectively:
The echo section, when it is included in input files, does not contain anything but its own label:
Its purpose is to signal Jaguar to include a copy (echo) of the input file in the output file. If your input file does not contain an echo section, the output file will not contain an echo of the input file.
The path section allows you to specify the execution path, which determines the order of the Jaguar (or other) programs to be run. If no path section exists, Jaguar will use the default path resulting from the settings in other sections of the input file.
The items listed in a path can be either Jaguar programs, Unix commands, or other programs accessible from the executable directory. If a program or command is not accessible from the executable directory, you must specify the full path for that program, with a `/' character at the beginning of the path.
Table 8.17.1 gives a brief description of each Jaguar program.
The simplest form available for the path section is a list of the programs to be run, as in the following example:
It is not actually necessary to list pre in paths, since the pre program will always be run.
If you wish to run additional programs after a standard Jaguar calculation, you can use the word `path' to indicate the default path, as below:
More complicated paths involve looping over programs until the last Jaguar program in the loop indicates that convergence is reached. The first program in the section of the path to be looped over is preceded by a `loop' label, and the last is followed by a `goto' label, where each of these labels is followed by the same character string. Nested loops are also allowed. The following path illustrates a loop which will cause the programs pre, onee, grid, and ig to run once, the series of programs rwr, scf, der1a, rwr, der1b, and geopt to run until the convergence criteria for geometry optimization are satisfied, and the program post to run once.
If you put a `jump' label between a `loop' label and a `goto' label, where `jump' is followed by the same character string that follows `loop' and `goto' (`jumpa1' for the above path, for instance), the path will jump to the end of the loop after the `goto' label, and will exit the loop, when the `jump' label indicates that the convergence criterion for that program is reached.
Note that since loops will only exit when convergence is reached, the program before a `goto' or `jump' label must have such a criterion. The three programs which can precede a `goto' or `jump' label are scf (when it is being used for solvation runs), geopt, and nude.
Sometimes, you may want a path to include a command of more than one word-for instance, you might want to use the Unix command `mv old-filename new-filename' to rename a file. In that case, you can input the path section in such a way that each line is assumed to contain a single command. To input the path this way, you must include the word `line' after the `&path' (or `$path') label at the beginning of the path section.
The plot section allows you to generate data on one or more orbitals, the potential, or the density in a form that allows you to plot one of these properties on a cubic grid. In order to request this data, you must include a plot section with settings to describe what to plot, the dimensions of the box in which it is to be plotted, and the number of points in each direction in the box. Since the plot section requests a plot of information from the initial guess unless a guess section is included in the input file, we recommend using a restart file resulting from a completed job if you wish to plot final properties from a job. See section 6.4 for information on restart files.
The plot section should contain settings for iorb1a, npts, origin, extentx, extenty, and extentz, and may also contain a setting for iorb2a. If the setting for iorb1a is -2, density plot information will be generated, while if it is -3, potential plot information will be generated. Otherwise, it dictates which orbitals' plot information will be generated. If it is -1, plot information on all orbitals is written out; if it is a positive number, that orbital and all orbitals up to the value of iorb2a will be written out. Therefore, to plot only one orbital, you should set iorb1a and iorb2a to the same number, while otherwise they describe a range (if iorb1a is positive).
The other settings describe the grid for which the plot information is generated. The settings for origin, extentx, extenty, and extentz describe the box containing these points. The edges of the box start at the origin and form vectors in the three directions determined by the coordinate values of extentx, extenty, and extentz, whose three coordinates should be separated by commas or spaces. The number of points in each direction in the box is then given by npts, another three-dimensional setting. All quantities should be in atomic units (bohr for distances).
Here is a sample plot section that causes a job to generate plot information for orbitals 2 through 5:
When the job is run, each type of output requested by the plot section shows up in a file whose name depends on <jobname>, the name for the job (for example, "h2o" for a job run from the input file h2o.in), and the type of information being plotted. The file name is <jobname>_density.plt for information for a density plot or <jobname>_potential.plt for a potential plot. Orbital plot information shows up in separate files for each orbital, whose names depend on the four-digit orbital number <orbnum>, which would be 0005 for the fifth orbital, for instance. The orbital file names are of the form <jobname>_a<orbnum>MO.plt; for instance, the tenth orbital from the job h2o would appear in a file called h2o_a0010MO.plt.
A .plt file always begins with an echo of the plot section used to generate it. The rest of the lines in the .plt file contain values (of the relevant property) to be plotted on the grid described by the plot section. The first line gives the value at the origin; next, the values along the vector described by extentz are given. The next values correspond to the grid points given by extentz but also displaced from the origin along extenty. The loop over the points along extenty continues, and the outer loop, generating points for displacements along extentx for the above square grids, provides the rest of the points in the file.
To request a Natural Bond Orbital (NBO) analysis at the end of the Jaguar job, you need to include an nbo section in your input file. If the section is empty, as it is here:
a default NBO analysis is performed. Other options for NBO calculations can also be specified in the nbo section or in the core, choose, and nrtstr sections of the Jaguar input file. See the NBO documentation for more details on NBO input and output.
You may often need to run series of Jaguar jobs. For instance, you might want to study the dissociation of a bond by evaluating the molecule's energy at various appropriate bond lengths; scan a potential energy surface; perform a Hartree-Fock-level geometry optimization and then evaluate the energy of the new structure using LMP2 or DFT techniques; or simply run several jobs in sequence, one at a time, to avoid overtaxing your machine. If you need to run consecutive Jaguar jobs, you can use the "jaguar batch" command to generate the input files you need and run the necessary jobs.
To use "jaguar batch", you need a batch input file (whose name should end in ".bat") and at least one template Jaguar input file. The batch input file tells "jaguar batch" how to modify the template input file for each Jaguar job. These modifications can include changes to particular bond lengths and angles of the structure, changes in the wavefunction or job type (such as changing an HF geometry optimization input file to a DFT single-point energy calculation input file), changes in the files or directories used for jobs, and virtually all other settings made in input files. One batch input file can be used to request several different input files, either from one template input file or from several different templates. The "jaguar batch" command then generates the input files and runs the corresponding jobs consecutively.
The lines in a batch input file should have the following general format, where this format example is repeated for each job description:
In the general format description above, the "[ ... ]" symbols denote optional entries, and entries in "<...>" represent character strings whose formats are described below. Note that if you had a set of input files jobname1.in, jobname2.in, jobname3.in, etc., you could simply generate a batch input file whose lines each listed a job name, then run the jobs by using that file as input to "jaguar batch".
For the template job name (or names, if there is more than one such line in the batch input file), you can either use a specific job name for which an input file exists, or you can enter the string "$JOB". For example, a line with the template job name could look like this:
The string "$JOB" indicates that "jaguar batch" should run the script one or more times, substituting in various job names for $JOB, where these job names listed at the end of the "jaguar batch" command (see below for more details).
Each line of a batch input file that begins with a template job name describes a single new Jaguar job. For each such job, "jaguar batch" first makes a new Jaguar input file (<new_job_name>.in) by changing the template input file (<template_job_name>.in), which is located in the directory listed in the INDIR line (or, if there is no INDIR line, in the current directory from which "jaguar batch" is being run), so that the new input file includes the changes from the options list for that particular job, as well as from any relevant earlier OPTIONS lines. If a <new_job_name> is not included for that job, <new_job_name> is considered to be the same as <template_job_name>. (If the file <new_job_name>.in already exists, "jaguar batch" will overwrite it, unless you are using the "jaguar batch -r" option described later in this section.) Next, "jaguar batch" runs the Jaguar job with any command line options dictated by the FLAGS line, which lets you provide the -n, -s, or -t command line options described at the end of Section 8.1 to "jaguar run". Temporary files generated during the job are written to the subdirectory <new_job_name> in the directory listed in the TEMP line, and output files are written to the directory listed on the OUTDIR line.
Comment lines beginning with "#" can appear anywhere in a batch input file. Blank lines are also allowed.
Any line beginning with "%" should be followed by a shell command. Such commands will be run in the order in which they appear in the batch input.
The INDIR, OUTDIR, TEMP, EXEC, FLAGS, and OPTIONS lines in a batch input file apply to all jobs described beneath them, unless a later line of the same type replaces them. Any INDIR, OUTDIR, TEMP, EXEC, or FLAGS line replaces any earlier setting made by the same type of line, and any of these settings can be reset to their default values with the setting NONE (for instance, "FLAGS = NONE"). An OPTIONS line beginning with "OPTIONS =" replaces any earlier OPTIONS line, but any options listed in an options line beginning "OPTIONS +" just get added to the most recent OPTIONS line (if any).
Options for each Jaguar job can be determined by preceding OPTIONS lines or by an options list appearing in the same line as the name of the template input file and new job name. An options list appearing in the same line as a new job name applies only to that job, while an OPTIONS line applies to any jobs described beneath it, unless either a later "OPTIONS =" line or the options list for the job supersedes it. Otherwise, the options listed in either of these types of lines are equivalent and use the same formats. These options can specify any of the following items for the relevant jobs:
· sections to remove from the template input file (for example, the guess section if you are changing basis sets, or the gvb section if you are comparing GVB results to HF, LMP2, or DFT results)
· a substitution of a specified number or character string for one already in the template input file
The format for each of these options and an example of each kind are shown in Table 8.20.1, where entries in <> brackets indicate descriptions of the appropriate character string. Host names cannot be included in any of the paths described in the table. Note that you should avoid using any of the characters "$!\<>? in a substitution pattern.
These options and the other line types in a batch input file are illustrated in the sample files in the next subsection. After the examples, directions on how to submit a batch job follow in the final subsection.
As an example, suppose you have ten different molecules and you want to optimize the geometry of each one at the B3LYP/6-31G* level of theory, and then do two single-point energy calculations on the optimized geometry, one using B3LYP/6-311+G* and the other using LMP2/6-311+G. You can create a batch file that will automate this process. The batch file would read in each molecular geometry from an existing input file, make the necessary keyword changes, and perform the calculations. Here is an example of such a batch file (lines beginning with '#' are comments):
To run "jaguar batch", you can enter a command in the form
where batchname.bat is the name of a batch input file with no occurrences of the string "$JOB". Otherwise, if the batch input file includes "$JOB" entries (described earlier in this section), the "jaguar batch" command should take the form
where joblist is a list of job names whose corresponding input files already exist and are to be submitted to the batch input file as template jobs. Each Jaguar input file described in the batch input file is then generated (unless doing so would overwrite an existing input file) and used in a Jaguar run.
The "jaguar batch" command also has several command line options, which are summarized in Table 8.20.2.
The -r option lets you dictate that "jaguar batch" should not overwrite existing Jaguar input files, while the -l and -s flags permit you to see what "jaguar batch" would do, but do not actually allow it to generate any new input files or run any Jaguar jobs.
|
Schrödinger, Inc. http://www.schrodinger.com Voice: (503) 299-1150 Fax: (503) 299-4532 help@schrodinger.com Last updated: Thu Oct 11 19:10:43 2001 |
| |
|
|
|
