Quantum 1 Modules - Quantum Chemistry Modules

Quantum 1 Modules

2 Quantum Chemistry Modules

This section introduces the role and benefits of modern quantum mechanical (chemistry) techniques for today's chemist and describes how the applications that make up the Quantum 1 module in Cerius² provide access to this technology.

The Quantum 1 module includes:

ADF interface--Provides an easy-to-use interface to the Amsterdam Density Functional (ADF) program (Fonseca Guerra et al. 1995, te Velde 1995).
DMol³ interface--Provides an easy-to-use interface to the updated DMol³ program (documented separately).
Gaussian interface--Provides an easy-to-use interface to the Gaussian^® 92 (Frisch et al. 1992) and Gaussian 94 (Frisch et al. 1995) programs.
MOPAC interface--Provides an easy-to-use interface to MOPAC (the general Molecular Orbital PACkage, Stewart 1993).
Zindo interface--Provides an easy-to-use interface to the Zindo program.

The cards that make up the Cerius²·Quantum 1 module also include a set of utilities that allow you to alter the structure of existing models by editing their Z-matrices, adding dummy atoms, and changing between Cartesian and Z-matrix representations. For complete details, see Quantum 1 Module Utilities.

Quantum chemistry applications

This section includes:

: Computational chemistry overview
: Overview of Quantum 1 module
: Configuring Quantum 1 applications

Computational chemistry overview

The Cerius² range of products provides a flexible, modular environment for molecular modeling and computational chemistry. Two major simulation techniques dedicated to molecular structure and reactivity exist within the field of computational chemistry:

Molecular mechanics.
Quantum mechanics.

Uses of computational chemistry

Both techniques can be used to perform the same range of basic tasks, including:

Computation of the energy of model structures. Some methods can also predict properties related to the energy of the structure.
Geometry optimizations, which find local energy minima for a specific starting structure.
Computation of vibrational frequencies resulting from interatomic motion within the structure.

Fundamental differences exist between the two techniques (below) in terms of approach, accuracy, and required computing power, and each has its appropriate use.

Molecular mechanics methods

Molecular mechanics simulations use the laws of classical physics to predict the structures and properties of molecules. Many different molecular mechanics methods exist, each characterized by a forcefield. Please see Forcefield-Based Simulations for details about molecular mechanics forcefields, theory, and methods.

Molecular mechanics methods do not consider the electrons in a molecular system explicitly. Instead, these calculations are based on interactions among the nuclei. Electronic effects are implicitly included in a forcefield via its parameterization. Such approximation makes molecular mechanics methods relatively inexpensive computationally and, hence, allow them to be used for very large systems containing many thousands of atoms. However, it also imposes limitations:

Many forcefields can achieve good results only for a limited class of models, related to those for which the forcefield was parameterized.
Neglecting the electrons means that molecular mechanics methods cannot treat chemical problems in which electronic effects predominate.

Quantum mechanics methods

Quantum mechanical simulations are based on the laws of quantum mechanics rather than classical physics. Quantum mechanics states that the energy and other related properties of a molecule can be obtained by solving the Schrödinger equation:

Eq. 1 H = E

For any but the smallest symmetric systems, however, exact solutions to the Schrödinger equation cannot be obtained in practice. Quantum mechanical methods are characterized by their various mathematical approximations to its solution. Several major classes of quantum mechanical methods exist:

Types of quantum methods

Semi-empirical methods--For example, AM1, CNDO, INDO, MINDO/3, MNDO, and PM3, which are implemented in programs such as Gaussian, MOPAC, and Zindo. These methods use parameters derived from experimental data to simplify the computation. They solve an approximate form of the Schrödinger equation that depends on having appropriate parameters available for the type of chemical system in question.
Ab initio methods--Unlike molecular mechanics or semi-empirical quantum mechanics methods, ab initio methods use no experimental parameters in their computations. Instead, these computations are based solely on the laws of quantum mechanics and on the values of the speed of light, the masses and charges of electrons and nuclei, and Planck's constant.
DFT (density functional theory) methods--Similar to other quantum chemistry methods (semiempirical or ab initio), DFT aims at predicting molecular (or solid) geometrical structures and electronic properties, Unlike the other methods, DFT assumes that the electron density, not the wavefunction, is the fundamental quantity that determines properties of molecular or solid systems.

: In practical applications, the electron density is calculated from orbitals that are generated by solving the one-electron Schrödinger-type equations, the Kohn-Sham equations.

The programs accessible through the Quantum 1 and Quantum 2 modules in Cerius² offer all the above methods.

Advantages and disadvantages

Semi-empirical and ab initio methods differ in the trade-off made between accuracy and computational cost. Semi-empirical calculations are relatively inexpensive and provide reasonable qualitative descriptions of molecular systems and fairly accurate quantitative predictions of energies and structures for systems where good parameter sets exist.

In contrast, ab initio computations provide high-quality quantitative predictions for a broad range of systems. They are not limited to any specific class of system. Early ab initio programs were very limited in the size of system they could handle; however, this is not true for modern ab initio programs. On a typical workstation, the energies and related properties for systems containing a dozen heavy atoms can now be computed in just a few minutes. Jobs of up to a few hundred atoms can be handled, and model structures having as many as one hundred atoms can also be predicted on typical workstations. Larger systems can be handled on supercomputers.

Ab initio methods can also handle any type of atom, including metals, and can be used to investigate models in their excited states and in solution.

The accuracy of the DFT method depends mainly on the functional used (local,nonlocal,hybrid) and the quality of the computational parameters such as basis sets and numerical integration grid. The local (LSD: local spin density) and nonlocal (NLSD) approaches can be very efficiently implemented, yielding algorithms that scale better with the size of the system than do ab initio methods. DFT programs are slower than semiempirical programs; however, they can be used for various types of molecular and solid-state systems including organic, organometallic, and metallic systems. The latest DFT approaches, NLSD or hybrid (HF-DFT) methods, can be used to study chemical reactions with consistently satisfactory accuracy.

Overview of Quantum 1 module

This section introduces the individual interfaces that are included in the Quantum 1 module and provides an overview of some of the features and terminology common to them.

Note

Quantum programs in the Cerius²·Quantum 2 module are documented separately.

ADF interface

ADF has been developed by the Vrije Universiteit Amsterdam and can be used in studies of molecular spectroscopy, organic and inorganic chemistry, crystallography, and pharmacochemistry. It is based on the Kohn-Sham approach to the density functional theory and, in principle, yields exact properties such as the electron density and related properties and the total energy.

The Quantum 1 ADF card provides an interface to ADF, allowing you to use the flexible modeling tools and advanced interface provided by the Cerius² modeling environment to set up, run (on the local machine or a remote host), and analyze the output from ADF jobs.

Details on using the Cerius²·ADF interface are provided in ADF Interface. For a complete description of ADF, please refer to the separate ADF 2.3 User's Guide published by the Vrije Universiteit, Amsterdam (see Other relevant websites).

DMol³ interface

DMol³ is a first-principles (ab initio) quantum chemistry software package that performs accurate theoretical calculations on a wide range of compounds, including metal clusters, biological compounds, organometallics, and organic compounds.

DMol³ calculates variational self-consistent solutions to the density functional theory (DFT) equations, expressed in a numerical atomic orbital basis. The solutions to these equations provide the molecular wavefunctions and electron densities, which can be used to evaluate the energetics and the electronic and magnetic properties of the system. In addition, evaluation of the energy gradients provides a convenient method for determining the equilibrium geometry of the system. These results provide a reliable predictive method for theoretically exploring the properties of unknown compounds, as well as for explaining, on a microscopic scale, the known properties of existing compounds.

The Quantum 1 DMOL3 card provides an interface to DMol³, allowing you to use the flexible molecular modeling tools and advanced interface provided by the Cerius² modeling environment to set up, run, and analyze the output from DMol³ jobs.

Details on using the Cerius²·DMol³ interface are provided in DMol³ Interface. For a complete description of DMol³, please refer to the sections on using DMol³ in standalone mode (DMol³--Running in Standalone, DMol³--Keyword Descriptions, and DMol³--Keyword Reference).

Gaussian interface

Gaussian 92 and Gaussian 94 are full-featured computational chemistry packages from Gaussian Inc. that provide a wide variety of powerful semi-empirical and ab initio molecular orbital methods. However, because input and output are in the form of ASCII text files, setting up and analyzing the results of Gaussian jobs in the absence of a graphical interface can prove time-consuming and difficult.

The Quantum 1 GAUSSIAN card provides a (nearly) transparent interface to Gaussian 92 and Gaussian 94, allowing you to use the flexible molecular modeling tools and advanced interface provided by the Cerius² modeling environment to set up, run (on the local machine or a remote host), and analyze the output from Gaussian jobs.

Details on using the Cerius²·Gaussian interface are provided in Gaussian Interface. For a complete description of Gaussian, please refer to the separate Gaussian Inc. documentation set (see Other relevant websites).

MOPAC interface

MOPAC is a general-purpose semi-empirical molecular orbital package that implements the MNDO, MINDO/3, AM1, and PM3 Hamiltonian approximation methods. Several versions are available in the public domain, and MOPAC6 executables are supplied with Cerius².

The Quantum 1 MOPAC card provides an interface to MOPAC, allowing you to use the flexible molecular modeling tools and advanced interface provided by the Cerius² modeling environment to set up, run, and analyze the output from MOPAC jobs.

Details on using the Cerius²·MOPAC interface are provided in MOPAC Interface. For a complete description of MOPAC, please refer to the separate MOPAC documentation set (see Other relevant websites).

Zindo interface

Zindo is a comprehensive semi-empirical package developed by M. C. Zerner (University of Florida) and co-workers. Zindo calculates electronic and structural properties of molecular systems. It's advantage over other semi-empirical packages lies in its ability to calculate UV/visible spectra and its ability to treat systems including transition metal atoms. Zindo executables are provided with Cerius².

The Quantum 1 ZINDO card provides an interface to Zindo, allowing you to use the flexible molecular modeling tools and advanced interface provided by the Cerius² modeling environment to set up, run, and analyze the output from Zindo jobs.

Details on using the Cerius²·Zindo interface are provided in Zindo Interface. For a complete description of Zindo standalone keywords, please refer to:

: http://www.msi.com/doc/quantum9709/zindoC/

Consistent graphical interface

Consistent look and feel

The menus, control panels, and other elements that make up the ADF, DMol³, Gaussian, MOPAC, and Zindo interfaces in Cerius² have been designed to provide an integrated, consistent look and feel throughout the Quantum 1 module.

Because of this consistency, once you have read the documentation and learned how to use any of the Quantum 1 cards, you should find it easy to work with the others. Once familiar with the interface features used throughout the Quantum 1 module, you will probably need to use only module-specific reference material.

Simplicity and flexibility

Quantum mechanics applications are extremely powerful tools. However, these tools are generally very complex, offering many options and parameters for specifying and fine-tuning a job. Although an experienced user may be familiar with them, the number of options may be daunting to a novice whose requirements are somewhat less demanding.

The Quantum 1 interfaces are designed to make the applications more accessible to everyone. The interfaces provide access to all application functionality, but in such a way that a basic job can be initiated quickly and easily. The key to this design approach is each application's Run control panel. This control panel contains or provides access to all the controls necessary to set up and run a job for that application.

How it works--job setup

You can specify all the options necessary for a basic job from the Run control panel--the interface automatically sets reasonable default values for all necessary ancillary parameters. To enable you to set up a more complex job and set the values of the ancillary parameters yourself, some pushbuttons on the Run control panels provide access to control panels that allow you to set options and parameters related to each area of functionality.

Setting up a Quantum 1 run involves generating an appropriate input file that defines the model of interest and the type of calculations that you want to perform upon it. The interface considerably simplifies job specification and setup because it generates the input file for you.

You can load, edit, and refine the model on which to perform calculations using any of the Cerius²·Visualizer tools and applications. The options that define the type of calculations you want to perform on that model (such as the task, approximation method, and basis set to use) are accessed through buttons, popups, dialog boxes, and so on, that appear logically grouped by function on the application control panels.

From the current model and the settings of these controls, the application interface generates all the commands and data entries necessary to define the model and the calculations you want to perform on it. This information is formatted as a command input file for the specific quantum application, and the job is started.

How it works--analysis of results

When the job ends successfully, the results of the run are written in output files with the same prefix as the input file. The Quantum 1 analysis tools allow you to select any such output file and, from the numeric description of the model's wavefunction, obtain more readily usable information.

For example, you can calculate and display molecular orbitals or electron densities as isosurfaces or compare different types of results (or even the same type of results calculated with different programs) by displaying them as surface maps on the isosurfaces.

Job execution and control

Interface to executables

Several issues help you understand how the Quantum 1 applications work:

The Quantum 1 interfaces within Cerius² do not actually perform the quantum mechanical calculations themselves, but rather send input files to external standalone applications for execution and retrieve output files after the run is complete.
ADF, DMol³, Gaussian, MOPAC, and Zindo executables are available for a wide variety of platforms, including some on which Cerius² does not run.
Quantum mechanical calculations are typically very time consuming and resource intensive. They can sometimes run for several days, using extensive CPU time, memory, and disk space. After starting a job, you can exit the Cerius² interface, leave the job running, and then retrieve the results in a later Cerius² session.

Networked computing environments

The sophisticated job control facilities provided by the Quantum 1 module allow you to take full advantage of heterogeneous network environments. You can readily specify how and where your jobs should run, monitor their progress, and transfer input and output files to and from remote systems.

The Quantum 1 module allows ADF, DMol³, Gaussian, MOPAC, and Zindo jobs to be run on the local machine or on any other host on your local area network on which the executables are available. Jobs can be run in interactive or background mode or via the Network Queueing System (NQS), if it is installed (see NQS run mode). Multiple jobs can be initiated on the same or different machines. Jobs started in background or NQS mode can continue independent of the Cerius² session in which they are initiated.

Interactive run mode

Quantum 1 jobs initiated in interactive mode run in much the same way as do other Cerius² tasks (that is, the job runs as though Cerius² were processing the job itself). Cerius² waits, so you cannot perform other Cerius² tasks until the job ends.

If the job is run remotely, input files are automatically transferred to that host for execution, and output files are automatically recovered from the remote host upon job completion.

You can stop an interactive job using the Cerius² Interrupt message window, which is displayed while the job is running to indicate that Cerius² is busy. If you click the INTERRUPT button and select the Stop current process ASAP option, Quantum 1 may display an additional dialog box from which you can confirm or cancel your request or send the job into the background.

Background run mode

Jobs initiated in background mode run as a background process on the specified local or remote host. Once the job has been successfully initiated, Cerius² is free to perform other tasks. If the job is run remotely, input files are transferred automatically to that host for execution; output files may need to be manually recovered from the remote host after the job is finished.

NQS run mode

Jobs initiated in NQS mode are submitted to queues on the specified local or remote host, provided that the Network Queueing System software has been installed on that host. Once the job has been successfully queued, Cerius² is free to perform other tasks. If the job is run remotely, input files are transferred automatically to that host for execution; output files may need to be manually recovered from the remote host after the job is finished.

Job control

Jobs initiated in background mode or via the NQS mechanism can run for long periods of time and, when complete, terminate silently (although you can request that email be sent to you when an NQS job ends). For this reason, the Quantum 1 applications include a complete set of job control tools that allow you to monitor job status, stop jobs by killing the associated process, and manually recover output files from remote systems.

Configuring Quantum 1 applications

This section describes the procedures necessary for configuring three of the standalone quantum applications for use in the Cerius² environment. You should have your system administrator perform the necessary configuration steps if this has not already been done.

Configuration is performed largely through entries in the applcomm.db file. For a detailed description of configuration via this file, please see Cerius² Installation and Administration Guide. Because ADF, DMol³, Gaussian, MOPAC, and Zindo are third-party products, each with its own installation method, the necessary procedures vary slightly from product to product. Example applcomm.db entries for these applications can be found under Example applcomm.db file entries.

Important

Each of the products can be run on hosts other than those licensed for Cerius². To support this functionality, rjrd (the MSI Remote Job Run Daemon), an application that controls Cerius²-initiated jobs on remote machines, must be available on potential hosts for any Quantum 1 application.

ADF

ADF must be installed according to the standard installation instructions. As part of this procedure, you (or the system administrator) need to define an A record in the applcomm.db file for each machine that ADF is installed on for each of these items:

ADFBIN--Where the ADF executable is located.
ADFUTILITIES--Where utility codes such as densf are located.
ADFRESOURCES--Where the basis sets are located.

DMol³

DMol³ must be installed according to the standard installation instructions.

For each machine on which standalone DMol³ is installed, you need a dmol3exe entry in the applcomm.db file which points to the location of the DMol³ standalone executable.

In a standard installation, the dmol3exe entry in the applcomm.db file points to the DMol³ standalone executable provided with Cerius².

Gaussian

The Cerius² GAUSSIAN card provides an interface to both Gaussian 92 and Gaussian 94. Either or both programs can be configured in applcomm.db.

Gaussian must be installed according to the standard installation instructions. As part of this procedure, you must set the environment variable g92root (for Gaussian 92) or g94root (for Gaussian 94) to point to the directory in which the program is installed. To run jobs using the Gaussian interface, g92root (or g94root) must be set (via applcomm.db) for all the hosts on which you want to run Gaussian.

Optional environment variables

The Gaussian software uses scratch files for temporary storage during calculations, and these can become very large. Gaussian allows the default location of the directory in which these files are held (that is, the working directory) to be changed via the environment variable GAUSS_SCRDIR. You can change the value of GAUSS_SCRDIR by setting the variables g92scratch and g94scratch in applcomm.db. They are then used to set GAUSS_SCRDIR. If g92scratch (or g94scratch for Gaussian 94) is not set in applcomm.db, the current working directory is used.

Three other variables, g92exe, g92formchk, and g94newzmat, can also be set in the applcomm.db file to specify nonstandard locations for the main g92 executable and for the formchk and newzmat programs, respectively. You should need to use these only if you have a customized Gaussian 92 installation.

Similarly, g92exe, g92formchk, and g94newzmat can be set if you have a customized Gaussian 94 installation.

MOPAC

Three different versions of the basic program exist:

MOPAC6--Available in the public domain and included with Cerius².
MOPAC7--The latest public-domain version of MOPAC.
MOPAC93--An enhanced, commercially sold version of MOPAC7.

Because of this, the procedure for configuring MOPAC is slightly more complicated than that for Gaussian or ADF.

In a standard installation, the directory c2_install_dir/mopac contains several files necessary to support MOPAC. These include a run script for each supported version of MOPAC (mopac6.sh, mopac7.sh, and mopac93.sh), a MOPAC6 executable (mopac6.exe), and a binary conversion utility (mopacconv.f).

The script files are used by the MOPAC interface to run the three supported versions of MOPAC, each calling the executable defined by the corresponding applcomm.db entry (see mopac6exe, mopac7exe, and mopac93exe).

The mopacdir entry points to the directory that contains the three run scripts. These scripts must always be together in the same directory. In the supplied version of applcomm.db, this is set to c2_install_dir/mopac. If you want to use a customized version of any of these scripts, you should put the customized script(s) and other standard scripts together in another directory and change the mopacdir entry in applcomm.db to point to this location.

The mopac6exe entry points to the MOPAC6 executable. In the supplied version of applcomm.db this is set to c2_install_dir/mopac/mopac6.exe.

The mopac7exe entry points to the name of the MOPAC7 executable. Because MSI cannot distribute this version of the program, mopac7exe is not set in the supplied version of the applcomm.db file.

The mopac93exe entry points to the name of the MOPAC93 executable. Because MSI cannot distribute this version of the program, mopac93exe is not set in the supplied version of the applcomm.db file.

The mopacconv entry points to the name of the executable version of the binary conversion program, if required. If this entry is set, then binary graphics files (.gpt) are converted into formatted files (.fgpt). This entry is not set in the supplied version of the applcomm.db file.

For further discussion of MOPAC configuration, refer to the README file found in c2_install_dir/mopac.

Zindo

Zindo must be installed according to the standard installation instructions.

For each machine on which standalone Zindo is installed, you need a zindoexe entry in the applcomm.db file which points to the location of the Zindo standalone executable

In a standard installation, the zindoexe entry in applcomm.db points to the Zindo standalone executable provided with Cerius².

Example applcomm.db file entries

The following applcomm.db extract contains example entries for quantum applications.


# These lines specify the locations of the ADF
# files. You may need to alter the specifications
# if you want to run ADF on a machine on which you do 
# not have Cerius2 licensed.
A SGI adf c2_install_dir/exec/adf.exe
A SGI ADFBIN c2_install_dir/adf/bin
A SGI ADFUTILITIES c2_install_dir/adf/bin
A SGI ADFRESOURCES c2_install_dir/Cerius2-Resources/ADF/atomicdata

# The following line specifies the location of the main
# Gaussian 92 directories. Replace the path name with that
# for your own installation. If you don't have Gaussian
# 92, omit this line.
A SGI g92root /usr/mydir/gaussian92

# The following line specifies the location of the main
# Gaussian 94 directories. Replace the path name with that
# for your own installation. If you don't have Gaussian
# 94, omit this line.
A SGI g94root /usr/mydir/gaussian94

# The following lines specify an alternative location for the
# Gaussian 92 and Gaussian 94 scratch directories. If this
# line is omitted, the current working directory is used.
A SGI g92scratch /usr/disk2/gaussian.scratch
A SGI g94scratch /usr/disk2/gaussian.scratch

# The following two lines are standard. Only change them
# if you have a non-standard installation, or if you 
# want to run mopac on a machine on which you do not
# have Cerius2 installed.
A SGI mopacdir c2_install_dir/mopac
A SGI mopac6exe c2_install_dir/mopac/mopac6.exe

# The following line specifies the location of the MOPAC7
# executable. If you don't have MOPAC7, omit this line.
A SGI mopac7exe /usr/mydir/mopac7/mopac7_sgrw/mopac.exe

# The following line specifies the location of the MOPAC93
# executable. Replace the path name with that of your own
# installation. If you don't have MOPAC93, omit this line.
A SGI mopac93exe /usr/mydir/mopac93/m93_src/mopac93.exe

# The following line specifies the location of the
# DMol3 executable.  Only change it if you have a 
# non-standard installation, or if you want to run DMol3
# on a machine on which you do not have Cerius2 installed.
A SGI dmol3exe c2_install_dir/exec/dmol3

Last updated December 06, 1998 at 11:50AM Pacific Standard Time.

Copyright © 1998, Molecular Simulations, Inc. All rights reserved.