http://www.nwchem-sw.org/index.php?title=Special:Contributions/Bert&feed=atom&limit=50&target=Bert&year=&month=NWChem - User contributions [en]2020-07-10T22:13:42ZFrom NWChemMediaWiki 1.16.4http://www.nwchem-sw.org/index.php/Ongoing_ProjectsOngoing Projects2015-08-10T20:20:33Z<p>Bert: /* Ongoing Projects and Future Directions */</p>
<hr />
<div>__NOTITLE__<br />
<br />
== Ongoing Projects and Future Directions ==<br />
<br />
'''Density functional theory (DFT), time-dependent DFT (TD-DFT) and properties<br />
'''<br />
*Discrete interaction model/quantum mechanical method (DIM/QM) for describing the response properties of molecules adsorbed on metal nanoparticles. '''Developers:''' ''Justin Moore, Lasse Jensen (Penn State University).''<br />
*Development of exact two-component relativistic theory and calculations of magnetic response parameters. '''Developers:''' ''Jochen Autschbach (SUNY Buffalo).''<br />
*Generalization of real-time TDDFT to include spin-orbit effects . '''Developers:''' ''Niri Govind (PNNL), Ken Lopata (LSU).''<br />
*Developing infrastructure for incorporating new density functionals and higher order derivatives thereof. The idea is to extend the density functionals in NWChem to support higher order partial derivatives to support new functionality. At the same this is a good opportunity to build the infrastructure needed to incorporate new density functionals and their higher order derivatives. The aim is to use open source tools as much as possible to make it easy for anyone to do this. '''Developers:''' ''Huub van Dam (PNNL).''<br />
'''Future projects''': Dynamics on excited-state surfaces, surface hopping, GW/BSE for molecular systems, Spin-flip TDDFT, Non-collinear DFT, spin-orbit TDDFT, interface to QWalk Quantum Monte-Carlo Program (w/ Lucas Wagner University of Illinois, Urbana-Champaign)<br />
<br />
<br />
'''Plane-Wave Density Functional Theory (DFT), Ab Initio Molecular Dynamics, and NWPhys'''<br />
*Parallel in Time Algorithms. '''Developers:''' ''Eric J. Bylaska (PNNL), Jonathan Q. Weare (University of Chicago), John H. Weare (UCSD).'' <br />
*New free energy methods based on diffusion Monte-Carlo algorithm. '''Developers:''' ''Eric J. Bylaska (PNNL), Ying Chen (UCSD), John H. Weare (UCSD).'' <br />
*Dynamic Mean Field Theory (DMFT). '''Developers:''' ''Duo Song (UCSD), Eric J. Bylaska (PNNL), John H. Weare (UCSD).'' <br />
*Development of new methods to calculate XPS and XANES spectra. '''Developers:''' ''Eric J. Bylaska (PNNL), Niri Govind (PNNL), John Rehr (University of Washington).'' <br />
*Implementation of electric field gradients and NMR in NWPW '''Developers:''' ''Eric J. Bylaska (PNNL).''<br />
*Implementation of the fast multipole method (FMM) in the combined Ab initio molecular dynamics and molecular dynamics (AIMD/MM) code. '''Developers:''' ''Eric J. Bylaska (PNNL).''<br />
*Constant pressure ab initio molecular dynamics. '''Developers:''' ''Eric J. Bylaska (PNNL).''<br />
*New implementation of the projector augmented wave method in NWPW. '''Developers:''' ''Eric J. Bylaska (PNNL).''<br />
*Initial implementation of orbital free DFT in NWPW. '''Developers:''' ''Eric J. Bylaska (PNNL).''<br />
*implementation of Hybrid openmp-mpi and offloading intel MIC algorithms in NWPW. '''Developers:''' ''Eric J. Bylaska (PNNL).''<br />
'''Future projects''': New NWPhys module development (w/ John Rehr University of Washington) which will include new methods to calculate XPS and XANES spectra. Interface to QWalk Quantum Monte-Carlo Program (w/ Lubos Mitas University of North Carolina).<br />
<br />
<br />
<br />
'''High-level Coupled-Cluster methods'''<br />
*Development of multi-reference coupled-cluster capabilities for quasidegenerate systems. '''Developers:''' ''Jiri Pittner (J Heyrovsky Institute of Physical Chemistry), Karol Kowalski (PNNL).''<br />
*Electron-affinity/ionization-potential Equation-of-motion Coupled-Cluster methods. '''Developers:''' ''Kiran Bhaskaran-Nair (LSU), Mark Jarrell (LSU), Juana Moreno (LSU), William Shelton (LSU), Karol Kowalski (PNNL).''<br />
*Green function Coupled Cluster formalism. '''Developers:''' ''LSU, PNNL.''<br />
*Development of Intel MIC implementation of the CCSD(T) approach '''Developers:''' ''Edoardo Apra (PNNL), Michael Klemm (Intel), Karol Kowalski (PNNL).''<br />
*Reduced scaling CC formulations based on the Cholesky Decomposition. '''Developers:''' ''Huub van Dam (PNNL), Edoardo Apra (PNNL), Karol Kowalski (PNNL).<br />
'''Future projects''': CC/EOMCC analytical gradients, Intel MIC implementations for iterative CC methods, Multi-reference CC formulations employing incomplete model spaces.<br />
<br />
<br />
'''Other Correlated methods'''<br />
*Development of GASSCF and SplitGAS multi configuration approaches. '''Developers:''' ''Bert de Jong (LBNL), Kostas Vogiatzis (Univ. Minnesota), Laura Galiardi (Univ. Minnesota).''<br />
*Implementation of MC-PDFT. '''Developers:''' ''Samuel Odoh (Univ. Minnesota), Don Truhlar (Univ. Minnesota), Laura Gagliardi (Univ. Minnesota), Bert de Jong (LBNL).''<br />
<br />
<br />
'''Long-term NWChem development plans:<br />
'''<br />
*Development of new algorithms for hybrid computer architectures including GPU and Intel Xeon Phi computer architectures (NWChem offers already GPU implementations of many-body methods, in 6.5 release we will extend these capabilities to Intel Xeon Phi technology) , <br />
*Implementation of reduced-scaling methods for electronic structure calculations (local formulations, tensor hypercontractions, resolution-of-identity based approaches),<br />
*Development of novel methodologies for extending temporal scales in ab-initio molecular dynamic and molecular dynamics simulations,<br />
*Approximate electronic structure methods for very large-scale simulations (various semi-empirical methods, order <math>N-N^2</math> DFT algorithms - orbital free DFT), <br />
*Integration and extension of existing capabilities towards predictive models for mesoscale systems (for example, aerosol particles, soil chemistry, biosystems, hormone-cofactor functionality in proteins, ionic liquids in cells, large-scale reactions containing multiple steps).</div>Berthttp://www.nwchem-sw.org/index.php/Developer_TeamDeveloper Team2013-11-11T18:47:39Z<p>Bert: /* Core Development Team */</p>
<hr />
<div>__NOTITLE__<br />
=NWChem Development Consortium=<br />
<br />
==Core Development Team==<br />
<br />
{| border='1' style="width: 100%"<br />
! scope="col" style="width: 30%" align="left" | Name<br />
! scope="col" style="width: 60%" align="left" | Current focus<br />
|-<br />
| [http://emslbios.pnl.gov/id/bylaska_ej E. J. Bylaska]<br />
| Plane wave development<br />
|-<br />
| [http://emslbios.pnl.gov/id/govind_n N. Govind]<br />
| DFT, (LR/RT)-TDDFT, Excited-state methods<br />
|-<br />
| [http://emslbios.pnl.gov/id/kowalski_k K. Kowalski]<br />
| High accuracy methods<br />
|-<br />
| [http://emslbios.pnl.gov/id/valiev_m M. Valiev]<br />
| QM/MM methodologies<br />
|-<br />
| [http://emslbios.pnl.gov/id/van+dam_h H. J. J. van Dam]<br />
| DFT, Fault tolerance<br />
|-<br />
| E. Apra<br />
| DFT, Cray optimization<br />
|-<br />
| [http://crd.lbl.gov/about/staff/amsc/scientific-computing-group-scg/bert-de-jong/ W. A. de Jong]<br />
| Properties, relativistic effects, basis sets, parallel performance, integrals, HPC<br />
|-<br />
| [http://www.pnl.gov/science/staff/staff_info.asp?staff_num=7066 T. P. Straatsma]<br />
| Molecular dynamics<br />
|-<br />
|}<br />
<br />
==Active Developers==<br />
<br />
{| border='1' style="width: 100%"<br />
! scope="col" style="width: 30%" align="left" | Name<br />
! scope="col" style="width: 60%" align="left" | Current focus<br />
|-<br />
| [http://www.csm.ornl.gov/ccsg/html/staff/harrison.html R. J. Harrison] (ORNL)<br />
| Multiresolution methods<br />
|-<br />
| [http://www.chem.iastate.edu/faculty/Theresa_Windus/ T. L. Windus] (Iowa State University and AMES)<br />
| Dynamic nucleation theory<br />
|-<br />
| [http://www.alcf.anl.gov/staff-directory/jeff-hammond J. R. Hammond] ([http://www.anl.gov ANL])<br />
| High accuracy response, IBM Blue Gene performance<br />
|-<br />
| [http://www.nsm.buffalo.edu/~jochena/ J. Autschbach] (SUNY Buffalo)<br />
| Response properties, relativistic effects<br />
|-<br />
| [http://research.chem.psu.edu/lxjgroup/ L. Jensen] (Penn State)<br />
| DFT functionals, properties<br />
|- <br />
| [http://iqc.udg.es/~marcel/eng/index.html M. Swart] (Universitat de Girona, Spain)<br />
| SSB-D functionals<br />
|-<br />
| [http://www.bnl.gov/cfn/people/?id=23957 Q. Wu] (BNL)<br />
| Constrained DFT<br />
|- <br />
| [http://www.mit.edu/~chemistry/faculty/vanvoorhis.html T. Van Voorhis] (MIT)<br />
| Constrained DFT<br />
|-<br />
| [http://comp.chem.umn.edu/~zhaoy/ Y. Zhao] (Hewlett-Packard)<br />
| Minnesota (Truhlar) functionals<br />
|-<br />
| R. Peverati (University of Minnesota -Truhlar Group)<br />
| Minnesota (Truhlar) functionals<br />
|-<br />
| K. Lopata (PNNL, NWChem Group)<br />
| RT-TDDFT development<br />
|-<br />
| [http://sites.google.com/site/alvarovazquezmayagoitia/ A. Vazquez-Mayagoitia] ([http://www.anl.gov ANL])<br />
| DFT functionals, properties<br />
|-<br />
| Kiran Bhaskharan Nair (PNNL, NWChem Group)<br />
| Multireference Coupled Cluster (MRCC) Theory development<br />
|-<br />
|}<br />
<br />
==Authors and Contributors ==<br />
<br />
E. Apra, E. J. Bylaska, W. A. de Jong, N. Govind, K. Kowalski,<br />
T. P. Straatsma, M. Valiev, H. J. J. van Dam, D. Wang, T. L. Windus,<br />
J. Hammond, J. Autschbach, K. Bhaskaran-Nair, J. Brabec, K. Lopata,<br />
F. Aquino, S. Hirata, M. T. Hackler, J. Mullin, P. Nichols, R. Peverati,<br />
J. Pittner, Y. Zhao, P.-D. Fan, R. J. Harrison, M. Dupuis, D. Silverstein,<br />
D. M. A. Smith, J. Nieplocha, V. Tipparaju, M. Krishnan, B. E. Van Kuiken,<br />
A. Vazquez-Mayagoitia, L. Jensen, M. Swart, Q. Wu, T. Van Voorhis,<br />
A. A. Auer, M. Nooijen, L. D. Crosby, E. Brown, G. Cisneros, G. I. Fann,<br />
H. Fruchtl, J. Garza, K. Hirao, R. Kendall, J. A. Nichols, K. Tsemekhman,<br />
K. Wolinski, J. Anchell, D. Bernholdt, P. Borowski, T. Clark, D. Clerc,<br />
H. Dachsel, M. Deegan, K. Dyall, D. Elwood, E. Glendening, M. Gutowski,<br />
A. Hess, J. Jaffe, B. Johnson, J. Ju, R. Kobayashi, R. Kutteh, Z. Lin,<br />
R. Littlefield, X. Long, B. Meng, T. Nakajima, S. Niu, L. Pollack, M. Rosing,<br />
K. Glaesemann, G. Sandrone, M. Stave, H. Taylor, G. Thomas, J. H. van Lenthe,<br />
A. Wong, Z. Zhang.</div>Berthttp://www.nwchem-sw.org/index.php/Developer_TeamDeveloper Team2013-08-11T11:08:54Z<p>Bert: /* Core Development Team */</p>
<hr />
<div>__NOTITLE__<br />
=NWChem Development Consortium=<br />
<br />
==Core Development Team==<br />
<br />
{| border='1' style="width: 100%"<br />
! scope="col" style="width: 30%" align="left" | Name<br />
! scope="col" style="width: 60%" align="left" | Current focus<br />
|-<br />
| [http://emslbios.pnl.gov/id/bylaska_ej E. J. Bylaska]<br />
| Plane wave development<br />
|-<br />
| [http://emslbios.pnl.gov/id/govind_n N. Govind]<br />
| DFT, (LR/RT)-TDDFT, Excited-state methods<br />
|-<br />
| [http://emslbios.pnl.gov/id/kowalski_k K. Kowalski]<br />
| High accuracy methods<br />
|-<br />
| [http://emslbios.pnl.gov/id/valiev_m M. Valiev]<br />
| QM/MM methodologies<br />
|-<br />
| [http://emslbios.pnl.gov/id/van+dam_h H. J. J. van Dam]<br />
| DFT, Fault tolerance<br />
|-<br />
| E. Apra<br />
| DFT, Cray optimization<br />
|-<br />
| [W. A. de Jong]<br />
| Properties, relativistic effects, basis sets, parallel performance, integrals, HPC<br />
|-<br />
| [http://www.pnl.gov/science/staff/staff_info.asp?staff_num=7066 T. P. Straatsma]<br />
| Molecular dynamics<br />
|-<br />
|}<br />
<br />
==Active Developers==<br />
<br />
{| border='1' style="width: 100%"<br />
! scope="col" style="width: 30%" align="left" | Name<br />
! scope="col" style="width: 60%" align="left" | Current focus<br />
|-<br />
| [http://www.csm.ornl.gov/ccsg/html/staff/harrison.html R. J. Harrison] (ORNL)<br />
| Multiresolution methods<br />
|-<br />
| [http://www.chem.iastate.edu/faculty/Theresa_Windus/ T. L. Windus] (Iowa State University and AMES)<br />
| Dynamic nucleation theory<br />
|-<br />
| [http://www.alcf.anl.gov/staff-directory/jeff-hammond J. R. Hammond] ([http://www.anl.gov ANL])<br />
| High accuracy response, IBM Blue Gene performance<br />
|-<br />
| [http://www.nsm.buffalo.edu/~jochena/ J. Autschbach] (SUNY Buffalo)<br />
| Response properties, relativistic effects<br />
|-<br />
| [http://research.chem.psu.edu/lxjgroup/ L. Jensen] (Penn State)<br />
| DFT functionals, properties<br />
|- <br />
| [http://iqc.udg.es/~marcel/eng/index.html M. Swart] (Universitat de Girona, Spain)<br />
| SSB-D functionals<br />
|-<br />
| [http://www.bnl.gov/cfn/people/?id=23957 Q. Wu] (BNL)<br />
| Constrained DFT<br />
|- <br />
| [http://www.mit.edu/~chemistry/faculty/vanvoorhis.html T. Van Voorhis] (MIT)<br />
| Constrained DFT<br />
|-<br />
| [http://comp.chem.umn.edu/~zhaoy/ Y. Zhao] (Hewlett-Packard)<br />
| Minnesota (Truhlar) functionals<br />
|-<br />
| R. Peverati (University of Minnesota -Truhlar Group)<br />
| Minnesota (Truhlar) functionals<br />
|-<br />
| K. Lopata (PNNL, NWChem Group)<br />
| RT-TDDFT development<br />
|-<br />
| [http://sites.google.com/site/alvarovazquezmayagoitia/ A. Vazquez-Mayagoitia] ([http://www.anl.gov ANL])<br />
| DFT functionals, properties<br />
|-<br />
| Kiran Bhaskharan Nair (PNNL, NWChem Group)<br />
| Multireference Coupled Cluster (MRCC) Theory development<br />
|-<br />
|}<br />
<br />
==Authors and Contributors ==<br />
<br />
E. Apra, E. J. Bylaska, W. A. de Jong, N. Govind, K. Kowalski,<br />
T. P. Straatsma, M. Valiev, H. J. J. van Dam, D. Wang, T. L. Windus,<br />
J. Hammond, J. Autschbach, K. Bhaskaran-Nair, J. Brabec, K. Lopata,<br />
F. Aquino, S. Hirata, M. T. Hackler, J. Mullin, P. Nichols, R. Peverati,<br />
J. Pittner, Y. Zhao, P.-D. Fan, R. J. Harrison, M. Dupuis, D. Silverstein,<br />
D. M. A. Smith, J. Nieplocha, V. Tipparaju, M. Krishnan, B. E. Van Kuiken,<br />
A. Vazquez-Mayagoitia, L. Jensen, M. Swart, Q. Wu, T. Van Voorhis,<br />
A. A. Auer, M. Nooijen, L. D. Crosby, E. Brown, G. Cisneros, G. I. Fann,<br />
H. Fruchtl, J. Garza, K. Hirao, R. Kendall, J. A. Nichols, K. Tsemekhman,<br />
K. Wolinski, J. Anchell, D. Bernholdt, P. Borowski, T. Clark, D. Clerc,<br />
H. Dachsel, M. Deegan, K. Dyall, D. Elwood, E. Glendening, M. Gutowski,<br />
A. Hess, J. Jaffe, B. Johnson, J. Ju, R. Kobayashi, R. Kutteh, Z. Lin,<br />
R. Littlefield, X. Long, B. Meng, T. Nakajima, S. Niu, L. Pollack, M. Rosing,<br />
K. Glaesemann, G. Sandrone, M. Stave, H. Taylor, G. Thomas, J. H. van Lenthe,<br />
A. Wong, Z. Zhang.</div>Berthttp://www.nwchem-sw.org/index.php/Guidelines_for_AuthorsGuidelines for Authors2013-06-21T18:23:58Z<p>Bert: /* Counters */</p>
<hr />
<div>The current wiki has been created to provide documentation related to NWChem <ref><refbase>13</refbase></ref>. This includes the user manual, tutorials and common practices, as well as programmer references, as well as other useful information. In order to make this wiki as useful as possible to the NWChem community a certain level of consistency of style is useful. To asist with this and beause of the nature of the subject matter of this specific wiki a number of tools and extensions have been selected to help document relevant aspects. These tools and suggestions for their use will be discussed here as well. Obviously for general information on these tools external references will be used.<br />
<br />
== Tools ==<br />
<br />
This wiki has a number of extensions installed to facilitate the documentation process for which it is intended. The configuration of the wiki installation can found at [[Special:Version]]. For the purpose of this wiki there are a number of aspects that are relevant. These include [[Guidelines for Authors#Links|Links]], [[Guidelines for Authors#Equations|Equations]], [[Guidelines for Authors#Citations|Citations]], and [[Guidelines for Authors#Images|Images]]. <br />
<br />
=== Links ===<br />
<br />
Links are an essential tool for integrating information from various sources. The wiki therefore supports a wide variety of links that can be used and details on how to used them can be found at [http://meta.wikimedia.org/wiki/Help:Advanced_editing#Links.2C_URLs Links, URLs]. For general use there are a few types of links that are clearly important. These links include<br />
* intra wiki links to other pages<br />
* intra wiki links to sections of pages<br />
* external links<br />
Below a few simple examples can be found. However, before links are discussed a few comments on how the wiki handles anchors are in order so that there is a construct to link to. <br />
<br />
==== Anchors on wiki pages ====<br />
<br />
Anchors are points on the wiki pages that you can link to. Anchors are either automatically generated by the wiki but can also be created manually.<br />
<br />
The wiki automatically creates anchors for all pages and all headers on each page. This means that you can link to every page and every section or subsection on every page in any case. <br />
<br />
In cases where the automatically generated anchors do not provide for the right points to link to anchors can be created manually. In HTML one would use a construct such as <nowiki><a name="link here">text</a></nowiki>. However, the wiki does not allow the use of the <nowiki><a></nowiki> tag. Instead, the "id" HTML attribute can be used with a number of tags to the same effect. Examples of this are:<br />
<br />
<nowiki><br />
<div id="link here">text</div><br />
<div id="link here"/><br />
<span id="link here">text</span><br />
</nowiki><br />
<br />
Occasionally manually entered anchors are also needed where one would expect automatically generated anchors to work. For example, the automatically generated anchor for the subsection entitled "Dyall's Modified Dirac Hamiltonian approximation" cannot be linked to as the apostrophe character cannot be used in a link. In this case adding an anchor manually for the title allows the subsection to be linked successfully. To see this compare the examples below:<br />
<br />
<nowiki><br />
[[Relativistic_All-electron_Approximations#Dyall's Modified Dirac-Hamiltonian approximation]]<br />
[[Relativistic_All-electron_Approximations#Dyall-Mod-Dirac-Hamiltonian]]<br />
</nowiki><br />
<br />
[[Relativistic_All-electron_Approximations#Dyall's Modified Dirac-Hamiltonian approximation]]<br />
[[Relativistic_All-electron_Approximations#Dyall-Mod-Dirac-Hamiltonian]]<br />
<br />
<br />
==== Intra wiki links to other pages ====<br />
<br />
Links to other pages are generated by placing the page title between double square brackets.<br />
<br />
<nowiki><br />
[[Getting Started]]<br />
[[ECP|Effective Core Potentials]]<br />
</nowiki><br />
<br />
becomes<br />
<br />
[[Getting Started]]<br />
[[ECP|Effective Core Potentials]]<br />
<br />
Note that spaces in the specified page name are automatically replaced by underscores to generate the correct link. In addition the "|" character may be used to specify a label for the link. <br />
<br />
==== Intra wiki links to sections of pages ====<br />
<br />
Links to sections of pages are a simple extension of the links to other pages. Similar to ordinary URLs one simply appends a "#" character followed by the section title. For example<br />
<br />
<nowiki><br />
[[ECP#Scalar ECPs]]<br />
[[ECP#Scalar ECPs|Scalar Effective Core Potentials]]<br />
</nowiki><br />
<br />
results in <br />
<br />
[[ECP#Scalar ECPs]]<br />
[[ECP#Scalar ECPs|Scalar Effective Core Potentials]]<br />
<br />
which takes you to the section "Scalar ECPs" on the ECP page. Obviously the construct to provide labels for links comes in handy to make these links look appealing.<br />
<br />
==== External links ====<br />
<br />
External links can be specified simply by placing the corresponding URL in single square brackets. For example<br />
<br />
<nowiki><br />
[http://dx.doi.org/10.1103/PhysRev.28.1049]<br />
[http://dx.doi.org/10.1103/PhysRev.28.1049 Schr&#0246;dingers wave mechanics (English)]<br />
</nowiki><br />
<br />
becomes<br />
<br />
[http://dx.doi.org/10.1103/PhysRev.28.1049]<br />
[http://dx.doi.org/10.1103/PhysRev.28.1049 Schr&#0246;dingers wave mechanics (English)]<br />
<br />
[http://www.sciencedirect.com/science?_ob=MiamiCaptionURL&_method=retrieve&_udi=B6TJ5-502V6YP-2&_image=fig004&_ba=4&_user=2741876&_coverDate=09%2F30%2F2010&_rdoc=1&_fmt=full&_orig=search&_cdi=5301&_issn=00104655&_pii=S0010465510001438&view=c&_acct=C000058656&_version=1&_urlVersion=0&_userid=2741876&md5=31635e54b2c090ff7f164cf0acad2a04 Hello World]<br />
<br />
<br />
The URLs may, of course, use any of the usual protocols including <nowiki>ftp: and mailto:</nowiki>. Note that in external links the "|" construct to provide a label does not work. Instead the text that appears after the first space is used as the label.<br />
<br />
=== Equations ===<br />
<br />
As people working in the quantum chemistry domain are usually familiar with LaTeX (and the original documentation was written in LaTeX) it is reasonable to provide a mechanism in which equations can be entered in LaTeX on the wiki pages. When a wiki page is saved the LaTeX equations are extracted and transformed to images which are displayed on pages served to readers.<br />
<br />
This capability is offered by the <nowiki><math> ... </math></nowiki> construct. With this construct the time dependent Schr&#0246;dinger equation may be entered as:<br />
<br />
<nowiki><br />
<math><br />
\hat{H}\Psi = i\hbar\frac{\partial}{\partial t}\Psi<br />
</math><br />
</nowiki><br />
<br />
which comes out to look like<br />
<br />
<math><br />
\hat{H}\Psi = i\hbar\frac{\partial}{\partial t}\Psi<br />
</math><br />
<br />
Because the expression is extracted, embedded in some default LaTeX shrubbery, and then passed to the LaTeX program for processing it is clear that only fairly standard mathematical commands are going to work. Therefore all equations need to be written in plain LaTeX without relying on special packages or user defined commands.<br />
<br />
For further details, including a quick LaTeX math reference, more information can be found at [http://meta.wikimedia.org/wiki/Help:Displaying_a_formula displaying a formula].<br />
<br />
=== Images ===<br />
<br />
"One picture says more than a thousand words" is the cliche statement expressing that graphical representations can provide a very direct way to communicate something. For the purposes of this wiki there are three kinds of graphical representations that are clearly useful. They are: Charts (scaling curves, spectra, function plots, etc.), Diagrams (organization of code modules, flow charts, data dependency graphs, etc.), Pictures (images of computer, molecules, developers & collaborators, etc.). Although the need for supporting diagrams is foreseen this is currently not supported for technical reasons. The support for other kinds of graphical representations is described below.<br />
<br />
==== Charts ====<br />
<br />
To include charts on the wiki pages the extension [[http://www.mediawiki.org/wiki/Extension:Pchart4mw pChart4mw]] is supported. Although the link provides a reasonable documentation of the extension the salient points are summarized below. The extension works similar to many other tools. The extension detects certain keywords on the wiki page and extracts the associated data block. The data block is fed to a tool (pChart in this case) which renders a chart based on the data provided. The chart is subsequently included as an image on the page the wiki serves. The advantage of using a tool like this is that charts can easily be updated when new data becomes available. If the chart was uploaded as a picture instead the chances are that it can only be updated by redrawing it from scratch.<br />
<br />
The extension supports a number of different kinds of charts. They are: line charts, bar charts, pie charts, scatter diagrams, radar charts and bubble charts. As line charts are probably the most important ones for our purposes let's look at an example of a scaling curve. <br />
<br />
<nowiki><br />
<plines title="Scaling of NWChem DFT on C240" xtitle="processors" ytitle="time (s)" labels=true xlabels=true<br />
legend=right cubic=true plots=closed><br />
,Fock_2e,Fock_xc,Diag<br />
32, 2777, 35, 26<br />
64, 1392, 19, 16<br />
128, 691, 11, 12<br />
256, 351, 7, 12<br />
512, 178, 5, 12<br />
1024, 91, 4, 12 <br />
2048, 51, 4, 13<br />
4096, 31, 6, 13<br />
</plines><br />
</nowiki><br />
<br />
<plines title="Scaling of NWChem DFT on C240" xtitle="processors" ytitle="time (s)" labels=true xlabels=true<br />
legend=right cubic=true plots=closed><br />
,Fock_2e,Fock_xc,Diag<br />
32, 2777, 35, 26<br />
64, 1392, 19, 16<br />
128, 691, 11, 12<br />
256, 351, 7, 12<br />
512, 178, 5, 12<br />
1024, 91, 4, 12 <br />
2048, 51, 4, 13<br />
4096, 31, 6, 13<br />
</plines><br />
<br />
Obviously there are quite a number of attributes that can be set at the start of the chart data. The [http://code.google.com/p/pchart4mw/wiki/Parameters pChart4mw Parameters] page provides details on which attributes can be set, how and what they mean.<br />
<br />
==== Pictures ====<br />
<br />
There are a variety of situations where the best way to show something is to provide a picture. In order to do this the image file has to be uploaded (see the [[Special:Upload|Upload]] page) to the wiki server. Next a link on the wiki page to the image file has be included. In order to avoid trampling over previously uploaded image files it is recommended to check the list of previously uploaded files at the [[Special:ListFiles|ListFiles]] page.<br />
<br />
As an example the (old) NWChem logo image is used. First the picture was included on with wiki page using<br />
<br />
<nowiki><br />
[[file:Nwchem_logo_dark.png|NWChem logo]]<br />
</nowiki><br />
<br />
to give <br />
<br />
[[file:Nwchem_logo_dark.png|NWChem logo]]<br />
<br />
Alternatively the construct <br />
<br />
<nowiki><br />
[[media:Nwchem_logo_dark.png]]<br />
</nowiki><br />
<br />
gives<br />
<br />
[[media:Nwchem_logo_dark.png]]<br />
<br />
The wiki page generated will include a link to the upload page to upload the file. Following the link the upload page is displayed with the destination file name already filled in (so less opportunity to introduce inconsistencies through typos). After that it is simply a matter of selecting the right file and click the upload button and the picture will appear on the wiki page. <br />
<br />
Note that the <nowiki>[[media: ... ]]</nowiki> construct introduces a link to the file instead of displaying its contents. This might be a good way to provide sample input files, for example.<br />
<br />
=== Citations ===<br />
<br />
In any scientific endeavor linking your statements to the work of others is essential in building interpersonal understanding of the scientific domain. As this wiki is about NWChem only the references cited tend to be related and each reference may be cited multiple times. So for consistency reasons alone it makes sense to store all the references in a single wiki-wide location. For this purpose [http://www.refbase.net/index.php/Web_Reference_Database RefBase] was chosen which is a literature reference data base. The corresponding media wiki extension enables the wiki to query the data base to extract the citation, the citation data is parsed by media wiki's [http://www.mediawiki.org/wiki/Extension:Cite/Cite.php Cite] extension to generate the appropriate links on the page and the table of references at the bottom.<br />
<br />
The consequence of this is that adding references is a two stage process:<br />
# Add the reference data to the data base<br />
# Cite the reference on the wiki page<br />
<br />
==== Adding references in RefBase ====<br />
<br />
To add references to the RefBase data base you will need a RefBase account ([mailto:hubertus.vandam@pnl.gov email e.g. huub] to request one to be set up). Go to [http://nwchemweb.emsl.pnl.gov/refbase/ RefBase] and login to get access to the data base. <br />
At the top of the page, right under the title "Your Literature Database", two new links "add record" and "import" have now appeared.<br />
<br />
Clicking "add record" brings up a form. Simply filling out the various fields on the form and clicking "Save Record" at the bottom of the page will add the data to the data base. It is recommended to also complete the DOI field as that eventually adds a link to the paper on the wiki page.<br />
<br />
Alternatively, clicking "import" brings up a form that allows reference to be imported from external sources. These sources can be files containing references in the EndNote, BibTeX or other formats (see the import page for a complete list), or they can be web-based sources such as DOI, OpenURL, etc. Unfortunately the web-based sources importation does not seem to work at present. What does work is looking the paper up online and using the publisher's export function to export the reference to a file of a format that RefBase recognizes and import this file into RefBase.<br />
<br />
After entering a reference, you can find and inspect the details of it. Particularly relevant in this is the field "Serial" which is the reference number RefBase assigned to it. This is the data base's primary key that you use to cite the reference on a wiki page.<br />
<br />
==== Citing references on wiki pages ====<br />
<br />
The mechanism for citing references from RefBase on a wiki is a two stage one. The first stage is extracting a reference from the RefBase data base. The second stage involves parsing and formatting the reference for presentation on the wiki page. <br />
<br />
To extract a reference from RefBase use the construct<br />
<br />
<nowiki><br />
<refbase>14</refbase><br />
</nowiki><br />
<br />
to obtain<br />
<br />
<refbase>14</refbase><br />
<br />
This information is the same kind of information that could be provided manually to the Cite extension.<br />
For example<br />
<br />
<nowiki><br />
DIIS<br />
<ref>Pulay, P. (1980). "Convergence acceleration of iterative sequences.<br />
the case of scf iteration". Chemical Physics Letters 73: 393-398. <br />
doi:10.1016/0009-2614(80)80396-4. ISSN 0009-2614</ref><br />
</nowiki><br />
<br />
gives<br />
<br />
DIIS<ref>Pulay, P. (1980). "Convergence acceleration of iterative sequences. the case of scf iteration". Chemical Physics Letters 73: 393-398. doi:10.1016/0009-2614(80)80396-4. ISSN 0009-2614</ref><br />
<br />
The combination of RefBase and Cite allows this to be rolled into one as<br />
<br />
<nowiki><br />
DIIS<ref><refbase>14</refbase></ref><br />
</nowiki><br />
<br />
to yield<br />
<br />
DIIS<ref><refbase>14</refbase></ref><br />
<br />
The Cite extension obviously still needs somewhere to put the references being cited. It uses the construct <br />
<br />
<nowiki><br />
<references/><br />
</nowiki><br />
<br />
for this. Where <nowiki><references/></nowiki> is replaced with the list of references. An example of a table generated in this way can be found at the bottom of this page under the heading [[Guidelines for Authors#References|References]].<br />
<br />
=== Jmol extensions ===<br />
<br />
JMol applets can be included in the pages. More information can be found at the [http://www.mediawiki.org/wiki/Extension:Jmol MediaWiki Extension Page] and the [http://wiki.jmol.org/index.php/MediaWiki JMol Wiki Page].<br />
<br />
<center><jmol><br />
<jmolApplet><br />
<title>Ethanol</title><color>gray</color><br />
<uploadedFileContents>Uo2no3o.xyz</uploadedFileContents><br />
<size>200</size><br />
</jmolApplet><br />
</jmol></center><br />
<br />
<br />
<br />
<center><jmol><br />
<jmolApplet><br />
<title>Ethanol</title><color>gray</color><br />
<uploadedFileContents>Diamond.opt.cif</uploadedFileContents><br />
</jmolApplet><br />
</jmol></center><br />
<br />
<jmolFile>Uo2no3o.xyz</jmolFile><br />
<br />
Clicking the link above should pop up a Java Applet window!!!<br />
<br />
==Generating a new copy of the documentation to work on for next development release==<br />
The NWChem 6.0 documentation is in the main namespace, and should be left alone.<br />
The NWChem 6.1 documentation is in the namespace Release61. To make a duplicate of this documentation for Development or for a next release, the following approach works best:<br />
<br />
* Go to Special Pages<br />
* Go to All Pages and select the namespace you want the pages from<br />
* Copy the list<br />
* Go to Export pages<br />
* Past the list, parse to one per line, add "namespace:" in front of each page<br />
* Export the page into an XML document<br />
* Edit the XML document and replace the old namespace with the new one you want to use. Example: replace "Release61:" with "Release 62:" and save.<br />
* Add the new namespace you want to use in the list of defined namespaces with a unique numbering to LocalSettings.php . Also add the new numbers of the namespace of the CollectionArticleNamespaces list in LocalSettings.php<br />
* Go to Import pages<br />
* Read in the file<br />
* Now you have a new set of pages with the new name space. beats copying one page at a time.<br />
<br />
==Updating release documentation on top==<br />
You need to update the page "MediaWiki:Sidebar".<br />
<br />
==Making a PDF of the NWChem documentation==<br />
<br />
* In LocalSettings.php, uncomment the Collections.php extensions (don't leave it there, comment out after you're done so it's not exposed to the users).<br />
<br />
* In "Book Creator" add all individual pages in the documentation (in order). Add chapter headings like the documentation. Export to PDF, and you're done.<br />
<br />
==Movies==<br />
<br />
The effort to add movies to the Wiki pages is under development.<br />
<br />
[[Media:Eric.mpg]]<br />
<br />
<player>Eric.mpg</player><br />
<br />
[[Image:Newtons cradle animation book 2.gif|thumb|200px|The GIF format can be used to display animation, as in this image of Newton's Cradle.]]<br />
<br />
[[Image:Meta-example.gif|The GIF format can be used to display animation, as in this image of metadynamics.]]<br />
<br />
==Counters==<br />
<br />
Below is a list of files and the number of times they have been downloaded. The download counts represent the number of downloads since we introduced the download.php mechanism on October 12, 2012. Downloads before that date have not been counted. The actual files users can obtain from the Download page.<br />
<br />
<table border="1"><br />
<tr><th> File </th><th> Total downloads </th><th> Last download </th></tr><br />
<tr><td> Release 6.3 </td><td> <AfficheDetailsTelechargements name="Nwchem-6.3-src.2013-05-17.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-6.3-src.2013-05-17.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Release 6.3.revision1 </td><td> <AfficheDetailsTelechargements name="Nwchem-6.3.revision1-src.2013-05-28.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-6.3.revision1-src.2013-05-28.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot June 17, 2013 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2013-06-17.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2013-06-17.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Release 6.1.1 </td><td> <AfficheDetailsTelechargements name="Nwchem-6.1.1-src.2012-06-27.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-6.1.1-src.2012-06-27.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot July 25, 2012 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Jul-25.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Jul-25.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot August 27, 2012 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Aug-27.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Aug-27.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot October 02, 2012 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Oct-02.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Oct-02.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot November 06, 2012 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Nov-06.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Nov-06.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot December 01, 2012 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-12-01.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-12-01.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot January 07, 2013 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2013-01-07.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2013-01-07.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot February 06, 2013 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2013-02-06.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2013-02-06.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> </td><td> </td><td> </td></tr><br />
<tr><td> PDF version of NWChem 6.3 documentation pages </td><td> <AfficheDetailsTelechargements name="NWChem6.3_Documentation.pdf" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="NWChem6.3_Documentation.pdf" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> PDF version of documentation pages </td><td> <AfficheDetailsTelechargements name="Nwchem_manual.pdf" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem_manual.pdf" | type="date"></AfficheDetailsTelechargements></td></tr><br />
</table><br />
<br />
== References ==<br />
<references/></div>Berthttp://www.nwchem-sw.org/index.php/Trunk:NWChem_DocumentationTrunk:NWChem Documentation2013-06-21T18:21:55Z<p>Bert: /* NWChem 6.3 User Documentation */</p>
<hr />
<div>__NOTITLE__<br />
=NWChem 6.3 User Documentation=<br />
<br />
A PDF version of the [http://www.nwchem-sw.org/download.php?f=NWChem6.3_Documentation.pdf Documentation pages is available.]<br />
<br />
[[Release62:Overview|'''Overview''']]<br />
{{:Release62:Overview}}<br />
<br />
[[Release62:System Description|'''System Description''']]<br />
{{:Release62:System Description}}<br />
<br />
[[Release62:Quantum Mechanical Methods|'''Quantum Mechanical Methods''']]<br />
{{:Release62:Quantum Mechanical Methods}}<br />
<br />
[[Release62:Classical Methods|'''Classical Methods''']]<br />
{{:Release62:Classical Methods}}<br />
<br />
[[Release62:Hybrid Approaches|'''Hybrid Approaches''']]<br />
{{:Release62:Hybrid Approaches}}<br />
<br />
[[Release62:Potential Energy Surface Analysis|'''Potential Energy Surface Analysis''']]<br />
{{:Release62:Potential Energy Surface Analysis}}<br />
<br />
[[Release62:Electronic Structure Analysis|'''Electronic Structure Analysis''']]<br />
{{:Release62:Electronic Structure Analysis}}<br />
<br />
[[Release62:Other Capabilities|'''Other Capabilities''']]<br />
{{:Release62:Other Capabilities}}<br />
<br />
[[Release62:Examples|'''Examples''']]<br />
{{:Release62:Examples}}<br />
<br />
[[supplementary_information|'''Supplementary Information''']]<br />
{{:supplementary_information}}</div>Berthttp://www.nwchem-sw.org/index.php/Release62:NWChem_DocumentationRelease62:NWChem Documentation2013-06-21T18:21:55Z<p>Bert: /* NWChem 6.3 User Documentation */</p>
<hr />
<div>__NOTITLE__<br />
=NWChem 6.3 User Documentation=<br />
<br />
A PDF version of the [http://www.nwchem-sw.org/download.php?f=NWChem6.3_Documentation.pdf Documentation pages is available.]<br />
<br />
[[Release62:Overview|'''Overview''']]<br />
{{:Release62:Overview}}<br />
<br />
[[Release62:System Description|'''System Description''']]<br />
{{:Release62:System Description}}<br />
<br />
[[Release62:Quantum Mechanical Methods|'''Quantum Mechanical Methods''']]<br />
{{:Release62:Quantum Mechanical Methods}}<br />
<br />
[[Release62:Classical Methods|'''Classical Methods''']]<br />
{{:Release62:Classical Methods}}<br />
<br />
[[Release62:Hybrid Approaches|'''Hybrid Approaches''']]<br />
{{:Release62:Hybrid Approaches}}<br />
<br />
[[Release62:Potential Energy Surface Analysis|'''Potential Energy Surface Analysis''']]<br />
{{:Release62:Potential Energy Surface Analysis}}<br />
<br />
[[Release62:Electronic Structure Analysis|'''Electronic Structure Analysis''']]<br />
{{:Release62:Electronic Structure Analysis}}<br />
<br />
[[Release62:Other Capabilities|'''Other Capabilities''']]<br />
{{:Release62:Other Capabilities}}<br />
<br />
[[Release62:Examples|'''Examples''']]<br />
{{:Release62:Examples}}<br />
<br />
[[supplementary_information|'''Supplementary Information''']]<br />
{{:supplementary_information}}</div>Berthttp://www.nwchem-sw.org/index.php/Trunk:NWChem_DocumentationTrunk:NWChem Documentation2013-06-21T18:21:17Z<p>Bert: /* NWChem 6.3 User Documentation */</p>
<hr />
<div>__NOTITLE__<br />
=NWChem 6.3 User Documentation=<br />
<br />
A PDF version of the [http://www.nwchem-sw.org/download.php?f=NWChem63_Documentation.pdf Documentation pages is available.]<br />
<br />
[[Release62:Overview|'''Overview''']]<br />
{{:Release62:Overview}}<br />
<br />
[[Release62:System Description|'''System Description''']]<br />
{{:Release62:System Description}}<br />
<br />
[[Release62:Quantum Mechanical Methods|'''Quantum Mechanical Methods''']]<br />
{{:Release62:Quantum Mechanical Methods}}<br />
<br />
[[Release62:Classical Methods|'''Classical Methods''']]<br />
{{:Release62:Classical Methods}}<br />
<br />
[[Release62:Hybrid Approaches|'''Hybrid Approaches''']]<br />
{{:Release62:Hybrid Approaches}}<br />
<br />
[[Release62:Potential Energy Surface Analysis|'''Potential Energy Surface Analysis''']]<br />
{{:Release62:Potential Energy Surface Analysis}}<br />
<br />
[[Release62:Electronic Structure Analysis|'''Electronic Structure Analysis''']]<br />
{{:Release62:Electronic Structure Analysis}}<br />
<br />
[[Release62:Other Capabilities|'''Other Capabilities''']]<br />
{{:Release62:Other Capabilities}}<br />
<br />
[[Release62:Examples|'''Examples''']]<br />
{{:Release62:Examples}}<br />
<br />
[[supplementary_information|'''Supplementary Information''']]<br />
{{:supplementary_information}}</div>Berthttp://www.nwchem-sw.org/index.php/Release62:NWChem_DocumentationRelease62:NWChem Documentation2013-06-21T18:21:17Z<p>Bert: /* NWChem 6.3 User Documentation */</p>
<hr />
<div>__NOTITLE__<br />
=NWChem 6.3 User Documentation=<br />
<br />
A PDF version of the [http://www.nwchem-sw.org/download.php?f=NWChem63_Documentation.pdf Documentation pages is available.]<br />
<br />
[[Release62:Overview|'''Overview''']]<br />
{{:Release62:Overview}}<br />
<br />
[[Release62:System Description|'''System Description''']]<br />
{{:Release62:System Description}}<br />
<br />
[[Release62:Quantum Mechanical Methods|'''Quantum Mechanical Methods''']]<br />
{{:Release62:Quantum Mechanical Methods}}<br />
<br />
[[Release62:Classical Methods|'''Classical Methods''']]<br />
{{:Release62:Classical Methods}}<br />
<br />
[[Release62:Hybrid Approaches|'''Hybrid Approaches''']]<br />
{{:Release62:Hybrid Approaches}}<br />
<br />
[[Release62:Potential Energy Surface Analysis|'''Potential Energy Surface Analysis''']]<br />
{{:Release62:Potential Energy Surface Analysis}}<br />
<br />
[[Release62:Electronic Structure Analysis|'''Electronic Structure Analysis''']]<br />
{{:Release62:Electronic Structure Analysis}}<br />
<br />
[[Release62:Other Capabilities|'''Other Capabilities''']]<br />
{{:Release62:Other Capabilities}}<br />
<br />
[[Release62:Examples|'''Examples''']]<br />
{{:Release62:Examples}}<br />
<br />
[[supplementary_information|'''Supplementary Information''']]<br />
{{:supplementary_information}}</div>Berthttp://www.nwchem-sw.org/index.php/Trunk:NWChem_DocumentationTrunk:NWChem Documentation2013-06-21T18:20:55Z<p>Bert: /* NWChem 6.3 User Documentation */</p>
<hr />
<div>__NOTITLE__<br />
=NWChem 6.3 User Documentation=<br />
<br />
A PDF version of the [http://www.nwchem-sw.org/download.php?f=Nwchem63_Documentation.pdf Documentation pages is available.]<br />
<br />
[[Release62:Overview|'''Overview''']]<br />
{{:Release62:Overview}}<br />
<br />
[[Release62:System Description|'''System Description''']]<br />
{{:Release62:System Description}}<br />
<br />
[[Release62:Quantum Mechanical Methods|'''Quantum Mechanical Methods''']]<br />
{{:Release62:Quantum Mechanical Methods}}<br />
<br />
[[Release62:Classical Methods|'''Classical Methods''']]<br />
{{:Release62:Classical Methods}}<br />
<br />
[[Release62:Hybrid Approaches|'''Hybrid Approaches''']]<br />
{{:Release62:Hybrid Approaches}}<br />
<br />
[[Release62:Potential Energy Surface Analysis|'''Potential Energy Surface Analysis''']]<br />
{{:Release62:Potential Energy Surface Analysis}}<br />
<br />
[[Release62:Electronic Structure Analysis|'''Electronic Structure Analysis''']]<br />
{{:Release62:Electronic Structure Analysis}}<br />
<br />
[[Release62:Other Capabilities|'''Other Capabilities''']]<br />
{{:Release62:Other Capabilities}}<br />
<br />
[[Release62:Examples|'''Examples''']]<br />
{{:Release62:Examples}}<br />
<br />
[[supplementary_information|'''Supplementary Information''']]<br />
{{:supplementary_information}}</div>Berthttp://www.nwchem-sw.org/index.php/Release62:NWChem_DocumentationRelease62:NWChem Documentation2013-06-21T18:20:55Z<p>Bert: /* NWChem 6.3 User Documentation */</p>
<hr />
<div>__NOTITLE__<br />
=NWChem 6.3 User Documentation=<br />
<br />
A PDF version of the [http://www.nwchem-sw.org/download.php?f=Nwchem63_Documentation.pdf Documentation pages is available.]<br />
<br />
[[Release62:Overview|'''Overview''']]<br />
{{:Release62:Overview}}<br />
<br />
[[Release62:System Description|'''System Description''']]<br />
{{:Release62:System Description}}<br />
<br />
[[Release62:Quantum Mechanical Methods|'''Quantum Mechanical Methods''']]<br />
{{:Release62:Quantum Mechanical Methods}}<br />
<br />
[[Release62:Classical Methods|'''Classical Methods''']]<br />
{{:Release62:Classical Methods}}<br />
<br />
[[Release62:Hybrid Approaches|'''Hybrid Approaches''']]<br />
{{:Release62:Hybrid Approaches}}<br />
<br />
[[Release62:Potential Energy Surface Analysis|'''Potential Energy Surface Analysis''']]<br />
{{:Release62:Potential Energy Surface Analysis}}<br />
<br />
[[Release62:Electronic Structure Analysis|'''Electronic Structure Analysis''']]<br />
{{:Release62:Electronic Structure Analysis}}<br />
<br />
[[Release62:Other Capabilities|'''Other Capabilities''']]<br />
{{:Release62:Other Capabilities}}<br />
<br />
[[Release62:Examples|'''Examples''']]<br />
{{:Release62:Examples}}<br />
<br />
[[supplementary_information|'''Supplementary Information''']]<br />
{{:supplementary_information}}</div>Berthttp://www.nwchem-sw.org/index.php/File:NWChem6.3_Documentation.pdfFile:NWChem6.3 Documentation.pdf2013-06-21T18:19:56Z<p>Bert: </p>
<hr />
<div></div>Berthttp://www.nwchem-sw.org/index.php/Guidelines_for_AuthorsGuidelines for Authors2013-06-21T18:17:12Z<p>Bert: /* Updating release documentation on top */</p>
<hr />
<div>The current wiki has been created to provide documentation related to NWChem <ref><refbase>13</refbase></ref>. This includes the user manual, tutorials and common practices, as well as programmer references, as well as other useful information. In order to make this wiki as useful as possible to the NWChem community a certain level of consistency of style is useful. To asist with this and beause of the nature of the subject matter of this specific wiki a number of tools and extensions have been selected to help document relevant aspects. These tools and suggestions for their use will be discussed here as well. Obviously for general information on these tools external references will be used.<br />
<br />
== Tools ==<br />
<br />
This wiki has a number of extensions installed to facilitate the documentation process for which it is intended. The configuration of the wiki installation can found at [[Special:Version]]. For the purpose of this wiki there are a number of aspects that are relevant. These include [[Guidelines for Authors#Links|Links]], [[Guidelines for Authors#Equations|Equations]], [[Guidelines for Authors#Citations|Citations]], and [[Guidelines for Authors#Images|Images]]. <br />
<br />
=== Links ===<br />
<br />
Links are an essential tool for integrating information from various sources. The wiki therefore supports a wide variety of links that can be used and details on how to used them can be found at [http://meta.wikimedia.org/wiki/Help:Advanced_editing#Links.2C_URLs Links, URLs]. For general use there are a few types of links that are clearly important. These links include<br />
* intra wiki links to other pages<br />
* intra wiki links to sections of pages<br />
* external links<br />
Below a few simple examples can be found. However, before links are discussed a few comments on how the wiki handles anchors are in order so that there is a construct to link to. <br />
<br />
==== Anchors on wiki pages ====<br />
<br />
Anchors are points on the wiki pages that you can link to. Anchors are either automatically generated by the wiki but can also be created manually.<br />
<br />
The wiki automatically creates anchors for all pages and all headers on each page. This means that you can link to every page and every section or subsection on every page in any case. <br />
<br />
In cases where the automatically generated anchors do not provide for the right points to link to anchors can be created manually. In HTML one would use a construct such as <nowiki><a name="link here">text</a></nowiki>. However, the wiki does not allow the use of the <nowiki><a></nowiki> tag. Instead, the "id" HTML attribute can be used with a number of tags to the same effect. Examples of this are:<br />
<br />
<nowiki><br />
<div id="link here">text</div><br />
<div id="link here"/><br />
<span id="link here">text</span><br />
</nowiki><br />
<br />
Occasionally manually entered anchors are also needed where one would expect automatically generated anchors to work. For example, the automatically generated anchor for the subsection entitled "Dyall's Modified Dirac Hamiltonian approximation" cannot be linked to as the apostrophe character cannot be used in a link. In this case adding an anchor manually for the title allows the subsection to be linked successfully. To see this compare the examples below:<br />
<br />
<nowiki><br />
[[Relativistic_All-electron_Approximations#Dyall's Modified Dirac-Hamiltonian approximation]]<br />
[[Relativistic_All-electron_Approximations#Dyall-Mod-Dirac-Hamiltonian]]<br />
</nowiki><br />
<br />
[[Relativistic_All-electron_Approximations#Dyall's Modified Dirac-Hamiltonian approximation]]<br />
[[Relativistic_All-electron_Approximations#Dyall-Mod-Dirac-Hamiltonian]]<br />
<br />
<br />
==== Intra wiki links to other pages ====<br />
<br />
Links to other pages are generated by placing the page title between double square brackets.<br />
<br />
<nowiki><br />
[[Getting Started]]<br />
[[ECP|Effective Core Potentials]]<br />
</nowiki><br />
<br />
becomes<br />
<br />
[[Getting Started]]<br />
[[ECP|Effective Core Potentials]]<br />
<br />
Note that spaces in the specified page name are automatically replaced by underscores to generate the correct link. In addition the "|" character may be used to specify a label for the link. <br />
<br />
==== Intra wiki links to sections of pages ====<br />
<br />
Links to sections of pages are a simple extension of the links to other pages. Similar to ordinary URLs one simply appends a "#" character followed by the section title. For example<br />
<br />
<nowiki><br />
[[ECP#Scalar ECPs]]<br />
[[ECP#Scalar ECPs|Scalar Effective Core Potentials]]<br />
</nowiki><br />
<br />
results in <br />
<br />
[[ECP#Scalar ECPs]]<br />
[[ECP#Scalar ECPs|Scalar Effective Core Potentials]]<br />
<br />
which takes you to the section "Scalar ECPs" on the ECP page. Obviously the construct to provide labels for links comes in handy to make these links look appealing.<br />
<br />
==== External links ====<br />
<br />
External links can be specified simply by placing the corresponding URL in single square brackets. For example<br />
<br />
<nowiki><br />
[http://dx.doi.org/10.1103/PhysRev.28.1049]<br />
[http://dx.doi.org/10.1103/PhysRev.28.1049 Schr&#0246;dingers wave mechanics (English)]<br />
</nowiki><br />
<br />
becomes<br />
<br />
[http://dx.doi.org/10.1103/PhysRev.28.1049]<br />
[http://dx.doi.org/10.1103/PhysRev.28.1049 Schr&#0246;dingers wave mechanics (English)]<br />
<br />
[http://www.sciencedirect.com/science?_ob=MiamiCaptionURL&_method=retrieve&_udi=B6TJ5-502V6YP-2&_image=fig004&_ba=4&_user=2741876&_coverDate=09%2F30%2F2010&_rdoc=1&_fmt=full&_orig=search&_cdi=5301&_issn=00104655&_pii=S0010465510001438&view=c&_acct=C000058656&_version=1&_urlVersion=0&_userid=2741876&md5=31635e54b2c090ff7f164cf0acad2a04 Hello World]<br />
<br />
<br />
The URLs may, of course, use any of the usual protocols including <nowiki>ftp: and mailto:</nowiki>. Note that in external links the "|" construct to provide a label does not work. Instead the text that appears after the first space is used as the label.<br />
<br />
=== Equations ===<br />
<br />
As people working in the quantum chemistry domain are usually familiar with LaTeX (and the original documentation was written in LaTeX) it is reasonable to provide a mechanism in which equations can be entered in LaTeX on the wiki pages. When a wiki page is saved the LaTeX equations are extracted and transformed to images which are displayed on pages served to readers.<br />
<br />
This capability is offered by the <nowiki><math> ... </math></nowiki> construct. With this construct the time dependent Schr&#0246;dinger equation may be entered as:<br />
<br />
<nowiki><br />
<math><br />
\hat{H}\Psi = i\hbar\frac{\partial}{\partial t}\Psi<br />
</math><br />
</nowiki><br />
<br />
which comes out to look like<br />
<br />
<math><br />
\hat{H}\Psi = i\hbar\frac{\partial}{\partial t}\Psi<br />
</math><br />
<br />
Because the expression is extracted, embedded in some default LaTeX shrubbery, and then passed to the LaTeX program for processing it is clear that only fairly standard mathematical commands are going to work. Therefore all equations need to be written in plain LaTeX without relying on special packages or user defined commands.<br />
<br />
For further details, including a quick LaTeX math reference, more information can be found at [http://meta.wikimedia.org/wiki/Help:Displaying_a_formula displaying a formula].<br />
<br />
=== Images ===<br />
<br />
"One picture says more than a thousand words" is the cliche statement expressing that graphical representations can provide a very direct way to communicate something. For the purposes of this wiki there are three kinds of graphical representations that are clearly useful. They are: Charts (scaling curves, spectra, function plots, etc.), Diagrams (organization of code modules, flow charts, data dependency graphs, etc.), Pictures (images of computer, molecules, developers & collaborators, etc.). Although the need for supporting diagrams is foreseen this is currently not supported for technical reasons. The support for other kinds of graphical representations is described below.<br />
<br />
==== Charts ====<br />
<br />
To include charts on the wiki pages the extension [[http://www.mediawiki.org/wiki/Extension:Pchart4mw pChart4mw]] is supported. Although the link provides a reasonable documentation of the extension the salient points are summarized below. The extension works similar to many other tools. The extension detects certain keywords on the wiki page and extracts the associated data block. The data block is fed to a tool (pChart in this case) which renders a chart based on the data provided. The chart is subsequently included as an image on the page the wiki serves. The advantage of using a tool like this is that charts can easily be updated when new data becomes available. If the chart was uploaded as a picture instead the chances are that it can only be updated by redrawing it from scratch.<br />
<br />
The extension supports a number of different kinds of charts. They are: line charts, bar charts, pie charts, scatter diagrams, radar charts and bubble charts. As line charts are probably the most important ones for our purposes let's look at an example of a scaling curve. <br />
<br />
<nowiki><br />
<plines title="Scaling of NWChem DFT on C240" xtitle="processors" ytitle="time (s)" labels=true xlabels=true<br />
legend=right cubic=true plots=closed><br />
,Fock_2e,Fock_xc,Diag<br />
32, 2777, 35, 26<br />
64, 1392, 19, 16<br />
128, 691, 11, 12<br />
256, 351, 7, 12<br />
512, 178, 5, 12<br />
1024, 91, 4, 12 <br />
2048, 51, 4, 13<br />
4096, 31, 6, 13<br />
</plines><br />
</nowiki><br />
<br />
<plines title="Scaling of NWChem DFT on C240" xtitle="processors" ytitle="time (s)" labels=true xlabels=true<br />
legend=right cubic=true plots=closed><br />
,Fock_2e,Fock_xc,Diag<br />
32, 2777, 35, 26<br />
64, 1392, 19, 16<br />
128, 691, 11, 12<br />
256, 351, 7, 12<br />
512, 178, 5, 12<br />
1024, 91, 4, 12 <br />
2048, 51, 4, 13<br />
4096, 31, 6, 13<br />
</plines><br />
<br />
Obviously there are quite a number of attributes that can be set at the start of the chart data. The [http://code.google.com/p/pchart4mw/wiki/Parameters pChart4mw Parameters] page provides details on which attributes can be set, how and what they mean.<br />
<br />
==== Pictures ====<br />
<br />
There are a variety of situations where the best way to show something is to provide a picture. In order to do this the image file has to be uploaded (see the [[Special:Upload|Upload]] page) to the wiki server. Next a link on the wiki page to the image file has be included. In order to avoid trampling over previously uploaded image files it is recommended to check the list of previously uploaded files at the [[Special:ListFiles|ListFiles]] page.<br />
<br />
As an example the (old) NWChem logo image is used. First the picture was included on with wiki page using<br />
<br />
<nowiki><br />
[[file:Nwchem_logo_dark.png|NWChem logo]]<br />
</nowiki><br />
<br />
to give <br />
<br />
[[file:Nwchem_logo_dark.png|NWChem logo]]<br />
<br />
Alternatively the construct <br />
<br />
<nowiki><br />
[[media:Nwchem_logo_dark.png]]<br />
</nowiki><br />
<br />
gives<br />
<br />
[[media:Nwchem_logo_dark.png]]<br />
<br />
The wiki page generated will include a link to the upload page to upload the file. Following the link the upload page is displayed with the destination file name already filled in (so less opportunity to introduce inconsistencies through typos). After that it is simply a matter of selecting the right file and click the upload button and the picture will appear on the wiki page. <br />
<br />
Note that the <nowiki>[[media: ... ]]</nowiki> construct introduces a link to the file instead of displaying its contents. This might be a good way to provide sample input files, for example.<br />
<br />
=== Citations ===<br />
<br />
In any scientific endeavor linking your statements to the work of others is essential in building interpersonal understanding of the scientific domain. As this wiki is about NWChem only the references cited tend to be related and each reference may be cited multiple times. So for consistency reasons alone it makes sense to store all the references in a single wiki-wide location. For this purpose [http://www.refbase.net/index.php/Web_Reference_Database RefBase] was chosen which is a literature reference data base. The corresponding media wiki extension enables the wiki to query the data base to extract the citation, the citation data is parsed by media wiki's [http://www.mediawiki.org/wiki/Extension:Cite/Cite.php Cite] extension to generate the appropriate links on the page and the table of references at the bottom.<br />
<br />
The consequence of this is that adding references is a two stage process:<br />
# Add the reference data to the data base<br />
# Cite the reference on the wiki page<br />
<br />
==== Adding references in RefBase ====<br />
<br />
To add references to the RefBase data base you will need a RefBase account ([mailto:hubertus.vandam@pnl.gov email e.g. huub] to request one to be set up). Go to [http://nwchemweb.emsl.pnl.gov/refbase/ RefBase] and login to get access to the data base. <br />
At the top of the page, right under the title "Your Literature Database", two new links "add record" and "import" have now appeared.<br />
<br />
Clicking "add record" brings up a form. Simply filling out the various fields on the form and clicking "Save Record" at the bottom of the page will add the data to the data base. It is recommended to also complete the DOI field as that eventually adds a link to the paper on the wiki page.<br />
<br />
Alternatively, clicking "import" brings up a form that allows reference to be imported from external sources. These sources can be files containing references in the EndNote, BibTeX or other formats (see the import page for a complete list), or they can be web-based sources such as DOI, OpenURL, etc. Unfortunately the web-based sources importation does not seem to work at present. What does work is looking the paper up online and using the publisher's export function to export the reference to a file of a format that RefBase recognizes and import this file into RefBase.<br />
<br />
After entering a reference, you can find and inspect the details of it. Particularly relevant in this is the field "Serial" which is the reference number RefBase assigned to it. This is the data base's primary key that you use to cite the reference on a wiki page.<br />
<br />
==== Citing references on wiki pages ====<br />
<br />
The mechanism for citing references from RefBase on a wiki is a two stage one. The first stage is extracting a reference from the RefBase data base. The second stage involves parsing and formatting the reference for presentation on the wiki page. <br />
<br />
To extract a reference from RefBase use the construct<br />
<br />
<nowiki><br />
<refbase>14</refbase><br />
</nowiki><br />
<br />
to obtain<br />
<br />
<refbase>14</refbase><br />
<br />
This information is the same kind of information that could be provided manually to the Cite extension.<br />
For example<br />
<br />
<nowiki><br />
DIIS<br />
<ref>Pulay, P. (1980). "Convergence acceleration of iterative sequences.<br />
the case of scf iteration". Chemical Physics Letters 73: 393-398. <br />
doi:10.1016/0009-2614(80)80396-4. ISSN 0009-2614</ref><br />
</nowiki><br />
<br />
gives<br />
<br />
DIIS<ref>Pulay, P. (1980). "Convergence acceleration of iterative sequences. the case of scf iteration". Chemical Physics Letters 73: 393-398. doi:10.1016/0009-2614(80)80396-4. ISSN 0009-2614</ref><br />
<br />
The combination of RefBase and Cite allows this to be rolled into one as<br />
<br />
<nowiki><br />
DIIS<ref><refbase>14</refbase></ref><br />
</nowiki><br />
<br />
to yield<br />
<br />
DIIS<ref><refbase>14</refbase></ref><br />
<br />
The Cite extension obviously still needs somewhere to put the references being cited. It uses the construct <br />
<br />
<nowiki><br />
<references/><br />
</nowiki><br />
<br />
for this. Where <nowiki><references/></nowiki> is replaced with the list of references. An example of a table generated in this way can be found at the bottom of this page under the heading [[Guidelines for Authors#References|References]].<br />
<br />
=== Jmol extensions ===<br />
<br />
JMol applets can be included in the pages. More information can be found at the [http://www.mediawiki.org/wiki/Extension:Jmol MediaWiki Extension Page] and the [http://wiki.jmol.org/index.php/MediaWiki JMol Wiki Page].<br />
<br />
<center><jmol><br />
<jmolApplet><br />
<title>Ethanol</title><color>gray</color><br />
<uploadedFileContents>Uo2no3o.xyz</uploadedFileContents><br />
<size>200</size><br />
</jmolApplet><br />
</jmol></center><br />
<br />
<br />
<br />
<center><jmol><br />
<jmolApplet><br />
<title>Ethanol</title><color>gray</color><br />
<uploadedFileContents>Diamond.opt.cif</uploadedFileContents><br />
</jmolApplet><br />
</jmol></center><br />
<br />
<jmolFile>Uo2no3o.xyz</jmolFile><br />
<br />
Clicking the link above should pop up a Java Applet window!!!<br />
<br />
==Generating a new copy of the documentation to work on for next development release==<br />
The NWChem 6.0 documentation is in the main namespace, and should be left alone.<br />
The NWChem 6.1 documentation is in the namespace Release61. To make a duplicate of this documentation for Development or for a next release, the following approach works best:<br />
<br />
* Go to Special Pages<br />
* Go to All Pages and select the namespace you want the pages from<br />
* Copy the list<br />
* Go to Export pages<br />
* Past the list, parse to one per line, add "namespace:" in front of each page<br />
* Export the page into an XML document<br />
* Edit the XML document and replace the old namespace with the new one you want to use. Example: replace "Release61:" with "Release 62:" and save.<br />
* Add the new namespace you want to use in the list of defined namespaces with a unique numbering to LocalSettings.php . Also add the new numbers of the namespace of the CollectionArticleNamespaces list in LocalSettings.php<br />
* Go to Import pages<br />
* Read in the file<br />
* Now you have a new set of pages with the new name space. beats copying one page at a time.<br />
<br />
==Updating release documentation on top==<br />
You need to update the page "MediaWiki:Sidebar".<br />
<br />
==Making a PDF of the NWChem documentation==<br />
<br />
* In LocalSettings.php, uncomment the Collections.php extensions (don't leave it there, comment out after you're done so it's not exposed to the users).<br />
<br />
* In "Book Creator" add all individual pages in the documentation (in order). Add chapter headings like the documentation. Export to PDF, and you're done.<br />
<br />
==Movies==<br />
<br />
The effort to add movies to the Wiki pages is under development.<br />
<br />
[[Media:Eric.mpg]]<br />
<br />
<player>Eric.mpg</player><br />
<br />
[[Image:Newtons cradle animation book 2.gif|thumb|200px|The GIF format can be used to display animation, as in this image of Newton's Cradle.]]<br />
<br />
[[Image:Meta-example.gif|The GIF format can be used to display animation, as in this image of metadynamics.]]<br />
<br />
==Counters==<br />
<br />
Below is a list of files and the number of times they have been downloaded. The download counts represent the number of downloads since we introduced the download.php mechanism on October 12, 2012. Downloads before that date have not been counted. The actual files users can obtain from the Download page.<br />
<br />
<table border="1"><br />
<tr><th> File </th><th> Total downloads </th><th> Last download </th></tr><br />
<tr><td> Release 6.3 </td><td> <AfficheDetailsTelechargements name="Nwchem-6.3-src.2013-05-17.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-6.3-src.2013-05-17.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Release 6.3.revision1 </td><td> <AfficheDetailsTelechargements name="Nwchem-6.3.revision1-src.2013-05-28.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-6.3.revision1-src.2013-05-28.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot June 17, 2013 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2013-06-17.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2013-06-17.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Release 6.1.1 </td><td> <AfficheDetailsTelechargements name="Nwchem-6.1.1-src.2012-06-27.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-6.1.1-src.2012-06-27.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot July 25, 2012 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Jul-25.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Jul-25.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot August 27, 2012 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Aug-27.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Aug-27.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot October 02, 2012 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Oct-02.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Oct-02.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot November 06, 2012 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Nov-06.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Nov-06.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot December 01, 2012 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-12-01.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-12-01.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot January 07, 2013 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2013-01-07.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2013-01-07.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot February 06, 2013 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2013-02-06.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2013-02-06.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> </td><td> </td><td> </td></tr><br />
<tr><td> PDF version of documentation pages </td><td> <AfficheDetailsTelechargements name="Nwchem_manual.pdf" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem_manual.pdf" | type="date"></AfficheDetailsTelechargements></td></tr><br />
</table><br />
<br />
== References ==<br />
<references/></div>Berthttp://www.nwchem-sw.org/index.php/Release62:CCCARelease62:CCCA2013-06-21T18:05:54Z<p>Bert: </p>
<hr />
<div>__NOTITLE__<br />
=Correlation consistent Composite Approach (ccCA)=<br />
<br />
The CCCA module calculates the total energy using the correlation consistent Composite Approach (ccCA). At present the ccCA module is designed for the study of main group species only.<br />
<br />
<math>E_{ccCA} = \Delta E_{MP2/CBS} + \Delta E_{CC} + \Delta E_{CV} + \Delta E_{SR} + \Delta E_{ZPE}</math><br />
<br />
where EMP2/CBS is the complete basis set extrapolation of MP2 energies with the aug-cc-pVnZ (n=T,D,Q) series of basis sets, <math>\Delta E_{CC}</math> is the correlation correction,<br />
<br />
<math>\Delta E_{CC} = E_{CCSD(T)/cc-pVTZ} - E_{MP2/cc-pVTZ}</math><br />
<br />
<math>\Delta E_{CV}</math> is the core-valence correction, <br />
<br />
<math>\Delta E_{CV} = E_{MP2(FC1)/aug-cc-pCVTZ} - E_{MP2/aug-cc-pVTZ}</math><br />
<br />
<math>\Delta E_{SR}</math> is the scalar-relativistic correction,<br />
<br />
<math>\Delta E_{SR} = E_{MP2/cc-pVTZ-DK} - E_{MP2/cc-pVTZ}</math><br />
<br />
and <math>\Delta E_{ZPE}</math> is the zero-point energy correction or thermal correction. Geometry optimization and subsequent frequency analysis are performed with B3LYP/cc-pVTZ.<br />
<br />
Suggested reference: N.J. DeYonker, B. R. Wilson, A.W. Pierpont, T.R. Cundari, A.K. Wilson, Mol. Phys. 107, 1107 (2009). Earlier variants for ccCA algorithms can also be found in: N. J. DeYonker, T. R. Cundari, A. K. Wilson, J. Chem. Phys. 124, 114104 (2006).<br />
<br />
The ccCA module can be used to calculate the total single point energy for a fixed geometry and the zero-point energy correction is not available in this calculation. Alternatively the geometry optimization by B3LYP/cc-pVTZ is performed before the single point energy evaluation. For open shell molecules, the number of unpaired electrons must be given explicitly.<br />
<br />
CCCA <br />
[(ENERGY||OPTIMIZE) default ENERGY]<br />
[(DFT||DIRECT) default DFT]<br />
[(MP2||MBPT2) default MP2]<br />
[(RHF||ROHF||UHF) default RHF]<br />
[(CCSD(T)||TCE) default CCSD(T)]<br />
[NOPEN <integer number of unpaired electrons default 0 >]<br />
[(THERM||NOTHERM) default THERM]<br />
[(PRINT||NOPRINT) default NOPRINT]<br />
[BASIS <basis name for orbital projection guess>]<br />
[MOVEC <file name for orbital projection guess>]<br />
END<br />
<br />
One example of input file for single point energy evaluation is given here:<br />
<br />
start h2o_ccca<br />
<br />
title "H2O, ccCA test"<br />
<br />
geometry units au<br />
H 0.0000000000 1.4140780900 -1.1031626600<br />
H 0.0000000000 -1.4140780900 -1.1031626600<br />
O 0.0000000000 0.0000000000 -0.0080100000<br />
end<br />
<br />
task ccca <br />
<br />
An input file for the ground state of O2 with geometry optimization is given below:<br />
<br />
start o2_ccca<br />
<br />
title "O2, ccCA test"<br />
<br />
geometry units au<br />
O 0.0000000000 0.0000000000 -2.0000<br />
O 0.0000000000 0.0000000000 0.0000<br />
end<br />
<br />
ccca<br />
optimize<br />
dft<br />
nopen 2<br />
end<br />
<br />
task ccca</div>Berthttp://www.nwchem-sw.org/index.php/Release62:CCCARelease62:CCCA2013-06-21T18:05:38Z<p>Bert: /* Correlation consistent Composite Approach (ccCA) */</p>
<hr />
<div>__NO TITLE__<br />
=Correlation consistent Composite Approach (ccCA)=<br />
<br />
The CCCA module calculates the total energy using the correlation consistent Composite Approach (ccCA). At present the ccCA module is designed for the study of main group species only.<br />
<br />
<math>E_{ccCA} = \Delta E_{MP2/CBS} + \Delta E_{CC} + \Delta E_{CV} + \Delta E_{SR} + \Delta E_{ZPE}</math><br />
<br />
where EMP2/CBS is the complete basis set extrapolation of MP2 energies with the aug-cc-pVnZ (n=T,D,Q) series of basis sets, <math>\Delta E_{CC}</math> is the correlation correction,<br />
<br />
<math>\Delta E_{CC} = E_{CCSD(T)/cc-pVTZ} - E_{MP2/cc-pVTZ}</math><br />
<br />
<math>\Delta E_{CV}</math> is the core-valence correction, <br />
<br />
<math>\Delta E_{CV} = E_{MP2(FC1)/aug-cc-pCVTZ} - E_{MP2/aug-cc-pVTZ}</math><br />
<br />
<math>\Delta E_{SR}</math> is the scalar-relativistic correction,<br />
<br />
<math>\Delta E_{SR} = E_{MP2/cc-pVTZ-DK} - E_{MP2/cc-pVTZ}</math><br />
<br />
and <math>\Delta E_{ZPE}</math> is the zero-point energy correction or thermal correction. Geometry optimization and subsequent frequency analysis are performed with B3LYP/cc-pVTZ.<br />
<br />
Suggested reference: N.J. DeYonker, B. R. Wilson, A.W. Pierpont, T.R. Cundari, A.K. Wilson, Mol. Phys. 107, 1107 (2009). Earlier variants for ccCA algorithms can also be found in: N. J. DeYonker, T. R. Cundari, A. K. Wilson, J. Chem. Phys. 124, 114104 (2006).<br />
<br />
The ccCA module can be used to calculate the total single point energy for a fixed geometry and the zero-point energy correction is not available in this calculation. Alternatively the geometry optimization by B3LYP/cc-pVTZ is performed before the single point energy evaluation. For open shell molecules, the number of unpaired electrons must be given explicitly.<br />
<br />
CCCA <br />
[(ENERGY||OPTIMIZE) default ENERGY]<br />
[(DFT||DIRECT) default DFT]<br />
[(MP2||MBPT2) default MP2]<br />
[(RHF||ROHF||UHF) default RHF]<br />
[(CCSD(T)||TCE) default CCSD(T)]<br />
[NOPEN <integer number of unpaired electrons default 0 >]<br />
[(THERM||NOTHERM) default THERM]<br />
[(PRINT||NOPRINT) default NOPRINT]<br />
[BASIS <basis name for orbital projection guess>]<br />
[MOVEC <file name for orbital projection guess>]<br />
END<br />
<br />
One example of input file for single point energy evaluation is given here:<br />
<br />
start h2o_ccca<br />
<br />
title "H2O, ccCA test"<br />
<br />
geometry units au<br />
H 0.0000000000 1.4140780900 -1.1031626600<br />
H 0.0000000000 -1.4140780900 -1.1031626600<br />
O 0.0000000000 0.0000000000 -0.0080100000<br />
end<br />
<br />
task ccca <br />
<br />
An input file for the ground state of O2 with geometry optimization is given below:<br />
<br />
start o2_ccca<br />
<br />
title "O2, ccCA test"<br />
<br />
geometry units au<br />
O 0.0000000000 0.0000000000 -2.0000<br />
O 0.0000000000 0.0000000000 0.0000<br />
end<br />
<br />
ccca<br />
optimize<br />
dft<br />
nopen 2<br />
end<br />
<br />
task ccca</div>Berthttp://www.nwchem-sw.org/index.php/Guidelines_for_AuthorsGuidelines for Authors2013-06-21T17:59:26Z<p>Bert: /* Generating a new copy of the documentation to work on for next development release */</p>
<hr />
<div>The current wiki has been created to provide documentation related to NWChem <ref><refbase>13</refbase></ref>. This includes the user manual, tutorials and common practices, as well as programmer references, as well as other useful information. In order to make this wiki as useful as possible to the NWChem community a certain level of consistency of style is useful. To asist with this and beause of the nature of the subject matter of this specific wiki a number of tools and extensions have been selected to help document relevant aspects. These tools and suggestions for their use will be discussed here as well. Obviously for general information on these tools external references will be used.<br />
<br />
== Tools ==<br />
<br />
This wiki has a number of extensions installed to facilitate the documentation process for which it is intended. The configuration of the wiki installation can found at [[Special:Version]]. For the purpose of this wiki there are a number of aspects that are relevant. These include [[Guidelines for Authors#Links|Links]], [[Guidelines for Authors#Equations|Equations]], [[Guidelines for Authors#Citations|Citations]], and [[Guidelines for Authors#Images|Images]]. <br />
<br />
=== Links ===<br />
<br />
Links are an essential tool for integrating information from various sources. The wiki therefore supports a wide variety of links that can be used and details on how to used them can be found at [http://meta.wikimedia.org/wiki/Help:Advanced_editing#Links.2C_URLs Links, URLs]. For general use there are a few types of links that are clearly important. These links include<br />
* intra wiki links to other pages<br />
* intra wiki links to sections of pages<br />
* external links<br />
Below a few simple examples can be found. However, before links are discussed a few comments on how the wiki handles anchors are in order so that there is a construct to link to. <br />
<br />
==== Anchors on wiki pages ====<br />
<br />
Anchors are points on the wiki pages that you can link to. Anchors are either automatically generated by the wiki but can also be created manually.<br />
<br />
The wiki automatically creates anchors for all pages and all headers on each page. This means that you can link to every page and every section or subsection on every page in any case. <br />
<br />
In cases where the automatically generated anchors do not provide for the right points to link to anchors can be created manually. In HTML one would use a construct such as <nowiki><a name="link here">text</a></nowiki>. However, the wiki does not allow the use of the <nowiki><a></nowiki> tag. Instead, the "id" HTML attribute can be used with a number of tags to the same effect. Examples of this are:<br />
<br />
<nowiki><br />
<div id="link here">text</div><br />
<div id="link here"/><br />
<span id="link here">text</span><br />
</nowiki><br />
<br />
Occasionally manually entered anchors are also needed where one would expect automatically generated anchors to work. For example, the automatically generated anchor for the subsection entitled "Dyall's Modified Dirac Hamiltonian approximation" cannot be linked to as the apostrophe character cannot be used in a link. In this case adding an anchor manually for the title allows the subsection to be linked successfully. To see this compare the examples below:<br />
<br />
<nowiki><br />
[[Relativistic_All-electron_Approximations#Dyall's Modified Dirac-Hamiltonian approximation]]<br />
[[Relativistic_All-electron_Approximations#Dyall-Mod-Dirac-Hamiltonian]]<br />
</nowiki><br />
<br />
[[Relativistic_All-electron_Approximations#Dyall's Modified Dirac-Hamiltonian approximation]]<br />
[[Relativistic_All-electron_Approximations#Dyall-Mod-Dirac-Hamiltonian]]<br />
<br />
<br />
==== Intra wiki links to other pages ====<br />
<br />
Links to other pages are generated by placing the page title between double square brackets.<br />
<br />
<nowiki><br />
[[Getting Started]]<br />
[[ECP|Effective Core Potentials]]<br />
</nowiki><br />
<br />
becomes<br />
<br />
[[Getting Started]]<br />
[[ECP|Effective Core Potentials]]<br />
<br />
Note that spaces in the specified page name are automatically replaced by underscores to generate the correct link. In addition the "|" character may be used to specify a label for the link. <br />
<br />
==== Intra wiki links to sections of pages ====<br />
<br />
Links to sections of pages are a simple extension of the links to other pages. Similar to ordinary URLs one simply appends a "#" character followed by the section title. For example<br />
<br />
<nowiki><br />
[[ECP#Scalar ECPs]]<br />
[[ECP#Scalar ECPs|Scalar Effective Core Potentials]]<br />
</nowiki><br />
<br />
results in <br />
<br />
[[ECP#Scalar ECPs]]<br />
[[ECP#Scalar ECPs|Scalar Effective Core Potentials]]<br />
<br />
which takes you to the section "Scalar ECPs" on the ECP page. Obviously the construct to provide labels for links comes in handy to make these links look appealing.<br />
<br />
==== External links ====<br />
<br />
External links can be specified simply by placing the corresponding URL in single square brackets. For example<br />
<br />
<nowiki><br />
[http://dx.doi.org/10.1103/PhysRev.28.1049]<br />
[http://dx.doi.org/10.1103/PhysRev.28.1049 Schr&#0246;dingers wave mechanics (English)]<br />
</nowiki><br />
<br />
becomes<br />
<br />
[http://dx.doi.org/10.1103/PhysRev.28.1049]<br />
[http://dx.doi.org/10.1103/PhysRev.28.1049 Schr&#0246;dingers wave mechanics (English)]<br />
<br />
[http://www.sciencedirect.com/science?_ob=MiamiCaptionURL&_method=retrieve&_udi=B6TJ5-502V6YP-2&_image=fig004&_ba=4&_user=2741876&_coverDate=09%2F30%2F2010&_rdoc=1&_fmt=full&_orig=search&_cdi=5301&_issn=00104655&_pii=S0010465510001438&view=c&_acct=C000058656&_version=1&_urlVersion=0&_userid=2741876&md5=31635e54b2c090ff7f164cf0acad2a04 Hello World]<br />
<br />
<br />
The URLs may, of course, use any of the usual protocols including <nowiki>ftp: and mailto:</nowiki>. Note that in external links the "|" construct to provide a label does not work. Instead the text that appears after the first space is used as the label.<br />
<br />
=== Equations ===<br />
<br />
As people working in the quantum chemistry domain are usually familiar with LaTeX (and the original documentation was written in LaTeX) it is reasonable to provide a mechanism in which equations can be entered in LaTeX on the wiki pages. When a wiki page is saved the LaTeX equations are extracted and transformed to images which are displayed on pages served to readers.<br />
<br />
This capability is offered by the <nowiki><math> ... </math></nowiki> construct. With this construct the time dependent Schr&#0246;dinger equation may be entered as:<br />
<br />
<nowiki><br />
<math><br />
\hat{H}\Psi = i\hbar\frac{\partial}{\partial t}\Psi<br />
</math><br />
</nowiki><br />
<br />
which comes out to look like<br />
<br />
<math><br />
\hat{H}\Psi = i\hbar\frac{\partial}{\partial t}\Psi<br />
</math><br />
<br />
Because the expression is extracted, embedded in some default LaTeX shrubbery, and then passed to the LaTeX program for processing it is clear that only fairly standard mathematical commands are going to work. Therefore all equations need to be written in plain LaTeX without relying on special packages or user defined commands.<br />
<br />
For further details, including a quick LaTeX math reference, more information can be found at [http://meta.wikimedia.org/wiki/Help:Displaying_a_formula displaying a formula].<br />
<br />
=== Images ===<br />
<br />
"One picture says more than a thousand words" is the cliche statement expressing that graphical representations can provide a very direct way to communicate something. For the purposes of this wiki there are three kinds of graphical representations that are clearly useful. They are: Charts (scaling curves, spectra, function plots, etc.), Diagrams (organization of code modules, flow charts, data dependency graphs, etc.), Pictures (images of computer, molecules, developers & collaborators, etc.). Although the need for supporting diagrams is foreseen this is currently not supported for technical reasons. The support for other kinds of graphical representations is described below.<br />
<br />
==== Charts ====<br />
<br />
To include charts on the wiki pages the extension [[http://www.mediawiki.org/wiki/Extension:Pchart4mw pChart4mw]] is supported. Although the link provides a reasonable documentation of the extension the salient points are summarized below. The extension works similar to many other tools. The extension detects certain keywords on the wiki page and extracts the associated data block. The data block is fed to a tool (pChart in this case) which renders a chart based on the data provided. The chart is subsequently included as an image on the page the wiki serves. The advantage of using a tool like this is that charts can easily be updated when new data becomes available. If the chart was uploaded as a picture instead the chances are that it can only be updated by redrawing it from scratch.<br />
<br />
The extension supports a number of different kinds of charts. They are: line charts, bar charts, pie charts, scatter diagrams, radar charts and bubble charts. As line charts are probably the most important ones for our purposes let's look at an example of a scaling curve. <br />
<br />
<nowiki><br />
<plines title="Scaling of NWChem DFT on C240" xtitle="processors" ytitle="time (s)" labels=true xlabels=true<br />
legend=right cubic=true plots=closed><br />
,Fock_2e,Fock_xc,Diag<br />
32, 2777, 35, 26<br />
64, 1392, 19, 16<br />
128, 691, 11, 12<br />
256, 351, 7, 12<br />
512, 178, 5, 12<br />
1024, 91, 4, 12 <br />
2048, 51, 4, 13<br />
4096, 31, 6, 13<br />
</plines><br />
</nowiki><br />
<br />
<plines title="Scaling of NWChem DFT on C240" xtitle="processors" ytitle="time (s)" labels=true xlabels=true<br />
legend=right cubic=true plots=closed><br />
,Fock_2e,Fock_xc,Diag<br />
32, 2777, 35, 26<br />
64, 1392, 19, 16<br />
128, 691, 11, 12<br />
256, 351, 7, 12<br />
512, 178, 5, 12<br />
1024, 91, 4, 12 <br />
2048, 51, 4, 13<br />
4096, 31, 6, 13<br />
</plines><br />
<br />
Obviously there are quite a number of attributes that can be set at the start of the chart data. The [http://code.google.com/p/pchart4mw/wiki/Parameters pChart4mw Parameters] page provides details on which attributes can be set, how and what they mean.<br />
<br />
==== Pictures ====<br />
<br />
There are a variety of situations where the best way to show something is to provide a picture. In order to do this the image file has to be uploaded (see the [[Special:Upload|Upload]] page) to the wiki server. Next a link on the wiki page to the image file has be included. In order to avoid trampling over previously uploaded image files it is recommended to check the list of previously uploaded files at the [[Special:ListFiles|ListFiles]] page.<br />
<br />
As an example the (old) NWChem logo image is used. First the picture was included on with wiki page using<br />
<br />
<nowiki><br />
[[file:Nwchem_logo_dark.png|NWChem logo]]<br />
</nowiki><br />
<br />
to give <br />
<br />
[[file:Nwchem_logo_dark.png|NWChem logo]]<br />
<br />
Alternatively the construct <br />
<br />
<nowiki><br />
[[media:Nwchem_logo_dark.png]]<br />
</nowiki><br />
<br />
gives<br />
<br />
[[media:Nwchem_logo_dark.png]]<br />
<br />
The wiki page generated will include a link to the upload page to upload the file. Following the link the upload page is displayed with the destination file name already filled in (so less opportunity to introduce inconsistencies through typos). After that it is simply a matter of selecting the right file and click the upload button and the picture will appear on the wiki page. <br />
<br />
Note that the <nowiki>[[media: ... ]]</nowiki> construct introduces a link to the file instead of displaying its contents. This might be a good way to provide sample input files, for example.<br />
<br />
=== Citations ===<br />
<br />
In any scientific endeavor linking your statements to the work of others is essential in building interpersonal understanding of the scientific domain. As this wiki is about NWChem only the references cited tend to be related and each reference may be cited multiple times. So for consistency reasons alone it makes sense to store all the references in a single wiki-wide location. For this purpose [http://www.refbase.net/index.php/Web_Reference_Database RefBase] was chosen which is a literature reference data base. The corresponding media wiki extension enables the wiki to query the data base to extract the citation, the citation data is parsed by media wiki's [http://www.mediawiki.org/wiki/Extension:Cite/Cite.php Cite] extension to generate the appropriate links on the page and the table of references at the bottom.<br />
<br />
The consequence of this is that adding references is a two stage process:<br />
# Add the reference data to the data base<br />
# Cite the reference on the wiki page<br />
<br />
==== Adding references in RefBase ====<br />
<br />
To add references to the RefBase data base you will need a RefBase account ([mailto:hubertus.vandam@pnl.gov email e.g. huub] to request one to be set up). Go to [http://nwchemweb.emsl.pnl.gov/refbase/ RefBase] and login to get access to the data base. <br />
At the top of the page, right under the title "Your Literature Database", two new links "add record" and "import" have now appeared.<br />
<br />
Clicking "add record" brings up a form. Simply filling out the various fields on the form and clicking "Save Record" at the bottom of the page will add the data to the data base. It is recommended to also complete the DOI field as that eventually adds a link to the paper on the wiki page.<br />
<br />
Alternatively, clicking "import" brings up a form that allows reference to be imported from external sources. These sources can be files containing references in the EndNote, BibTeX or other formats (see the import page for a complete list), or they can be web-based sources such as DOI, OpenURL, etc. Unfortunately the web-based sources importation does not seem to work at present. What does work is looking the paper up online and using the publisher's export function to export the reference to a file of a format that RefBase recognizes and import this file into RefBase.<br />
<br />
After entering a reference, you can find and inspect the details of it. Particularly relevant in this is the field "Serial" which is the reference number RefBase assigned to it. This is the data base's primary key that you use to cite the reference on a wiki page.<br />
<br />
==== Citing references on wiki pages ====<br />
<br />
The mechanism for citing references from RefBase on a wiki is a two stage one. The first stage is extracting a reference from the RefBase data base. The second stage involves parsing and formatting the reference for presentation on the wiki page. <br />
<br />
To extract a reference from RefBase use the construct<br />
<br />
<nowiki><br />
<refbase>14</refbase><br />
</nowiki><br />
<br />
to obtain<br />
<br />
<refbase>14</refbase><br />
<br />
This information is the same kind of information that could be provided manually to the Cite extension.<br />
For example<br />
<br />
<nowiki><br />
DIIS<br />
<ref>Pulay, P. (1980). "Convergence acceleration of iterative sequences.<br />
the case of scf iteration". Chemical Physics Letters 73: 393-398. <br />
doi:10.1016/0009-2614(80)80396-4. ISSN 0009-2614</ref><br />
</nowiki><br />
<br />
gives<br />
<br />
DIIS<ref>Pulay, P. (1980). "Convergence acceleration of iterative sequences. the case of scf iteration". Chemical Physics Letters 73: 393-398. doi:10.1016/0009-2614(80)80396-4. ISSN 0009-2614</ref><br />
<br />
The combination of RefBase and Cite allows this to be rolled into one as<br />
<br />
<nowiki><br />
DIIS<ref><refbase>14</refbase></ref><br />
</nowiki><br />
<br />
to yield<br />
<br />
DIIS<ref><refbase>14</refbase></ref><br />
<br />
The Cite extension obviously still needs somewhere to put the references being cited. It uses the construct <br />
<br />
<nowiki><br />
<references/><br />
</nowiki><br />
<br />
for this. Where <nowiki><references/></nowiki> is replaced with the list of references. An example of a table generated in this way can be found at the bottom of this page under the heading [[Guidelines for Authors#References|References]].<br />
<br />
=== Jmol extensions ===<br />
<br />
JMol applets can be included in the pages. More information can be found at the [http://www.mediawiki.org/wiki/Extension:Jmol MediaWiki Extension Page] and the [http://wiki.jmol.org/index.php/MediaWiki JMol Wiki Page].<br />
<br />
<center><jmol><br />
<jmolApplet><br />
<title>Ethanol</title><color>gray</color><br />
<uploadedFileContents>Uo2no3o.xyz</uploadedFileContents><br />
<size>200</size><br />
</jmolApplet><br />
</jmol></center><br />
<br />
<br />
<br />
<center><jmol><br />
<jmolApplet><br />
<title>Ethanol</title><color>gray</color><br />
<uploadedFileContents>Diamond.opt.cif</uploadedFileContents><br />
</jmolApplet><br />
</jmol></center><br />
<br />
<jmolFile>Uo2no3o.xyz</jmolFile><br />
<br />
Clicking the link above should pop up a Java Applet window!!!<br />
<br />
==Generating a new copy of the documentation to work on for next development release==<br />
The NWChem 6.0 documentation is in the main namespace, and should be left alone.<br />
The NWChem 6.1 documentation is in the namespace Release61. To make a duplicate of this documentation for Development or for a next release, the following approach works best:<br />
<br />
* Go to Special Pages<br />
* Go to All Pages and select the namespace you want the pages from<br />
* Copy the list<br />
* Go to Export pages<br />
* Past the list, parse to one per line, add "namespace:" in front of each page<br />
* Export the page into an XML document<br />
* Edit the XML document and replace the old namespace with the new one you want to use. Example: replace "Release61:" with "Release 62:" and save.<br />
* Add the new namespace you want to use in the list of defined namespaces with a unique numbering to LocalSettings.php . Also add the new numbers of the namespace of the CollectionArticleNamespaces list in LocalSettings.php<br />
* Go to Import pages<br />
* Read in the file<br />
* Now you have a new set of pages with the new name space. beats copying one page at a time.<br />
<br />
==Updating release documentation on top==<br />
You need to update the page "MediaWiki:Sidebar".<br />
<br />
==Movies==<br />
<br />
The effort to add movies to the Wiki pages is under development.<br />
<br />
[[Media:Eric.mpg]]<br />
<br />
<player>Eric.mpg</player><br />
<br />
[[Image:Newtons cradle animation book 2.gif|thumb|200px|The GIF format can be used to display animation, as in this image of Newton's Cradle.]]<br />
<br />
[[Image:Meta-example.gif|The GIF format can be used to display animation, as in this image of metadynamics.]]<br />
<br />
==Counters==<br />
<br />
Below is a list of files and the number of times they have been downloaded. The download counts represent the number of downloads since we introduced the download.php mechanism on October 12, 2012. Downloads before that date have not been counted. The actual files users can obtain from the Download page.<br />
<br />
<table border="1"><br />
<tr><th> File </th><th> Total downloads </th><th> Last download </th></tr><br />
<tr><td> Release 6.3 </td><td> <AfficheDetailsTelechargements name="Nwchem-6.3-src.2013-05-17.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-6.3-src.2013-05-17.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Release 6.3.revision1 </td><td> <AfficheDetailsTelechargements name="Nwchem-6.3.revision1-src.2013-05-28.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-6.3.revision1-src.2013-05-28.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot June 17, 2013 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2013-06-17.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2013-06-17.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Release 6.1.1 </td><td> <AfficheDetailsTelechargements name="Nwchem-6.1.1-src.2012-06-27.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-6.1.1-src.2012-06-27.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot July 25, 2012 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Jul-25.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Jul-25.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot August 27, 2012 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Aug-27.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Aug-27.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot October 02, 2012 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Oct-02.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Oct-02.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot November 06, 2012 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Nov-06.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Nov-06.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot December 01, 2012 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-12-01.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-12-01.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot January 07, 2013 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2013-01-07.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2013-01-07.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot February 06, 2013 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2013-02-06.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2013-02-06.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> </td><td> </td><td> </td></tr><br />
<tr><td> PDF version of documentation pages </td><td> <AfficheDetailsTelechargements name="Nwchem_manual.pdf" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem_manual.pdf" | type="date"></AfficheDetailsTelechargements></td></tr><br />
</table><br />
<br />
== References ==<br />
<references/></div>Berthttp://www.nwchem-sw.org/index.php/Guidelines_for_AuthorsGuidelines for Authors2013-06-21T17:42:18Z<p>Bert: /* Generating a new copy of the documentation to work on for next development release */</p>
<hr />
<div>The current wiki has been created to provide documentation related to NWChem <ref><refbase>13</refbase></ref>. This includes the user manual, tutorials and common practices, as well as programmer references, as well as other useful information. In order to make this wiki as useful as possible to the NWChem community a certain level of consistency of style is useful. To asist with this and beause of the nature of the subject matter of this specific wiki a number of tools and extensions have been selected to help document relevant aspects. These tools and suggestions for their use will be discussed here as well. Obviously for general information on these tools external references will be used.<br />
<br />
== Tools ==<br />
<br />
This wiki has a number of extensions installed to facilitate the documentation process for which it is intended. The configuration of the wiki installation can found at [[Special:Version]]. For the purpose of this wiki there are a number of aspects that are relevant. These include [[Guidelines for Authors#Links|Links]], [[Guidelines for Authors#Equations|Equations]], [[Guidelines for Authors#Citations|Citations]], and [[Guidelines for Authors#Images|Images]]. <br />
<br />
=== Links ===<br />
<br />
Links are an essential tool for integrating information from various sources. The wiki therefore supports a wide variety of links that can be used and details on how to used them can be found at [http://meta.wikimedia.org/wiki/Help:Advanced_editing#Links.2C_URLs Links, URLs]. For general use there are a few types of links that are clearly important. These links include<br />
* intra wiki links to other pages<br />
* intra wiki links to sections of pages<br />
* external links<br />
Below a few simple examples can be found. However, before links are discussed a few comments on how the wiki handles anchors are in order so that there is a construct to link to. <br />
<br />
==== Anchors on wiki pages ====<br />
<br />
Anchors are points on the wiki pages that you can link to. Anchors are either automatically generated by the wiki but can also be created manually.<br />
<br />
The wiki automatically creates anchors for all pages and all headers on each page. This means that you can link to every page and every section or subsection on every page in any case. <br />
<br />
In cases where the automatically generated anchors do not provide for the right points to link to anchors can be created manually. In HTML one would use a construct such as <nowiki><a name="link here">text</a></nowiki>. However, the wiki does not allow the use of the <nowiki><a></nowiki> tag. Instead, the "id" HTML attribute can be used with a number of tags to the same effect. Examples of this are:<br />
<br />
<nowiki><br />
<div id="link here">text</div><br />
<div id="link here"/><br />
<span id="link here">text</span><br />
</nowiki><br />
<br />
Occasionally manually entered anchors are also needed where one would expect automatically generated anchors to work. For example, the automatically generated anchor for the subsection entitled "Dyall's Modified Dirac Hamiltonian approximation" cannot be linked to as the apostrophe character cannot be used in a link. In this case adding an anchor manually for the title allows the subsection to be linked successfully. To see this compare the examples below:<br />
<br />
<nowiki><br />
[[Relativistic_All-electron_Approximations#Dyall's Modified Dirac-Hamiltonian approximation]]<br />
[[Relativistic_All-electron_Approximations#Dyall-Mod-Dirac-Hamiltonian]]<br />
</nowiki><br />
<br />
[[Relativistic_All-electron_Approximations#Dyall's Modified Dirac-Hamiltonian approximation]]<br />
[[Relativistic_All-electron_Approximations#Dyall-Mod-Dirac-Hamiltonian]]<br />
<br />
<br />
==== Intra wiki links to other pages ====<br />
<br />
Links to other pages are generated by placing the page title between double square brackets.<br />
<br />
<nowiki><br />
[[Getting Started]]<br />
[[ECP|Effective Core Potentials]]<br />
</nowiki><br />
<br />
becomes<br />
<br />
[[Getting Started]]<br />
[[ECP|Effective Core Potentials]]<br />
<br />
Note that spaces in the specified page name are automatically replaced by underscores to generate the correct link. In addition the "|" character may be used to specify a label for the link. <br />
<br />
==== Intra wiki links to sections of pages ====<br />
<br />
Links to sections of pages are a simple extension of the links to other pages. Similar to ordinary URLs one simply appends a "#" character followed by the section title. For example<br />
<br />
<nowiki><br />
[[ECP#Scalar ECPs]]<br />
[[ECP#Scalar ECPs|Scalar Effective Core Potentials]]<br />
</nowiki><br />
<br />
results in <br />
<br />
[[ECP#Scalar ECPs]]<br />
[[ECP#Scalar ECPs|Scalar Effective Core Potentials]]<br />
<br />
which takes you to the section "Scalar ECPs" on the ECP page. Obviously the construct to provide labels for links comes in handy to make these links look appealing.<br />
<br />
==== External links ====<br />
<br />
External links can be specified simply by placing the corresponding URL in single square brackets. For example<br />
<br />
<nowiki><br />
[http://dx.doi.org/10.1103/PhysRev.28.1049]<br />
[http://dx.doi.org/10.1103/PhysRev.28.1049 Schr&#0246;dingers wave mechanics (English)]<br />
</nowiki><br />
<br />
becomes<br />
<br />
[http://dx.doi.org/10.1103/PhysRev.28.1049]<br />
[http://dx.doi.org/10.1103/PhysRev.28.1049 Schr&#0246;dingers wave mechanics (English)]<br />
<br />
[http://www.sciencedirect.com/science?_ob=MiamiCaptionURL&_method=retrieve&_udi=B6TJ5-502V6YP-2&_image=fig004&_ba=4&_user=2741876&_coverDate=09%2F30%2F2010&_rdoc=1&_fmt=full&_orig=search&_cdi=5301&_issn=00104655&_pii=S0010465510001438&view=c&_acct=C000058656&_version=1&_urlVersion=0&_userid=2741876&md5=31635e54b2c090ff7f164cf0acad2a04 Hello World]<br />
<br />
<br />
The URLs may, of course, use any of the usual protocols including <nowiki>ftp: and mailto:</nowiki>. Note that in external links the "|" construct to provide a label does not work. Instead the text that appears after the first space is used as the label.<br />
<br />
=== Equations ===<br />
<br />
As people working in the quantum chemistry domain are usually familiar with LaTeX (and the original documentation was written in LaTeX) it is reasonable to provide a mechanism in which equations can be entered in LaTeX on the wiki pages. When a wiki page is saved the LaTeX equations are extracted and transformed to images which are displayed on pages served to readers.<br />
<br />
This capability is offered by the <nowiki><math> ... </math></nowiki> construct. With this construct the time dependent Schr&#0246;dinger equation may be entered as:<br />
<br />
<nowiki><br />
<math><br />
\hat{H}\Psi = i\hbar\frac{\partial}{\partial t}\Psi<br />
</math><br />
</nowiki><br />
<br />
which comes out to look like<br />
<br />
<math><br />
\hat{H}\Psi = i\hbar\frac{\partial}{\partial t}\Psi<br />
</math><br />
<br />
Because the expression is extracted, embedded in some default LaTeX shrubbery, and then passed to the LaTeX program for processing it is clear that only fairly standard mathematical commands are going to work. Therefore all equations need to be written in plain LaTeX without relying on special packages or user defined commands.<br />
<br />
For further details, including a quick LaTeX math reference, more information can be found at [http://meta.wikimedia.org/wiki/Help:Displaying_a_formula displaying a formula].<br />
<br />
=== Images ===<br />
<br />
"One picture says more than a thousand words" is the cliche statement expressing that graphical representations can provide a very direct way to communicate something. For the purposes of this wiki there are three kinds of graphical representations that are clearly useful. They are: Charts (scaling curves, spectra, function plots, etc.), Diagrams (organization of code modules, flow charts, data dependency graphs, etc.), Pictures (images of computer, molecules, developers & collaborators, etc.). Although the need for supporting diagrams is foreseen this is currently not supported for technical reasons. The support for other kinds of graphical representations is described below.<br />
<br />
==== Charts ====<br />
<br />
To include charts on the wiki pages the extension [[http://www.mediawiki.org/wiki/Extension:Pchart4mw pChart4mw]] is supported. Although the link provides a reasonable documentation of the extension the salient points are summarized below. The extension works similar to many other tools. The extension detects certain keywords on the wiki page and extracts the associated data block. The data block is fed to a tool (pChart in this case) which renders a chart based on the data provided. The chart is subsequently included as an image on the page the wiki serves. The advantage of using a tool like this is that charts can easily be updated when new data becomes available. If the chart was uploaded as a picture instead the chances are that it can only be updated by redrawing it from scratch.<br />
<br />
The extension supports a number of different kinds of charts. They are: line charts, bar charts, pie charts, scatter diagrams, radar charts and bubble charts. As line charts are probably the most important ones for our purposes let's look at an example of a scaling curve. <br />
<br />
<nowiki><br />
<plines title="Scaling of NWChem DFT on C240" xtitle="processors" ytitle="time (s)" labels=true xlabels=true<br />
legend=right cubic=true plots=closed><br />
,Fock_2e,Fock_xc,Diag<br />
32, 2777, 35, 26<br />
64, 1392, 19, 16<br />
128, 691, 11, 12<br />
256, 351, 7, 12<br />
512, 178, 5, 12<br />
1024, 91, 4, 12 <br />
2048, 51, 4, 13<br />
4096, 31, 6, 13<br />
</plines><br />
</nowiki><br />
<br />
<plines title="Scaling of NWChem DFT on C240" xtitle="processors" ytitle="time (s)" labels=true xlabels=true<br />
legend=right cubic=true plots=closed><br />
,Fock_2e,Fock_xc,Diag<br />
32, 2777, 35, 26<br />
64, 1392, 19, 16<br />
128, 691, 11, 12<br />
256, 351, 7, 12<br />
512, 178, 5, 12<br />
1024, 91, 4, 12 <br />
2048, 51, 4, 13<br />
4096, 31, 6, 13<br />
</plines><br />
<br />
Obviously there are quite a number of attributes that can be set at the start of the chart data. The [http://code.google.com/p/pchart4mw/wiki/Parameters pChart4mw Parameters] page provides details on which attributes can be set, how and what they mean.<br />
<br />
==== Pictures ====<br />
<br />
There are a variety of situations where the best way to show something is to provide a picture. In order to do this the image file has to be uploaded (see the [[Special:Upload|Upload]] page) to the wiki server. Next a link on the wiki page to the image file has be included. In order to avoid trampling over previously uploaded image files it is recommended to check the list of previously uploaded files at the [[Special:ListFiles|ListFiles]] page.<br />
<br />
As an example the (old) NWChem logo image is used. First the picture was included on with wiki page using<br />
<br />
<nowiki><br />
[[file:Nwchem_logo_dark.png|NWChem logo]]<br />
</nowiki><br />
<br />
to give <br />
<br />
[[file:Nwchem_logo_dark.png|NWChem logo]]<br />
<br />
Alternatively the construct <br />
<br />
<nowiki><br />
[[media:Nwchem_logo_dark.png]]<br />
</nowiki><br />
<br />
gives<br />
<br />
[[media:Nwchem_logo_dark.png]]<br />
<br />
The wiki page generated will include a link to the upload page to upload the file. Following the link the upload page is displayed with the destination file name already filled in (so less opportunity to introduce inconsistencies through typos). After that it is simply a matter of selecting the right file and click the upload button and the picture will appear on the wiki page. <br />
<br />
Note that the <nowiki>[[media: ... ]]</nowiki> construct introduces a link to the file instead of displaying its contents. This might be a good way to provide sample input files, for example.<br />
<br />
=== Citations ===<br />
<br />
In any scientific endeavor linking your statements to the work of others is essential in building interpersonal understanding of the scientific domain. As this wiki is about NWChem only the references cited tend to be related and each reference may be cited multiple times. So for consistency reasons alone it makes sense to store all the references in a single wiki-wide location. For this purpose [http://www.refbase.net/index.php/Web_Reference_Database RefBase] was chosen which is a literature reference data base. The corresponding media wiki extension enables the wiki to query the data base to extract the citation, the citation data is parsed by media wiki's [http://www.mediawiki.org/wiki/Extension:Cite/Cite.php Cite] extension to generate the appropriate links on the page and the table of references at the bottom.<br />
<br />
The consequence of this is that adding references is a two stage process:<br />
# Add the reference data to the data base<br />
# Cite the reference on the wiki page<br />
<br />
==== Adding references in RefBase ====<br />
<br />
To add references to the RefBase data base you will need a RefBase account ([mailto:hubertus.vandam@pnl.gov email e.g. huub] to request one to be set up). Go to [http://nwchemweb.emsl.pnl.gov/refbase/ RefBase] and login to get access to the data base. <br />
At the top of the page, right under the title "Your Literature Database", two new links "add record" and "import" have now appeared.<br />
<br />
Clicking "add record" brings up a form. Simply filling out the various fields on the form and clicking "Save Record" at the bottom of the page will add the data to the data base. It is recommended to also complete the DOI field as that eventually adds a link to the paper on the wiki page.<br />
<br />
Alternatively, clicking "import" brings up a form that allows reference to be imported from external sources. These sources can be files containing references in the EndNote, BibTeX or other formats (see the import page for a complete list), or they can be web-based sources such as DOI, OpenURL, etc. Unfortunately the web-based sources importation does not seem to work at present. What does work is looking the paper up online and using the publisher's export function to export the reference to a file of a format that RefBase recognizes and import this file into RefBase.<br />
<br />
After entering a reference, you can find and inspect the details of it. Particularly relevant in this is the field "Serial" which is the reference number RefBase assigned to it. This is the data base's primary key that you use to cite the reference on a wiki page.<br />
<br />
==== Citing references on wiki pages ====<br />
<br />
The mechanism for citing references from RefBase on a wiki is a two stage one. The first stage is extracting a reference from the RefBase data base. The second stage involves parsing and formatting the reference for presentation on the wiki page. <br />
<br />
To extract a reference from RefBase use the construct<br />
<br />
<nowiki><br />
<refbase>14</refbase><br />
</nowiki><br />
<br />
to obtain<br />
<br />
<refbase>14</refbase><br />
<br />
This information is the same kind of information that could be provided manually to the Cite extension.<br />
For example<br />
<br />
<nowiki><br />
DIIS<br />
<ref>Pulay, P. (1980). "Convergence acceleration of iterative sequences.<br />
the case of scf iteration". Chemical Physics Letters 73: 393-398. <br />
doi:10.1016/0009-2614(80)80396-4. ISSN 0009-2614</ref><br />
</nowiki><br />
<br />
gives<br />
<br />
DIIS<ref>Pulay, P. (1980). "Convergence acceleration of iterative sequences. the case of scf iteration". Chemical Physics Letters 73: 393-398. doi:10.1016/0009-2614(80)80396-4. ISSN 0009-2614</ref><br />
<br />
The combination of RefBase and Cite allows this to be rolled into one as<br />
<br />
<nowiki><br />
DIIS<ref><refbase>14</refbase></ref><br />
</nowiki><br />
<br />
to yield<br />
<br />
DIIS<ref><refbase>14</refbase></ref><br />
<br />
The Cite extension obviously still needs somewhere to put the references being cited. It uses the construct <br />
<br />
<nowiki><br />
<references/><br />
</nowiki><br />
<br />
for this. Where <nowiki><references/></nowiki> is replaced with the list of references. An example of a table generated in this way can be found at the bottom of this page under the heading [[Guidelines for Authors#References|References]].<br />
<br />
=== Jmol extensions ===<br />
<br />
JMol applets can be included in the pages. More information can be found at the [http://www.mediawiki.org/wiki/Extension:Jmol MediaWiki Extension Page] and the [http://wiki.jmol.org/index.php/MediaWiki JMol Wiki Page].<br />
<br />
<center><jmol><br />
<jmolApplet><br />
<title>Ethanol</title><color>gray</color><br />
<uploadedFileContents>Uo2no3o.xyz</uploadedFileContents><br />
<size>200</size><br />
</jmolApplet><br />
</jmol></center><br />
<br />
<br />
<br />
<center><jmol><br />
<jmolApplet><br />
<title>Ethanol</title><color>gray</color><br />
<uploadedFileContents>Diamond.opt.cif</uploadedFileContents><br />
</jmolApplet><br />
</jmol></center><br />
<br />
<jmolFile>Uo2no3o.xyz</jmolFile><br />
<br />
Clicking the link above should pop up a Java Applet window!!!<br />
<br />
==Generating a new copy of the documentation to work on for next development release==<br />
The NWChem 6.0 documentation is in the main namespace, and should be left alone.<br />
The NWChem 6.1 documentation is in the namespace Release61. To make a duplicate of this documentation for Development or for a next release, the following approach works best:<br />
<br />
* Go to Special Pages<br />
* Go to All Pages and select the namespace you want the pages from<br />
* Copy the list<br />
* Go to Export pages<br />
* Past the list, parse to one per line, add "namespace:" in front of each page<br />
* Export the page into an XML document<br />
* Edit the XML document and replace the old namespace with the new one you want to use. Example: replace "Release61:" with "Release 62:" and save.<br />
* Add the new namespace you want to use add the beginning in the list, and also add this one (with the same numbering) to LocalSettings.php .<br />
* Go to Import pages<br />
* Read in the file<br />
* Now you have a new set of pages with the new name space. beats copying one page at a time.<br />
<br />
==Updating release documentation on top==<br />
You need to update the page "MediaWiki:Sidebar".<br />
<br />
==Movies==<br />
<br />
The effort to add movies to the Wiki pages is under development.<br />
<br />
[[Media:Eric.mpg]]<br />
<br />
<player>Eric.mpg</player><br />
<br />
[[Image:Newtons cradle animation book 2.gif|thumb|200px|The GIF format can be used to display animation, as in this image of Newton's Cradle.]]<br />
<br />
[[Image:Meta-example.gif|The GIF format can be used to display animation, as in this image of metadynamics.]]<br />
<br />
==Counters==<br />
<br />
Below is a list of files and the number of times they have been downloaded. The download counts represent the number of downloads since we introduced the download.php mechanism on October 12, 2012. Downloads before that date have not been counted. The actual files users can obtain from the Download page.<br />
<br />
<table border="1"><br />
<tr><th> File </th><th> Total downloads </th><th> Last download </th></tr><br />
<tr><td> Release 6.3 </td><td> <AfficheDetailsTelechargements name="Nwchem-6.3-src.2013-05-17.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-6.3-src.2013-05-17.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Release 6.3.revision1 </td><td> <AfficheDetailsTelechargements name="Nwchem-6.3.revision1-src.2013-05-28.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-6.3.revision1-src.2013-05-28.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot June 17, 2013 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2013-06-17.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2013-06-17.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Release 6.1.1 </td><td> <AfficheDetailsTelechargements name="Nwchem-6.1.1-src.2012-06-27.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-6.1.1-src.2012-06-27.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot July 25, 2012 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Jul-25.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Jul-25.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot August 27, 2012 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Aug-27.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Aug-27.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot October 02, 2012 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Oct-02.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Oct-02.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot November 06, 2012 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Nov-06.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-Nov-06.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot December 01, 2012 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-12-01.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2012-12-01.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot January 07, 2013 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2013-01-07.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2013-01-07.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> Development snapshot February 06, 2013 </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2013-02-06.tar.gz" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem-src-2013-02-06.tar.gz" | type="date"></AfficheDetailsTelechargements></td></tr><br />
<tr><td> </td><td> </td><td> </td></tr><br />
<tr><td> PDF version of documentation pages </td><td> <AfficheDetailsTelechargements name="Nwchem_manual.pdf" | type="total"></AfficheDetailsTelechargements> </td><td> <AfficheDetailsTelechargements name="Nwchem_manual.pdf" | type="date"></AfficheDetailsTelechargements></td></tr><br />
</table><br />
<br />
== References ==<br />
<references/></div>Berthttp://www.nwchem-sw.org/index.php/Template:Release64:QMMM_Optimization_LinksTemplate:Release64:QMMM Optimization Links2013-06-21T17:39:07Z<p>Bert: Created page with "Potential Energy Surface Analysis: <small> Optimization '''|''' Transition States '''|''' [[Release64:qm..."</p>
<hr />
<div>Potential Energy Surface Analysis: <br />
<small><br />
[[Release64:qmmm_optimization|Optimization]] '''|'''<br />
[[Release64:QMMM_Transition_States|Transition States]] '''|'''<br />
[[Release64:qmmm_freq|Hessians and Frequency]] '''|'''<br />
[[Release64:qmmm_NEB_Calculations|NEB]] '''|'''<br />
</small><br />
----</div>Berthttp://www.nwchem-sw.org/index.php/Template:Release64:QMMM_Single_Point_CalculationsTemplate:Release64:QMMM Single Point Calculations2013-06-21T17:38:09Z<p>Bert: </p>
<hr />
<div>QMMM Single Point Calculations: <br />
<small><br />
[[Release64:qmmm_sp_energy|Ground State Energy and Gradient]] |<br />
[[Release64:QMMM_Excited_States|Excited State Energy]]|<br />
[[Release64:qmmm_sp_property|Properties]] |<br />
[[Release64:QMMM_ESP|ESP]]<br />
</small><br />
----</div>Berthttp://www.nwchem-sw.org/index.php/Template:Release64:QMMM_Single_Point_CalculationsTemplate:Release64:QMMM Single Point Calculations2013-06-21T17:37:57Z<p>Bert: Created page with "QMMM Single Point Calculations: <small> Ground State Energy and Gradient | Excited State Energy| [[Release62:q..."</p>
<hr />
<div>QMMM Single Point Calculations: <br />
<small><br />
[[Release62:qmmm_sp_energy|Ground State Energy and Gradient]] |<br />
[[Release62:QMMM_Excited_States|Excited State Energy]]|<br />
[[Release62:qmmm_sp_property|Properties]] |<br />
[[Release62:QMMM_ESP|ESP]]<br />
</small><br />
----</div>Berthttp://www.nwchem-sw.org/index.php/Template:Release64:QMMM_Input_LinksTemplate:Release64:QMMM Input Links2013-06-21T17:37:23Z<p>Bert: Created page with "QM/MM Input File: <small> QM Parameters | MM Parameters | [[Release62:QMMM_Parameters|Q..."</p>
<hr />
<div>[[Release62:QMMM_Input_File|QM/MM Input File]]: <br />
<small><br />
[[Release62:QM_Parameters|QM Parameters]] |<br />
[[Release62:MM_Parameters|MM Parameters]] |<br />
[[Release62:QMMM_Parameters|QM/MM Parameters]] |<br />
</small><br />
----</div>Berthttp://www.nwchem-sw.org/index.php/Template:Release64:QMMM_Restart_and_Topology_Files_LinksTemplate:Release64:QMMM Restart and Topology Files Links2013-06-21T17:36:25Z<p>Bert: Created page with "QM/MM Restart and Topology files: <small> Prerequisites | [[Release64:qmmm_prepara..."</p>
<hr />
<div>[[Release64:QMMM_Restart_and_Topology_Files|QM/MM Restart and Topology files]]: <br />
<small><br />
[[Release64:QMMM_Preparation_Prerequisites|Prerequisites]] |<br />
[[Release64:qmmm_preparation_basic|QM region definition]] |<br />
[[Release64:qmmm_preparation_solvation|Solvation]] |<br />
[[Release64:qmmm_preparation_constraints|Permanent Constraints]]<br />
</small><br />
----</div>Berthttp://www.nwchem-sw.org/index.php/Release66:ExamplesRelease66:Examples2013-06-21T17:34:08Z<p>Bert: Created page with "__NOTITLE__ *Sample input files *Examples of geometries using symmetry"</p>
<hr />
<div>__NOTITLE__<br />
*[[Release66:Sample|Sample input files]]<br />
<br />
*[[Release66:Geometry_examples|Examples of geometries using symmetry]]</div>Berthttp://www.nwchem-sw.org/index.php/Release65:ExamplesRelease65:Examples2013-06-21T17:34:08Z<p>Bert: Created page with "__NOTITLE__ *Sample input files *Examples of geometries using symmetry"</p>
<hr />
<div>__NOTITLE__<br />
*[[Release64:Sample|Sample input files]]<br />
<br />
*[[Release64:Geometry_examples|Examples of geometries using symmetry]]</div>Berthttp://www.nwchem-sw.org/index.php/Release66:Multiconfiguration_SCFRelease66:Multiconfiguration SCF2013-06-21T17:33:39Z<p>Bert: Created page with "__NOTITLE__ =MCSCF= The NWChem multiconfiguration SCF (MCSCF) module can currently perform complete active space SCF (CASSCF) calculations with at most 20 active orbitals and ab..."</p>
<hr />
<div>__NOTITLE__<br />
=MCSCF=<br />
<br />
The NWChem multiconfiguration SCF (MCSCF) module can currently perform complete active space SCF (CASSCF) calculations with at most 20 active orbitals and about 500 basis functions. <br />
<br />
MCSCF<br />
STATE <string state><br />
ACTIVE <integer nactive><br />
ACTELEC <integer nactelec><br />
MULTIPLICITY <integer multiplicity><br />
[SYMMETRY <integer symmetry default 1>]<br />
[VECTORS [[input] <string input_file default file_prefix.movecs>] <br />
[swap <integer vec1 vec2> ...] \<br />
[output <string output_file default input_file>] \<br />
[lock]<br />
[HESSIAN (exact||onel)]<br />
[MAXITER <integer maxiter default 20>]<br />
[THRESH <real thresh default 1.0e-4>]<br />
[TOL2E <real tol2e default 1.0e-9>]<br />
[LEVEL <real shift default 0.1d0>]<br />
END<br />
<br />
Note that the ACTIVE, ACTELEC, and MULTIPLICITY directives are required. The symmetry and multiplicity may alternatively be entered using the STATE directive.<br />
<br />
==ACTIVE -- Number of active orbitals==<br />
<br />
The number of orbitals in the CASSCF active space must be specified using the ACTIVE directive.<br />
<br />
E.g.,<br />
<br />
active 10<br />
<br />
The input molecular orbitals (see the vectors directive in [[#VECTORS -- Input/output of MO vectors|MCSCF Vectors]] and [[Release62:Hartree-Fock Theory for Molecules#VECTORS -- input/output of MO vectors|SCF Vectors]]) must be arranged in order<br />
<br />
#doubly occupied orbitals,<br />
#active orbitals, and<br />
#unoccupied orbitals.<br />
<br />
==ACTELEC -- Number of active electrons==<br />
<br />
The number of electrons in the CASSCF active space must be specified using the the ACTELEC directive. An error is reported if the number of active electrons and the multiplicity are inconsistent.<br />
<br />
The number of closed shells is determined by subtracting the number of active electrons from the total number of electrons (which in turn is derived from the sum of the nuclear charges minus the total system charge).<br />
<br />
==MULTIPLICITY==<br />
<br />
The spin multiplicity must be specified and is enforced by projection of the determinant wavefunction.<br />
<br />
E.g., to obtain a triplet state<br />
<br />
multiplicity 3<br />
<br />
==SYMMETRY -- Spatial symmetry of the wavefunction==<br />
<br />
This species the irreducible representation of the wavefunction as an integer in the range 1--8 using the same numbering of representations as output by the SCF program. Note that only Abelian point groups are supported.<br />
<br />
E.g., to specify a <math>B_1</math> state when using the <math>C_{2v}</math> group<br />
<br />
symmetry 3<br />
<br />
==STATE -- Symmetry and multiplicity==<br />
<br />
The electronic state (spatial symmetry and multiplicity) may alternatively be specified using the conventional notation for an electronic state, such as <math>^3B_2</math> for a triplet state of <math>B_2</math> symmetry. This would be accomplished with the input<br />
<br />
state 3b2<br />
<br />
which is equivalent to<br />
<br />
symmetry 4<br />
multiplicity 3<br />
<br />
<br />
==VECTORS -- Input/output of MO vectors==<br />
<br />
Calculations are best started from RHF/ROHF molecular orbitals (see [[Release62:Hartree-Fock Theory for Molecules|SCF]]), and by default vectors are taken from the previous MCSCF or SCF calculation. To specify another input file use the VECTORS directive. Vectors are by default output to the input file, and may be redirected using the output keyword. The swap keyword of the [[Release62:Hartree-Fock Theory for Molecules#VECTORS_--_input.2Foutput_of_MO_vectors|VECTORS]] directive may be used to reorder orbitals to obtain the correct active space. <br />
<br />
The [[Release62:Hartree-Fock Theory for Molecules#VECTORS -- input/output of MO vectors|LOCK]] keyword allows the user to specify that the ordering of orbitals will be locked to that of the initial vectors, insofar as possible. The default is to order by ascending orbital energies within each orbital space. One application where locking might be desirable is a calculation where it is necessary to preserve the ordering of a previous geometry, despite flipping of the orbital energies. For such a case, the LOCK directive can be used to prevent the SCF calculation from changing the ordering, even if the orbital energies change.<br />
<br />
Output orbitals of a converged MCSCF calculation are canonicalized as follows:<br />
<br />
* Doubly occupied and unoccupied orbitals diagonalize the corresponding blocks of an effective Fock operator. Note that in the case of degenerate orbital energies this does not fully determine the orbtials.<br />
* Active-space orbitals are chosen as natural orbitals by diagonalization of the active space 1-particle density matrix. Note that in the case of degenerate occupations that this does not fully determine the orbitals.<br />
<br />
==HESSIAN -- Select preconditioner==<br />
<br />
The MCSCF will use a one-electron approximation to the orbital-orbital Hessian until some degree of convergence is obtained, whereupon it will attempt to use the exact orbital-orbital Hessian which makes the micro iterations more expensive but potentially reduces the total number of macro iterations. Either choice may be forced throughout the calculation by specifying the appropriate keyword on the HESSIAN directive.<br />
<br />
E.g., to specify the one-electron approximation throughout<br />
<br />
hessian onel<br />
<br />
==LEVEL -- Level shift for convergence==<br />
<br />
The [[Release62:Hessians & Vibrational Frequencies|Hessian]] used in the MCSCF optimization is by default level shifted by 0.1 until the orbital gradient norm falls below 0.01, at which point the level shift is reduced to zero. The initial value of 0.1 may be changed using the LEVEL directive. Increasing the level shift may make convergence more stable in some instances.<br />
<br />
E.g., to set the initial level shift to 0.5<br />
<br />
level 0.5<br />
<br />
==PRINT and NOPRINT==<br />
<br />
Specific output items can be selectively enabled or disabled using the [[Release62:Top-level#PRINT_.2F_NOPRINT|print control mechanism]] with the available print options listed in the table below.<br />
<br />
<center><br />
{| border='1' cellspacing='0'<br />
|MCSCF Print Options<br />
| Option<br />
| Class<br />
| Synopsis<br />
|-<br />
| ci energy<br />
| default<br />
| CI energy eigenvalue<br />
|-<br />
| fock energy<br />
| default<br />
| Energy derived from Fock matrices<br />
|-<br />
| gradient norm<br />
| default<br />
| Gradient norm<br />
|-<br />
| movecs<br />
| default<br />
| Converged occupied MO vectors<br />
|-<br />
| trace energy<br />
| high<br />
| Trace Energy<br />
|-<br />
| converge info<br />
| high<br />
| Convergence data and monitoring<br />
|-<br />
| precondition<br />
| high<br />
| Orbital preconditioner iterations<br />
|-<br />
| microci<br />
| high<br />
| CI iterations in line search<br />
|-<br />
| canonical<br />
| high<br />
| Canonicalization information<br />
|-<br />
| new movecs<br />
| debug<br />
| MO vectors at each macro-iteration<br />
|-<br />
| ci guess<br />
| debug<br />
| Initial guess CI vector<br />
|-<br />
| density matrix<br />
| debug<br />
| One- and Two-particle density matrices<br />
|}<br />
</center></div>Berthttp://www.nwchem-sw.org/index.php/Release65:Multiconfiguration_SCFRelease65:Multiconfiguration SCF2013-06-21T17:33:39Z<p>Bert: Created page with "__NOTITLE__ =MCSCF= The NWChem multiconfiguration SCF (MCSCF) module can currently perform complete active space SCF (CASSCF) calculations with at most 20 active orbitals and ab..."</p>
<hr />
<div>__NOTITLE__<br />
=MCSCF=<br />
<br />
The NWChem multiconfiguration SCF (MCSCF) module can currently perform complete active space SCF (CASSCF) calculations with at most 20 active orbitals and about 500 basis functions. <br />
<br />
MCSCF<br />
STATE <string state><br />
ACTIVE <integer nactive><br />
ACTELEC <integer nactelec><br />
MULTIPLICITY <integer multiplicity><br />
[SYMMETRY <integer symmetry default 1>]<br />
[VECTORS [[input] <string input_file default file_prefix.movecs>] <br />
[swap <integer vec1 vec2> ...] \<br />
[output <string output_file default input_file>] \<br />
[lock]<br />
[HESSIAN (exact||onel)]<br />
[MAXITER <integer maxiter default 20>]<br />
[THRESH <real thresh default 1.0e-4>]<br />
[TOL2E <real tol2e default 1.0e-9>]<br />
[LEVEL <real shift default 0.1d0>]<br />
END<br />
<br />
Note that the ACTIVE, ACTELEC, and MULTIPLICITY directives are required. The symmetry and multiplicity may alternatively be entered using the STATE directive.<br />
<br />
==ACTIVE -- Number of active orbitals==<br />
<br />
The number of orbitals in the CASSCF active space must be specified using the ACTIVE directive.<br />
<br />
E.g.,<br />
<br />
active 10<br />
<br />
The input molecular orbitals (see the vectors directive in [[#VECTORS -- Input/output of MO vectors|MCSCF Vectors]] and [[Release62:Hartree-Fock Theory for Molecules#VECTORS -- input/output of MO vectors|SCF Vectors]]) must be arranged in order<br />
<br />
#doubly occupied orbitals,<br />
#active orbitals, and<br />
#unoccupied orbitals.<br />
<br />
==ACTELEC -- Number of active electrons==<br />
<br />
The number of electrons in the CASSCF active space must be specified using the the ACTELEC directive. An error is reported if the number of active electrons and the multiplicity are inconsistent.<br />
<br />
The number of closed shells is determined by subtracting the number of active electrons from the total number of electrons (which in turn is derived from the sum of the nuclear charges minus the total system charge).<br />
<br />
==MULTIPLICITY==<br />
<br />
The spin multiplicity must be specified and is enforced by projection of the determinant wavefunction.<br />
<br />
E.g., to obtain a triplet state<br />
<br />
multiplicity 3<br />
<br />
==SYMMETRY -- Spatial symmetry of the wavefunction==<br />
<br />
This species the irreducible representation of the wavefunction as an integer in the range 1--8 using the same numbering of representations as output by the SCF program. Note that only Abelian point groups are supported.<br />
<br />
E.g., to specify a <math>B_1</math> state when using the <math>C_{2v}</math> group<br />
<br />
symmetry 3<br />
<br />
==STATE -- Symmetry and multiplicity==<br />
<br />
The electronic state (spatial symmetry and multiplicity) may alternatively be specified using the conventional notation for an electronic state, such as <math>^3B_2</math> for a triplet state of <math>B_2</math> symmetry. This would be accomplished with the input<br />
<br />
state 3b2<br />
<br />
which is equivalent to<br />
<br />
symmetry 4<br />
multiplicity 3<br />
<br />
<br />
==VECTORS -- Input/output of MO vectors==<br />
<br />
Calculations are best started from RHF/ROHF molecular orbitals (see [[Release62:Hartree-Fock Theory for Molecules|SCF]]), and by default vectors are taken from the previous MCSCF or SCF calculation. To specify another input file use the VECTORS directive. Vectors are by default output to the input file, and may be redirected using the output keyword. The swap keyword of the [[Release62:Hartree-Fock Theory for Molecules#VECTORS_--_input.2Foutput_of_MO_vectors|VECTORS]] directive may be used to reorder orbitals to obtain the correct active space. <br />
<br />
The [[Release62:Hartree-Fock Theory for Molecules#VECTORS -- input/output of MO vectors|LOCK]] keyword allows the user to specify that the ordering of orbitals will be locked to that of the initial vectors, insofar as possible. The default is to order by ascending orbital energies within each orbital space. One application where locking might be desirable is a calculation where it is necessary to preserve the ordering of a previous geometry, despite flipping of the orbital energies. For such a case, the LOCK directive can be used to prevent the SCF calculation from changing the ordering, even if the orbital energies change.<br />
<br />
Output orbitals of a converged MCSCF calculation are canonicalized as follows:<br />
<br />
* Doubly occupied and unoccupied orbitals diagonalize the corresponding blocks of an effective Fock operator. Note that in the case of degenerate orbital energies this does not fully determine the orbtials.<br />
* Active-space orbitals are chosen as natural orbitals by diagonalization of the active space 1-particle density matrix. Note that in the case of degenerate occupations that this does not fully determine the orbitals.<br />
<br />
==HESSIAN -- Select preconditioner==<br />
<br />
The MCSCF will use a one-electron approximation to the orbital-orbital Hessian until some degree of convergence is obtained, whereupon it will attempt to use the exact orbital-orbital Hessian which makes the micro iterations more expensive but potentially reduces the total number of macro iterations. Either choice may be forced throughout the calculation by specifying the appropriate keyword on the HESSIAN directive.<br />
<br />
E.g., to specify the one-electron approximation throughout<br />
<br />
hessian onel<br />
<br />
==LEVEL -- Level shift for convergence==<br />
<br />
The [[Release62:Hessians & Vibrational Frequencies|Hessian]] used in the MCSCF optimization is by default level shifted by 0.1 until the orbital gradient norm falls below 0.01, at which point the level shift is reduced to zero. The initial value of 0.1 may be changed using the LEVEL directive. Increasing the level shift may make convergence more stable in some instances.<br />
<br />
E.g., to set the initial level shift to 0.5<br />
<br />
level 0.5<br />
<br />
==PRINT and NOPRINT==<br />
<br />
Specific output items can be selectively enabled or disabled using the [[Release62:Top-level#PRINT_.2F_NOPRINT|print control mechanism]] with the available print options listed in the table below.<br />
<br />
<center><br />
{| border='1' cellspacing='0'<br />
|MCSCF Print Options<br />
| Option<br />
| Class<br />
| Synopsis<br />
|-<br />
| ci energy<br />
| default<br />
| CI energy eigenvalue<br />
|-<br />
| fock energy<br />
| default<br />
| Energy derived from Fock matrices<br />
|-<br />
| gradient norm<br />
| default<br />
| Gradient norm<br />
|-<br />
| movecs<br />
| default<br />
| Converged occupied MO vectors<br />
|-<br />
| trace energy<br />
| high<br />
| Trace Energy<br />
|-<br />
| converge info<br />
| high<br />
| Convergence data and monitoring<br />
|-<br />
| precondition<br />
| high<br />
| Orbital preconditioner iterations<br />
|-<br />
| microci<br />
| high<br />
| CI iterations in line search<br />
|-<br />
| canonical<br />
| high<br />
| Canonicalization information<br />
|-<br />
| new movecs<br />
| debug<br />
| MO vectors at each macro-iteration<br />
|-<br />
| ci guess<br />
| debug<br />
| Initial guess CI vector<br />
|-<br />
| density matrix<br />
| debug<br />
| One- and Two-particle density matrices<br />
|}<br />
</center></div>Berthttp://www.nwchem-sw.org/index.php/Release65:Excited-State_CalculationsRelease65:Excited-State Calculations2013-06-21T17:33:17Z<p>Bert: Created page with "__NOTITLE__ =CIS, TDHF, TDDFT = ==Overview== NWChem supports a spectrum of single excitation theories for vertical excitation energy calculations, namely, configuration interac..."</p>
<hr />
<div>__NOTITLE__<br />
=CIS, TDHF, TDDFT =<br />
<br />
==Overview==<br />
<br />
NWChem supports a spectrum of single excitation theories for vertical excitation energy calculations, namely, configuration interaction singles (CIS), time-dependent Hartree-Fock (TDHF or also known as random-phase approximation RPA), time-dependent density functional theory (TDDFT),[ref] and Tamm-Dancoff approximation to TDDFT. These methods are implemented in a single framework that invokes Davidson's trial vector algorithm (or its modification for a non-Hermitian eigenvalue problem). The capabilities of the module are summarized as follows:<br />
<br />
* Vertical excitation energies,<br />
* Spin-restricted singlet and triplet excited states for closed-shell systems,<br />
* Spin-unrestricted doublet, etc., excited states for open-shell systems,<br />
* Tamm-Dancoff and full time-dependent linear response theories,<br />
* Davidson's trial vector algorithm,<br />
* Symmetry (irreducible representation) characterization and specification,<br />
* Spin multiplicity characterization and specification,<br />
* Transition moments and oscillator strengths,<br />
* Geometrical first and second derivatives of vertical excitation energies by numerical differentiation,<br />
* Disk-based and fully incore algorithms,<br />
* Multiple and single trial-vector processing algorithms,<br />
* Frozen core and virtual approximation,<br />
* Asymptotically correct exchange-correlation potential by van Leeuwen and Baerends (R. van Leeuwen and E. J. Baerends, Phys. Rev. A 49, 2421 (1994)),<br />
* Asymptotic correction by Casida and Salahub (M. E. Casida, C. Jamorski, K. C. Casida, and D. R. Salahub, J. Chem. Phys. 108, 4439 (1998)),<br />
* Asymptotic correction by Hirata, Zhan, Aprà, Windus, and Dixon (S. Hirata, C.-G. Zhan, E. Aprà, T. L. Windus, and D. A. Dixon, J. Phys. Chem. A 107, 10154 (2003)).<br />
<br />
These are very effective way to rectify the shortcomings of TDDFT when applied to Rydberg excited states (see below).<br />
<br />
==Performance of CIS, TDHF, and TDDFT methods==<br />
<br />
The accuracy of CIS and TDHF for excitation energies of closed-shell systems are comparable to each other, and are normally considered a zeroth-order description of the excitation process. These methods are particularly well balanced in describing Rydberg excited states, in contrast to TDDFT. However, for open-shell systems, the errors in the CIS and TDHF excitation energies are often excessive, primarily due to the multi-determinantal character of the ground and excited state wave functions of open-shell systems in a HF reference.[ref] The scaling of the computational cost of a CIS or TDHF calculation per state with respect to the system size is the same as that for a HF calculation for the ground state, since the critical step of the both methods are the Fock build, namely, the contraction of two-electron integrals with density matrices. It is usually necessary to include two sets of diffuse exponents in the basis set to properly account for the diffuse Rydberg excited states of neutral species.<br />
<br />
The accuracy of TDDFT may vary depending on the exchange-correlation functional. In general, the exchange-correlation functionals that are widely used today and are implemented in NWChem work well for low-lying valence excited states. However, for high-lying diffuse excited states and Rydberg excited states in particular, TDDFT employing these conventional functionals breaks down and the excitation energies are substantially underestimated. This is because of the fact that the exchange-correlation potentials generated from these functionals decay too rapidly (exponentially) as opposed to the slow <math>-1/r</math> asymptotic decay of the true potential. A rough but useful index is the negative of the highest occupied KS orbital energy; when the calculated excitation energies become close to this threshold, these numbers are most likely underestimated relative to experimental results. It appears that TDDFT provides a better-balanced description of radical excited states. This may be traced to the fact that, in DFT, the ground state wave function is represented well as a single KS determinant, with less multi-determinantal character and less spin contamination, and hence the excitation thereof is described well as a simple one electron transition. The computational cost per state of TDDFT calculations scales as the same as the ground state DFT calculations, although the prefactor of the scaling may be much greater in the former.<br />
<br />
A very simple and effecive way to rectify the TDDFT's failure for Rydberg excited states has been proposed by Tozer and Handy (D. J. Tozer and N. C. Handy, J. Chem. Phys. 109, 10180 (1998)) and by Casida and Salahub (see previous reference). They proposed to splice a <math>-1/r</math> asymptotic tail to an exchange-correlation potential that does not have the correct asymptotic behavior. Because the approximate exchange-correlation potentials are too shallow everywhere, a negative constant must be added to them before they can be spliced to the <math>-1/r</math> tail seamlessly in a region that is not sensitive to chemical effects or to the long-range behavior. The negative constant or the shift is usually taken to be the difference of the HOMO energy from the true ionization potential, which can be obtained either from experiment or from a &Delta;SCF calculation. Recently, we proposed a new, expedient, and self-contained asymptotic correction that does not require an ionization potential (or shift) as an external parameter from a separate calculation. In this scheme, the shift is computed by a semi-empirical formula proposed by Zhan, Nichols, and Dixon (C.-G. Zhan, J. A. Nichols, and D. A. Dixon, J. Phys. Chem. A 107, 4184 (2003)). Both Casida-Salahub scheme and this new asymptotic correction scheme give considerably improved (Koopmans type) ionization potentials and Rydberg excitation energies. The latter, however, supply the shift by itself unlike to former.<br />
<br />
==Input syntax==<br />
<br />
The module is called TDDFT as TDDFT employing a hybrid HF-DFT functional encompasses all of the above-mentioned methods implemented. To use this module, one needs to specify TDDFT on the task directive, e.g.,<br />
<br />
TASK TDDFT ENERGY<br />
<br />
for a single-point excitation energy calculation, and<br />
<br />
TASK TDDFT OPTIMIZE<br />
<br />
for an excited-state geometry optimization (and perhaps an adiabatic excitation energy calculation), and<br />
<br />
TASK TDDFT FREQUENCIES<br />
<br />
for an excited-state vibrational frequency calculation. The TDDFT module first invokes DFT module for a ground-state calculation (regardless of whether the calculations uses a HF reference as in CIS or TDHF or a DFT functional), and hence there is no need to perform a separate ground-state DFT calculation prior to calling a TDDFT task. When no second argument of the task directive is given, a single-point excitation energy calculation will be assumed. For geometry optimizations, it is usually necessary to specify the target excited state and its irreducible representation it belongs to. See the subsections TARGET and TARGETSYM for more detail.<br />
<br />
Individual parameters and keywords may be supplied in the TDDFT input block. The syntax is:<br />
<br />
TDDFT<br />
[(CIS||RPA) default RPA]<br />
[NROOTS <integer nroots default 1>]<br />
[MAXVECS <integer maxvecs default 1000>]<br />
[(SINGLET||NOSINGLET) default SINGLET]<br />
[(TRIPLET||NOTRIPLET) default TRIPLET]<br />
[THRESH <double thresh default 1e-4>]<br />
[MAXITER <integer maxiter default 100>]<br />
[TARGET <integer target default 1>]<br />
[TARGETSYM <character targetsym default 'none'>]<br />
[SYMMETRY]<br />
[ECUT] <-cutoff energy><br />
[EWIN] <-lower cutoff energy> <-higher cutoff energy><br />
[alpha] <integer lower orbital> <integer upper orbital><br />
[beta] <integer lower orbital> <integer upper orbital><br />
[CDSPECTRUM]<br />
[VELOCITY]<br />
[ALGORITHM <integer algorithm default 0>]<br />
[FREEZE [[core] (atomic || <integer nfzc default 0>)] \<br />
[virtual <integer nfzv default 0>]]<br />
[PRINT (none||low||medium||high||debug)<br />
<string list_of_names ...>]<br />
END<br />
<br />
The user can also specify the reference wave function in the DFT input block (even when CIS and TDHF calculations are requested). See the section of Sample input and output for more details.<br />
<br />
Since each keyword has a default value, a minimal input file will be<br />
<br />
GEOMETRY<br />
Be 0.0 0.0 0.0<br />
END<br />
BASIS<br />
Be library 6-31G**<br />
END<br />
TASK TDDFT ENERGY<br />
<br />
Note that the keyword for the asymptotic correction must be given in the DFT input block, since all the effects of the correction (and also changes in the computer program) occur in the SCF calculation stage. See [[DFT]] (keyword CS00 and LB94) for details.<br />
<br />
==Keywords of TDDFT input block==<br />
<br />
===CIS and RPA -- the Tamm-Dancoff approximation===<br />
<br />
These keywords toggle the Tamm-Dancoff approximation. CIS means that the Tamm-Dancoff approximation is used and the CIS or Tamm-Dancoff TDDFT calculation is requested. RPA, which is the default, requests TDHF (RPA) or TDDFT calculation.<br />
<br />
The performance of CIS (Tamm-Dancoff TDDFT) and RPA (TDDFT) are comparable in accuracy. However, the computational cost is slightly greater in the latter due to the fact that the latter involves a non-Hermitian eigenvalue problem and requires left and right eigenvectors while the former needs just one set of eigenvectors of a Hermitian eigenvalue problem. The latter has much greater chance of aborting the calculation due to triplet near instability or other instability problems.<br />
<br />
===NROOTS -- the number of excited states===<br />
<br />
One can specify the number of excited state roots to be determined. The default value is 1. It is advised that the users request several more roots than actually needed, since owing to the nature of the trial vector algorithm, some low-lying roots can be missed when they do not have sufficient overlap with the initial guess vectors.<br />
<br />
===MAXVECS -- the subspace size===<br />
<br />
This keyword limits the subspace size of Davidson's algorithm; in other words, it is the maximum number of trial vectors that the calculation is allowed to hold. Typically, 10 to 20 trial vectors are needed for each excited state root to be converged. However, it need not exceed the product of the number of occupied orbitals and the number of virtual orbitals. The default value is 1000.<br />
<br />
===SINGLET and NOSINGLET -- singlet excited states===<br />
<br />
SINGLET (NOSINGLET) requests (suppresses) the calculation of singlet excited states when the reference wave function is closed shell. The default is SINGLET.<br />
<br />
===TRIPLET and NOTRIPLET -- triplet excited states===<br />
<br />
TRIPLET (NOTRIPLET) requests (suppresses) the calculation of triplet excited states when the reference wave function is closed shell. The default is TRIPLET.<br />
<br />
===THRESH -- the convergence threshold of Davidson iteration===<br />
<br />
This keyword specifies the convergence threshold of Davidson's iterative algorithm to solve a matrix eigenvalue problem. The threshold refers to the norm of residual, namely, the difference between the left-hand side and right-hand side of the matrix eigenvalue equation with the current solution vector. With the default value of 1e-4, the excitation energies are usually converged to 1e-5 hartree.<br />
<br />
===MAXITER -- the maximum number of Davidson iteration===<br />
<br />
It typically takes 10-30 iterations for the Davidson algorithm to get converged results. The default value is 100.<br />
<br />
===TARGET and TARGETSYM-- the target root and its symmetry===<br />
<br />
At the moment, the first and second geometrical derivatives of excitation energies that are needed in force, geometry, and frequency calculations are obtained by numerical differentiation. These keywords may be used to specify which excited state root is being used for the geometrical derivative calculation. For instance, when TARGET 3 and TARGETSYM a1g are included in the input block, the total energy (ground state energy plus excitation energy) of the third lowest excited state root (excluding the ground state) transforming as the irreducible representation a1g will be passed to the module which performs the derivative calculations. The default values of these keywords are 1 and none, respectively.<br />
<br />
The keyword TARGETSYM is essential in excited state geometry optimization, since it is very common that the order of excited states changes due to the geometry changes in the course of optimization. Without specifying the TARGETSYM, the optimizer could (and would likely) be optimizing the geometry of an excited state that is different from the one the user had intended to optimize at the starting geometry. On the other hand, in the frequency calculations, TARGETSYM must be none, since the finite displacements given in the course of frequency calculations will lift the spatial symmetry of the equilibrium geometry. When these finite displacements can alter the order of excited states including the target state, the frequency calculation is not be feasible.<br />
<br />
===SYMMETRY -- restricting the excited state symmetry===<br />
<br />
By adding this keyword to the input block, the user can request the module to generate the initial guess vectors transforming as the same irreducible representation as TARGETSYM. This causes the final excited state roots be (exclusively) dominated by those with the specified irreducible representation. This may be useful, when the user is interested in just the optically allowed transitions, or in the geometry optimization of an excited state root with a particular irreducible representation. By default, this option is not set. TARGETSYM must be specified when SYMMETRY is invoked.<br />
<br />
===ECUT -- energy cutoff===<br />
<br />
This keyword enables restricted excitation window TDDFT (REW-TDDFT). This is an approach best suited for core excitations. By specifying this keyword only excitations from occupied states below the energy cutoff will be considered.<br />
<br />
===EWIN -- energy window===<br />
This keyword enables a restricted energy window between a lower energy cutoff and a higher energy cutoff.<br />
For example, ewin -20.0 -10.0 will only consider excitations within the specfied energy window<br />
<br />
=== Alpha, Beta -- alpha, beta orbital windows ===<br />
Orbital windows can be specified using the following keywords:<br />
<br />
* alpha 1 4<br />
* beta 2 5<br />
<br />
Here alpha excitations will be considered from orbitals 1 through 4 depending on the number of roots requested and beta excitations will be considered from orbitals 2 through 5 depending on the number of roots requested.<br />
<br />
===CDSpectrum -- optical rotation calculations===<br />
<br />
Perform optical rotation calculations. <br />
<br />
===VELOCITY -- velocity gauge===<br />
<br />
Perform CD spectrum calculations with the velocity gauge. <br />
<br />
===ALGORITHM -- algorithms for tensor contractions===<br />
<br />
There are four distinct algorithms to choose from, and the default value of 0 (optimal) means that the program makes an optimal choice from the four algorithms on the basis of available memory. In the order of decreasing memory requirement, the four algorithms are:<br />
<br />
* ALGORITHM 1 : Incore, multiple tensor contraction,<br />
* ALGORITHM 2 : Incore, single tensor contraction,<br />
* ALGORITHM 3 : Disk-based, multiple tensor contraction,<br />
* ALGORITHM 4 : Disk-based, single tensor contraction.<br />
<br />
The incore algorithm stores all the trial and product vectors in memory across different nodes with the GA, and often decreases the MAXITER value to accommodate them. The disk-based algorithm stores the vectors on disks across different nodes with the DRA, and retrieves each vector one at a time when it is needed. The multiple and single tensor contraction refers to whether just one or more than one trial vectors are contracted with integrals. The multiple tensor contraction algorithm is particularly effective (in terms of speed) for CIS and TDHF, since the number of the direct evaluations of two-electron integrals is diminished substantially.<br />
<br />
===FREEZE -- the frozen core/virtual approximation===<br />
<br />
Some of the lowest-lying core orbitals and/or some of the highest-lying virtual orbitals may be excluded in the CIS, TDHF, and TDDFT calculations by this keyword (this does not affect the ground state HF or DFT calculation). No orbitals are frozen by default. To exclude the atom-like core regions altogether, one may request<br />
<br />
FREEZE atomic<br />
<br />
To specify the number of lowest-lying occupied orbitals be excluded, one may use<br />
<br />
FREEZE 10<br />
<br />
which causes 10 lowest-lying occupied orbitals excluded. This is equivalent to writing<br />
<br />
FREEZE core 10<br />
<br />
To freeze the highest virtual orbitals, use the virtual keyword. For instance, to freeze the top 5 virtuals<br />
<br />
FREEZE virtual 5<br />
<br />
===PRINT -- the verbosity===<br />
<br />
This keyword changes the level of output verbosity. One may also request some particular items in the table below.<br />
<br />
<br />
<center><br />
{| border='1' cellspacing='0'<br />
|+Printable items in the TDDFT modules and their default print levels.<br />
| Item<br />
| Print Level<br />
| Description<br />
|-<br />
| "timings"<br />
| high<br />
| CPU and wall times spent in each step<br />
|-<br />
| "trial vectors"<br />
| high<br />
| Trial CI vectors<br />
|-<br />
| "initial guess"<br />
| debug<br />
| Initial guess CI vectors<br />
|-<br />
| "general information"<br />
| default<br />
| General information<br />
|-<br />
| &quot;xc information&quot;<br />
| default<br />
| HF/DFT information<br />
|-<br />
| "memory information"<br />
| default<br />
| Memory information<br />
|-<br />
| "convergence"<br />
| debug<br />
| Convergence<br />
|-<br />
| "subspace"<br />
| debug<br />
| Subspace representation of CI matrices<br />
|-<br />
| "transform"<br />
| debug<br />
| MO to AO and AO to MO transformation of CI vectors<br />
|-<br />
| "diagonalization"<br />
| debug<br />
| Diagonalization of CI matrices<br />
|-<br />
| "iteration"<br />
| default<br />
| Davidson iteration update<br />
|-<br />
| "contract"<br />
| debug<br />
| Integral transition density contraction<br />
|-<br />
| "ground state"<br />
| default<br />
| Final result for ground state<br />
|-<br />
| "excited state"<br />
| low<br />
| Final result for target excited state<br />
|}<br />
</center><br />
<br />
<br />
==Sample input==<br />
<br />
The following is a sample input for a spin-restricted TDDFT calculation of singlet excitation energies for the water molecule at the B3LYP/6-31G*.<br />
<br />
START h2o<br />
TITLE "B3LYP/6-31G* H2O"<br />
GEOMETRY<br />
O 0.00000000 0.00000000 0.12982363<br />
H 0.75933475 0.00000000 -0.46621158<br />
H -0.75933475 0.00000000 -0.46621158<br />
END<br />
BASIS<br />
* library 6-31G*<br />
END<br />
DFT<br />
XC B3LYP<br />
END<br />
TDDFT<br />
RPA<br />
NROOTS 20<br />
END<br />
TASK TDDFT ENERGY<br />
<br />
To perform a spin-unrestricted TDHF/aug-cc-pVDZ calculation for the CO+ radical,<br />
<br />
START co<br />
TITLE "TDHF/aug-cc-pVDZ CO+"<br />
CHARGE 1<br />
GEOMETRY<br />
C 0.0 0.0 0.0<br />
O 1.5 0.0 0.0<br />
END<br />
BASIS<br />
* library aug-cc-pVDZ<br />
END<br />
DFT<br />
XC HFexch<br />
MULT 2<br />
END<br />
TDDFT<br />
RPA<br />
NROOTS 5<br />
END<br />
TASK TDDFT ENERGY<br />
<br />
A geometry optimization followed by a frequency calculation for an excited state is carried out for BF at the CIS/6-31G* level in the following sample input.<br />
<br />
START bf<br />
TITLE "CIS/6-31G* BF optimization frequencies"<br />
GEOMETRY<br />
B 0.0 0.0 0.0<br />
F 0.0 0.0 1.2<br />
END<br />
BASIS<br />
* library 6-31G*<br />
END<br />
DFT<br />
XC HFexch<br />
END<br />
TDDFT<br />
CIS<br />
NROOTS 3<br />
NOTRIPLET<br />
TARGET 1<br />
END<br />
TASK TDDFT OPTIMIZE<br />
TASK TDDFT FREQUENCIES<br />
<br />
TDDFT with an asymptotically corrected SVWN exchange-correlation potential. Casida-Salahub scheme has been used with the shift value of 0.1837 a.u. supplied as an input parameter.<br />
<br />
START tddft_ac_co<br />
GEOMETRY<br />
O 0.0 0.0 0.0000<br />
C 0.0 0.0 1.1283<br />
END<br />
BASIS SPHERICAL<br />
C library aug-cc-pVDZ<br />
O library aug-cc-pVDZ<br />
END<br />
DFT<br />
XC Slater VWN_5<br />
CS00 0.1837<br />
END<br />
TDDFT<br />
NROOTS 12<br />
END<br />
TASK TDDFT ENERGY<br />
<br />
TDDFT with an asymptotically corrected B3LYP exchange-correlation potential. Hirata-Zhan-Apra-Windus-Dixon scheme has been used (this is only meaningful with B3LYP functional).<br />
<br />
START tddft_ac_co<br />
GEOMETRY<br />
O 0.0 0.0 0.0000<br />
C 0.0 0.0 1.1283<br />
END<br />
BASIS SPHERICAL<br />
C library aug-cc-pVDZ<br />
O library aug-cc-pVDZ<br />
END<br />
DFT<br />
XC B3LYP<br />
CS00<br />
END<br />
TDDFT<br />
NROOTS 12<br />
END<br />
TASK TDDFT ENERGY<br />
<br />
TDDFT for core states. The following example illustrates the usage of an energy cutoff and energy and orbital windows.<br />
<br />
echo<br />
start h2o_core<br />
memory 1000 mb<br />
geometry units au noautosym noautoz<br />
O 0.00000000 0.00000000 0.22170860<br />
H 0.00000000 1.43758081 -0.88575430<br />
H 0.00000000 -1.43758081 -0.88575430<br />
end<br />
basis<br />
O library 6-31g*<br />
H library 6-31g*<br />
end<br />
dft<br />
xc beckehandh<br />
print "final vector analysis"<br />
end<br />
task dft<br />
tddft<br />
ecut -10<br />
nroots 5<br />
notriplet<br />
thresh 1d-03<br />
end<br />
task tddft<br />
tddft<br />
ewin -20.0 -10.0<br />
cis<br />
nroots 5<br />
notriplet<br />
thresh 1d-03<br />
end<br />
task tddft<br />
dft<br />
odft<br />
mult 1<br />
xc beckehandh<br />
print "final vector analysis"<br />
end<br />
task dft<br />
tddft<br />
alpha 1 1<br />
beta 1 1<br />
cis<br />
nroots 10<br />
notriplet<br />
thresh 1d-03<br />
end<br />
task tddft</div>Berthttp://www.nwchem-sw.org/index.php/Release65:NWChem_DocumentationRelease65:NWChem Documentation2013-06-21T17:32:15Z<p>Bert: /* NWChem 6.3 User Documentation */</p>
<hr />
<div>__NOTITLE__<br />
=NWChem 6.4 User Documentation=<br />
[[Release64:Overview|'''Overview''']]<br />
{{:Release64:Overview}}<br />
<br />
[[Release64:System Description|'''System Description''']]<br />
{{:Release64:System Description}}<br />
<br />
[[Release64:Quantum Mechanical Methods|'''Quantum Mechanical Methods''']]<br />
{{:Release64:Quantum Mechanical Methods}}<br />
<br />
[[Release64:Classical Methods|'''Classical Methods''']]<br />
{{:Release64:Classical Methods}}<br />
<br />
[[Release64:Hybrid Approaches|'''Hybrid Approaches''']]<br />
{{:Release64:Hybrid Approaches}}<br />
<br />
[[Release64:Potential Energy Surface Analysis|'''Potential Energy Surface Analysis''']]<br />
{{:Release64:Potential Energy Surface Analysis}}<br />
<br />
[[Release64:Electronic Structure Analysis|'''Electronic Structure Analysis''']]<br />
{{:Release64:Electronic Structure Analysis}}<br />
<br />
[[Release64:Other Capabilities|'''Other Capabilities''']]<br />
{{:Release64:Other Capabilities}}<br />
<br />
[[Release64:Examples|'''Examples''']]<br />
{{:Release64:Examples}}<br />
<br />
[[supplementary_information|'''Supplementary Information''']]<br />
{{:supplementary_information}}</div>Berthttp://www.nwchem-sw.org/index.php/Release66:VSCFRelease66:VSCF2013-06-21T17:31:35Z<p>Bert: 1 revision</p>
<hr />
<div>__NOTITLE__<br />
=VSCF=<br />
<br />
The VSCF module can be used to calculate the anharmonic contributions to the vibrational modes of the molecule of interest. Energies are calculated on a one-dimensional grid along each normal mode, on a two-dimensional grid along each pair of normal modes, and optionally on a three-dimensional grid along each triplet of normal modes. These energies are then used to calculate the vibrational nuclear wavefunction at an SCF- (VSCF) and MP2-like (cc-VSCF) level of theory.<br />
<br />
VSCF can be used at all levels of theory, SCF and correlated methods, and DFT. For correlated methods, only the SCF level dipole is evaluated and used to calculate the IR intensity values.<br />
<br />
The VSCF module is started when the task directive TASK <theory> vscf is defined in the user input file. The input format has the form:<br />
<br />
VSCF<br />
[coupling <string couplelevel default "pair">]<br />
[ngrid <integer default 16 >]<br />
[iexcite <integer default 1 >]<br />
[vcfct <real default 1.0>]<br />
END<br />
<br />
The order of coupling of the harmonic normal modes included in the calculation is controlled by the specifying:<br />
<br />
coupling <string couplelevel default "pair"><br />
<br />
For coupling=diagonal a one-dimensional grid along each normal mode is computed. For coupling=pair a two-dimensional grid along each pair of normal modes is computed. For coupling=triplet a three-dimensional grid along each triplet of normal modes is computed.<br />
<br />
The number of grid points along each normal mode, or pair of modes can be defined by specifying:<br />
<br />
ngrid <integer default 16><br />
<br />
This VSCF module by default calculates the ground state (v=0), but can also calculate excited states (such as v=1). The number of excited states calculated is defined by specifying:<br />
<br />
iexcite <integer default 1><br />
<br />
With iexcite=1 the fundamental frequencies are calculated. With iexcite=2 the first overtones are calculated. With iexcite=3 the second overtones are calculated.<br />
<br />
In certain cases the pair coupling potentials can become larger than those for a single normal mode. In this case the pair potentials need to be scaled down. The scaling factor used can be defined by specifying:<br />
<br />
vcfct <real default 1.0></div>Berthttp://www.nwchem-sw.org/index.php/Release66:Top-levelRelease66:Top-level2013-06-21T17:31:35Z<p>Bert: 1 revision</p>
<hr />
<div>__NOTITLE__<br />
=Top-level Directives=<br />
<br />
Top-level directives are directives that can affect all modules in the code. Some specify molecular properties or other data that should apply to all subsequent calculations with the current database. However, most top-level directives provide the user with the means to manage the resources for a calculation and to start computations. As the first step in the execution of a job, NWChem scans the entire input file looking for start-up directives, which NWChem must process before all other input. The input file is then rewound and processed sequentially, and each directive is processed in the order in which it is encountered. In this second pass, start-up directives are ignored.<br />
<br />
The following sections describe each of the top-level directives in detail, noting all keywords, options, required input, and defaults.<br />
<br />
==START / RESTART ==<br />
<br />
The START or RESTART directive define the start-up mode and are optional keywords. If one of these two directives is not specified explicitly, the code will infer one, based upon the name of the input file and the availability of the database. When allowing NWChem to infer the start-up directive, the user must be quite certain that the contents of the database will result in the desired action. It is usually more prudent to specify the directive explicitly, using the following format:<br />
<br />
(RESTART || START) [<string file_prefix default input_file_prefix>] \<br />
[rtdb <string rtdb_file_name default file_prefix.db>]<br />
<br />
The START directive indicates that the calculation is one in which a new database is to be created. Any relevant information that<br />
already exists in a previous database of the same name is destroyed. The string variable <file_prefix> will be used as the prefix to name any files created in the course of the calculation. <br />
<br />
E.g., to start a new calculation on water, one might specify<br />
<br />
start water<br />
<br />
which will make all files begin with "water.".<br />
<br />
If the user does not specify an entry for <file_prefix> on the START directive (or omits the START directive<br />
altogether), the code uses the base-name of the input file as the file prefix. That is, the variable <file_prefix> is assigned the name of the input file (not its full pathname), but without the last "dot-suffix". For example, the input file name<br />
/home/dave/job.2.nw yields job.2 as the file prefix, if a name is not assigned explicitly using the START directive.<br />
<br />
The user also has the option of specifying a unique name for the database, using the keyword rtdb. When this keyword is entered, the string entered for rtdb_file_name is used as the database name. If the keyword rtdb is omitted, the name of the database defaults to file_prefix.db in the directory for permanent files.<br />
<br />
If a calculation is to start from a previous calculation and go on using the existing database, the RESTART directive must be used. In such a case, the previous database must already exist. The name specified for <file_prefix> usually should<br />
not be changed when restarting a calculation. If it is changed, NWChem will not be able to find needed files when going on with the<br />
calculation.<br />
<br />
In the most common situation, the previous calculation was completed (with or without an error condition), and it is desired to perform a new task or restart the previous one, perhaps with some input changes. In these instances, the RESTART directive should be used. This re-uses the previous database and associated files, and reads the input file for new input and task information.<br />
<br />
The RESTART directive looks immediately for new input and task information, deleting information about previous incomplete tasks.<br />
For example, when doing a RESTART there is no need to specify geometry or basis set declaration because the program will detect this information since it is stored in the run-time database.<br />
<br />
If a calculation runs out of time, for example because it is on a queuing system, this is another instance where doing a<br />
RESTART is advisable. Simply include nothing after the RESTART directive except those tasks that are unfinished.<br />
<br />
To summarize the default options for this start-up directive, if the input file does not contain a START or a RESTART directive, then<br />
*the variable <file_prefix> is assigned the name of the input file for the job, without the suffix (which is usually .nw)<br />
*the variable <rtdb_file_name> is assigned the default name, file_prefix.db<br />
<br />
If the database with name file_prefix.db does not already exist, the calculation is carried out as if a START directive had been encountered. If the database with name file_prefix.db does exist, then the calculation is performed as if a RESTART directive had been encountered. <br />
<br />
For example, NWChem can be run using an input file with the name water.nw by typing the UNIX command line,<br />
<br />
nwchem water.nw<br />
<br />
If the NWChem input file water.nw does not contain a START or RESTART directive, the code sets the variable <file_prefix> to water. Files created by the job will have this prefix, and the database will be named water.db. If the database water.db does not exist already, the code behaves as if the input file contains the directive,<br />
<br />
start water<br />
<br />
If the database water.db does exist, the code behaves as if the input file contained the directive,<br />
<br />
restart water<br />
<br />
==PERMANENT_DIR==<br />
<br />
This start-up directive allows the user to specify the directory location of permanent files created by NWChem. NWChem distinguishes between permanent (or persistent) files and scratch (or temporary) files, and allows the user the option of putting them in different locations. In most installations, however, permanent and scratch files are all written to the current directory by default. What constitutes &quot;local&quot; disk space may also differ from machine to machine.<br />
<br />
The PERMANENT_DIR directives enable the user to specify a single directory for all processes or different directories for different processes. The general form of the directive is as follows:<br />
<br />
(PERMANENT_DIR) [(<string host&>||<integer process>):] <string directory> [...]<br />
<br />
==SCRATCH_DIR==<br />
<br />
This start-up directive allows the user to specify the directory location of scratch files created by NWChem. NWChem distinguishes between permanent (or persistent) files and scratch (or temporary) files, and allows the user the option of putting them in different locations. In most installations, however, permanent and scratch files are all written to the current directory by default. What constitutes &quot;local&quot; disk space may also differ from machine to machine.<br />
<br />
The conventions for file storage are at the discretion of the specific installation, and are quite likely to be different on different machines. When assigning locations for permanent and scratch files, the user must be cognizant of the characteristics of the installation on a particular platform. To consider just a few examples, on clusters, machine-specific or process-specific names must be supplied for both local and shared file systems, while on SMPs it is useful to specify scratch file directories with automated striping across processors with round-robin allocation. On SMP clusters (a.k.a. constellations), both of these specifications are required. <br />
<br />
The SCRATCH_DIR enables the user to specify a single directory for all processes or different directories for different processes. The general form of the directive is as follows:<br />
<br />
(SCRATCH_DIR) [(<string host&>||<integer process>):] <string directory> [...]<br />
<br />
Directories are extracted from the user input by executing the following steps, in sequence:<br />
#Look for a directory qualified by the process ID number of the invoking process. Processes are numbered from zero. Else,<br />
#If there is a list of directories qualified by the name of the host machineAs returned by util_hostname() which maps to the output of the command hostname on Unix workstations., then use round-robin allocation from the list for processes executing on the given host. Else,<br />
#If there is a list of directories unqualified by any hostname or process ID, then use round-robin allocation from this list.<br />
<br />
If directory allocation directive(s) are not specified in the input file, or if no match is found to the directory names specified by input using these directives, then the steps above are executed using the installation-specific defaults. If the code cannot find a valid directory name based on the input specified in either the directive(s) or the system defaults, files are automatically written to the current working directory (".").<br />
<br />
The following is a list of examples of specific allocations of scratch directory locations:<br />
*Put scratch files from all processes in the local scratch directory (Warning: the definition of "local scratch directory" may change from machine to machine):<br />
<br />
scratch_dir /localscratch<br />
<br />
*Put scratch files from Process 0 in /piofs/rjh, but put all other scratch files in /scratch:<br />
<br />
scratch_dir /scratch 0:/piofs/rjh<br />
<br />
*Put scratch files from Process 0 in directory scr1, those from Process 1 in scr2, and so forth, in a round-robin fashion, using the given list of directories:<br />
<br />
scratch_dir /scr1 /scr2 /scr3 /scr4 /scr5<br />
<br />
*Allocate files in a round-robin fashion from host-specific lists for processes distributed across two SGI multi-processor machines (node names coho and bohr):<br />
<br />
scratch_dir coho:/xfs1/rjh coho:/xfs2/rjh coho:/xfs3/rjh bohr:/disk01/rjh bohr:/disk02/rjh bohr:/disk13/rjh<br />
<br />
==MEMORY==<br />
<br />
This is a start-up directive that allows the user to specify the amount of memory PER PROCESSOR CORE that NWChem can use for the job. If this directive<br />
is not specified, memory is allocated according to installation-dependent defaults. The defaults should generally suffice for most calculations, since the defaults usually correspond to the total amount of memory available on the machine. <br />
<br />
The general form of the directive is as follows:<br />
<br />
MEMORY [[total] <integer total_size>] \<br />
[stack <integer stack_size>] \<br />
[heap <integer heap_size>] \<br />
[global <integer global_size>] \ <br />
[units <string units default real>] \ <br />
[(verify||noverify)] \<br />
[(nohardfail||hardfail)]<br />
<br />
NWChem recognizes the following memory units:<br />
*real and double (synonyms)<br />
*integer<br />
*real and double (synonyms)<br />
*integer<br />
*byte<br />
*kb (kilobytes)<br />
*mb (megabytes)<br />
*mw (megawords, 64-bit word)<br />
<br />
In most cases, the user need specify only the total memory limit to adjust the amount of memory used by NWChem. The following specifications all provide for eight megabytes of total memory (assuming 64-bit floating point numbers), which will be distributed according to the default partitioning:<br />
<br />
memory 1048576 <br />
memory 1048576 real <br />
memory 1 mw<br />
memory 8 mb <br />
memory total 8 mb <br />
memory total 1048576<br />
<br />
In NWChem there are three distinct regions of memory: stack, heap, and global. Stack and heap are node-private, while the union of the global region on all processors is used to provide globally-shared memory. The allowed limits on each category are determined from a default partitioning (currently 25% heap, 25% stack, and 50% global). Alternatively, the keywords stack, heap, and<br />
global can be used to define specific allocations for each of these categories. If the user sets only one of the stack, heap, or<br />
global limits by input, the limits for the other two categories are obtained by partitioning the remainder of the total memory available in proportion to the weight of those two categories in the default memory partitioning. If two of the category limits are given, the third is obtained by subtracting the two given limits from the total limit (which may have been specified or may be a default value). If all three category limits are specified, they determine the total memory allocated. However, if the total memory is also specified, it must be larger than the sum of all three categories. The code will abort if it detects an inconsistent memory specification.<br />
<br />
The following memory directives also allocate 8 megabytes, but specify a complete partitioning as well:<br />
<br />
memory total 8 stack 2 heap 2 global 4 mb <br />
memory stack 2 heap 2 global 4 mb<br />
<br />
The optional keywords verify and noverify in the directive give the user the option of enabling or disabling automatic detection of corruption of allocated memory. The default is verify, which enables the feature. This incurs some overhead (which can be around 10% increase in walltime on some platforms), which can be eliminated by specifying noverify.<br />
<br />
The keywords hardfail and nohardfail give the user the option of forcing (or not forcing) the local memory management<br />
routines to generate an internal fatal error if any memory operation fails. The default is nohardfail, which allows the code to<br />
continue past any memory operation failure, and perhaps generate a more meaningful error message before terminating the calculation.<br />
Forcing a hard-fail can be useful when poorly coded applications do not check the return status of memory management routines.<br />
<br />
When assigning the specific memory allocations using the keywords stack, heap, and global in the MEMORY directive, the user should be aware that some of the distinctions among these categories of memory have been blurred in their actual implementation in the code. The memory allocator (MA) allocates both the heap and the stack from a single memory region of size heap+stack, without enforcing the partition. The heap vs. stack partition is meaningful only to applications developers, and can be ignored by most users. Further complicating matters, the global array (GA) toolkit is allocated from within the MA space on distributed memory machines, while on shared-memory machines it is separate. This is because on true shared-memory machines there is no choice but to allocate GAs from within a shared-memory segment, which is managed differently by the operating system.<br />
<br />
On distributed memory platforms, the MA region is actually the total size of stack+heap+global. All three types of memory allocation<br />
compete for the same pool of memory, with no limits except on the total available memory. This relaxation of the memory category<br />
definitions usually benefits the user, since it can allow allocation requests to succeed where a stricter memory model would cause the directive to fail. These implementation characteristics must be kept in mind when reading program output that relates to memory usage.<br />
<br />
Standard default for memory is currently 400 MB.<br />
<br />
==ECHO==<br />
<br />
This start-up directive is provided as a convenient way to include a listing of the input file in the output of a calculation. It causes the entire input file to be printed to Fortran unit six (standard output). It has no keywords, arguments, or options, and consists of the single line:<br />
ECHO<br />
<br />
The ECHO directive is processed only once, by Process 0 when the input file is read.<br />
<br />
==TITLE==<br />
Specify job title.<br />
<br />
This top-level directive allows the user to identify a job or series of jobs that use a particular database. It is an optional directive, and if omitted, the character string containing the input title will be empty. Multiple TITLE directives may appear in the input file (e.g., the [[Release66:Getting_Started#Water Molecule Sample Input File|water example file]]) in which case a task will use the one most recently specified. The format for the directive is as follows:<br />
<br />
TITLE <string title><br />
<br />
The character string <title> is assigned to the contents of the string following the TITLE directive. If the string contains<br />
white space, it must be surrounded by double quotes. For example,<br />
<br />
title "This is the title of my NWChem job"<br />
<br />
The title is stored in the database and will be used in all subsequent tasks/jobs until redefined in the input.<br />
<br />
==PRINT / NOPRINT ==<br />
<br />
The PRINT and NOPRINT directives allow the user to control how much output NWChem generates. These two directives are<br />
special in that the compound directives for all modules are supposed to recognize them. Each module can control both the overall<br />
print level (general verbosity) and the printing of individual items which are identified by name (see below). The standard form of the PRINT directive is as follows:<br />
<br />
PRINT [(none || low || medium || high || debug) default medium] [<string list_of_names ... >]<br />
NOPRINT <string list_of_names ... ><br />
<br />
The default print level is medium.<br />
<br />
Every output that is printed by NWChem has a print threshold associated with it. If this threshold is equal to or lower than the<br />
print level requested by the user, then the output is generated. For example, the [[Release66:Hartree-Fock Theory for Molecules#Printing Information from the SCF Module|threshold for printing]] the SCF energy at convergence is low. This means that if the user-specified print level on the PRINT directive is<br />
low, medium, high, or debug, then the SCF energy will be printed at convergence.<br />
<br />
The overall print level specified using the PRINT directive is a convenient tool for controlling the verbosity of NWChem. Setting the print level to high might be helpful in diagnosing convergence problems. The print level of debug might also be of use in evaluating problem cases, but the user should be aware that this can generate a huge amount of output. Setting the print level to low might be the preferable choice for geometry optimizations that will perform many steps which are in themselves of little interest to the user.<br />
<br />
In addition, it is possible to enable the printing of specific items by naming them in the PRINT directive in the <list_of_names>. Items identified in this way will be printed, regardless of the overall print level specified. Similarly, the NOPRINT directive can be used to suppress the printing of specific items by naming them in its <list_of_names>. These items will not be printed, regardless of the overall print level, or the specific print level of the individual items.<br />
<br />
The list of items that can be printed for each module is documented as part of the input instructions for that module. The items recognized by the top level of the code, and their thresholds, are:<br />
<br />
{| border='1' cellspacing='0'<br />
| '''Name'''<br />
| '''Print Level'';'<br />
| '''Description'''<br />
|-<br />
| "total time";<br />
| medium<br />
| Print cpu and wall time at job end<br />
|-<br />
| &quot;task time&quot;<br />
| high<br />
| Print cpu and wall time for each task<br />
|-<br />
| &quot;rtdb&quot;<br />
| high<br />
| Print names of RTDB entries<br />
|-<br />
| &quot;rtdbvalues&quot;<br />
| high<br />
| Print name and values of RTDB entries<br />
|-<br />
| &quot;ga summary&quot;<br />
| medium<br />
| Summarize GA allocations at job end<br />
|-<br />
| &quot;ga stats&quot;<br />
| high<br />
| Print GA usage statistics at job end<br />
|-<br />
| &quot;ma summary&quot;<br />
| medium<br />
| Summarize MA allocations at job end<br />
|-<br />
| &quot;ma stats&quot;<br />
| high<br />
| Print MA usage statistics at job end<br />
|-<br />
| &quot;version&quot;<br />
| debug<br />
| Print version number of all compiled routines<br />
|-<br />
| &quot;tcgmsg&quot;<br />
| never<br />
| Print TCGMSG debug information<br />
|}<br />
<br />
===Top Level Print Control Specifications===<br />
<br />
The following example shows how a PRINT directive for the top level process can be used to limit printout to only essential information. The directive is<br />
<br />
print none "ma stats" rtdb<br />
<br />
This directive instructs the NWChem main program to print nothing, except for the memory usage statistics (ma stats) and the names of all items stored in the database at the end of the job.<br />
<br />
The print level within a module is inherited from the calling layer. For instance, by specifying the print to be low within the MP2 module will cause the SCF, CPHF and gradient modules when invoked from the MP2 to default to low print. Explicit user input of print thresholds overrides the inherited value.<br />
<br />
==SET==<br />
<br />
This top-level directive allows the user to enter data directly into the [[Release66:Nwarch#Database Structure|run-time database]]. The format of the directive is as follows:<br />
<br />
SET <string name> [<string type default automatic>] <type data><br />
<br />
The entry for variable <name> is the name of data to be entered into the database. This must be specified; there is no default. The variable <type>, which is optional, allows the user to define a string specifying the type of data in the array <name>. The data type can be explicitly specified as integer, real, double, logical, or string. If no entry for <type> is specified on the directive, its value is inferred from the data type of the first datum. In such a case, floating-point data entered using this directive must include either an exponent or a decimal point, to ensure that the correct default type will be inferred. The correct default type will be inferred for logical values if logical-true values are specified as .true., true, or t, and logical-false values are specified as .false., false, or f. One exception to the automatic detection of the data type is that the data type '''must''' be explicitly stated to input integer ranges, unless the first element in the list is an integer that is not a [[Release66:Getting_Started#Input Format and Syntax for Directives|range]]. For example,<br />
<br />
set atomid 1 3:7 21<br />
<br />
will be interpreted as a list of integers. However, <br />
<br />
set atomid 3:7 21 <br />
<br />
will not work since the first element will be interpreted as a string and not an integer. To work around this feature, use instead<br />
<br />
set atomid integer 3:7 21<br />
<br />
which says to write three through seven, as well as twenty-one.<br />
<br />
The SET directive is useful for providing indirection by associating the name of a basis set or geometry with the standard object names (such as "ao basis" or geometry) used by NWChem. The following input file shows an example using the SET directive to direct different tasks to different geometries. The required input lines are as follows:<br />
<br />
title "Ar dimer BSSE corrected MP2 interaction energy" <br />
geometry "Ar+Ar" <br />
Ar1 0 0 0 <br />
Ar2 0 0 2 <br />
end<br />
geometry "Ar+ghost" <br />
Ar1 0 0 0 <br />
Bq2 0 0 2 <br />
end<br />
basis <br />
Ar1 library aug-cc-pvdz <br />
Ar2 library aug-cc-pvdz <br />
Bq2 library Ar aug-cc-pvdz <br />
end<br />
set geometry "Ar+Ar" task mp2 <br />
scf; vectors atomic; end<br />
set geometry "Ar+ghost" task mp2 <br />
<br />
This input tells the code to perform MP2 energy calculations on an argon dimer in the first task, and then on the argon atom in the presence of the "ghost" basis of the other atom.<br />
<br />
The SET directive can also be used as an indirect means of supplying input to a part of the code that does not have a separate<br />
input module (e.g., the [[Release66:Hartree-Fock Theory for Molecules#Atomic guess orbitals with charged atoms|atomic SCF]]). Additional examples of applications of this directive can be found in<br />
the [[Release66:Getting_Started#Water Molecule Sample Input File|sample input files]], and its usage with [[Release66:Basis|basis sets]] and [[Release66:Geometry|geometries]]. Also see [[Release66:Nwarch#Database Structure|database section]] for an example of how to store an array in the database.<br />
<br />
==UNSET==<br />
Delete data in the RTDB.<br />
<br />
This directive gives the user a way to delete simple entries from the database. The general form of the directive is as follows:<br />
<br />
UNSET <string name>[*]<br />
<br />
This directive cannot be used with complex objects such as geometries and basis sets. Complex objects are stored using a structured naming convention that is not matched by a simple wild card. A wild-card (*) specified at the end of the string <name> will<br />
cause all entries whose name begins with that string to be deleted. This is very useful as a way to reset modules to their<br />
default behavior, since modules typically store information in the database with names that begin with module:. For example, the<br />
SCF program can be restored to its default behavior by deleting all database entries beginning with scf:, using the directive<br />
<br />
unset scf:*<br />
<br />
<br />
Section -sec:fragguess- has an example using unset on a water dimer calculation.<br />
<br />
The following example makes an entry in the database using the SET directive, and then immediately deletes it using the UNSET directive:<br />
<br />
set mylist 1 2 3 4 <br />
unset mylist<br />
<br />
==STOP==<br />
Terminate processing.<br />
<br />
This top-level directive provides a convenient way of verifying an input file without actually running the calculation. It consists of the single line,<br />
<br />
STOP<br />
<br />
As soon as this directive is encountered, all processing ceases and the calculation terminates with an error condition.<br />
<br />
==TASK==<br />
<br />
The TASK directive is used to tell the code what to do. The input directives are parsed sequentially until a TASK directive<br />
is encountered, as described in [[Release66:Getting_Started#Input File Structure|Input File Structure]]. At that point, the calculation or operation specified in the TASK directive is performed. When that task is completed, the code looks for additional input to process until the next TASK directive is encountered, which is then executed. This process continues to the end of the input file. NWChem expects the last directive before the end-of-file to be a TASK directive. If it is not, a warning message is printed. Since the database is persistent, multiple tasks within one job behave exactly the same as multiple restart jobs with the same sequence of input.<br />
<br />
There are four main forms of the the TASK directive. The most common form is used to tell the code at what level of theory to<br />
perform an electronic structure calculation, and which specific calculations to perform. The second form is used to specify tasks<br />
that do not involve electronic structure calculations or tasks that have not been fully implemented at all theory levels in NWChem, such as simple property evaluations. The third form is used to execute UNIX commands on machines having a Bourne shell. The fourth form is specific to combined quantum-mechanics and molecular-mechanics (QM/MM) calculations.<br />
<br />
By default, the program terminates when a task does not complete successfully. The keyword ignore can be used to prevent this<br />
termination, and is recognized by all forms of the TASK directive. When a TASK directive includes the keyword ignore, a warning message is printed if the task fails, and code execution continues with the next task. An example of this feature is given in the [[Release66:Density Functional Theory for Molecules#Sample_input_file|sample input file]].<br />
<br />
The input options, keywords, and defaults for each of these four forms for the TASK directive are discussed in the following sections.<br />
<br />
===TASK Directive for Electronic Structure===<br />
<br />
This is the most commonly used version of the TASK directive, and it has the following form:<br />
<br />
TASK <string theory> [<string operation default energy>] [ignore]<br />
<br />
The string <theory> specifies the level of theory to be used in the calculations for this task. NWChem currently supports ten different options. These are listed below, with the corresponding entry for the variable <theory>:<br />
*scf - Hartree-Fock<br />
*dft - Density functional theory for molecules<br />
*sodft - Spin-Orbit Density functional theory<br />
*mp2 - MP2 using a semi-direct algorithm<br />
*direct_mp2 - MP2 using a full-direct algorithm<br />
*rimp2 - MP2 using the RI approximation<br />
*ccsd - Coupled-cluster single and double excitations<br />
*ccsd(t) - Coupled-cluster linearized triples approximation<br />
*#ccsd+t(ccsd)# - Fourth order triples contribution<br />
*mcscf - Multiconfiguration SCF<br />
*selci - Selected configuration interaction with perturbation correction<br />
*md - Classical molecular dynamics simulation<br />
*pspw - Pseudopotential plane-wave density functional theory for molecules and insulating solids using NWPW<br />
*band - Pseudopotential plane-wave density functional theory for solids using NWPW<br />
*tce - Tensor Contraction Engine <br />
<br />
The string <operation> specifies the calculation that will be performed in the task. The default operation is a single point energy<br />
evaluation. The following list gives the selection of operations currently available in NWChem:<br />
*energy - Evaluate the single point energy.<br />
*gradient - Evaluate the derivative of the energy with respect to nuclear coordinates.<br />
*optimize - Minimize the energy by varying the molecular structure. By default, this geometry optimization is presently driven by the [[Release66:Hessians & Vibrational Frequencies#Geometry_Optimization_with_DRIVER|Driver module]], but the [[Release66:Hessians & Vibrational Frequencies#Geometry_Optimization_with_STEPPER|Stepper module]] may also be used.<br />
*saddle - Conduct a search for a transition state (or saddle point) using either [[Release66:Hessians & Vibrational Frequencies#Geometry_Optimization_with_DRIVER|Driver module]] (the default) or [[Release66:Hessians & Vibrational Frequencies#Geometry_Optimization_with_STEPPER|Stepper]].<br />
*hessian - Compute second derivatives. See [[Release66:Hessians & Vibrational Frequencies#Hessians|hessian section]] for analytic hessians.<br />
*frequencies or freq - Compute second derivatives and print out an analysis of molecular vibrations. See [[Release66:Hessians & Vibrational Frequencies#Vibrational_frequencies|vibration section]] for controls for vibration calculations.<br />
*vscf - Compute anharmonic contributions to the vibrational modes. See the [[Release66:VSCF|vibrational SCF section]] for options.<br />
*property - Calculate the properties for the wave function.<br />
*dynamics - Perform classical molecular dynamics.<br />
*thermodynamics - Perform multi-configuration thermo-dynamic integration using classical MD<br />
<br />
NOTE: See [[Release66:Plane-Wave Density Functional Theory#PSPW Tasks|PSPW Tasks]] for the complete list of operations that accompany the NWPW module.<br />
<br />
The user should be aware that some of these operations (gradient, optimize, dynamics, thermodynamics) require computation of<br />
derivatives of the energy with respect to the molecular coordinates. If analytical derivatives are not available ([[Release66:Capabilities|Capabilities]]), they must be computed numerically, which can be very computationally intensive.<br />
<br />
Here are some examples of the TASK directive, to illustrate the input needed to specify particular calculations with the code. To<br />
perform a single point energy evaluation using any level of theory, the directive is very simple, since the energy evaluation is the default for the string operation. For an SCF energy calculation, the input line is simply<br />
<br />
task scf<br />
<br />
Equivalently, the operation can be specified explicitly, using the directive<br />
<br />
task scf energy<br />
<br />
Similarly, to perform a geometry optimization using density functional theory, the TASK directive is<br />
<br />
task dft optimize<br />
<br />
The optional keyword ignore can be used to allow execution to continue even if the task fails, as discussed above. An example with the keyword ignore can be found in the [[Release66:Density Functional Theory for Molecules#Sample_input_file|DFT example]].<br />
<br />
===TASK Directive for Special Operations===<br />
<br />
This form of the TASK directive is used in instances where the task to be performed does not fit the model of the previous version<br />
(such as execution of a [[Release66:Python|Python program]]), or if the operation has not yet been implemented in a fashion that<br />
applies to a wide range of theories (e.g., property evaluation). Instead of requiring theory and operation as input, the directive needs only a string identifying the task. The form of the directive in such cases is as follows:<br />
<br />
TASK <string task> [ignore]<br />
<br />
The supported tasks that can be accessed with this form of the TASK directive are listed below, with the corresponding entries for string variable <task>.<br />
*python - Execute a [[Release66:Python|Python program]].<br />
*rtdbprint - Print the contents of the database.<br />
*cphf - Invoke the CPHF module.<br />
*property - Perform miscellaneous property calculations.<br />
*dplot - Execute a [[Release66:DPLOT|DPLOT run]].<br />
<br />
This directive also recognizes the keyword ignore, which allows execution to continue after a task has failed.<br />
<br />
===TASK Directive for Bourne Shell===<br />
<br />
This form of the TASK directive is supported only on machines with a fully UNIX-style operating system. This directive causes<br />
specified processes to be executed using the Bourne shell. This form of the task directive is:<br />
<br />
TASK shell [(<integer-range process = 0>||all)] <string command><br />
<br />
The keyword shell is required for this directive. It specifies that the given command will be executed in the Bourne shell. The user<br />
can also specify which process(es) will execute this command by entering values for process on the directive. The default is for only process zero to execute the command. A range of processes may be specified, using Fortran triplet notation. Alternatively, all processes can be specified simply by entering the keyword all. The input entered for command must form a single string, and must consist of valid UNIX command(s). If the string includes white space, it must be enclosed in double quotes. <br />
<br />
For example, the TASK directive to tell process zero to copy the molecular orbitals file to a backup location /piofs/save can be input as follows:<br />
<br />
task shell "cp *.movecs /piofs/save"<br />
<br />
The TASK directive to tell all processes to list the contents of their /scratch directories is as follows:<br />
<br />
task shell all "ls -l /scratch"<br />
<br />
The TASK directive to tell processes 0 to 10 to remove the contents of the current directory is as follows:<br />
<br />
task shell 0:10:1 "/bin/rm -f *"<br />
<br />
Note that NWChem's ability to quote special input characters is very limited when compared with that of the Bourne shell. To execute all but the simplest UNIX commands, it is usually much easier to put the shell script in a file and execute the file from within<br />
NWChem.<br />
<br />
===TASK Directive for QM/MM simulations===<br />
<br />
This is very similar to the most commonly used version of the [[Release66:Top-level#TASK_Directive_for_Electronic_Structure|TASK directive]], and it has the following form:<br />
<br />
TASK QMMM <string theory> [<string operation default energy>] [ignore]<br />
<br />
The string <theory> specifies the QM theory to be used in the QM/MM simulation. If theory is &quot;md&quot; this is not a QM/MM<br />
simulation and will result in an appropriate error. The level of theory may be any QM method that can compute gradients but those<br />
algorithms in NWChem that do not support analytic gradients should be avoided (see [[Release66:Functionality|Functionality]]). <br />
<br />
The string <operation> is used to specify the calculation that will be performed in the QM/MM task. The default operation is a single point energy evaluation. The following list gives the selection of operations currently available in the NWChem QM/MM module;<br />
<br />
*energy - single point energy evaluation<br />
*optimize - minimize the energy by variation of the molecular structure.<br />
*dynamics - molecular dynamics using nwARGOS<br />
<br />
Here are some examples of the TASK directive for QM/MM simulations. To perform a single point energy of a QM/MM system using any QM level of theory, the directive is very simple. As with the general task directive, the QM/MM energy evaluation is the default. For a DFT energy calculation the task directive input is,<br />
<br />
task qmmm dft<br />
<br />
or completely as<br />
<br />
task qmmm dft energy<br />
<br />
To do a molecular dynamics simulation of a QM/MM system using the SCF level of theory the task directive input would be<br />
<br />
task qmmm scf dynamics<br />
<br />
The optional keyword ignore can be used to allow execution to continue even if the task fails, as discussed above.<br />
<br />
===TASK Directive for BSSE calculations===<br />
<br />
NWChem computes the basis set superposition error (BSSE) when two or more fragments are interacting by using the counterpoise method. This directive is performed if the BSSE section is present. Single point energies, energy gradients, geometry optimizations, Hessians and frequencies, at the level of theory that allows these tasks, can be obtained with the BSSE correction. The input options for the BSSE section are:<br />
<br />
BSSE <br />
MON <string monomer name> <integer natoms> <br />
[INPUT [<string input>]] <br />
[INPUT_WGHOST[<string input>]] <br />
[CHARGE [<real charge>]] <br />
[OFF] <br />
[ON]<br />
END<br />
<br />
MON defines the monomer's name and its atoms; <string monomer name> defines the name of the monomer, <integer atoms> is the list of atoms corresponding to the monomer (where such a list is relative to the initial geometry). This information is needed for each monomer. With the tag INPUT the user can modify any calculation attributes for each monomer without ghost. For example, the iterations number and the grid can be changed in a DFT calculation (see the example of the interaction between <math>Zn^{2+}</math> and water). INPUT_WGHOST is the same than INPUT but for the monomer with ghost. The input changes will be applied within this and for the following calculations, you should be cautious reverting the changes for the next monomers. CHARGE assigns a charge to a monomer and it must be consistent with the total charge in the whole system (see Section -sec:charge-). The options OFF and ON turns off and on any BSSE calculation.<br />
<br />
The energy evaluation involves 1 + 2N calculations, i.e. one for the supermolecule and two for the N monomers. [S. Simon, M. Duran, J. J. Dannenberg, J. Chem. Phys., 105, 11024 (1996)] NWChem stores the vector files for each calculation (<string monomer name>.bsse.movecs), and one hessian file (<string monomer name>.bsse.hess). The code does not assign automatically the basis set for the ghost atoms, you must assign the corresponding bqX for each element, instead.<br />
<br />
===Examples===<br />
<br />
The dimer <math>(FH)_2</math><br />
<br />
title dimer<br />
start dimer<br />
geometry units angstrom<br />
symmetry c1 <br />
F 1.47189 2.47463 -0.00000 <br />
H 1.47206 3.29987 0.00000 <br />
F 1.46367 -0.45168 0.00000 <br />
H 1.45804 0.37497 -0.00000<br />
end<br />
basis "ao basis" <br />
F library 6-31G <br />
H library 6-31G <br />
bqF library F 6-31G <br />
bqH library H 6-31G<br />
end<br />
dft; xc slater 1.0 vwn_5 1.0; direct; end<br />
bsse <br />
mon first 1 2 <br />
mon second 3 4<br />
end<br />
task dft energy<br />
<br />
Changing maxiter for a specific monomer: <math>Zn^{2+}(H_2O)</math><br />
<br />
title znwater<br />
start znwater<br />
echo<br />
geometry noautoz units angstrom<br />
symmetry c1 <br />
Zn -1.89334 -0.72741 -0.00000 <br />
O -0.20798 0.25012 0.00000 <br />
H -0.14200 1.24982 -0.00000 <br />
H 0.69236 -0.18874 -0.00000<br />
end<br />
basis "ao basis" <br />
O library 6-31G <br />
Zn library 6-31G <br />
H library 6-31G <br />
bqO library O 6-31G <br />
bqZn library Zn 6-31G <br />
bqH library H 6-31G<br />
end<br />
charge 2<br />
scf; direct; end<br />
mp2; end<br />
bsse <br />
mon metal 1 <br />
charge 2 <br />
input_wghost "scf\; maxiter 200\; end" <br />
mon water 2 3 4<br />
end<br />
task mp2 optimize<br />
<br />
==ECCE_PRINT==<br />
<br />
The ECCE_PRINT directive allows the user to print out a file, usually called ecce.out, that will allow the calculation and its<br />
results to be imported into Ecce (see http://ecce.pnl.gov).<br />
<br />
ECCE_PRINT <string name><br />
<br />
The entry for variable <name> is the name of the file that will contain the Ecce import information and should include the full path to the directory where you want that file. For example<br />
<br />
ecce_print /home/user/job/ecce.out<br />
<br />
If the full path is not given and only the file name is given, the file will be located in whatever directory the job is started in. For example, if the line<br />
<br />
ecce_print ecce.out<br />
<br />
is in the input file, the file could end up in the scratch directory if the user is using a batch script that copies the input file to a local scratch directory and then launches NWChem from there. If the system then automatically removes files in the scratch space at the end of the job, the ecce.out file will be lost. So, the best practice is to include the full path name for the file.</div>Berthttp://www.nwchem-sw.org/index.php/Release65:VSCFRelease65:VSCF2013-06-21T17:31:35Z<p>Bert: 1 revision</p>
<hr />
<div>__NOTITLE__<br />
=VSCF=<br />
<br />
The VSCF module can be used to calculate the anharmonic contributions to the vibrational modes of the molecule of interest. Energies are calculated on a one-dimensional grid along each normal mode, on a two-dimensional grid along each pair of normal modes, and optionally on a three-dimensional grid along each triplet of normal modes. These energies are then used to calculate the vibrational nuclear wavefunction at an SCF- (VSCF) and MP2-like (cc-VSCF) level of theory.<br />
<br />
VSCF can be used at all levels of theory, SCF and correlated methods, and DFT. For correlated methods, only the SCF level dipole is evaluated and used to calculate the IR intensity values.<br />
<br />
The VSCF module is started when the task directive TASK <theory> vscf is defined in the user input file. The input format has the form:<br />
<br />
VSCF<br />
[coupling <string couplelevel default "pair">]<br />
[ngrid <integer default 16 >]<br />
[iexcite <integer default 1 >]<br />
[vcfct <real default 1.0>]<br />
END<br />
<br />
The order of coupling of the harmonic normal modes included in the calculation is controlled by the specifying:<br />
<br />
coupling <string couplelevel default "pair"><br />
<br />
For coupling=diagonal a one-dimensional grid along each normal mode is computed. For coupling=pair a two-dimensional grid along each pair of normal modes is computed. For coupling=triplet a three-dimensional grid along each triplet of normal modes is computed.<br />
<br />
The number of grid points along each normal mode, or pair of modes can be defined by specifying:<br />
<br />
ngrid <integer default 16><br />
<br />
This VSCF module by default calculates the ground state (v=0), but can also calculate excited states (such as v=1). The number of excited states calculated is defined by specifying:<br />
<br />
iexcite <integer default 1><br />
<br />
With iexcite=1 the fundamental frequencies are calculated. With iexcite=2 the first overtones are calculated. With iexcite=3 the second overtones are calculated.<br />
<br />
In certain cases the pair coupling potentials can become larger than those for a single normal mode. In this case the pair potentials need to be scaled down. The scaling factor used can be defined by specifying:<br />
<br />
vcfct <real default 1.0></div>Berthttp://www.nwchem-sw.org/index.php/Release65:Top-levelRelease65:Top-level2013-06-21T17:31:35Z<p>Bert: 1 revision</p>
<hr />
<div>__NOTITLE__<br />
=Top-level Directives=<br />
<br />
Top-level directives are directives that can affect all modules in the code. Some specify molecular properties or other data that should apply to all subsequent calculations with the current database. However, most top-level directives provide the user with the means to manage the resources for a calculation and to start computations. As the first step in the execution of a job, NWChem scans the entire input file looking for start-up directives, which NWChem must process before all other input. The input file is then rewound and processed sequentially, and each directive is processed in the order in which it is encountered. In this second pass, start-up directives are ignored.<br />
<br />
The following sections describe each of the top-level directives in detail, noting all keywords, options, required input, and defaults.<br />
<br />
==START / RESTART ==<br />
<br />
The START or RESTART directive define the start-up mode and are optional keywords. If one of these two directives is not specified explicitly, the code will infer one, based upon the name of the input file and the availability of the database. When allowing NWChem to infer the start-up directive, the user must be quite certain that the contents of the database will result in the desired action. It is usually more prudent to specify the directive explicitly, using the following format:<br />
<br />
(RESTART || START) [<string file_prefix default input_file_prefix>] \<br />
[rtdb <string rtdb_file_name default file_prefix.db>]<br />
<br />
The START directive indicates that the calculation is one in which a new database is to be created. Any relevant information that<br />
already exists in a previous database of the same name is destroyed. The string variable <file_prefix> will be used as the prefix to name any files created in the course of the calculation. <br />
<br />
E.g., to start a new calculation on water, one might specify<br />
<br />
start water<br />
<br />
which will make all files begin with "water.".<br />
<br />
If the user does not specify an entry for <file_prefix> on the START directive (or omits the START directive<br />
altogether), the code uses the base-name of the input file as the file prefix. That is, the variable <file_prefix> is assigned the name of the input file (not its full pathname), but without the last "dot-suffix". For example, the input file name<br />
/home/dave/job.2.nw yields job.2 as the file prefix, if a name is not assigned explicitly using the START directive.<br />
<br />
The user also has the option of specifying a unique name for the database, using the keyword rtdb. When this keyword is entered, the string entered for rtdb_file_name is used as the database name. If the keyword rtdb is omitted, the name of the database defaults to file_prefix.db in the directory for permanent files.<br />
<br />
If a calculation is to start from a previous calculation and go on using the existing database, the RESTART directive must be used. In such a case, the previous database must already exist. The name specified for <file_prefix> usually should<br />
not be changed when restarting a calculation. If it is changed, NWChem will not be able to find needed files when going on with the<br />
calculation.<br />
<br />
In the most common situation, the previous calculation was completed (with or without an error condition), and it is desired to perform a new task or restart the previous one, perhaps with some input changes. In these instances, the RESTART directive should be used. This re-uses the previous database and associated files, and reads the input file for new input and task information.<br />
<br />
The RESTART directive looks immediately for new input and task information, deleting information about previous incomplete tasks.<br />
For example, when doing a RESTART there is no need to specify geometry or basis set declaration because the program will detect this information since it is stored in the run-time database.<br />
<br />
If a calculation runs out of time, for example because it is on a queuing system, this is another instance where doing a<br />
RESTART is advisable. Simply include nothing after the RESTART directive except those tasks that are unfinished.<br />
<br />
To summarize the default options for this start-up directive, if the input file does not contain a START or a RESTART directive, then<br />
*the variable <file_prefix> is assigned the name of the input file for the job, without the suffix (which is usually .nw)<br />
*the variable <rtdb_file_name> is assigned the default name, file_prefix.db<br />
<br />
If the database with name file_prefix.db does not already exist, the calculation is carried out as if a START directive had been encountered. If the database with name file_prefix.db does exist, then the calculation is performed as if a RESTART directive had been encountered. <br />
<br />
For example, NWChem can be run using an input file with the name water.nw by typing the UNIX command line,<br />
<br />
nwchem water.nw<br />
<br />
If the NWChem input file water.nw does not contain a START or RESTART directive, the code sets the variable <file_prefix> to water. Files created by the job will have this prefix, and the database will be named water.db. If the database water.db does not exist already, the code behaves as if the input file contains the directive,<br />
<br />
start water<br />
<br />
If the database water.db does exist, the code behaves as if the input file contained the directive,<br />
<br />
restart water<br />
<br />
==PERMANENT_DIR==<br />
<br />
This start-up directive allows the user to specify the directory location of permanent files created by NWChem. NWChem distinguishes between permanent (or persistent) files and scratch (or temporary) files, and allows the user the option of putting them in different locations. In most installations, however, permanent and scratch files are all written to the current directory by default. What constitutes &quot;local&quot; disk space may also differ from machine to machine.<br />
<br />
The PERMANENT_DIR directives enable the user to specify a single directory for all processes or different directories for different processes. The general form of the directive is as follows:<br />
<br />
(PERMANENT_DIR) [(<string host&>||<integer process>):] <string directory> [...]<br />
<br />
==SCRATCH_DIR==<br />
<br />
This start-up directive allows the user to specify the directory location of scratch files created by NWChem. NWChem distinguishes between permanent (or persistent) files and scratch (or temporary) files, and allows the user the option of putting them in different locations. In most installations, however, permanent and scratch files are all written to the current directory by default. What constitutes &quot;local&quot; disk space may also differ from machine to machine.<br />
<br />
The conventions for file storage are at the discretion of the specific installation, and are quite likely to be different on different machines. When assigning locations for permanent and scratch files, the user must be cognizant of the characteristics of the installation on a particular platform. To consider just a few examples, on clusters, machine-specific or process-specific names must be supplied for both local and shared file systems, while on SMPs it is useful to specify scratch file directories with automated striping across processors with round-robin allocation. On SMP clusters (a.k.a. constellations), both of these specifications are required. <br />
<br />
The SCRATCH_DIR enables the user to specify a single directory for all processes or different directories for different processes. The general form of the directive is as follows:<br />
<br />
(SCRATCH_DIR) [(<string host&>||<integer process>):] <string directory> [...]<br />
<br />
Directories are extracted from the user input by executing the following steps, in sequence:<br />
#Look for a directory qualified by the process ID number of the invoking process. Processes are numbered from zero. Else,<br />
#If there is a list of directories qualified by the name of the host machineAs returned by util_hostname() which maps to the output of the command hostname on Unix workstations., then use round-robin allocation from the list for processes executing on the given host. Else,<br />
#If there is a list of directories unqualified by any hostname or process ID, then use round-robin allocation from this list.<br />
<br />
If directory allocation directive(s) are not specified in the input file, or if no match is found to the directory names specified by input using these directives, then the steps above are executed using the installation-specific defaults. If the code cannot find a valid directory name based on the input specified in either the directive(s) or the system defaults, files are automatically written to the current working directory (".").<br />
<br />
The following is a list of examples of specific allocations of scratch directory locations:<br />
*Put scratch files from all processes in the local scratch directory (Warning: the definition of "local scratch directory" may change from machine to machine):<br />
<br />
scratch_dir /localscratch<br />
<br />
*Put scratch files from Process 0 in /piofs/rjh, but put all other scratch files in /scratch:<br />
<br />
scratch_dir /scratch 0:/piofs/rjh<br />
<br />
*Put scratch files from Process 0 in directory scr1, those from Process 1 in scr2, and so forth, in a round-robin fashion, using the given list of directories:<br />
<br />
scratch_dir /scr1 /scr2 /scr3 /scr4 /scr5<br />
<br />
*Allocate files in a round-robin fashion from host-specific lists for processes distributed across two SGI multi-processor machines (node names coho and bohr):<br />
<br />
scratch_dir coho:/xfs1/rjh coho:/xfs2/rjh coho:/xfs3/rjh bohr:/disk01/rjh bohr:/disk02/rjh bohr:/disk13/rjh<br />
<br />
==MEMORY==<br />
<br />
This is a start-up directive that allows the user to specify the amount of memory PER PROCESSOR CORE that NWChem can use for the job. If this directive<br />
is not specified, memory is allocated according to installation-dependent defaults. The defaults should generally suffice for most calculations, since the defaults usually correspond to the total amount of memory available on the machine. <br />
<br />
The general form of the directive is as follows:<br />
<br />
MEMORY [[total] <integer total_size>] \<br />
[stack <integer stack_size>] \<br />
[heap <integer heap_size>] \<br />
[global <integer global_size>] \ <br />
[units <string units default real>] \ <br />
[(verify||noverify)] \<br />
[(nohardfail||hardfail)]<br />
<br />
NWChem recognizes the following memory units:<br />
*real and double (synonyms)<br />
*integer<br />
*real and double (synonyms)<br />
*integer<br />
*byte<br />
*kb (kilobytes)<br />
*mb (megabytes)<br />
*mw (megawords, 64-bit word)<br />
<br />
In most cases, the user need specify only the total memory limit to adjust the amount of memory used by NWChem. The following specifications all provide for eight megabytes of total memory (assuming 64-bit floating point numbers), which will be distributed according to the default partitioning:<br />
<br />
memory 1048576 <br />
memory 1048576 real <br />
memory 1 mw<br />
memory 8 mb <br />
memory total 8 mb <br />
memory total 1048576<br />
<br />
In NWChem there are three distinct regions of memory: stack, heap, and global. Stack and heap are node-private, while the union of the global region on all processors is used to provide globally-shared memory. The allowed limits on each category are determined from a default partitioning (currently 25% heap, 25% stack, and 50% global). Alternatively, the keywords stack, heap, and<br />
global can be used to define specific allocations for each of these categories. If the user sets only one of the stack, heap, or<br />
global limits by input, the limits for the other two categories are obtained by partitioning the remainder of the total memory available in proportion to the weight of those two categories in the default memory partitioning. If two of the category limits are given, the third is obtained by subtracting the two given limits from the total limit (which may have been specified or may be a default value). If all three category limits are specified, they determine the total memory allocated. However, if the total memory is also specified, it must be larger than the sum of all three categories. The code will abort if it detects an inconsistent memory specification.<br />
<br />
The following memory directives also allocate 8 megabytes, but specify a complete partitioning as well:<br />
<br />
memory total 8 stack 2 heap 2 global 4 mb <br />
memory stack 2 heap 2 global 4 mb<br />
<br />
The optional keywords verify and noverify in the directive give the user the option of enabling or disabling automatic detection of corruption of allocated memory. The default is verify, which enables the feature. This incurs some overhead (which can be around 10% increase in walltime on some platforms), which can be eliminated by specifying noverify.<br />
<br />
The keywords hardfail and nohardfail give the user the option of forcing (or not forcing) the local memory management<br />
routines to generate an internal fatal error if any memory operation fails. The default is nohardfail, which allows the code to<br />
continue past any memory operation failure, and perhaps generate a more meaningful error message before terminating the calculation.<br />
Forcing a hard-fail can be useful when poorly coded applications do not check the return status of memory management routines.<br />
<br />
When assigning the specific memory allocations using the keywords stack, heap, and global in the MEMORY directive, the user should be aware that some of the distinctions among these categories of memory have been blurred in their actual implementation in the code. The memory allocator (MA) allocates both the heap and the stack from a single memory region of size heap+stack, without enforcing the partition. The heap vs. stack partition is meaningful only to applications developers, and can be ignored by most users. Further complicating matters, the global array (GA) toolkit is allocated from within the MA space on distributed memory machines, while on shared-memory machines it is separate. This is because on true shared-memory machines there is no choice but to allocate GAs from within a shared-memory segment, which is managed differently by the operating system.<br />
<br />
On distributed memory platforms, the MA region is actually the total size of stack+heap+global. All three types of memory allocation<br />
compete for the same pool of memory, with no limits except on the total available memory. This relaxation of the memory category<br />
definitions usually benefits the user, since it can allow allocation requests to succeed where a stricter memory model would cause the directive to fail. These implementation characteristics must be kept in mind when reading program output that relates to memory usage.<br />
<br />
Standard default for memory is currently 400 MB.<br />
<br />
==ECHO==<br />
<br />
This start-up directive is provided as a convenient way to include a listing of the input file in the output of a calculation. It causes the entire input file to be printed to Fortran unit six (standard output). It has no keywords, arguments, or options, and consists of the single line:<br />
ECHO<br />
<br />
The ECHO directive is processed only once, by Process 0 when the input file is read.<br />
<br />
==TITLE==<br />
Specify job title.<br />
<br />
This top-level directive allows the user to identify a job or series of jobs that use a particular database. It is an optional directive, and if omitted, the character string containing the input title will be empty. Multiple TITLE directives may appear in the input file (e.g., the [[Release64:Getting_Started#Water Molecule Sample Input File|water example file]]) in which case a task will use the one most recently specified. The format for the directive is as follows:<br />
<br />
TITLE <string title><br />
<br />
The character string <title> is assigned to the contents of the string following the TITLE directive. If the string contains<br />
white space, it must be surrounded by double quotes. For example,<br />
<br />
title "This is the title of my NWChem job"<br />
<br />
The title is stored in the database and will be used in all subsequent tasks/jobs until redefined in the input.<br />
<br />
==PRINT / NOPRINT ==<br />
<br />
The PRINT and NOPRINT directives allow the user to control how much output NWChem generates. These two directives are<br />
special in that the compound directives for all modules are supposed to recognize them. Each module can control both the overall<br />
print level (general verbosity) and the printing of individual items which are identified by name (see below). The standard form of the PRINT directive is as follows:<br />
<br />
PRINT [(none || low || medium || high || debug) default medium] [<string list_of_names ... >]<br />
NOPRINT <string list_of_names ... ><br />
<br />
The default print level is medium.<br />
<br />
Every output that is printed by NWChem has a print threshold associated with it. If this threshold is equal to or lower than the<br />
print level requested by the user, then the output is generated. For example, the [[Release64:Hartree-Fock Theory for Molecules#Printing Information from the SCF Module|threshold for printing]] the SCF energy at convergence is low. This means that if the user-specified print level on the PRINT directive is<br />
low, medium, high, or debug, then the SCF energy will be printed at convergence.<br />
<br />
The overall print level specified using the PRINT directive is a convenient tool for controlling the verbosity of NWChem. Setting the print level to high might be helpful in diagnosing convergence problems. The print level of debug might also be of use in evaluating problem cases, but the user should be aware that this can generate a huge amount of output. Setting the print level to low might be the preferable choice for geometry optimizations that will perform many steps which are in themselves of little interest to the user.<br />
<br />
In addition, it is possible to enable the printing of specific items by naming them in the PRINT directive in the <list_of_names>. Items identified in this way will be printed, regardless of the overall print level specified. Similarly, the NOPRINT directive can be used to suppress the printing of specific items by naming them in its <list_of_names>. These items will not be printed, regardless of the overall print level, or the specific print level of the individual items.<br />
<br />
The list of items that can be printed for each module is documented as part of the input instructions for that module. The items recognized by the top level of the code, and their thresholds, are:<br />
<br />
{| border='1' cellspacing='0'<br />
| '''Name'''<br />
| '''Print Level'';'<br />
| '''Description'''<br />
|-<br />
| "total time";<br />
| medium<br />
| Print cpu and wall time at job end<br />
|-<br />
| &quot;task time&quot;<br />
| high<br />
| Print cpu and wall time for each task<br />
|-<br />
| &quot;rtdb&quot;<br />
| high<br />
| Print names of RTDB entries<br />
|-<br />
| &quot;rtdbvalues&quot;<br />
| high<br />
| Print name and values of RTDB entries<br />
|-<br />
| &quot;ga summary&quot;<br />
| medium<br />
| Summarize GA allocations at job end<br />
|-<br />
| &quot;ga stats&quot;<br />
| high<br />
| Print GA usage statistics at job end<br />
|-<br />
| &quot;ma summary&quot;<br />
| medium<br />
| Summarize MA allocations at job end<br />
|-<br />
| &quot;ma stats&quot;<br />
| high<br />
| Print MA usage statistics at job end<br />
|-<br />
| &quot;version&quot;<br />
| debug<br />
| Print version number of all compiled routines<br />
|-<br />
| &quot;tcgmsg&quot;<br />
| never<br />
| Print TCGMSG debug information<br />
|}<br />
<br />
===Top Level Print Control Specifications===<br />
<br />
The following example shows how a PRINT directive for the top level process can be used to limit printout to only essential information. The directive is<br />
<br />
print none "ma stats" rtdb<br />
<br />
This directive instructs the NWChem main program to print nothing, except for the memory usage statistics (ma stats) and the names of all items stored in the database at the end of the job.<br />
<br />
The print level within a module is inherited from the calling layer. For instance, by specifying the print to be low within the MP2 module will cause the SCF, CPHF and gradient modules when invoked from the MP2 to default to low print. Explicit user input of print thresholds overrides the inherited value.<br />
<br />
==SET==<br />
<br />
This top-level directive allows the user to enter data directly into the [[Release64:Nwarch#Database Structure|run-time database]]. The format of the directive is as follows:<br />
<br />
SET <string name> [<string type default automatic>] <type data><br />
<br />
The entry for variable <name> is the name of data to be entered into the database. This must be specified; there is no default. The variable <type>, which is optional, allows the user to define a string specifying the type of data in the array <name>. The data type can be explicitly specified as integer, real, double, logical, or string. If no entry for <type> is specified on the directive, its value is inferred from the data type of the first datum. In such a case, floating-point data entered using this directive must include either an exponent or a decimal point, to ensure that the correct default type will be inferred. The correct default type will be inferred for logical values if logical-true values are specified as .true., true, or t, and logical-false values are specified as .false., false, or f. One exception to the automatic detection of the data type is that the data type '''must''' be explicitly stated to input integer ranges, unless the first element in the list is an integer that is not a [[Release64:Getting_Started#Input Format and Syntax for Directives|range]]. For example,<br />
<br />
set atomid 1 3:7 21<br />
<br />
will be interpreted as a list of integers. However, <br />
<br />
set atomid 3:7 21 <br />
<br />
will not work since the first element will be interpreted as a string and not an integer. To work around this feature, use instead<br />
<br />
set atomid integer 3:7 21<br />
<br />
which says to write three through seven, as well as twenty-one.<br />
<br />
The SET directive is useful for providing indirection by associating the name of a basis set or geometry with the standard object names (such as "ao basis" or geometry) used by NWChem. The following input file shows an example using the SET directive to direct different tasks to different geometries. The required input lines are as follows:<br />
<br />
title "Ar dimer BSSE corrected MP2 interaction energy" <br />
geometry "Ar+Ar" <br />
Ar1 0 0 0 <br />
Ar2 0 0 2 <br />
end<br />
geometry "Ar+ghost" <br />
Ar1 0 0 0 <br />
Bq2 0 0 2 <br />
end<br />
basis <br />
Ar1 library aug-cc-pvdz <br />
Ar2 library aug-cc-pvdz <br />
Bq2 library Ar aug-cc-pvdz <br />
end<br />
set geometry "Ar+Ar" task mp2 <br />
scf; vectors atomic; end<br />
set geometry "Ar+ghost" task mp2 <br />
<br />
This input tells the code to perform MP2 energy calculations on an argon dimer in the first task, and then on the argon atom in the presence of the "ghost" basis of the other atom.<br />
<br />
The SET directive can also be used as an indirect means of supplying input to a part of the code that does not have a separate<br />
input module (e.g., the [[Release64:Hartree-Fock Theory for Molecules#Atomic guess orbitals with charged atoms|atomic SCF]]). Additional examples of applications of this directive can be found in<br />
the [[Release64:Getting_Started#Water Molecule Sample Input File|sample input files]], and its usage with [[Release64:Basis|basis sets]] and [[Release64:Geometry|geometries]]. Also see [[Release64:Nwarch#Database Structure|database section]] for an example of how to store an array in the database.<br />
<br />
==UNSET==<br />
Delete data in the RTDB.<br />
<br />
This directive gives the user a way to delete simple entries from the database. The general form of the directive is as follows:<br />
<br />
UNSET <string name>[*]<br />
<br />
This directive cannot be used with complex objects such as geometries and basis sets. Complex objects are stored using a structured naming convention that is not matched by a simple wild card. A wild-card (*) specified at the end of the string <name> will<br />
cause all entries whose name begins with that string to be deleted. This is very useful as a way to reset modules to their<br />
default behavior, since modules typically store information in the database with names that begin with module:. For example, the<br />
SCF program can be restored to its default behavior by deleting all database entries beginning with scf:, using the directive<br />
<br />
unset scf:*<br />
<br />
<br />
Section -sec:fragguess- has an example using unset on a water dimer calculation.<br />
<br />
The following example makes an entry in the database using the SET directive, and then immediately deletes it using the UNSET directive:<br />
<br />
set mylist 1 2 3 4 <br />
unset mylist<br />
<br />
==STOP==<br />
Terminate processing.<br />
<br />
This top-level directive provides a convenient way of verifying an input file without actually running the calculation. It consists of the single line,<br />
<br />
STOP<br />
<br />
As soon as this directive is encountered, all processing ceases and the calculation terminates with an error condition.<br />
<br />
==TASK==<br />
<br />
The TASK directive is used to tell the code what to do. The input directives are parsed sequentially until a TASK directive<br />
is encountered, as described in [[Release64:Getting_Started#Input File Structure|Input File Structure]]. At that point, the calculation or operation specified in the TASK directive is performed. When that task is completed, the code looks for additional input to process until the next TASK directive is encountered, which is then executed. This process continues to the end of the input file. NWChem expects the last directive before the end-of-file to be a TASK directive. If it is not, a warning message is printed. Since the database is persistent, multiple tasks within one job behave exactly the same as multiple restart jobs with the same sequence of input.<br />
<br />
There are four main forms of the the TASK directive. The most common form is used to tell the code at what level of theory to<br />
perform an electronic structure calculation, and which specific calculations to perform. The second form is used to specify tasks<br />
that do not involve electronic structure calculations or tasks that have not been fully implemented at all theory levels in NWChem, such as simple property evaluations. The third form is used to execute UNIX commands on machines having a Bourne shell. The fourth form is specific to combined quantum-mechanics and molecular-mechanics (QM/MM) calculations.<br />
<br />
By default, the program terminates when a task does not complete successfully. The keyword ignore can be used to prevent this<br />
termination, and is recognized by all forms of the TASK directive. When a TASK directive includes the keyword ignore, a warning message is printed if the task fails, and code execution continues with the next task. An example of this feature is given in the [[Release64:Density Functional Theory for Molecules#Sample_input_file|sample input file]].<br />
<br />
The input options, keywords, and defaults for each of these four forms for the TASK directive are discussed in the following sections.<br />
<br />
===TASK Directive for Electronic Structure===<br />
<br />
This is the most commonly used version of the TASK directive, and it has the following form:<br />
<br />
TASK <string theory> [<string operation default energy>] [ignore]<br />
<br />
The string <theory> specifies the level of theory to be used in the calculations for this task. NWChem currently supports ten different options. These are listed below, with the corresponding entry for the variable <theory>:<br />
*scf - Hartree-Fock<br />
*dft - Density functional theory for molecules<br />
*sodft - Spin-Orbit Density functional theory<br />
*mp2 - MP2 using a semi-direct algorithm<br />
*direct_mp2 - MP2 using a full-direct algorithm<br />
*rimp2 - MP2 using the RI approximation<br />
*ccsd - Coupled-cluster single and double excitations<br />
*ccsd(t) - Coupled-cluster linearized triples approximation<br />
*#ccsd+t(ccsd)# - Fourth order triples contribution<br />
*mcscf - Multiconfiguration SCF<br />
*selci - Selected configuration interaction with perturbation correction<br />
*md - Classical molecular dynamics simulation<br />
*pspw - Pseudopotential plane-wave density functional theory for molecules and insulating solids using NWPW<br />
*band - Pseudopotential plane-wave density functional theory for solids using NWPW<br />
*tce - Tensor Contraction Engine <br />
<br />
The string <operation> specifies the calculation that will be performed in the task. The default operation is a single point energy<br />
evaluation. The following list gives the selection of operations currently available in NWChem:<br />
*energy - Evaluate the single point energy.<br />
*gradient - Evaluate the derivative of the energy with respect to nuclear coordinates.<br />
*optimize - Minimize the energy by varying the molecular structure. By default, this geometry optimization is presently driven by the [[Release64:Hessians & Vibrational Frequencies#Geometry_Optimization_with_DRIVER|Driver module]], but the [[Release64:Hessians & Vibrational Frequencies#Geometry_Optimization_with_STEPPER|Stepper module]] may also be used.<br />
*saddle - Conduct a search for a transition state (or saddle point) using either [[Release64:Hessians & Vibrational Frequencies#Geometry_Optimization_with_DRIVER|Driver module]] (the default) or [[Release64:Hessians & Vibrational Frequencies#Geometry_Optimization_with_STEPPER|Stepper]].<br />
*hessian - Compute second derivatives. See [[Release64:Hessians & Vibrational Frequencies#Hessians|hessian section]] for analytic hessians.<br />
*frequencies or freq - Compute second derivatives and print out an analysis of molecular vibrations. See [[Release64:Hessians & Vibrational Frequencies#Vibrational_frequencies|vibration section]] for controls for vibration calculations.<br />
*vscf - Compute anharmonic contributions to the vibrational modes. See the [[Release64:VSCF|vibrational SCF section]] for options.<br />
*property - Calculate the properties for the wave function.<br />
*dynamics - Perform classical molecular dynamics.<br />
*thermodynamics - Perform multi-configuration thermo-dynamic integration using classical MD<br />
<br />
NOTE: See [[Release64:Plane-Wave Density Functional Theory#PSPW Tasks|PSPW Tasks]] for the complete list of operations that accompany the NWPW module.<br />
<br />
The user should be aware that some of these operations (gradient, optimize, dynamics, thermodynamics) require computation of<br />
derivatives of the energy with respect to the molecular coordinates. If analytical derivatives are not available ([[Release64:Capabilities|Capabilities]]), they must be computed numerically, which can be very computationally intensive.<br />
<br />
Here are some examples of the TASK directive, to illustrate the input needed to specify particular calculations with the code. To<br />
perform a single point energy evaluation using any level of theory, the directive is very simple, since the energy evaluation is the default for the string operation. For an SCF energy calculation, the input line is simply<br />
<br />
task scf<br />
<br />
Equivalently, the operation can be specified explicitly, using the directive<br />
<br />
task scf energy<br />
<br />
Similarly, to perform a geometry optimization using density functional theory, the TASK directive is<br />
<br />
task dft optimize<br />
<br />
The optional keyword ignore can be used to allow execution to continue even if the task fails, as discussed above. An example with the keyword ignore can be found in the [[Release64:Density Functional Theory for Molecules#Sample_input_file|DFT example]].<br />
<br />
===TASK Directive for Special Operations===<br />
<br />
This form of the TASK directive is used in instances where the task to be performed does not fit the model of the previous version<br />
(such as execution of a [[Release64:Python|Python program]]), or if the operation has not yet been implemented in a fashion that<br />
applies to a wide range of theories (e.g., property evaluation). Instead of requiring theory and operation as input, the directive needs only a string identifying the task. The form of the directive in such cases is as follows:<br />
<br />
TASK <string task> [ignore]<br />
<br />
The supported tasks that can be accessed with this form of the TASK directive are listed below, with the corresponding entries for string variable <task>.<br />
*python - Execute a [[Release64:Python|Python program]].<br />
*rtdbprint - Print the contents of the database.<br />
*cphf - Invoke the CPHF module.<br />
*property - Perform miscellaneous property calculations.<br />
*dplot - Execute a [[Release64:DPLOT|DPLOT run]].<br />
<br />
This directive also recognizes the keyword ignore, which allows execution to continue after a task has failed.<br />
<br />
===TASK Directive for Bourne Shell===<br />
<br />
This form of the TASK directive is supported only on machines with a fully UNIX-style operating system. This directive causes<br />
specified processes to be executed using the Bourne shell. This form of the task directive is:<br />
<br />
TASK shell [(<integer-range process = 0>||all)] <string command><br />
<br />
The keyword shell is required for this directive. It specifies that the given command will be executed in the Bourne shell. The user<br />
can also specify which process(es) will execute this command by entering values for process on the directive. The default is for only process zero to execute the command. A range of processes may be specified, using Fortran triplet notation. Alternatively, all processes can be specified simply by entering the keyword all. The input entered for command must form a single string, and must consist of valid UNIX command(s). If the string includes white space, it must be enclosed in double quotes. <br />
<br />
For example, the TASK directive to tell process zero to copy the molecular orbitals file to a backup location /piofs/save can be input as follows:<br />
<br />
task shell "cp *.movecs /piofs/save"<br />
<br />
The TASK directive to tell all processes to list the contents of their /scratch directories is as follows:<br />
<br />
task shell all "ls -l /scratch"<br />
<br />
The TASK directive to tell processes 0 to 10 to remove the contents of the current directory is as follows:<br />
<br />
task shell 0:10:1 "/bin/rm -f *"<br />
<br />
Note that NWChem's ability to quote special input characters is very limited when compared with that of the Bourne shell. To execute all but the simplest UNIX commands, it is usually much easier to put the shell script in a file and execute the file from within<br />
NWChem.<br />
<br />
===TASK Directive for QM/MM simulations===<br />
<br />
This is very similar to the most commonly used version of the [[Release64:Top-level#TASK_Directive_for_Electronic_Structure|TASK directive]], and it has the following form:<br />
<br />
TASK QMMM <string theory> [<string operation default energy>] [ignore]<br />
<br />
The string <theory> specifies the QM theory to be used in the QM/MM simulation. If theory is &quot;md&quot; this is not a QM/MM<br />
simulation and will result in an appropriate error. The level of theory may be any QM method that can compute gradients but those<br />
algorithms in NWChem that do not support analytic gradients should be avoided (see [[Release64:Functionality|Functionality]]). <br />
<br />
The string <operation> is used to specify the calculation that will be performed in the QM/MM task. The default operation is a single point energy evaluation. The following list gives the selection of operations currently available in the NWChem QM/MM module;<br />
<br />
*energy - single point energy evaluation<br />
*optimize - minimize the energy by variation of the molecular structure.<br />
*dynamics - molecular dynamics using nwARGOS<br />
<br />
Here are some examples of the TASK directive for QM/MM simulations. To perform a single point energy of a QM/MM system using any QM level of theory, the directive is very simple. As with the general task directive, the QM/MM energy evaluation is the default. For a DFT energy calculation the task directive input is,<br />
<br />
task qmmm dft<br />
<br />
or completely as<br />
<br />
task qmmm dft energy<br />
<br />
To do a molecular dynamics simulation of a QM/MM system using the SCF level of theory the task directive input would be<br />
<br />
task qmmm scf dynamics<br />
<br />
The optional keyword ignore can be used to allow execution to continue even if the task fails, as discussed above.<br />
<br />
===TASK Directive for BSSE calculations===<br />
<br />
NWChem computes the basis set superposition error (BSSE) when two or more fragments are interacting by using the counterpoise method. This directive is performed if the BSSE section is present. Single point energies, energy gradients, geometry optimizations, Hessians and frequencies, at the level of theory that allows these tasks, can be obtained with the BSSE correction. The input options for the BSSE section are:<br />
<br />
BSSE <br />
MON <string monomer name> <integer natoms> <br />
[INPUT [<string input>]] <br />
[INPUT_WGHOST[<string input>]] <br />
[CHARGE [<real charge>]] <br />
[OFF] <br />
[ON]<br />
END<br />
<br />
MON defines the monomer's name and its atoms; <string monomer name> defines the name of the monomer, <integer atoms> is the list of atoms corresponding to the monomer (where such a list is relative to the initial geometry). This information is needed for each monomer. With the tag INPUT the user can modify any calculation attributes for each monomer without ghost. For example, the iterations number and the grid can be changed in a DFT calculation (see the example of the interaction between <math>Zn^{2+}</math> and water). INPUT_WGHOST is the same than INPUT but for the monomer with ghost. The input changes will be applied within this and for the following calculations, you should be cautious reverting the changes for the next monomers. CHARGE assigns a charge to a monomer and it must be consistent with the total charge in the whole system (see Section -sec:charge-). The options OFF and ON turns off and on any BSSE calculation.<br />
<br />
The energy evaluation involves 1 + 2N calculations, i.e. one for the supermolecule and two for the N monomers. [S. Simon, M. Duran, J. J. Dannenberg, J. Chem. Phys., 105, 11024 (1996)] NWChem stores the vector files for each calculation (<string monomer name>.bsse.movecs), and one hessian file (<string monomer name>.bsse.hess). The code does not assign automatically the basis set for the ghost atoms, you must assign the corresponding bqX for each element, instead.<br />
<br />
===Examples===<br />
<br />
The dimer <math>(FH)_2</math><br />
<br />
title dimer<br />
start dimer<br />
geometry units angstrom<br />
symmetry c1 <br />
F 1.47189 2.47463 -0.00000 <br />
H 1.47206 3.29987 0.00000 <br />
F 1.46367 -0.45168 0.00000 <br />
H 1.45804 0.37497 -0.00000<br />
end<br />
basis "ao basis" <br />
F library 6-31G <br />
H library 6-31G <br />
bqF library F 6-31G <br />
bqH library H 6-31G<br />
end<br />
dft; xc slater 1.0 vwn_5 1.0; direct; end<br />
bsse <br />
mon first 1 2 <br />
mon second 3 4<br />
end<br />
task dft energy<br />
<br />
Changing maxiter for a specific monomer: <math>Zn^{2+}(H_2O)</math><br />
<br />
title znwater<br />
start znwater<br />
echo<br />
geometry noautoz units angstrom<br />
symmetry c1 <br />
Zn -1.89334 -0.72741 -0.00000 <br />
O -0.20798 0.25012 0.00000 <br />
H -0.14200 1.24982 -0.00000 <br />
H 0.69236 -0.18874 -0.00000<br />
end<br />
basis "ao basis" <br />
O library 6-31G <br />
Zn library 6-31G <br />
H library 6-31G <br />
bqO library O 6-31G <br />
bqZn library Zn 6-31G <br />
bqH library H 6-31G<br />
end<br />
charge 2<br />
scf; direct; end<br />
mp2; end<br />
bsse <br />
mon metal 1 <br />
charge 2 <br />
input_wghost "scf\; maxiter 200\; end" <br />
mon water 2 3 4<br />
end<br />
task mp2 optimize<br />
<br />
==ECCE_PRINT==<br />
<br />
The ECCE_PRINT directive allows the user to print out a file, usually called ecce.out, that will allow the calculation and its<br />
results to be imported into Ecce (see http://ecce.pnl.gov).<br />
<br />
ECCE_PRINT <string name><br />
<br />
The entry for variable <name> is the name of the file that will contain the Ecce import information and should include the full path to the directory where you want that file. For example<br />
<br />
ecce_print /home/user/job/ecce.out<br />
<br />
If the full path is not given and only the file name is given, the file will be located in whatever directory the job is started in. For example, if the line<br />
<br />
ecce_print ecce.out<br />
<br />
is in the input file, the file could end up in the scratch directory if the user is using a batch script that copies the input file to a local scratch directory and then launches NWChem from there. If the system then automatically removes files in the scratch space at the end of the job, the ecce.out file will be lost. So, the best practice is to include the full path name for the file.</div>Berthttp://www.nwchem-sw.org/index.php/Release65:TCERelease65:TCE2013-06-21T17:31:35Z<p>Bert: 1 revision</p>
<hr />
<div>__NOTITLE__<br />
=Tensor Contraction Engine Module: CI, MBPT, and CC=<br />
<br />
==Overview==<br />
<br />
The Tensor Contraction Engine (TCE) Module of NWChem implements a variety of approximations that converge at the exact solutions of Schrödinger equation. They include configuration interaction theory through singles, doubles, triples, and quadruples substitutions, coupled-cluster theory through connected singles, doubles, triples, and quadruples substitutions, and many-body perturbation theory through fourth order in its tensor formulation. Not only optimized parallel programs of some of these high-end correlation theories are new, but also the way in which they have been developed is unique. The working equations of all of these methods have been derived completely automatically by a symbolic manipulation program called a Tensor Contraction Engine (TCE), and the optimized parallel programs have also been computer-generated by the same program, which were interfaced to NWChem. The development of the TCE program and this portion of the NWChem program has been financially supported by the United States Department of Energy, Office of Science, Office of Basic Energy Science, through the SciDAC program.<br />
<br />
The capabilities of the module include:<br />
<br />
* Restricted Hartree-Fock, unrestricted Hartree-Fock, and restricted open-shell Hartree-Fock references,<br />
* Restricted KS DFT and unrestricted KS DFT references,<br />
* Unrestricted configuration interaction theory (CISD, CISDT, and CISDTQ),<br />
* Unrestricted coupled-cluster theory (LCCD, CCD, LCCSD, CCSD, QCISD, CCSDT, CCSDTQ),<br />
* Unrestricted iterative many-body perturbation theory [MBPT(2), MBPT(3), MBPT(4)] in its tensor formulation,<br />
* Unrestricted coupled-cluster singles and doubles with perturbative connected triples {CCSD(T), CCSD[T]},<br />
* Unrestricted equation-of-motion coupled-cluster theory (EOM-CCSD, EOM-CCSDT, EOM-CCSDTQ) for excitation energies, transition moments and oscillator strengths, and excited-state dipole moments,<br />
* Unrestricted coupled-cluster theory (CCSD, CCSDT, CCSDTQ) for dipole moments.<br />
* Several variants of active-space CCSDt and EOMCCSDt methods that employ limited set of triply excited cluster amplitudes defined by active orbitals.<br />
* Ground-state non-iterative CC approaches that account for the effect of triply and/or quadruply excited connected clusters: the perturbative approaches based on the similarity transformed Hamiltonian: CCSD(2), <math>CCSD(2)_T</math>, <math>CCSDT(2)_Q</math>, the completely and locally renormalized methods: CR-CCSD(T), LR-CCSD(T), LR-CCSD(TQ)-1.<br />
* Excited-state non-iterative corrections due to triples to the EOMCCSD excitation energies: the completely renormalized EOMCCSD(T) method (CR-EOMCCSD(T)).<br />
* Dynamic dipole polarizabilities at the CCSD and CCSDT levels using the linear response formalism.<br />
* Ground- and excited- states the iterative second-order model CC2.<br />
* Dynamic dipole polarizabilities at the CCSDTQ level using the linear response formalism.<br />
* State-specific Multireference Coupled Cluster methods (MRCC) (Brillouin-Wigner (BW-MRCC) and Mukherjee (Mk-MRCC) approaches).<br />
<br />
The distributed binary executables do not contain CCSDTQ and its derivative methods, owing to their large volume. The source code includes them, so a user can reinstate them by setenv CCSDTQ yes and recompile TCE module. The following optimizations have been used in the module:<br />
<br />
* Spin symmetry (spin integration is performed wherever possible within the unrestricted framework, making the present unrestricted program optimal for an open-shell system. The spin adaption was not performed, although in a restricted calculation for a closed-shell system, certain spin blocks of integrals and amplitudes are further omitted by symmetry, and consequently, the present unrestricted CCSD requires only twice as many operations as a spin-adapted restricted CCSD for a closed-shell system),<br />
* Point-group symmetry,<br />
* Index permutation symmetry,<br />
* Runtime orbital range tiling for memory management,<br />
* Dynamic load balancing (local index sort and matrix multiplications) parallelism,<br />
* Multiple parallel I/O schemes including fully in-core algorithm using Global Arrays,<br />
* Frozen core and virtual approximation.<br />
* DIIS extrapolation and Jacobi update of excitation amplitudes<br />
* Additional algorithms for the 2-e integral transformation, including efficient and scalable spin-free out-of-core <math>N^5</math> algorithms.<br />
* Hybrid I/O schemes for both spin-orbital and spin-free calculations which eliminate the memory bottleneck of the 2-e integrals in favor of disk storage. Calculations with nearly 400 basis functions at the CCSD(T) can be performed on workstation using this method.<br />
* Parallel check-pointing and restart for ground-state (including property) calculations at the CCSD, CCSDT and CCSDTQ levels of theory.<br />
<br />
==Performance of CI, MBPT, and CC methods==<br />
<br />
For reviews or tutorials of these highly-accurate correlation methods, the user is referred to:<br />
<br />
* Trygve Helgaker, Poul Jorgensen and Jeppe Olsen, Molecular Electronic-Structure Theory.<br />
* A. Szabo and N. S. Ostlund, Modern Quantum Chemistry: Introduction to Advanced Electronic Structure Theory.<br />
* B. O. Roos (editor), Lecture Notes in Quantum Chemistry.<br />
<br />
For background on development of the symbolic algebra tools which help create the code used in this model see:<br />
<br />
* S. Hirata, J. Phys. Chem. A 107, 9887 (2003).<br />
* S. Hirata, J. Chem. Phys. 121, 51 (2004).<br />
* S. Hirata, Theor. Chem. Acc. 116, 2 (2006).<br />
<br />
For details of particular CC implementations, see:<br />
<br />
* S. Hirata, P.-D. Fan, A.A. Auer, M. Nooijen, P. Piecuch, J. Chem. Phys. 121, 12197 (2004).<br />
* K. Kowalski, S. Hirata, M. Wloch, P. Piecuch, T.L. Windus, J. Chem. Phys. 123, 074319 (2005).<br />
* K. Kowalski, P. Piecuch, J. Chem. Phys. 115, 643 (2001).<br />
* K. Kowalski, P. Piecuch, Chem. Phys. Lett. 347, 237 (2001).<br />
* P. Piecuch, S.A. Kucharski, and R.J. Bartlett, J. Chem. Phys. 110, 6103 (1999).<br />
* P. Piecuch, N. Oliphant, and L. Adamowicz, J. Chem. Phys. 99, 1875 (1993).<br />
* N. Oliphant and L. Adamowicz, Int. Rev. Phys. Chem. 12, 339 (1993).<br />
* P. Piecuch, N. Oliphant, and L. Adamowicz, J. Chem. Phys. 99, 1875 (1993).<br />
* K. Kowalski, P. Piecuch, J. Chem. Phys. 120, 1715 (2004).<br />
* K. Kowalski, J. Chem. Phys. 123, 014102 (2005).<br />
* P. Piecuch, K. Kowalski, I.S.O. Pimienta, M.J. McGuire, Int. Rev. Phys. Chem. 21, 527 (2002).<br />
* K. Kowalski, P. Piecuch, J. Chem. Phys. 122, 074107 (2005)<br />
* K. Kowalski, W. de Jong, J. Mol. Struct.: THEOCHEM, 768, 45 (2006).<br />
* O. Christiansen, H. Koch, P. Jørgensen, Chem. Phys. Lett. 243, 409 (1995).<br />
* K. Kowalski, J. Chem. Phys. 125, 124101 (2006).<br />
* K. Kowalski, S. Krishnamoorthy, O. Villa, J.R. Hammond, N. Govind, J. Chem. Phys. 132, 154103 (2010).<br />
* J.R. Hammond, K. Kowalski, W.A. de Jong, J. Chem. Phys. 127, 144105 (2007).<br />
* J.R. Hammond, W.A. de Jong, K. Kowalski, J. Chem. Phys. 128, 224102 (2008).<br />
* J.R. Hammond, K. Kowalski, J. Chem. Phys. 130, 194108 (2009).<br />
* J.Brabec, J. Pittner, H.J.J. van Dam, E. Apra, K. Kowalski, J. Chem. Theory Comput. 8, 487 (2012).<br />
* K. Bhaskaran-Nair, J. Brabec, E. Apra, H.J.J. van Dam. J. Pittner, K. Kowalski, J. Chem. Phys. 137, 094112 (2012).<br />
and references therein.<br />
<br />
==Algorithms of CI, MBPT, and CC methods==<br />
<br />
===Spin, spatial, and index permutation symmetry===<br />
<br />
The TCE thoroughly analyzes the working equation of many-electron theory models and automatically generates a program that takes full advantage of these symmetries at the same time. To do so, the TCE first recognizes the index permutation symmetries among the working equations, and perform strength reduction and factorization by carefully monitoring the index permutation symmetries of intermediate tensors. Accordingly, every input and output tensor (such as integrals, excitation amplitudes, residuals) has just two independent but strictly ordered index strings, and each intermediate tensor has just four independent but strictly ordered index strings. The operation cost and storage size of tensor contraction is minimized by using the index range restriction arising from these index permutation symmetries and also spin and spatial symmetry integration.<br />
<br />
===Runtime orbital range tiling===<br />
<br />
To maintain the peak local memory usage at a manageable level, in the beginning of the calculation, the orbitals are rearranged into tiles (blocks) that contains orbitals with the same spin and spatial symmetries. So the tensor contractions in these methods are carried out at the tile level; the spin, spatial, and index permutation symmetry is employed to reduce the operation and storage cost at the tile level also.<br />
The so-called tile-structure of all tensors used in CC equations is also the key-factor determining the parallel structure of the TCE CC codes . The tiling scheme corresponds to partitioning of the spin-orbital domain into smaller subsets containing the spin-orbitals of the same spin and spatial symmetries (the so-called tiles). This partitioning of the spin-orbital domain entails the blocking of all tensors corresponding to one- and two-electron integrals, cluster amplitudes, and all recursive intermediates, into smaller blocks of the size defined by the size of the tile (or tilesize for short). Since the parallel scheme used in all TCE generated codes is deeply rooted in dynamic load balancing techniques, the tile-structure defines the granularity of the work to be distributed. The size of tiles (tilesize) defines also the local memory requirements in all TCE derived CC implementations. For CI/CC/EOMCC/LR-CC models based on the sinlges and doubles models (CISD,CCSD,EOMCCSD,LR-CCSD) the peak local memory requirement is proportional to the <math>(tilesize)^{4}</math>. In approaches accounting for triples, either in iterative or non-iterative fashion, the local memory usage is proportional to <math>(tilesize)^{6}</math>. This means that in the CCSD(T), CCSDt, CCSDT, CR-EOMCCSD(T), EOMCCSDt, EOMCCSDT, LR-CCSDT caluclations the tilesize cannot be defined too large. <br />
<br />
===Dynamic load balancing parallelism===<br />
<br />
In a parallel execution, dynamic load balancing of tile-level local tensor index sorting and local tensor contraction (matrix multiplication) will be invoked.<br />
<br />
===Parallel I/O schemes===<br />
<br />
Each process is assigned a local tensor index sorting and tensor contraction dynamically. It must first retrieve the tiles of input tensors, and perform these local operations, and accumulate the output tensors to the storage. We have developed a uniform interface for these I/O operations to either (1) a global file on a global file system, (2) a global memory on a global or distributed memory system, and (3) semi-replicated files on a distributed file systems. Some of these operations depend on the ParSoft library.<br />
<br />
<br />
=== CCSD(T) method with CUDA ===<br />
<br />
NWChem 6.3 offers a possibility of using GPU accelerators to perform the most computationally intensive part of the CCSD(T) calculations (non-iterative triples corrections).<br />
To enable this option one has to enable compilation options described below and add the "cuda n" directive to the tce block of input, where "n" refers to number of CUDA devices per node.<br />
<br />
geometry/basis set specifications<br />
tce <br />
io ga<br />
freeze atomic<br />
thresh 1.0d-6<br />
tilesize 15<br />
ccsd(t)<br />
cuda 1<br />
end<br />
<br />
In the example above the number of CUDA devises is set equal to 1, which means that user will use 1 GPU per node. <br />
<br />
To enable the compilation of CUDA code one has to set the follwoing variables before the compilation of NWChem.<br />
<br />
export TCE_CUDA=Y<br />
export CUDA_LIBS="-L''<Your Path to cuda>''/lib64 -L''<Your Path to cuda>''/lib -lcudart"<br />
export CUDA_FLAGS="-arch ''compute capability 2.x or higher''"<br />
export CUDA_INCLUDE="-I. -I''<Your Path to cuda>''/include"<br />
<br />
For example:<br />
<br />
export TCE_CUDA=Y<br />
export CUDA_LIBS="-L/usr/local/cuda-5.0/lib64 -L/usr/local/cuda-5.0/lib -lcudart"<br />
export CUDA_FLAGS="-arch sm_20 "<br />
export CUDA_INCLUDE="-I. -I/usr/local/cuda-5.0/include"<br />
<br />
In addition the code needs to be compiled with the following make command<br />
<br />
make FC=<fortran compiler> CUDA=nvcc<br />
<br />
NOTE: Current version of cuda implementation is NOT supported for ARMCI_NETWORK=MPI-TS.<br />
<br />
Before running production style calculations we strongly suggest the users to perform QA test from the /nwchem/QA/tests/tce_cuda directory. A full example of a TCE CUDA<br />
input file is given below:<br />
<br />
<br />
start tce_cuda<br />
echo<br />
memory stack 1000 mb heap 100 mb global 500 mb verify<br />
geometry units bohr<br />
O 0.00000000 0.00000000 0.22138519<br />
H 0.00000000 -1.43013023 -0.88554075<br />
H 0.00000000 1.43013023 -0.88554075<br />
end<br />
basis spherical<br />
H library cc-pVDZ<br />
O library cc-pVDZ<br />
end<br />
charge 0<br />
scf<br />
thresh 1.0e-10<br />
tol2e 1.0e-10<br />
singlet<br />
rhf<br />
end<br />
tce<br />
ccsd(t)<br />
io ga<br />
cuda 1<br />
tilesize 18<br />
end<br />
task tce energy<br />
<br />
==Input syntax==<br />
<br />
The keyword to invoke the many-electron theories in the module is TCE. To perform a single-point energy calculation, include<br />
<br />
TASK TCE ENERGY<br />
<br />
in the input file, which may be preceeded by the TCE input block that details the calculations:<br />
<br />
TCE<br />
[(DFT||HF||SCF) default HF=SCF]<br />
[FREEZE [[core] (atomic || <integer nfzc default 0>)] \<br />
[virtual <integer nfzv default 0>]]<br />
[(LCCD||CCD||CCSD||CC2||LR-CCSD||LCCSD||CCSDT||CCSDTA||CCSDTQ|| \<br />
CCSD(T)||CCSD[T]||CCSD(2)_T||CCSD(2)||CCSDT(2)_Q|| \<br />
CR-CCSD[T]||CR-CCSD(T)|| \<br />
LR-CCSD(T)||LR-CCSD(TQ)-1||CREOMSD(T)|| \<br />
QCISD||CISD||CISDT||CISDTQ|| \<br />
MBPT2||MBPT3||MBPT4||MP2||MP3||MP4) default CCSD]<br />
[THRESH <double thresh default 1e-6>]<br />
[MAXITER <integer maxiter default 100>]<br />
[PRINT (none||low||medium||high||debug)<br />
<string list_of_names ...>]<br />
[IO (fortran||eaf||ga||sf||replicated||dra||ga_eaf) default ga]<br />
[DIIS <integer diis default 5>]<br />
[LSHIFT <double lshift default is 0.0d0>]<br />
[NROOTS <integer nroots default 0>]<br />
[TARGET <integer target default 1>]<br />
[TARGETSYM <character targetsym default 'none'>]<br />
[SYMMETRY]<br />
[2EORB]<br />
[2EMET <integer fast2e default 1>]<br />
[T3A_LVL] <br />
[ACTIVE_OA]<br />
[ACTIVE_OB]<br />
[ACTIVE_VA]<br />
[ACTIVE_VB]<br />
[DIPOLE]<br />
[TILESIZE <no default (automatically adjusted)>]<br />
[(NO)FOCK <logical recompf default .true.>]<br />
[FRAGMENT <default -1 (off)>]<br />
END<br />
<br />
Also supported are energy gradient calculation, geometry optimization, and vibrational frequency (or hessian) calculation, on the basis of numerical differentiation. To perform these calculations, use<br />
<br />
TASK TCE GRADIENT<br />
<br />
or<br />
<br />
TASK TCE OPTIMIZE<br />
<br />
or<br />
<br />
TASK TCE FREQUENCIES<br />
<br />
The user may also specify the parameters of reference wave function calculation in a separate block for either HF (SCF) or DFT, depending on the first keyword in the above syntax.<br />
<br />
Since every keyword except the model has a default value, a minimal input file will be<br />
<br />
GEOMETRY<br />
Be 0.0 0.0 0.0<br />
END<br />
BASIS<br />
Be library cc-pVDZ<br />
END<br />
TCE<br />
ccsd<br />
END<br />
TASK TCE ENERGY<br />
<br />
which performs a CCSD/cc-pVDZ calculation of the Be atom in its singlet ground state with a spin-restricted HF reference.<br />
<br />
New implementions of the iterative CCSD and EOMCCSD methods based on the improved task scheduling can be enable by the<br />
"set tce:nts T" command as in the following example:<br />
<br />
geometry/basis set specifications <br />
tce<br />
freeze atomic<br />
creomccsd(t)<br />
tilesize 20<br />
2eorb<br />
2emet 13<br />
eomsol 2<br />
end <br />
<br />
set tce:nts T<br />
<br />
task tce energy<br />
<br />
New task scheduling should reduce time to solutions and provide better parallel perfromance especially in large CCSD/EOMCCSD runs.<br />
<br />
==Keywords of TCE input block==<br />
<br />
===HF, SCF, or DFT -- the reference wave function===<br />
<br />
This keyword tells the module which of the HF (SCF) or DFT module is going to be used for the calculation of a reference wave function. The keyword HF and SCF are one and the same keyword internally, and are default. When these are used, the details of the HF (SCF) calculation can be specified in the SCF input block, whereas if DFT is chosen, DFT input block may be provided.<br />
<br />
For instance, RHF-RCCSDT calculation (R standing for spin-restricted) can be performed with the following input blocks:<br />
<br />
SCF<br />
SINGLET<br />
RHF<br />
END<br />
TCE<br />
SCF<br />
CCSDT<br />
END<br />
TASK TCE ENERGY<br />
<br />
This calculation (and any correlation calculation in the TCE module using a RHF or RDFT reference for a closed-shell system) skips the storage and computation of all &beta; spin blocks of integrals and excitation amplitudes. ROHF-UCCSDT (U standing for spin-unrestricted) for an open-shell doublet system can be requested by<br />
<br />
SCF<br />
DOUBLET<br />
ROHF<br />
END<br />
TCE<br />
SCF<br />
CCSDT<br />
END<br />
TASK TCE ENERGY<br />
<br />
and likewise, UHF-UCCSDT for an open-shell doublet system can be specified with<br />
<br />
SCF<br />
DOUBLET<br />
UHF<br />
END<br />
TCE<br />
SCF<br />
CCSDT<br />
END<br />
TASK TCE ENERGY<br />
<br />
The operation and storage costs of the last two calculations are identical. To use the KS DFT reference wave function for a UCCSD calculation of an open-shell doublet system,<br />
<br />
DFT<br />
ODFT<br />
MULT 2<br />
END<br />
TCE<br />
DFT<br />
CCSD<br />
END<br />
TASK TCE ENERGY<br />
<br />
Note that the default model of the DFT module is LDA.<br />
<br />
===CCSD,CCSDT,CCSDTQ,CISD,CISDT,CISDTQ, MBPT2,MBPT3,MBPT4, etc. -- the correlation models===<br />
<br />
These keywords stand for the following models:<br />
<br />
* LCCD: linearized coupled-cluster doubles,<br />
* CCD: coupled-cluster doubles,<br />
* LCCSD: linearized coupled-cluster singles & doubles,<br />
* CCSD: coupled-cluster singles & doubles (also EOM-CCSD),<br />
* CCSD_ACT: coupled-cluster singles & active doubles (also active-space EOMCCSD),<br />
* LR-CCSD: locally renormalized EOMCCSD method,<br />
* CC2: second-order approximate coupled cluster with singles and doubles model<br />
* CCSDT: coupled-cluster singles, doubles, & triples (also EOM-CCSDT),<br />
* CCSDTA: coupled-cluster singles, doubles, & active triples (also EOM-CCSDT). Three variants of the active-space CCSDt and EOMCCSDt approaches can be selected based on various definitions of triply excited clusters: (1) version I (keyword T3A_LVL 1) uses the largest set of triply excited amplitudes defined by at least one occupied and one unoccupied active spinorbital labels. (2) Version II (keyword T3A_LVL 2) uses triply excited amplitudes that carry at least two occupied and unoccupied active spinorbital labels. (3) Version III (keyword T3A_LVL 3) uses triply excited amplitudes that are defined by active indices only. Each version requires defining relevant set of occupied active &alpha; and &beta; spinorbitals (ACTIVE_OA and ACTIVE_OB) as well as active unoccupied &alpha; and &beta; spinorbitals (ACTIVE_VA and ACTIVE_VB).<br />
* CCSDTQ: coupled-cluster singles, doubles, triples, & quadruples (also EOM-CCSDTQ),<br />
* CCSD(T): CCSD and perturbative connected triples,<br />
* CCSD[T]: CCSD and perturbative connected triples,<br />
* CR-CCSD[T]: completely renormalized CCSD[T] method,<br />
* CR-CCSD(T): completely renormalized CCSD(T) method,<br />
* CCSD(2)_T: CCSD and perturbative <math>CCSD(T)_T</math> correction,<br />
* CCSD(2)_TQ: CCSD and perturbative CCSD(2) correction,<br />
* CCSDT(2)_Q: CCSDT and perturbative CCSDT(2)$_Q$ correction.<br />
* LR-CCSD(T): CCSD and perturbative locally renormalized CCSD(T) correction,<br />
* LR-CCSD(TQ)-1: CCSD and perturbative locally renormalized CCSD(TQ) (LR-CCSD(TQ)-1) correction,<br />
* CREOMSD(T): EOMCCSD energies and completely renormalized EOMCCSD(T)(IA) correction. In this option NWCHEM prints two components: (1) total energy of the K-th state <math>E_K=E_K^{\rm EOMCCSD}+\delta_K^{\rm CR-EOMCCSD(T),IA}(T)</math> and (2) the so-called &delta;-corrected EOMCCSD excitation energy <math>\omega_K^{\rm CR-EOMCCSD(T),IA}=\omega_K^{\rm EOMCCSD}+\delta_K^{\rm CR-EOMCCSD(T),IA}(T)</math>.<br />
* CREOM(T)AC: active-space CR-EOMCCSD(T) approach,<br />
* QCISD: quadratic configuration interaction singles & doubles,<br />
* CISD: configuration interaction singles & doubles,<br />
* CISDT: configuration interaction singles, doubles, & triples,<br />
* CISDTQ: configuration interaction singles, doubles, triples, & quadruples,<br />
* MBPT2=MP2: iterative tensor second-order many-body or Møller-Plesset perturbation theory,<br />
* MBPT3=MP3: iterative tensor third-order many-body or Møller-Plesset perturbation theory,<br />
* MBPT4=MP4: iterative tensor fourth-order many-body or Møller-Plesset perturbation theory,<br />
<br />
All of these models are based on spin-orbital expressions of the amplitude and energy equations, and designed primarily for spin-unrestricted reference wave functions. However, for a restricted reference wave function of a closed-shell system, some further reduction of operation and storage cost will be made. Within the unrestricted framework, all these methods take full advantage of spin, spatial, and index permutation symmetries to save operation and storage costs at every stage of the calculation. Consequently, these computer-generated programs will perform significantly faster than, for instance, a hand-written spin-adapted CCSD program in NWChem, although the nominal operation cost for a spin-adapted CCSD is just one half of that for spin-unrestricted CCSD (in spin-unrestricted CCSD there are three independent sets of excitation amplitudes, whereas in spin-adapted CCSD there is only one set, so the nominal operation cost for the latter is one third of that of the former. For a restricted reference wave function of a closed-shell system, all &beta; spin block of the excitation amplitudes and integrals can be trivially mapped to the all &alpha; spin block, reducing the ratio to one half).<br />
<br />
While the MBPT (MP) models implemented in the TCE module give identical correlation energies as conventional implementation for a canonical HF reference of a closed-shell system, the former are intrinsically more general and theoretically robust for other less standard reference wave functions and open-shell systems. This is because the zeroth order of Hamiltonian is chosen to be the full Fock operatior (not just the diagonal part), and no further approximation was invoked. So unlike the conventional implementation where the Fock matrix is assumed to be diagonal and a correlation energy is evaluated in a single analytical formula that involves orbital energies (or diagonal Fock matrix elements), the present tensor MBPT requires the iterative solution of amplitude equations and subsequent energy evaluation and is generally more expensive than the former. For example, the operation cost of many conventional implementation of MBPT(2) scales as the fourth power of the system size, but the cost of the present tensor MBPT(2) scales as the fifth power of the system size, as the latter permits non-canonical HF reference and the former does not (to reinstate the non-canonical HF reference in the former makes it also scale as the fifth power of the system size).<br />
<br />
=== State-Specific Multireference Coupled Cluster methods (MRCC) ===<br />
<br />
Several State-Specific MRCC methods have been implemented in 6.3 release of nwchem. These include:<br />
* Iterative Brillouin-Wigner MRCC method employing single and double excitations (BW-MRCCSD)<br />
* Iterative Mukherjee MRCC method employing single and double excitations (Mk-MRCCSD)<br />
* Non-iterative methods accounting for triple excitations in MRCC formalisms: BW-MRCCSD(T) and Mk-MRCCSD(T)<br />
<br />
The current implementation can be used in studies of systems composed of an even number of correlated electrons (this limitation will be removed in the next release).<br />
This includes typical examples of diradical, open-shell singlets, and bond-forming/breaking processes where the corresponding wavefunctions <br />
have strong quasidegenerate character.<br />
<br />
To enable the compilation of the MRCC codes one has to set the following variable before the compilation of NWChem<br />
<br />
export MRCC_METHODS=y<br />
<br />
To run MRCC calculations the user has to define two groups in the input file. First, the TCE group and secondly the MRCCDATA group.<br />
In the TCE group the iterative level of theory is defined, e.g. BWCCSD or MKCCSD.<br />
This implementation was designed for complete model spaces (CMS) which means that the modelspace contains all Slater determinants of all possible (in the context of the spatial and spin symmetry, M_s) distributions of active electrons among active spin orbitals.<br />
The user can define the modelspace in two ways. As a first approach the model space can be defined by hand, as shown in the two examples below. The input of the model space starts with the "NREF" keyword followed by the number of reference configurations that will be used, which should equal the number of strings for references below. In the input "2" refers to doubly occupied orbitals, "a" to alpha electrons, "b" to beta electrons and "0" identifies an unoccupied orbital. When the model space is defined by hand the occupation strings have to include the frozen orbitals as well. In the second way the CMS can be generated using the keyword "CAS" followed by the number of active electrons and the number of active orbitals. When using the "CAS" keyword we strongly recommend that users check the references that are generated. <br />
<br />
As the model space typically includes multiple configurations it is possible to use the MRCC method to calculate excited states instead of the ground state. For this reason it is required to specify the root of interest. The ROOT keyword followed by the root number specifies the state the code calculates. The lowest root, the ground state, is identified as root 1. If one wants to calculate the third root the keyword ROOT 3 should be used. An example is given below.<br />
<br />
<br />
echo<br />
start tce_mrcc_bwcc <br />
memory stack 1000 mb heap 100 mb global 500 mb verify<br />
geometry units au<br />
H 0.00000000 -2.27289450 -1.58834700<br />
O 0.00000000 0.00000000 -0.01350000<br />
H 0.00000000 2.27289450 -1.58834700<br />
end<br />
basis spherical<br />
O library cc-pvdz<br />
H library cc-pvdz<br />
end<br />
charge 0<br />
scf<br />
rohf<br />
singlet<br />
thresh 1.0e-10<br />
tol2e 1.0e-10<br />
end<br />
tce<br />
bwccsd<br />
thresh 1.0e-7<br />
targetsym a1<br />
io ga<br />
tilesize 18<br />
end<br />
mrccdata<br />
root 1<br />
nref 4<br />
222220<br />
222202<br />
2222ab<br />
2222ba<br />
end<br />
task tce energy<br />
<br />
<br />
echo<br />
start tce_mrcc_mkcc <br />
memory stack 1000 mb heap 100 mb global 500 mb verify<br />
geometry units au<br />
H 0.00000000 -2.27289450 -1.58834700<br />
O 0.00000000 0.00000000 -0.01350000<br />
H 0.00000000 2.27289450 -1.58834700<br />
end<br />
basis spherical<br />
O library cc-pvdz<br />
H library cc-pvdz<br />
end<br />
charge 0<br />
scf<br />
rohf<br />
singlet<br />
thresh 1.0e-10<br />
tol2e 1.0e-10<br />
end<br />
tce<br />
mkccsd<br />
thresh 1.0e-5<br />
targetsym a1<br />
maxiter 100<br />
io ga<br />
tilesize 18<br />
end<br />
mrccdata<br />
root 1<br />
cas 2 2 # Please make sure the references generated are correct.<br />
end<br />
task tce energy<br />
<br />
<br />
This version of MRCC works only with GA as specified by the "IO GA" option. In addition this code works only with the spin-orbit 4-index transformation, however in all circumstances an RHF Hartree-Fock initial calculation has to be used. In this implementation the effective Hamiltonian operator contains only scalar, one- and two-body many body components. Finally, in our implementation the BWCCSD methods use the energy threshold for the convergence, whereas the MKCCSD method uses the norm of the residual.<br />
<br />
In addition to the iterative single-double calculations the code can calculate non-iterative triples corrections. To request these triples corrections the keyword "SE4T" should be added to the MRCCDATA block. The implementation details and the from of the triples correction are given in equation 20 [ [http://dx.doi.org/10.1063/1.4747698 J. Chem. Phys. 137, 094112 (2012)]]. <br />
<br />
<br />
echo<br />
start tce_mrcc_bwcc <br />
memory stack 1000 mb heap 100 mb global 500 mb verify<br />
geometry units au<br />
H 0.00000000 -2.27289450 -1.58834700<br />
O 0.00000000 0.00000000 -0.01350000<br />
H 0.00000000 2.27289450 -1.58834700<br />
end<br />
basis spherical<br />
O library cc-pvdz<br />
H library cc-pvdz<br />
end<br />
charge 0<br />
scf<br />
rohf<br />
singlet<br />
thresh 1.0e-10<br />
tol2e 1.0e-10<br />
end<br />
tce<br />
bwccsd<br />
thresh 1.0e-7<br />
targetsym a1<br />
io ga<br />
tilesize 18<br />
end<br />
mrccdata<br />
se4t<br />
no_aposteriori<br />
root 1<br />
nref 4<br />
222220<br />
222202<br />
2222ab<br />
2222ba<br />
end<br />
task tce energy<br />
<br />
<br />
echo<br />
start tce_mrcc_mkcc <br />
memory stack 1000 mb heap 100 mb global 500 mb verify<br />
geometry units au<br />
H 0.00000000 -2.27289450 -1.58834700<br />
O 0.00000000 0.00000000 -0.01350000<br />
H 0.00000000 2.27289450 -1.58834700<br />
end<br />
basis spherical<br />
O library cc-pvdz<br />
H library cc-pvdz<br />
end<br />
charge 0<br />
scf<br />
rohf<br />
singlet<br />
thresh 1.0e-10<br />
tol2e 1.0e-10<br />
end<br />
tce<br />
mkccsd<br />
thresh 1.0e-5<br />
targetsym a1<br />
io ga<br />
tilesize 18<br />
maxiter 100<br />
end<br />
mrccdata<br />
se4t<br />
root 1<br />
nref 4<br />
222220<br />
222202<br />
2222ab<br />
2222ba<br />
end<br />
task tce energy<br />
<br />
The current version of the MRCC codes contains also a pilot implementation of the reference-level-parallelism based on the use of processor groups for BWCCSD and BWCCSD(T) approaches. The main ideas of this approach have been described in<br />
<br />
* J.Brabec, J. Pittner, H.J.J. van Dam, E. Apra, K. Kowalski, [http://dx.doi.org/10.1021/ct200809m J. Chem. Theory Comput. 8, 487 (2012)].<br />
* K. Bhaskaran-Nair, J. Brabec, E. Apra, H.J.J. van Dam. J. Pittner, K. Kowalski, [http://dx.doi.org/10.1063/1.4747698 J. Chem. Phys. 137, 094112 (2012)].<br />
<br />
Two essential keywords have to be added to the "mrccdata" block of the input: <br />
subgroupsize n<br />
improvetiling<br />
and <br />
diis 0<br />
in tce block.<br />
The "subgroupsize n" defines the size of the subgroup and improvetiling refers to the data representation in the MRCC subgroup algorithm.<br />
For example, if user has 4 references and total 32 cores/CPU then n should be defined as 32/4=8. <br />
If user has 10 references and 1200 cores/CPU available then the size of the subgroupsize (n) is 120. <br />
<br />
echo<br />
start tce_mrcc_bwcc_subgroups <br />
memory stack 1000 mb heap 100 mb global 500 mb verify<br />
geometry units au<br />
H 0.00000000 -2.27289450 -1.58834700<br />
O 0.00000000 0.00000000 -0.01350000<br />
H 0.00000000 2.27289450 -1.58834700<br />
end<br />
basis spherical<br />
O library cc-pvdz<br />
H library cc-pvdz<br />
end<br />
charge 0<br />
scf<br />
rohf<br />
singlet<br />
thresh 1e-12<br />
tol2e 1e-12<br />
end<br />
tce<br />
bwccsd<br />
targetsym a1<br />
io ga<br />
diis 0<br />
thresh 1e-7<br />
tilesize 18<br />
end<br />
mrccdata<br />
subgroupsize 2 # Please read the documentation below.<br />
improvetiling<br />
root 1<br />
cas 2 2<br />
end<br />
task tce energy<br />
<br />
CAUTION: Before using the subgroup-based algorithm the users should perform the GA subgroup test in nwchem/src/tools/ga-5-2/global/testing/pgtest.x and pg2test.x in the same location. Additionally it is strongly encouraged to run the NWChem QA tests from the /nwchem/QA/tests/tce_mrcc_bwcc_subgroups directory<br />
with various combinations of subgroup size and total number of CPU.<br />
<br />
===THRESH -- the convergence threshold of iterative solutions of amplitude equations===<br />
<br />
This keyword specifies the convergence threshold of iterative solutions of amplitude equations, and applies to all of the CI, CC, and MBPT models. The threshold refers to the norm of residual, namely, the deviation from the amplitude equations. The default value is 1e-6.<br />
<br />
===MAXITER -- the maximum number of iterations===<br />
<br />
It sets the maximum allowed number iterations for the iterative solutions of amplitude equations. The default value is 100.<br />
<br />
===IO -- parallel I/O scheme===<br />
<br />
There are five parallel I/O schemes implemented for all the models, which need to be wisely chosen for a particular problem and computer architecture.<br />
<br />
* fortran : Fortran77 direct access,<br />
* eaf : Exclusive Access File library,<br />
* ga : Fully incore, Global Array virtual file,<br />
* sf : Shared File library,<br />
* replicated : Semi-replicated file on distributed file system with EAF library.<br />
* dra : Distributed file on distributed file system with DRA library.<br />
* ga_eaf : Semi-replicated file on distributed file system with EAF library. GA is used to speedup the file reconciliation.<br />
<br />
<br />
The GA algorithm, which is default, stores all input (integrals and excitation amplitudes), output (residuals), and intermediate tensors in the shared memory area across all nodes by virtue of GA library. This fully incore algorithm replaces disk I/O by inter-process communications. This is a recommended algorithm whenever feasible. Note that the memory management through runtime orbital range tiling described above applies to local (unshared) memory of each node, which may be separately allocated from the shared memory space for GA. So when there is not enough shared memory space (either physically or due to software limitations, in particular, shmmax setting), the GA algorithm can crash due to an out-of-memory error. The replicated scheme is the currently the only disk-based algorithm for a genuinely distributed file system. This means that each node keeps an identical copy of input tensors and it holds non-identical overlapping segments of intermediate and output tensors in its local disk. Whenever data coherency is required, a file reconcilation process will take place to make the intermediate and output data identical throughout the nodes. This algorithm, while requiring redundant data space on local disk, performs reasonably efficiently in parallel. For sequential execution, this reduces to the EAF scheme. For a global file system, the SF scheme is recommended. This together with the Fortran77 direct access scheme does not usually exhibit scalability unless shared files on the global file system also share the same I/O buffer. For sequential executions, the SF, EAF, and replicated schemes are interchangeable, while the Fortran77 scheme is appreciably slower.<br />
<br />
Two new I/O algorithms dra and ga_eaf combines GA and DRA or EAF based replicated algorithm. In the former, arrays that are not active (e.g., prior T amplitudes used in DIIS or EOM-CC trial vectors) in GA algorithm will be moved to DRA. In the latter, the intermediates that are formed by tensor contractions are initially stored in GA, thereby avoiding the need to accumulate the fragments of the intermediate scattered in EAFs in the original EAF algorithm. Once the intermediate is formed completely, then it will be replicated as EAFs.<br />
<br />
The spin-free 4-index transformation algorithms are exclusively compatible with the GA I/O scheme, although out-of-core algorithms for the 4-index transformation are accessible using the 2emet options. See [[#2EMET -- alternative storage of two-electron integrals|Alternative storage of two-electron integrals]] for details.<br />
<br />
===DIIS -- the convergence acceleration===<br />
<br />
It sets the number iterations in which a DIIS extrapolation is performed to accelerate the convergence of excitation amplitudes. The default value is 5, which means in every five iteration, one DIIS extrapolation is performed (and in the rest of the iterations, Jacobi rotation is used). When zero or negative value is specified, the DIIS is turned off. It is not recommended to perform DIIS every iteration, whereas setting a large value for this parameter necessitates a large memory (disk) space to keep the excitation amplitudes of previous iterations. In 5.0 version we significantly improved the DIIS solver by re-organizing the itrative process and by introducing the level shift option (lshift) that enable to increase small orbital energy differences used in calculating the up-dates for cluster amplitudes. Typical values for lshift oscillates between 0.3 and 0.5 for CC calculations for ground states of multi-configurational character. Otherwise, the value of lshift is by default set equal to 0.<br />
<br />
===FREEZE -- the frozen core/virtual approximation===<br />
<br />
Some of the lowest-lying core orbitals and/or some of the highest-lying virtual orbitals may be excluded in the calculations by this keyword (this does not affect the ground state HF or DFT calculation). No orbitals are frozen by default. To exclude the atom-like core regions altogether, one may request<br />
<br />
FREEZE atomic<br />
<br />
To specify the number of lowest-lying occupied orbitals be excluded, one may use<br />
<br />
FREEZE 10<br />
<br />
which causes 10 lowest-lying occupied orbitals excluded. This is equivalent to writing<br />
<br />
FREEZE core 10<br />
<br />
To freeze the highest virtual orbitals, use the virtual keyword. For instance, to freeze the top 5 virtuals<br />
<br />
FREEZE virtual 5<br />
<br />
===NROOTS -- the number of excited states===<br />
<br />
One can specify the number of excited state roots to be determined. The default value is 1. It is advised that the users request several more roots than actually needed, since owing to the nature of the trial vector algorithm, some low-lying roots can be missed when they do not have sufficient overlap with the initial guess vectors.<br />
<br />
===TARGET and TARGETSYM -- the target root and its symmetry===<br />
<br />
At the moment, the first and second geometrical derivatives of excitation energies that are needed in force, geometry, and frequency calculations are obtained by numerical differentiation. These keywords may be used to specify which excited state root is being used for the geometrical derivative calculation. For instance, when TARGET 3 and TARGETSYM a1g are included in the input block, the total energy (ground state energy plus excitation energy) of the third lowest excited state root (excluding the ground state) transforming as the irreducible representation a1g will be passed to the module which performs the derivative calculations. The default values of these keywords are 1 and none, respectively.<br />
<br />
The keyword TARGETSYM is essential in excited state geometry optimization, since it is very common that the order of excited states changes due to the geometry changes in the course of optimization. Without specifying the TARGETSYM, the optimizer could (and would likely) be optimizing the geometry of an excited state that is different from the one the user had intended to optimize at the starting geometry. On the other hand, in the frequency calculations, TARGETSYM must be none, since the finite displacements given in the course of frequency calculations will lift the spatial symmetry of the equilibrium geometry. When these finite displacements can alter the order of excited states including the target state, the frequency calculation is not be feasible.<br />
<br />
===SYMMETRY -- restricting the excited state symmetry===<br />
<br />
By adding this keyword to the input block, the user can request the module to seek just the roots of the specified irreducible representation as TARGETSYM. By default, this option is not set. TARGETSYM must be specified when SYMMETRY is invoked.<br />
<br />
===EOMSOL -- alternative solver for the right EOMCCSD eigenvalue problem===<br />
<br />
The EOMSOL enables the user to switch between two algorithms for solving EOMCCSD eigenproblem. When EOMSOL is set equal to 1<br />
("eomsol 1" directive in the tce group) the old solver is invoked. The advantage of this solver is a possibility of finding states of complicated configurational structure, for example doubly excited states. However, the dimension of the iterative space increases with each iteration and in effect this algorithm requires large memory allocations especially for large systems. In order to address this bottleneck, new algorithm ("eomsol 2" directive in the tce group) was designed. In EOMSOL 2 algorithm all iterations are split into microcycles corresponding to diis microiterations (the use of "diis" parameter is discussed earlier). This algorithm enables the user to precisely estimate the memory usage in the EOMCCSD calculations, which is equal to diis*nroots*(size_x1+size_x2), where diis is the length of the DIIS cycle, nroots is the number of sought roots, size_x1 corresponds to the size of GA storing singly excited EOMCC almplitudes, and size_x2 is the size of GA with doubly excited EOMCC amplitudes. Generally, larger values of diis parameter lead to a faster convergence, however, this happens at the expense of larger memory requirements. It is recommended not to use in the EOMCCSD calculations with "eomsol 2" diis parameter smaller than 5, which is its default value. The EOMSOL 2 algorithm uses the CIS vectors as initial guesses, and for this reason is suited mainly to track singly excited states. By default, the EOMSOL 1 option is called in the EOMCCSD calculations. It should be also stressed that all iterative EOMCC methods with higher than double excitations use EOMSOL 1 approach.<br />
<br />
In some situations it is convenient to use separate convergence threshold for the CCSD and EOMCCSD solvers. <br />
This can be achieved by setting proper environmetal variables. In the following example<br />
<br />
geometry/basis set specifications<br />
tce <br />
thresh 1.0d-6<br />
ccsd<br />
nroots 2<br />
end<br />
set tce:thresheom 1.0d-4<br />
task tce energy<br />
<br />
the CCSD equations will be converged to the 1.0d-6 threshold while the EOMCCSD ones to 1.0d-4. This option shoul dbe used with the "eomsol 2" option.<br />
In some situations finding several (n) roots to the EOMCCSD equations can be quite challenging. To by-pass this problem one can use the "n+1" model, i.e.,<br />
we request another root to be converged. Usually, the presence the "buffer" root can imporve the iterative process for n roots of interest. However, the buffer root does not have to be converged to the same accuracy as n roots of interest. The follwing example, shows how to handle this process (we chose n=2, n+1=3):<br />
<br />
geometry/basis set specifications<br />
tce <br />
freeze core<br />
ccsd<br />
nroots 3<br />
thresh 1.0d-6<br />
end<br />
set tce:thresheom 1.0d-4<br />
set tce:threshl 1.0d-3<br />
task tce energy<br />
<br />
In this example the CCSD equations are solved with the 1.0d-6 threshold, the first n (2) EOMCCSD roots are determined with the 10d-4 accuracy, while the <br />
buffer root is determined with relax conv. criterion 1.0d-3.<br />
<br />
===2EORB -- alternative storage of two-electron integrals===<br />
<br />
In the 5.0 version a new option has been added in order to provide more economical way of storing two-electron integrals used in CC calculations based on the RHF and ROHF references. The 2EORB keyword can be used for all CC methods except for those using an active-space (CCSDt). All two-electron integrals are transformed and subsequently stored in a way which is compatible with assumed tiling scheme. The transformation from orbital to spinorbital form of the two-electron integrals is performed on-the-fly during execution of the CC module. This option, although slower, allows to significantly reduce the memory requirements needed by the first half of 4-index transformation and final file with fully transformed two-electron integrals. Savings in the memory requirements on the order of magnitude (and more) have been observed for large-scale open-shell calculations.<br />
<br />
===2EMET -- alternative storage of two-electron integrals===<br />
<br />
Several new computation-intensive algorithms has been added with the purpose of improving scalability and overcoming local memory bottleneck of the 5.0 2EORB 4-index transformation. In order to give the user a full control over this part of the TCE code several keywords were designed to define the most vital parameters that determine the perfromance of 4-index transformation. All new keywords must be used with the 2EORB keyword. The 2emet keyword (default value 1 or 2emet 1, refers to the older 4-index transformation), defines the algorithm to be used. <br />
By putting 2emet 2 the TCE code will execute the algoritm based on the two step procedure with two intermediate files. In some instances this algorithm is characterized by better timings compared to algorithms 3 and 4, although it is more memory demanding. In contrast to algorithms nr 1,3, and 4 this approach can make use of a disk to store intermediate files. For this purpose one should use the keyword idiskx (idiskx 0 causes that all intermediate files are stored on global arrays, while idiskx 1 tells the code to use a disk to store intermediates; default value of idiskx is equal 0). Algorithm nr 3 (2emet 3) uses only one intermediate file whereas algorithm nr 4 (2emet 4) is a version of algorithm 3 with the option of reducing the memory requirements. For example, by using new keyword split 4 we will reduce the size of only intermediate file by factor of 4 (the split keyword can be only used in the context of algorithm nr 4). All new algorithms (i.e. 2emet 2+) use the attilesize setting to define the size of the atomic tile. By default attilesize is set equal 30. For larger systems the use of larger values of attilesize is recommended (typically between 40-60).<br />
<br />
Additional algorithms are numbered 5, 6 and 9. Other values of 2emet are not supported and refer to methods which do not function properly. Algorithms 5 and 6 were written as out-of-core <math>N^5</math> methods (idiskx 1) and are the most efficient algorithms at the present time. The corresponding in-core variants (idiskx 0) are available but require excessive memory with respect to the methods discussed above, although they may be faster if sufficient memory is available (to get enough memory often requires excessive nodes, which decreases performance in the later stages of the calculation). The difference between 5 and 6 is that 5 writes to a single file (SF or GA) while 6 uses multiple files. For smaller calculations, particularly single-node jobs, 5 is faster than 6, but for more than a handful of processors, algorithm 6 should be used. The perforance discrepancy depends on the hardware used but in algorithm eliminates simulataneous disk access on parallel file systems or memory mutexes for the in-core case. For NFS filesystems attached to parallel clusters, no performance differences have been observed, but for Lustre and PVFS they are signficant. Using algorithm 5 for large parallel file systems will make the file system inaccessible to other users, invoking the wrath of system administrators.<br />
<br />
Algorithm 9 is an out-of-core solution to the memory bottleneck of the 2-e integrals. In this approach, the intermediates of the 4-index transformation as well as the MO integrals are stored in an SF file. As before, this requires a shared file system. Because algorithm 9 is based upon algorithm 5, described above, it is not expected to scale. The primary purpose of algorithm 9 is to make the performance of the NWChem coupled-cluster codes competive with fast serial codes on workstations. It succeeds in this purpose when corresponding functionality is compared. A more scalable version of this algorithm is possible, but the utility is limited since large parallel computers do not permit the wall times necessary to use an out-of-core method, which is necessarily slower than the in-core variant. An extensible solution to these issues using complex heterogeneous I/O is in development. Restarting with algorithm 9 is not supported and attempting to use this feature with the present version may produce meaningless results.<br />
<br />
New is the inclusion of multiple 2emet options for the spin-orbital transformations, which are the default when 2eorb is not set and are mandatory for UHF and KS references. The are currently three algorithms 1, 2 and 3 available. The numbering scheme does not correspond in any way to the numbering scheme for the 2eorb case, except that 2emet 1 corresponds to the default algorithm present in previous releases, which uses the user-defined I/O scheme. Algorithm 2 (2emet 2) writes an SF file for the half-transformed integrals, which is at least an order-of-magnitude larger than the fully-transformed integrals, but stores the fully-transformed integrals in core. Thus, once the 4-index transformation is complete, this algorithm will perform exactly as when algorithm 1 is used. Unfortuntely, the spin-orbital 2-e fully-transformed integrals are still quite large and an algorithm corresponding to 2eorb/2emet=9 is available with 2emet 3. Algorithm 3 is also limited in its scalability, but it permits relatively large UHF-based calculations using single workstations for patient users.<br />
<br />
In cases where the user has access to both shared and local filesystems for parallel calculations, the permanent_dir setting refers to the location of SF files. The file system for scratch_dir will not be used for any of the 4-index transformation algorithms which are compatible with io=ga.<br />
<br />
Algorithms 13 and 14 are the <math>N^5</math> variants of algorithms 3 and 4. They are the most efficient in core GA-based algorithms for the RHF and ROHF reference functions.<br />
Again, two parameters are needed to define the perfromance of these algorithms: tilesize and attilesize. By default attilesize is set equal to 40. In all runs tilesize is required to be less than attilesize (tilesize < attilesize).<br />
<br />
In the later part of this manual several examples illustrate the use of the newly introduced keywords.<br />
<br />
===DIPOLE -- the ground- and excited-state dipole moments===<br />
<br />
When this is set, the ground-state CC calculation will enter another round of iterative step for the so-called $\Lambda$ equation to obtain the one-particle density matrix and dipole moments. Likewise, for excited-states (EOM-CC), the transition moments and dipole moments will be computed when (and only when) this option is set. In the latter case, EOM-CC left hand side solutions will be sought incurring approximately three times the computational cost of excitation energies alone (note that the EOM-CC effective Hamiltonian is not Hermitian and has distinct left and right eigenvectors).<br />
<br />
===(NO)FOCK -- (not) recompute Fock matrix===<br />
<br />
The default is FOCK meaning that the Fock matrix will be reconstructed (as opposed to using the orbital energies as the diagonal part of Fock). This is essential in getting correct correlation energies with ROHF or DFT reference wave functions. However, currently, this module cannot reconstruct the Fock matrix when one-component relativistic effects are operative. So when a user wishes to run TCE's correlation methods with DK or other relativistic reference, NOFOCK must be set and orbital energies must be used for the Fock matrix.<br />
<br />
===PRINT -- the verbosity===<br />
<br />
This keyword changes the level of output verbosity. One may also request some particular items in the table below. <br />
<br />
<br />
<center><br />
{| border='1' cellspacing='0'<br />
|+Printable items in the TCE modules and their default print levels<br />
| Item<br />
| Print Level<br />
| Description<br />
|-<br />
| "time"<br />
| vary<br />
| CPU and wall times<br />
|-<br />
| "tile"<br />
| vary<br />
| Orbital range tiling information<br />
|-<br />
| "t1"<br />
| debug<br />
| <math>T_1</math> excitation amplitude dumping<br />
|-<br />
| "t2"<br />
| debug<br />
| <math>T_2</math> excitation amplitude dumping<br />
|-<br />
| "t3"<br />
| debug<br />
| <math>T_3</math> excitation amplitude dumping<br />
|-<br />
| "t4"<br />
| debug<br />
| <math>T_4</math> excitation amplitude dumping<br />
|-<br />
| "general information"<br />
| default<br />
| General information<br />
|-<br />
| "correlation information"<br />
| default<br />
| TCE information<br />
|-<br />
| "mbpt2"<br />
| debug<br />
| Caonical HF MBPT2 test<br />
|-<br />
| "get_block"<br />
| debug<br />
| I/O information<br />
|-<br />
| "put_block"<br />
| debug<br />
| I/O information<br />
|-<br />
| "add_block"<br />
| debug<br />
| I/O information<br />
|-<br />
| "files"<br />
| debug<br />
| File information<br />
|-<br />
| "offset"<br />
| debug<br />
| File offset information<br />
|-<br />
| "ao1e"<br />
| debug<br />
| AO one-electron integral evaluation<br />
|-<br />
| "ao2e"<br />
| debug<br />
| AO two-electron integral evaluation<br />
|-<br />
| "mo1e"<br />
| debug<br />
| One-electron integral transformation<br />
|-<br />
| "mo2e"<br />
| debug<br />
| Two-electron integral transformation<br />
|}<br />
</center><br />
<br />
<br />
==Sample input==<br />
<br />
The following is a sample input for a ROHF-UCCSD energy calculation of a water radical cation.<br />
<br />
START h2o<br />
TITLE "ROHF-UCCSD/cc-pVTZ H2O"<br />
CHARGE 1<br />
GEOMETRY<br />
O 0.00000000 0.00000000 0.12982363<br />
H 0.75933475 0.00000000 -0.46621158<br />
H -0.75933475 0.00000000 -0.46621158<br />
END<br />
BASIS<br />
* library cc-pVTZ<br />
END<br />
SCF<br />
ROHF<br />
DOUBLET<br />
THRESH 1.0e-10<br />
TOL2E 1.0e-10<br />
END<br />
TCE<br />
CCSD<br />
END<br />
TASK TCE ENERGY<br />
<br />
The same result can be obtained by the following input:<br />
<br />
START h2o<br />
TITLE "ROHF-UCCSD/cc-pVTZ H2O"<br />
CHARGE 1<br />
GEOMETRY<br />
O 0.00000000 0.00000000 0.12982363<br />
H 0.75933475 0.00000000 -0.46621158<br />
H -0.75933475 0.00000000 -0.46621158<br />
END<br />
BASIS<br />
* library cc-pVTZ<br />
END<br />
SCF<br />
ROHF<br />
DOUBLET<br />
THRESH 1.0e-10<br />
TOL2E 1.0e-10<br />
END<br />
TASK UCCSD ENERGY<br />
<br />
EOMCCSD calculations with EOMSOL 2 algorithm. In these claculations the diis value of 8 will be used both in the CCSD and EOMCCSD iterations.<br />
<br />
TITLE "tce_eomccsd_eomsol2"<br />
ECHO<br />
START tce_eomccsd_eomsol2<br />
GEOMETRY UNITS ANGSTROM<br />
N .034130 -.986909 .000000<br />
N -1.173397 .981920 .000000<br />
C -1.218805 -.408164 .000000<br />
C -.007302 1.702153 .000000<br />
C 1.196200 1.107045 .000000<br />
C 1.289085 -.345905 .000000<br />
O 2.310232 -.996874 .000000<br />
O -2.257041 -1.026495 .000000<br />
H .049329 -1.997961 .000000<br />
H -2.070598 1.437050 .000000<br />
H -.125651 2.776484 .000000<br />
H 2.111671 1.674079 .000000<br />
END<br />
BASIS<br />
* library 6-31G<br />
END<br />
SCF<br />
THRESH 1.0e-10<br />
TOL2E 1.0e-10<br />
SINGLET<br />
RHF<br />
END<br />
TCE<br />
FREEZE ATOMIC<br />
CREOMSD(T)<br />
EOMSOL 2<br />
DIIS 8<br />
TILESIZE 15<br />
THRESH 1.0d-5<br />
2EORB<br />
2EMET 13<br />
NROOTS 1<br />
END<br />
TASK TCE ENERGY<br />
<br />
EOM-CCSDT calculation for excitation energies, excited-state dipole, and transition moments.<br />
<br />
START tce_h2o_eomcc<br />
GEOMETRY UNITS BOHR<br />
H 1.474611052297904 0.000000000000000 0.863401706825835<br />
O 0.000000000000000 0.000000000000000 -0.215850436155089<br />
H -1.474611052297904 0.000000000000000 0.863401706825835<br />
END<br />
BASIS<br />
* library sto-3g<br />
END<br />
SCF<br />
SINGLET<br />
RHF<br />
END<br />
TCE<br />
CCSDT<br />
DIPOLE<br />
FREEZE CORE ATOMIC<br />
NROOTS 1<br />
END<br />
TASK TCE ENERGY<br />
<br />
Active-space CCSDt/EOMCCSDt calculations (version I) of several excited states of the <math>Be_3</math> molecule. Three highest-lying occupied &alpha; and &beta; orbitals (active_oa and active_ob) and nine lowest-lying unoccupied &alpha; and &beta; orbitals (active_va and active_vb) define the active space.<br />
<br />
START TCE_ACTIVE_CCSDT<br />
ECHO<br />
GEOMETRY UNITS ANGSTROM<br />
SYMMETRY C2V<br />
BE 0.00 0.00 0.00<br />
BE 0.00 1.137090 -1.96949<br />
end<br />
BASIS spherical<br />
# --- DEFINE YOUR BASIS SET ---<br />
END<br />
SCF<br />
THRESH 1.0e-10<br />
TOL2E 1.0e-10<br />
SINGLET<br />
RHF<br />
END<br />
TCE<br />
FREEZE ATOMIC<br />
CCSDTA<br />
TILESIZE 15<br />
THRESH 1.0d-5<br />
ACTIVE_OA 3<br />
ACTIVE_OB 3<br />
ACTIVE_VA 9<br />
ACTIVE_VB 9<br />
T3A_LVL 1<br />
NROOTS 2<br />
END <br />
TASK TCE ENERGY<br />
<br />
Completely renormalized EOMCCSD(T) (CR-EOMCCSD(T)) calculations for the ozone molecule as described by the POL1 basis set. The CREOMSD(T) directive automatically initialize three-step procedure: (1) CCSD calculations; (2) EOMCCSD calculations; (3) non-iterative CR-EOMCCSD(T) corrections.<br />
<br />
START TCE_CR_EOM_T_OZONE<br />
ECHO<br />
GEOMETRY UNITS BOHR<br />
SYMMETRY C2V<br />
O 0.0000000000 0.0000000000 0.0000000000<br />
O 0.0000000000 -2.0473224350 -1.2595211660<br />
O 0.0000000000 2.0473224350 -1.2595211660<br />
END<br />
BASIS SPHERICAL<br />
O S<br />
10662.285000000 0.00079900<br />
1599.709700000 0.00615300<br />
364.725260000 0.03115700<br />
103.651790000 0.11559600<br />
33.905805000 0.30155200<br />
O S<br />
12.287469000 0.44487000<br />
4.756805000 0.24317200<br />
O S<br />
1.004271000 1.00000000<br />
O S<br />
0.300686000 1.00000000<br />
O S<br />
0.090030000 1.00000000<br />
O P<br />
34.856463000 0.01564800<br />
7.843131000 0.09819700<br />
2.306249000 0.30776800<br />
0.723164000 0.49247000<br />
O P<br />
0.214882000 1.00000000<br />
O P<br />
0.063850000 1.00000000<br />
O D<br />
2.306200000 0.20270000<br />
0.723200000 0.57910000<br />
O D<br />
0.214900000 0.78545000<br />
0.063900000 0.53387000<br />
END<br />
SCF<br />
THRESH 1.0e-10<br />
TOL2E 1.0e-10<br />
SINGLET<br />
RHF<br />
END<br />
TCE<br />
FREEZE ATOMIC<br />
CREOMSD(T)<br />
TILESIZE 20<br />
THRESH 1.0d-6<br />
NROOTS 2<br />
END<br />
TASK TCE ENERGY<br />
<br />
The input for the active-space CR-EOMCCSD(T) calculations (the uracil molecule in the 6-31G* basis set). In this example, the model space is specified by defining the number of highest occupied orbitals<br />
(noact) and the number of lowest unoccupied orbitals (nuact) that will be considered as the active orbitals. In any type of the active-space CR-EOMCCSD(T) calculatoins <br />
based on the RHF and ROHF references more efficient versions of the orbital 4-index transformation can be invoked (i.e., 2emet 13 or 2emet 14).<br />
<br />
title "uracil-6-31-Gs-act"<br />
echo<br />
start uracil-6-31-Gs-act <br />
memory stack 1000 mb heap 100 mb global 1000 mb noverify<br />
geometry units angstrom<br />
N .034130 -.986909 .000000<br />
N -1.173397 .981920 .000000<br />
C -1.218805 -.408164 .000000<br />
C -.007302 1.702153 .000000<br />
C 1.196200 1.107045 .000000<br />
C 1.289085 -.345905 .000000<br />
O 2.310232 -.996874 .000000<br />
O -2.257041 -1.026495 .000000<br />
H .049329 -1.997961 .000000<br />
H -2.070598 1.437050 .000000<br />
H -.125651 2.776484 .000000<br />
H 2.111671 1.674079 .000000<br />
end<br />
basis cartesian<br />
* library 6-31G*<br />
end<br />
scf<br />
thresh 1.0e-10<br />
tol2e 1.0e-10<br />
singlet<br />
rhf<br />
end<br />
tce<br />
freeze atomic<br />
creom(t)ac<br />
oact 21<br />
uact 99<br />
tilesize 15<br />
thresh 1.0d-5<br />
2eorb<br />
2emet 13<br />
nroots 1<br />
symmetry<br />
targetsym a'<br />
end<br />
task tce energy<br />
<br />
The active-space in the active-space CR-EOMCCSD(T) calculations can be alternatively specified by defining the energy "window" [emin_act,emax_act].<br />
All orbitals with orbital energies falling into this widnow will considered as active (the active space in the following example is different from the one used in the previous example). <br />
<br />
title "uracil-6-31-Gs-act"<br />
echo<br />
start uracil-6-31-Gs-act <br />
memory stack 1000 mb heap 100 mb global 1000 mb noverify<br />
geometry units angstrom<br />
N .034130 -.986909 .000000<br />
N -1.173397 .981920 .000000<br />
C -1.218805 -.408164 .000000<br />
C -.007302 1.702153 .000000<br />
C 1.196200 1.107045 .000000<br />
C 1.289085 -.345905 .000000<br />
O 2.310232 -.996874 .000000<br />
O -2.257041 -1.026495 .000000<br />
H .049329 -1.997961 .000000<br />
H -2.070598 1.437050 .000000<br />
H -.125651 2.776484 .000000<br />
H 2.111671 1.674079 .000000<br />
end<br />
basis cartesian<br />
* library 6-31G*<br />
end<br />
scf<br />
thresh 1.0e-10<br />
tol2e 1.0e-10<br />
singlet<br />
rhf<br />
end<br />
tce<br />
freeze atomic<br />
creom(t)ac<br />
emin_act -0.5<br />
emax_act 1.0<br />
tilesize 15<br />
thresh 1.0d-5<br />
2eorbe<br />
2emet 13<br />
nroots 1<br />
symmetry<br />
targetsym a'<br />
end<br />
task tce energy <br />
<br />
<br />
The LR-CCSD(T) calculations for the glycine molecule in the aug-cc-pVTZ basis set. Option 2EORB is used in order to minimize memory requirements associated with the storage of two-electron integrals.<br />
<br />
START TCE_LR_CCSD_T<br />
ECHO<br />
GEOMETRY UNITS BOHR<br />
O -2.8770919486 1.5073755650 0.3989960497<br />
C -0.9993929716 0.2223265108 -0.0939400216<br />
C 1.6330980507 1.1263991128 -0.7236778647<br />
O -1.3167079358 -2.3304840070 -0.1955378962<br />
N 3.5887721300 -0.1900460352 0.6355723246<br />
H 1.7384347574 3.1922914768 -0.2011420479<br />
H 1.8051078216 0.9725472539 -2.8503867814<br />
H 3.3674278149 -2.0653924379 0.5211399625<br />
H 5.2887327108 0.3011058554 -0.0285088728<br />
H -3.0501350657 -2.7557071585 0.2342441831<br />
END<br />
BASIS<br />
* library aug-cc-pVTZ<br />
END<br />
SCF<br />
THRESH 1.0e-10<br />
TOL2E 1.0e-10<br />
SINGLET<br />
RHF<br />
END<br />
TCE<br />
FREEZE ATOMIC<br />
2EORB<br />
TILESIZE 15<br />
LR-CCSD(T)<br />
THRESH 1.0d-7<br />
END<br />
TASK TCE ENERGY<br />
<br />
The CCSD calculations for the triplet state of the <math>C_{20}</math> molecule. New algorithms for 4-index tranformation are used.<br />
<br />
title "c20_cage"<br />
echo<br />
start c20_cage<br />
memory stack 2320 mb heap 180 mb global 2000 mb noverify<br />
geometry print xyz units bohr<br />
symmetry c2<br />
C -0.761732 -1.112760 3.451966<br />
C 0.761732 1.112760 3.451966<br />
C 0.543308 -3.054565 2.168328<br />
C -0.543308 3.054565 2.168328<br />
C 3.190553 0.632819 2.242986<br />
C -3.190553 -0.632819 2.242986<br />
C 2.896910 -1.982251 1.260270<br />
C -2.896910 1.982251 1.260270<br />
C -0.951060 -3.770169 0.026589<br />
C 0.951060 3.770169 0.026589<br />
C 3.113776 2.128908 0.076756<br />
C -3.113776 -2.128908 0.076756<br />
C 3.012003 -2.087494 -1.347695<br />
C -3.012003 2.087494 -1.347695<br />
C 0.535910 -2.990532 -2.103427<br />
C -0.535910 2.990532 -2.103427<br />
C 3.334106 0.574125 -2.322563<br />
C -3.334106 -0.574125 -2.322563<br />
C -0.764522 -1.081362 -3.453211<br />
C 0.764522 1.081362 -3.453211<br />
end<br />
basis spherical<br />
* library cc-pvtz<br />
end<br />
scf<br />
triplet<br />
rohf<br />
thresh 1.e-8<br />
maxiter 200<br />
end<br />
tce<br />
ccsd<br />
maxiter 60<br />
diis 5<br />
thresh 1.e-6<br />
2eorb<br />
2emet 3<br />
attilesize 40<br />
tilesize 30<br />
freeze atomic<br />
end<br />
task tce energy<br />
<br />
==TCE Response Properties==<br />
<br />
===Introduction===<br />
<br />
Response properties can be calculated within the TCE. Ground-state dipole polarizabilities can be performed at the CCSD, CCSDT and CCSDTQ levels of theory. Neither CCSDT-LR nor CCSDTQ-LR are compiled by default. Like the rest of the TCE, properties can be calculated with RHF, UHF, ROHF and DFT reference wavefunctions.<br />
<br />
Specific details for the implementation of CCSD-LR and CCSDT-LR can be found in the following papers:<br />
<br />
* J. R. Hammond, M. Valiev, W. A. deJong and K. Kowalski, J. Phys. Chem. A, 111, 5492 (2007).<br />
* J. R. Hammond, K. Kowalski and W. A. de Jong, J. Chem. Phys., 127, 144105 (2007).<br />
* J. R. Hammond, W. A. de Jong and K. Kowalski , J. Chem. Phys., 128, 224102 (2008).<br />
<br />
An appropriate background on coupled-cluster linear response (CC-LR) can be found in the references of those papers.<br />
<br />
===Performance===<br />
<br />
The coupled-cluster response codes were generated in the same manner as the rest of the TCE, thus all previous comments on performance apply here as well. The improved offsets available in the CCSD and EOM-CCSD codes is now also available in the CCSD-&Lambda; and CCSD-LR codes. The bottleneck for CCSD-LR is the same as EOM-CCSD, likewise for CCSDT-LR and EOM-CCSDT. The CCSD-LR code has been tested on as many as 1024 processors for systems with more than 2000 spin-orbitals, while the CCSDT-LR code has been run on as many as 1024 processors. The CCSDTQ-LR code is not particularly useful due to the extreme memory requirements of quadruples amplitudes, limited scalability and poor convergence in the CCSDTQ equations in general.<br />
<br />
===Input===<br />
<br />
The input commands for TCE response properties exclusively use set directives (see [[Top-level#SET|SET]]) instead of TCE input block keywords. There are currently only three commands available:<br />
<br />
set tce:lineresp <logical lineresp default: F><br />
set tce:afreq <double precision afreq(9) default: 0.0> <br />
set tce:respaxis <logical respaxis(3) default: T T T><br />
<br />
The boolean variable lineresp invokes the linear response equations for the corresponding coupled-cluster method (only CCSD and CCSDT possess this feature) and evaluates the dipole polarizability. When lineresp is true, the &Lambda;-equations will also be solved, so the dipole moment is also calculated. If no other options are set, the complete dipole polarizability tensor will be calculated at zero frequency (static). Up to nine real frequencies can be set; adding more should not crash the code but it will calculate meaningless quanities. If one desires to calculate more frequencies at one time, merely change the line double precision afreq(9) in $(NWCHEM_TOP)/src/tce/include/tce.fh appropriately and recompile.<br />
<br />
The user can choose to calculate response amplitudes only for certain axis, either because of redundancy due to symmetry or because of memory limitations. The boolean vector of length three respaxis is used to determine whether or not a given set of response amplitudes are allocated, solved for, and used in the polarizability tensor evaluation. The logical variables represent the X, Y, Z axes, respectively. If respaxis is set to T F T, for example, the responses with respect to the X and Z dipoles will be calculated, and the four (three unique) tensor components will be evaluated. This feature is also useful for conserving memory. By calculating only one axis at a time, memory requirements can be reduced by $25\%$ or more, depending on the number of DIIS vectors used. Reducing the number of DIIS vectors also reduces the memory requirements.<br />
<br />
It is strongly advised that when calculating polarizabilities at high-frequencies, that user set the frequencies in increasing order, preferably starting with zero or other small value. This approach is computationally efficient (the initial guess for subsequent responses is the previously converged value) and mitigates starting from a zero vector for the response amplitudes.<br />
<br />
===Examples===<br />
<br />
This example runs in-core on a large workstation.<br />
<br />
geometry units angstrom<br />
symmetry d2h<br />
C 0.000 1.390 0.000<br />
H 0.000 2.470 0.000<br />
C 1.204 0.695 0.000<br />
H 2.139 1.235 0.000<br />
C 0.000 -1.390 0.000<br />
H 0.000 -2.470 0.000<br />
C -1.204 -0.695 0.000<br />
H -2.139 -1.235 0.000<br />
C 1.204 -0.695 0.000<br />
H 2.139 -1.235 0.000<br />
C -1.204 0.695 0.000<br />
H -2.139 1.235 0.000<br />
end<br />
basis spherical<br />
* library aug-cc-pvdz<br />
end<br />
tce<br />
freeze atomic<br />
ccsd<br />
io ga<br />
2eorb<br />
tilesize 16<br />
end<br />
set tce:lineresp T<br />
set tce:afreq 0.000 0.072<br />
set tce:respaxis T T T<br />
task tce energy<br />
<br />
This is a relatively simple example for CCSDT-LR.<br />
<br />
geometry units au<br />
symmetry c2v<br />
H 0 0 0<br />
F 0 0 1.7328795<br />
end<br />
basis spherical<br />
* library aug-cc-pvdz<br />
end<br />
tce<br />
ccsdt<br />
io ga<br />
2eorb<br />
end<br />
set tce:lineresp T<br />
set tce:afreq 0.0 0.1 0.2 0.3 0.4<br />
set tce:respaxis T F T<br />
task tce energy<br />
<br />
==TCE Restart Capability==<br />
<br />
===Overview===<br />
<br />
Check-pointing and restart are critical for computational chemistry applications of any scale, but particularly those done on supercomputers, or run for an extended period on workstations and clusters. The TCE supports parallel check-pointing and restart using the Shared Files (SF) library in the Global Arrays Tools. The SF library requires that the file system be accessible by every node, so reading and writing restart files can only be performed on a shared file system. For workstations, this condition is trivially met. Restart files must be persistent to be useful, so volatile file systems or those which are periodicly erased should not be used for check-pointing.<br />
<br />
Restart is possible for all ground-state amplitudes (''T'', &Lambda; and <math>T^{(1)}</math>) but not for excited-state amplitudes, as in an EOM-CC calculation. The latter functionality is under development.<br />
<br />
Restart capability is useful in the following situations:<br />
<br />
* The total run time is limited, as is the case for most supercomputing facilities.<br />
* The system is volatile and jobs die randomly.<br />
* When doing property calculations which require a large number of responses which cannot all be stored in-core simultaneously.<br />
<br />
At the present time, restarting the amplitudes during a potential energy surface scan or numerical geometry optmization/frequency calculation is not advised due to the phase issue in the molecular orbital coefficients. If the phase changes, the amplitudes will no longer be a useful guess and may lead to nonsense results. Expert users may be able to use restart when the geometry varies using careful choices in the SCF input by using the "rotate" and "lock" options but this use of restart is not supported.<br />
<br />
If SF encounters a failure during restart I/O, the job will fail. The capability to ignore a subset of failures, such as when saving the amplitudes prior to convergence, will be available in the future. This is useful on some large machines when the filesystem is being taxed by another job and may be appear unavailable at the moment a check-point write is attempted.<br />
<br />
The performance of SF I/O for restart is excellent and the wall time for reading and writing integrals and amplitudes is negligible, even on a supercomputer (such systems have very fast parallel file systems in most cases). The only platform for which restart may cause I/O problems is BlueGene, due to ratio of compute to I/O nodes (64 on BlueGene/P).<br />
<br />
===Input===<br />
<br />
set tce:read_integrals <logical read_integrals default: F F F F F><br />
set tce:read_t <logical read_t default: F F F F><br />
set tce:read_l <logical read_l default: F F F F><br />
set tce:read_tr <logical read_tr default: F F F F><br />
set tce:save_integrals <logical save_integrals default: F F F F F><br />
set tce:save_t <logical save_t default: F F F F><br />
set tce:save_l <logical save_l default: F F F F><br />
set tce:save_tr <logical save_tr default: F F F F><br />
set tce:save_interval <integer save_interval default: 100000><br />
<br />
The boolean variables read_integrals and save_integrals control which integrals are read/saved. The first location is the 1-e integrals, the second is for the 2-e integrals, and the third is for dipole integrals. The fourth and fifth positions are reserved for quadrupole and octupole integrals but this functionality is not available. The read_t, read_l, read_tr, save_t, save_l and save_tr variables control the reading/saving of the <math>T</math>, &Lambda; and <math>T^{(1)}</math> (response) amplitudes. Restart control on the response amplitudes is implicitly controlled by the value of respaxis (see above). Requesting amplitudes that are beyond the scope of a given calculation, such as <math>T_3</math> in a CCSD calculation, does not produce an error as these commands will never be processed.<br />
<br />
Attempting to restart with a set of amplitudes without the corresponding integrals is ill-advised, due to the phase issue discussed above. For the same reason, one cannot save a subset of the integrals, so if it is even remotely possible that the dipole moment or polarizabilities will be desired for a given molecule, the dipole integrals should be saved as well. It is possible to save the dipole integrals without setting dipole in the TCE input block; setting save_integrals(3) true is sufficient for this to occur.<br />
<br />
The save_interval variable controls the frequency with which amplitudes are saved. By default, the amplitudes are saved only when the iterative process has converged, meaning that if the iterations do not converge in less than the maximum, one must start the calculation again from scratch. The solution is to set save_interval to a smaller value, such as the number of DIIS cycles being used.<br />
<br />
The user shall not change the tilesize when reading in saved amplitudes. The results of this are catastrophic and under no circumstance will this lead to physically meaningful results. Restart does not work for 2eorb and 2emet 9; no error will be produced but the results may be meaningless.<br />
<br />
===Examples===<br />
<br />
geometry units au<br />
symmetry c2v<br />
H 0 0 0<br />
F 0 0 1.7328795<br />
end<br />
basis spherical<br />
* library aug-cc-pvdz<br />
end<br />
tce<br />
ccsdt<br />
io ga<br />
end<br />
set tce:lineresp T<br />
set tce:afreq 0.0 0.1 0.2 0.3 0.4<br />
set tce:respaxis T F T<br />
task tce energy<br />
<br />
==Maximizing performance==<br />
<br />
The following are recommended parameters for getting the best performance and efficiency for common methods on various hardware configurations. The optimal settings are far from extensible and it is extremely important that users take care in how they apply these recommendations. Testing a variety of settings on a simple example is recommended when optimal settings are desired. Nonetheless, a few guiding principles will improve the performance of TCE jobs markedly, including making otherwise impossible jobs possible.<br />
<br />
===Memory considerations===<br />
<br />
The default memory settings for NWChem are not optimal for TCE calculations. When 2 GB of memory is available per process, the following settings are close to optimal for CCSD jobs<br />
<br />
memory stack 800 mb heap 100 mb global 1000 mb<br />
<br />
for property jobs, which require more amplitudes to be stored, it is wise to favor the global allocation<br />
<br />
memory stack 500 mb heap 100 mb global 1300 mb<br />
<br />
If you get an error for ga_create during the iterative steps, reduce the number of DIIS vectors. If this error occurs during the four-index transformation (after d_v2 filesize appears) you need more GA space, a different 2emet, or more nodes.<br />
<br />
The memory requirements for CCSD(T) are quite different because the triples are generated in local memory. The value of tilesize should not be larger than 30 in most cases and one should set something similar to the following<br />
<br />
memory stack 1200 mb heap 100 mb global 600 mb<br />
<br />
The local memory requires will be <math>\sim tilesize^N</math> where N=4 for CCSD, N=6 for CCSD(T) and CCSDT, and N=8 for CCSDTQ. One should set <math>tilesize^{\sim 15}</math> for CCSDT and CCSDTQ, although symmetry will affect the local memory use significantly. The local memory usage of the CR-EOMCCSD(T) approach has recently been significantly reduced to the level of the CCSD(T) approach (<math>2 * (tilesize)^6</math>).<br />
<br />
===SCF options===<br />
<br />
For parallel jobs on clusters with poor disk performance on the filesystem used for scratch_dir, it is a good idea to disable disk IO during the SCF stage of the calculation. This is done by adding semidirect memsize N filesize 0, where N is 80% of the stack memory divided by 8, as the value in this directive is the number of dwords, rather than bytes. With these settings, if the aggregate memory is sufficient to store the integrals, the SCF performance will be excellent, and it will be better than if direct is set in the SCF input block. If scratch_dir is set to a local disk, then one should use as much disk as is permissible, controlled by the value of filesize. On many high-performance computers, filling up the local scratch disk will crash the node, so one cannot be careless with these settings. In addition, on many such machines, the shared file system performance is better than that of the local disk (this is true for many NERSC systems).<br />
<br />
===Convergence criteria===<br />
<br />
It makes no sense to converge a calculation to a precision not relevant to experiment. However, the relationship between convergence criteria and calculated quantities is not fully known for some properties. For example, the effect of the convergence criteria on the polarizability is significant in some cases. In the case of CN, convergence of <math>10^{-11}</math> is necessary to resolve the polarizability tensor components to <math>10^{-2}</math>. However, for many systems <math>10^{-7}</math> convergence is sufficient to get accurate results for all properties. It is important to calibrate the effect of convergence on property calculations, particularly for open-shell and post-CCSD methods, on a modest basis set before relaxing the convergence criteria too much.<br />
<br />
===IO schemes and integral transformation algorithms===<br />
<br />
The effect on memory use of using the 2eorb keyword is huge. However, this option can only be used with IO=GA and an RHF/ROHF reference. There are a number of choices for the integral transformation algorithm when using spin-free integrals. The fastest algorithm is 2EMET=5, but significant disk IO is required for this algorithm. One must set permanent_dir to a fast, shared file system for this algorithm to work. If disk performance is not good, one should use either 2EMET=3 or 2EMET=4 depending on how much memory is available. If one sees a ga_create error with 2EMET=3, then switch to algorithm 4 and add split 8 to the TCE input block.</div>Berthttp://www.nwchem-sw.org/index.php/Release66:System_DescriptionRelease66:System Description2013-06-21T17:31:34Z<p>Bert: 1 revision</p>
<hr />
<div>__NOTITLE__<br />
*[[Release66:Charge|Charge]]<br />
<br />
*[[Release66:Geometry|Geometry]]<br />
<br />
*[[Release66:Basis|Basis Sets]]<br />
<br />
*[[Release66:ECP|Effective Core Potentials]]<br />
<br />
*[[Release66:Relativistic All-electron Approximations|Relativistic All-electron Approximations]]</div>Berthttp://www.nwchem-sw.org/index.php/Release66:SampleRelease66:Sample2013-06-21T17:31:34Z<p>Bert: 1 revision</p>
<hr />
<div>__NOTITLE__<br />
=Sample input files=<br />
<br />
==Water SCF calculation and geometry optimization in a 6-31g basis==<br />
<br />
The [[Release66:Getting Started|Getting Started]] input file performs a geometry optimization in a single task. A single point SCF energy calculation is performed and then restarted to perform the optimization (both could of course be performed in a single task).<br />
<br />
===Job 1. Single point SCF energy===<br />
<br />
start h2o<br />
title "Water in 6-31g basis set"<br />
<br />
geometry units au<br />
O 0.00000000 0.00000000 0.00000000<br />
H 0.00000000 1.43042809 -1.10715266<br />
H 0.00000000 -1.43042809 -1.10715266<br />
end<br />
basis<br />
H library 6-31g<br />
O library 6-31g<br />
end<br />
task scf<br />
<br />
The final energy should be -75.983998.<br />
<br />
===Job 2. Restarting and perform a geometry optimization===<br />
<br />
restart h2o<br />
title "Water geometry optimization"<br />
<br />
task scf optimize<br />
<br />
There is no need to specify anything that has not changed from the previous input deck, though it will do no harm to repeat it.<br />
<br />
==Compute the polarizability of Ne using finite field==<br />
<br />
===Job 1. Compute the atomic energy===<br />
<br />
start ne<br />
title "Neon"<br />
geometry; ne 0 0 0; end<br />
basis spherical <br />
ne library aug-cc-pvdz<br />
end<br />
scf; thresh 1e-10; end<br />
task scf<br />
<br />
The final energy should be -128.496350.<br />
<br />
===Job 2. Compute the energy with applied field===<br />
<br />
An external field may be simulated with point charges. The charges here apply a field of magnitude 0.01 atomic units to the atom at the origin. Since the basis functions have not been reordered by the additional centers we can also restart from the previous vectors, which is the default for a restart job.<br />
<br />
restart ne<br />
title "Neon in electric field"<br />
geometry units atomic<br />
bq1 0 0 100 charge 50<br />
ne 0 0 0<br />
bq2 0 0 -100 charge -50<br />
end<br />
task scf<br />
<br />
The final energy should be -128.496441, which together with the previous field-free result yields an estimate for the polarizability of 1.83 atomic units. Note that by [[Geometry|default]] NWChem does not include the interaction between the two point charges in the total energy.<br />
<br />
==SCF energy of <math>H_{2}CO</math> using ECPs for C and O==<br />
<br />
The following will compute the SCF energy for formaldehyde with ECPs on the Carbon and Oxygen centers.<br />
<br />
title "formaldehyde ECP deck"<br />
<br />
start ecpchho<br />
<br />
geometry units au<br />
C 0.000000 0.000000 -1.025176<br />
O 0.000000 0.000000 1.280289<br />
H 0.000000 1.767475 -2.045628<br />
H 0.000000 -1.767475 -2.045628<br />
end<br />
<br />
basis <br />
C SP<br />
0.1675097360D+02 -0.7812840500D-01 0.3088908800D-01<br />
0.2888377460D+01 -0.3741108860D+00 0.2645728130D+00<br />
0.6904575040D+00 0.1229059640D+01 0.8225024920D+00<br />
C SP<br />
0.1813976910D+00 0.1000000000D+01 0.1000000000D+01<br />
C D<br />
0.8000000000D+00 0.1000000000D+01<br />
C F<br />
0.1000000000D+01 0.1000000000D+01<br />
O SP<br />
0.1842936330D+02 -0.1218775590D+00 0.5975796600D-01<br />
0.4047420810D+01 -0.1962142380D+00 0.3267825930D+00<br />
0.1093836980D+01 0.1156987900D+01 0.7484058930D+00<br />
O SP<br />
0.2906290230D+00 0.1000000000D+01 0.1000000000D+01<br />
O D<br />
0.8000000000D+00 0.1000000000D+01<br />
O F<br />
0.1100000000D+01 0.1000000000D+01<br />
H S<br />
0.1873113696D+02 0.3349460434D-01<br />
0.2825394365D+01 0.2347269535D+00<br />
0.6401216923D+00 0.8137573262D+00<br />
H S <br />
0.1612777588D+00 0.1000000000D+01<br />
end<br />
<br />
ecp<br />
C nelec 2<br />
C ul<br />
1 80.0000000 -1.60000000<br />
1 30.0000000 -0.40000000<br />
2 0.5498205 -0.03990210<br />
C s<br />
0 0.7374760 0.63810832<br />
0 135.2354832 11.00916230<br />
2 8.5605569 20.13797020<br />
C p<br />
2 10.6863587 -3.24684280<br />
2 23.4979897 0.78505765<br />
O nelec 2<br />
O ul<br />
1 80.0000000 -1.60000000<br />
1 30.0000000 -0.40000000<br />
2 1.0953760 -0.06623814<br />
O s<br />
0 0.9212952 0.39552179<br />
0 28.6481971 2.51654843<br />
2 9.3033500 17.04478500<br />
O p<br />
2 52.3427019 27.97790770<br />
2 30.7220233 -16.49630500<br />
end<br />
<br />
scf<br />
vectors input hcore<br />
maxiter 20<br />
end<br />
<br />
task scf<br />
<br />
This should produce the following output:<br />
<br />
Final RHF results <br />
------------------ <br />
<br />
Total SCF energy = -22.507927218024<br />
One electron energy = -71.508730162974<br />
Two electron energy = 31.201960019808<br />
Nuclear repulsion energy = 17.798842925142<br />
<br />
==MP2 optimization and CCSD(T) on nitrogen==<br />
<br />
The following performs an MP2 geometry optimization followed by a CCSD(T) energy evaluation at the converged geometry. A Dunning correlation-consistent triple-zeta basis is used. The default of Cartesian basis functions must be overridden using the keyword spherical on the BASIS directive. The 1s core orbitals are frozen in both the MP2 and coupled-cluster calculations (note that these must separately specified). The final MP2 energy is -109.383276, and the CCSD(T) energy is -109.399662.<br />
<br />
start n2 <br />
<br />
geometry<br />
symmetry d2h<br />
n 0 0 0.542<br />
end<br />
<br />
basis spherical<br />
n library cc-pvtz<br />
end<br />
<br />
mp2<br />
freeze core<br />
end<br />
<br />
task mp2 optimize<br />
<br />
ccsd<br />
freeze core<br />
end<br />
<br />
task ccsd(t)</div>Berthttp://www.nwchem-sw.org/index.php/Release64:System_DescriptionRelease64:System Description2013-06-21T17:31:34Z<p>Bert: 1 revision</p>
<hr />
<div>__NOTITLE__<br />
*[[Release64:Charge|Charge]]<br />
<br />
*[[Release64:Geometry|Geometry]]<br />
<br />
*[[Release64:Basis|Basis Sets]]<br />
<br />
*[[Release64:ECP|Effective Core Potentials]]<br />
<br />
*[[Release64:Relativistic All-electron Approximations|Relativistic All-electron Approximations]]</div>Berthttp://www.nwchem-sw.org/index.php/Release65:SampleRelease65:Sample2013-06-21T17:31:34Z<p>Bert: 1 revision</p>
<hr />
<div>__NOTITLE__<br />
=Sample input files=<br />
<br />
==Water SCF calculation and geometry optimization in a 6-31g basis==<br />
<br />
The [[Release64:Getting Started|Getting Started]] input file performs a geometry optimization in a single task. A single point SCF energy calculation is performed and then restarted to perform the optimization (both could of course be performed in a single task).<br />
<br />
===Job 1. Single point SCF energy===<br />
<br />
start h2o<br />
title "Water in 6-31g basis set"<br />
<br />
geometry units au<br />
O 0.00000000 0.00000000 0.00000000<br />
H 0.00000000 1.43042809 -1.10715266<br />
H 0.00000000 -1.43042809 -1.10715266<br />
end<br />
basis<br />
H library 6-31g<br />
O library 6-31g<br />
end<br />
task scf<br />
<br />
The final energy should be -75.983998.<br />
<br />
===Job 2. Restarting and perform a geometry optimization===<br />
<br />
restart h2o<br />
title "Water geometry optimization"<br />
<br />
task scf optimize<br />
<br />
There is no need to specify anything that has not changed from the previous input deck, though it will do no harm to repeat it.<br />
<br />
==Compute the polarizability of Ne using finite field==<br />
<br />
===Job 1. Compute the atomic energy===<br />
<br />
start ne<br />
title "Neon"<br />
geometry; ne 0 0 0; end<br />
basis spherical <br />
ne library aug-cc-pvdz<br />
end<br />
scf; thresh 1e-10; end<br />
task scf<br />
<br />
The final energy should be -128.496350.<br />
<br />
===Job 2. Compute the energy with applied field===<br />
<br />
An external field may be simulated with point charges. The charges here apply a field of magnitude 0.01 atomic units to the atom at the origin. Since the basis functions have not been reordered by the additional centers we can also restart from the previous vectors, which is the default for a restart job.<br />
<br />
restart ne<br />
title "Neon in electric field"<br />
geometry units atomic<br />
bq1 0 0 100 charge 50<br />
ne 0 0 0<br />
bq2 0 0 -100 charge -50<br />
end<br />
task scf<br />
<br />
The final energy should be -128.496441, which together with the previous field-free result yields an estimate for the polarizability of 1.83 atomic units. Note that by [[Geometry|default]] NWChem does not include the interaction between the two point charges in the total energy.<br />
<br />
==SCF energy of <math>H_{2}CO</math> using ECPs for C and O==<br />
<br />
The following will compute the SCF energy for formaldehyde with ECPs on the Carbon and Oxygen centers.<br />
<br />
title "formaldehyde ECP deck"<br />
<br />
start ecpchho<br />
<br />
geometry units au<br />
C 0.000000 0.000000 -1.025176<br />
O 0.000000 0.000000 1.280289<br />
H 0.000000 1.767475 -2.045628<br />
H 0.000000 -1.767475 -2.045628<br />
end<br />
<br />
basis <br />
C SP<br />
0.1675097360D+02 -0.7812840500D-01 0.3088908800D-01<br />
0.2888377460D+01 -0.3741108860D+00 0.2645728130D+00<br />
0.6904575040D+00 0.1229059640D+01 0.8225024920D+00<br />
C SP<br />
0.1813976910D+00 0.1000000000D+01 0.1000000000D+01<br />
C D<br />
0.8000000000D+00 0.1000000000D+01<br />
C F<br />
0.1000000000D+01 0.1000000000D+01<br />
O SP<br />
0.1842936330D+02 -0.1218775590D+00 0.5975796600D-01<br />
0.4047420810D+01 -0.1962142380D+00 0.3267825930D+00<br />
0.1093836980D+01 0.1156987900D+01 0.7484058930D+00<br />
O SP<br />
0.2906290230D+00 0.1000000000D+01 0.1000000000D+01<br />
O D<br />
0.8000000000D+00 0.1000000000D+01<br />
O F<br />
0.1100000000D+01 0.1000000000D+01<br />
H S<br />
0.1873113696D+02 0.3349460434D-01<br />
0.2825394365D+01 0.2347269535D+00<br />
0.6401216923D+00 0.8137573262D+00<br />
H S <br />
0.1612777588D+00 0.1000000000D+01<br />
end<br />
<br />
ecp<br />
C nelec 2<br />
C ul<br />
1 80.0000000 -1.60000000<br />
1 30.0000000 -0.40000000<br />
2 0.5498205 -0.03990210<br />
C s<br />
0 0.7374760 0.63810832<br />
0 135.2354832 11.00916230<br />
2 8.5605569 20.13797020<br />
C p<br />
2 10.6863587 -3.24684280<br />
2 23.4979897 0.78505765<br />
O nelec 2<br />
O ul<br />
1 80.0000000 -1.60000000<br />
1 30.0000000 -0.40000000<br />
2 1.0953760 -0.06623814<br />
O s<br />
0 0.9212952 0.39552179<br />
0 28.6481971 2.51654843<br />
2 9.3033500 17.04478500<br />
O p<br />
2 52.3427019 27.97790770<br />
2 30.7220233 -16.49630500<br />
end<br />
<br />
scf<br />
vectors input hcore<br />
maxiter 20<br />
end<br />
<br />
task scf<br />
<br />
This should produce the following output:<br />
<br />
Final RHF results <br />
------------------ <br />
<br />
Total SCF energy = -22.507927218024<br />
One electron energy = -71.508730162974<br />
Two electron energy = 31.201960019808<br />
Nuclear repulsion energy = 17.798842925142<br />
<br />
==MP2 optimization and CCSD(T) on nitrogen==<br />
<br />
The following performs an MP2 geometry optimization followed by a CCSD(T) energy evaluation at the converged geometry. A Dunning correlation-consistent triple-zeta basis is used. The default of Cartesian basis functions must be overridden using the keyword spherical on the BASIS directive. The 1s core orbitals are frozen in both the MP2 and coupled-cluster calculations (note that these must separately specified). The final MP2 energy is -109.383276, and the CCSD(T) energy is -109.399662.<br />
<br />
start n2 <br />
<br />
geometry<br />
symmetry d2h<br />
n 0 0 0.542<br />
end<br />
<br />
basis spherical<br />
n library cc-pvtz<br />
end<br />
<br />
mp2<br />
freeze core<br />
end<br />
<br />
task mp2 optimize<br />
<br />
ccsd<br />
freeze core<br />
end<br />
<br />
task ccsd(t)</div>Berthttp://www.nwchem-sw.org/index.php/Release65:SELCIRelease65:SELCI2013-06-21T17:31:34Z<p>Bert: 1 revision</p>
<hr />
<div>__NOTITLE__<br />
=Selected CI=<br />
<br />
The selected CI module is integrated into NWChem but as yet no input module has been written. The input thus consists of setting the appropriate variables in the database.<br />
<br />
It is assumed that an initial SCF/MCSCF calculation has completed, and that MO vectors are available. These will be used to perform a four-index transformation, if this has not already been performed.<br />
<br />
==Background==<br />
<br />
This is a general spin-adapted, configuration-driven CI program which can perform arbitrary CI calculations, the only restriction being that all spin functions are present for each orbital occupation. CI wavefunctions may be specified using a simple configuration generation program, but the prime usage is intended to be in combination with perturbation correction and selection of new configurations. The second-order correction (Epstein-Nesbet) to the CI energy may be computed, and at the same time configurations that interact greater than a certain threshold with the current CI wavefunction may be chosen for inclusion in subsequent calculations. By repeating this process (typically twice is adequate) with the same threshold until no new configurations are added, the CI expansion may be made consistent with the selection threshold, enabling tentative extrapolation to the full-CI limit.<br />
<br />
A typical sequence of calculations is as follows:<br />
<br />
#Pick as an initial CI reference the previously executed SCF/MCSCF.<br />
#Define an initial selection threshold.<br />
#Determine the roots of interest in the current reference space.<br />
#Compute the perturbation correction and select additional configurations that interact greater than the current threshold.<br />
#Repeat steps 3 and 4.<br />
#Lower the threshold (a factor of 10 is common) and repeat steps 3, 4, and 5. The first pass through step 4 will yield the approximately self-consistent CI and CI+PT energies from the previous selection threshold.<br />
<br />
To illustrate this, below is some abbreviated output from a calculation on water in an augmented cc-PVDZ basis set with one frozen core orbital. The SCF was converged to high precision in <math>C_{2v}</math> symmetry with the following input<br />
<br />
start h2o<br />
geometry; symmetry c2v<br />
O 0 0 0; H 0 1.43042809 -1.10715266<br />
end<br />
basis<br />
H library aug-cc-pvdz; O library aug-cc-pvdz<br />
end<br />
task scf<br />
scf; thresh 1d-8; end<br />
<br />
The following input restarts from the SCF to perform a sequence of selected CI calculations with the specified tolerances, starting with the SCF reference.<br />
<br />
restart h2o<br />
set fourindex:occ_frozen 1<br />
set selci:mode select<br />
set "selci:selection thresholds" \<br />
0.001 0.001 0.0001 0.0001 0.00001 0.00001 0.000001<br />
task selci<br />
<br />
The table below summarizes the output from each of the major computational steps that were performed. <br />
<br />
<br />
<center><br />
{| border='1' cellspacing='0'<br />
|+Summary of steps performed in a selected CI calculation on water.<br />
|<br />
|<br />
| CI<br />
|<br />
|-<br />
| Step<br />
| Description<br />
| dimension<br />
| Energy<br />
|-<br />
| |<br />
|<br />
|<br />
|-<br />
| 1<br />
| Four-index, one frozen-core<br />
|<br />
|<br />
|-<br />
| 2<br />
| Config. generator, SCF default<br />
| 1<br />
|<br />
|-<br />
| 3+4<br />
| CI diagonalization<br />
| 1<br />
| <math>E_{CI} = -76.041983</math><br />
|-<br />
| 5<br />
| PT selection T=0.001<br />
| 1<br />
| <math>E_{CI+PT} = -76.304797</math><br />
|-<br />
| 6+7<br />
| CI diagonalization<br />
| 75<br />
| <math>E_{CI} = -76.110894</math><br />
|-<br />
| 8<br />
| PT selection T=0.001<br />
| 75<br />
| <math>E_{CI+PT} = -76.277912</math><br />
|-<br />
| 9+10<br />
| CI diagonalization<br />
| 75<br />
| <math>E_{CI}(T=0.001) = -76.110894</math><br />
|-<br />
| 11<br />
| PT selection T=0.0001<br />
| 75<br />
| <math>E_{CI+PT}(T=0.001) = -76.277912</math><br />
|-<br />
| 12+13<br />
| CI diagonalization<br />
| 823<br />
| <math>E_{CI} = -76.228419</math><br />
|-<br />
| 14<br />
| PT selection T=0.0001<br />
| 823<br />
| <math>E_{CI+PT} = -76.273751</math><br />
|-<br />
| 15+16<br />
| CI diagonalization<br />
| 841<br />
| <math>E_{CI}(T=0.0001) = -76.2300544</math><br />
|-<br />
| 17<br />
| PT selection T=0.00001<br />
| 841<br />
| <math>E_{CI+PT}(T=0.0001) = -76.274073</math><br />
|-<br />
| 18+19<br />
| CI diagonalization<br />
| 2180<br />
| <math>E_{CI} = -76.259285</math><br />
|-<br />
| 20<br />
| PT selection T=0.00001<br />
| 2180<br />
| <math>E_{CI+PT} = -76.276418</math><br />
|-<br />
| 21+22<br />
| CI diagonalization<br />
| 2235<br />
| <math>E_{CI}(T=0.00001) = -76.259818</math><br />
|-<br />
| 23<br />
| PT selection T=0.000001<br />
| 2235<br />
| <math>E_{CI+PT}(T=0.00001) = -76.276478</math><br />
|-<br />
| 24<br />
| CI diagonalization<br />
| 11489<br />
|<br />
|}<br />
</center><br />
<br />
<br />
==Files==<br />
<br />
Currently, no direct control is provided over filenames. All files are prefixed with the standard file-prefix, and any files generated by all nodes are also postfixed with the processor number. Thus, for example the molecular integrals file, used only by process zero, might be called h2o.moints whereas the off-diagonal Hamiltonian matrix element file used by process number eight would be called h2o.hamil.8.<br />
<br />
*ciconf -- the CI configuration file, which holds information about the current CI expansion, indexing vectors, etc. This is the most important file and is required for all restarts. Note that the CI configuration generator is only run if this file does not exist. Referenced only by process zero. <br />
*moints -- the molecular integrals, generated by the four-index transformation. As noted above these must currently be manually deleted, or the database entry selci:moints:force set, to force regeneration. Referenced only by process zero. <br />
*civecs -- the CI vectors. Referenced only by process zero. <br />
*wmatrx -- temporary file used to hold coupling coefficients. Deleted at calculation end. Referenced only by process zero. <br />
*rtname, roname -- restart information for the PT selection. Should be automatically deleted if no restart is necessary. Referenced only by process zero. <br />
*hamdg -- diagonal elements of the Hamiltonian. Deleted at calculation end. Referenced only by process zero. <br />
*hamil -- off-diagonal Hamiltonian matrix elements. All processes generate a file containing a subset of these elements. These files can become very large. Deleted at calculation end. <br />
<br />
==Configuration Generation==<br />
<br />
If no configuration is explicitly specified then the previous SCF/MCSCF wavefunction is used, adjusting for any orbitals frozen in the four-index transformation. The four-index transformation must have completed successfully before this can execute. Orbital configurations for use as reference functions may also be explicitly specified.<br />
<br />
Once the default/user-input reference configurations have been determined additional reference functions may be generated by applying multiple sets of creation-annihilation operators, permitting for instance, the ready specification of complete or restricted active spaces.<br />
<br />
Finally, a uniform level of excitation from the current set of configurations into all orbitals may be applied, enabling, for instance, the simple creation of single or single+double excitation spaces from an MCSCF reference.<br />
<br />
===Specifying the reference occupation===<br />
<br />
A single orbital configuration or occupation is specified by<br />
<br />
ns (socc(i),i=1,ns) (docc(i),i=1,nd)<br />
<br />
where ns specifies the number of singly occupied orbitals, socc() is the list of singly occupied orbitals, and docc() is the list of doubly occupied orbitals (the number of doubly occupied orbitals, nd, is inferred from ns and the total number of electrons). All occupations may be strung together and inserted into the database as a single integer array with name "selci:conf". For example, the input<br />
<br />
set "selci:conf" \<br />
0 1 2 3 4 \<br />
0 1 2 3 27 \<br />
0 1 3 4 19 \<br />
2 11 19 1 3 4 \<br />
2 8 27 1 2 3 \<br />
0 1 2 4 25 \<br />
4 3 4 25 27 1 2 \<br />
4 2 3 19 20 1 4 \<br />
4 2 4 20 23 1 3<br />
<br />
specifies the following nine orbital configurations<br />
<br />
1(2) 2(2) 3(2) 4(2)<br />
1(2) 2(2) 3(2) 27(2)<br />
1(2) 3(2) 4(2) 19(2)<br />
1(2) 3(2) 4(2) 11(1) 19(1)<br />
1(2) 2(2) 3(2) 8(1) 27(1)<br />
1(2) 2(2) 4(2) 25(2)<br />
1(2) 2(2) 3(1) 4(1) 25(1) 27(1)<br />
1(2) 2(1) 3(1) 4(2) 19(1) 20(1)<br />
1(2) 2(1) 3(2) 4(1) 20(1) 23(1)<br />
<br />
The optional formatting of the input is just to make this arcane notation easier to read. Relatively few configurations can be currently specified in this fashion because of the input line limit of 1024 characters.<br />
<br />
===Applying creation-annihilation operators===<br />
<br />
Up to 10 sets of creation-annihilation operator pairs may be specified, each set containing up to 255 pairs. This suffices to specify complete active spaces with up to ten electrons.<br />
<br />
The number of sets is specified as follows,<br />
<br />
set selci:ngen 4<br />
<br />
which indicates that there will be four sets. Each set is then specified as a separate integer array<br />
<br />
set "selci:refgen 1" 5 4 6 4 5 3 6 3 <br />
set "selci:refgen 2" 5 4 6 4 5 3 6 3 <br />
set "selci:refgen 3" 5 4 6 4 5 3 6 3 <br />
set "selci:refgen 4" 5 4 6 4 5 3 6 3<br />
<br />
In the absence of friendly, input note that the names "selci:refgen n" must be formatted with n in I2 format. Each set specifies a list of creation-annihilation operator pairs (in that order). So for instance, in the above example each set is the same and causes the excitations<br />
<br />
4->5 4->6 3->5 3->6<br />
<br />
If orbitals 3 and 4 were initially doubly occupied, and orbitals 5 and 6 initially unoccupied, then the application of this set of operators four times in succession is sufficient to generate the four electron in four orbital complete active space.<br />
<br />
The precise sequence in which operators are applied is<br />
<br />
#loop through sets of operators<br />
#loop through reference configurations<br />
#loop through operators in the set<br />
#apply the operator to the configuration, if the result is new add it to the new list<br />
#end the loop over operators<br />
#end the loop over reference configurations<br />
#augment the configuration list with the new list<br />
#end the loop over sets of operators<br />
<br />
===Uniform excitation level===<br />
<br />
By default no excitation is applied to the reference configurations. If, for instance, you wanted to generate a single excitation CI space from the current configuration list, specify<br />
<br />
set selci:exci 1<br />
<br />
Any excitation level may be applied, but since the list of configurations is explicitly generated, as is the CI Hamiltonian matrix, you will run out of disk space if you attempt to use more than a few tens of thousands of configurations.<br />
<br />
==Number of roots==<br />
<br />
By default, only one root is generated in the CI diagonalization or perturbation selection. The following requests that 2 roots be generated<br />
<br />
set selci:nroot 2<br />
<br />
There is no imposed upper limit. If many roots are required, then, to minimize root skipping problems, it helps to perform an initial approximate diagonalization with several more roots than required, and then resetting this parameter once satisfied that the desired states are obtained.<br />
<br />
==Accuracy of diagonalization==<br />
<br />
By default, the CI wavefunctions are converged to a residual norm of <math>10^{-6}</math> which provides similar accuracy in the perturbation corrections to the energy, and much higher accuracy in the CI eigenvalues. This may be adjusted with<br />
<br />
set "selci:diag tol" 1d-3<br />
<br />
the example setting much lower precision, appropriate for the approximate diagonalization discussed in the preceding section.<br />
<br />
==Selection thresholds==<br />
<br />
When running in the selected-CI mode the program will loop through a list of selection thresholds (''T''), performing the CI diagonalization, computing the perturbation correction, and augmenting the CI expansion with configurations that make an energy lowering to any root greater than ''T''. The list of selection thresholds is specified as follows<br />
<br />
set "selci:selection thresholds" \<br />
0.001 0.001 0.0001 0.0001 0.00001 0.00001 0.000001<br />
<br />
There is no default for this parameter.<br />
<br />
==Mode==<br />
<br />
By default the program runs in "ci+davids" mode and just determines the CI eigenvectors/values in the current configuration space. To perform a selected-CI with perturbation correction use the following<br />
<br />
set selci:mode select<br />
<br />
and remember to define the selection thresholds.<br />
<br />
==Memory requirements==<br />
<br />
No global arrays are used inside the selected-CI, though the four-index transformation can be automatically invoked and it does use GAs. The selected CI replicates inside each process<br />
<br />
* all unique two-electron integrals in the MO basis that are non-zero by symmetry, and<br />
* all CI information, including the CI vectors.<br />
<br />
These large data structures are allocated on the local stack. A fatal error will result if insufficient memory is available.<br />
<br />
18.9 Forcing regeneration of the MO integrals<br />
<br />
When scanning a potential energy surface or optimizing a geometry the MO integrals need to be regenerated each time. Specify<br />
<br />
set selci:moints:force logical .true.<br />
<br />
to accomplish this.<br />
<br />
==Disabling update of the configuration list==<br />
<br />
When computing CI+PT energy the reference configuration list is normally updated to reflect all configurations that interact more than the specified threshold. This is usually desirable. But when scanning a potential energy surface or optimizing a geometry the reference list must be kept fixed to keep the potential energy surface continuous and well defined. To do this specify<br />
<br />
set selci:update logical .false.<br />
<br />
==Orbital locking in CI geometry optimization==<br />
<br />
The selected CI wavefunction is not invariant to orbital rotations or to swapping two or more orbitals. Orbitals could be swapped or rotated when the geometry is changed in a geometry optimization step. The keyword lock has to be set in the SCF/MCSCF (vectors) input block to keep the orbitals in the same order throughout the geometry optimization.</div>Berthttp://www.nwchem-sw.org/index.php/Release66:RunningRelease66:Running2013-06-21T17:31:33Z<p>Bert: 1 revision</p>
<hr />
<div>__NOTITLE__<br />
=Running NWChem=<br />
<br />
The command required to invoke NWChem is machine dependent, whereas most of the NWChem input is machine independent.<br />
<br />
==Sequential execution==<br />
<br />
To run NWChem sequentially on nearly all UNIX-based platforms simply use the command nwchem and provide the name of the input file as an argument. This does assume that either nwchem is in your path or you have set an alias of nwchem to point to the appropriate executable.<br />
<br />
Output is to standard output, standard error and Fortran unit 6 (usually the same as standard output). Files are created by default in the current directory, though this may be [[Release66:Top-level#SCRATCH_DIR_.2F_PERMANENT_DIR|overridden in the input]].<br />
<br />
Generally, one will run a job with the following command:<br />
<br />
nwchem input.nw >& input.out &<br />
<br />
==Parallel execution on UNIX-based parallel machines including workstation clusters using TCGMSG==<br />
<br />
These platforms require the use of the TCGMSGD.2 parallel command and thus also require the definition of a process-group (or procgroup) file. The process-group file describes how many processes to start, what program to run, which machines to use, which directories to work in, and under which userid to run the processes. By convention the process-group file has a .p suffix.<br />
<br />
The process-group file is read to end-of-file. The character # (hash or pound sign) is used to indicate a comment which continues to the next new-line character. Each line describes a cluster of processes and consists of the following whitespace separated fields:<br />
<br />
userid hostname nslave executable workdir<br />
<br />
* userid - The user-name on the machine that will be executing the process.<br />
* hostname - The hostname of the machine to execute this process. If it is the same machine on which parallel was invoked the name must match the value returned by the command hostname. If a remote machine it must allow remote execution from this machine (see man pages for rlogin, rsh).<br />
* nslave - The total number of copies of this process to be executing on the specified machine. Only "clusters" of identical processes specified in this fashion can use shared memory to communicate. If no shared memory is supported on machine <hostname> then only the value one (1) is valid.<br />
* executable - Full path name on the host <hostname> of the image to execute. If <hostname> is the local machine then a local path will suffice.<br />
* workdir - Full path name on the host <hostname> of the directory to work in. Processes execute a chdir() to this directory before returning from pbegin(). If specified as a ""."" then remote processes will use the login directory on that machine and local processes (relative to where parallel was invoked) will use the current directory of parallel.<br />
<br />
For example, if your file "nwchem.p" contained the following<br />
<br />
d3g681 pc 4 /msrc/apps/bin/nwchem /scr22/rjh<br />
<br />
then 4 processes running NWChem would be started on the machine pc running as user d3g681 in directory "/scr22/rjh". To actually run this simply type:<br />
<br />
parallel nwchem big_molecule.nw<br />
<br />
N.B. : The first process specified (process zero) is the only process that<br />
<br />
* opens and reads the input file, and<br />
* opens and reads/updates the database.<br />
<br />
Thus, if your file systems are physically distributed (e.g., most workstation clusters) you must ensure that process zero can correctly resolve the paths for the input and database files.<br />
<br />
==Parallel execution on UNIX-based parallel machines including workstation clusters using MPI==<br />
<br />
To run with MPI, parallel should not be used. The way we usually run nwchem under MPI are the following<br />
<br />
* using mpirun: <br><br> mpirun -np 8 $NWCHEM_TOP/bin/$NWCHEM_TARGET/nwchem input.nw <br><br><br />
* If you have all nodes connected via shared memory and you have installed the ch_shmem version of MPICH, you can do <br><br> $NWCHEM_TOP/bin/$NWCHEM_TARGET/nwchem -np 8 h2o.nw <br><br><br />
<br />
==Parallel execution on MPPs==<br />
<br />
All of these machines require use of different commands in order to gain exclusive access to computational resources.</div>Berthttp://www.nwchem-sw.org/index.php/Release66:Relativistic_All-electron_ApproximationsRelease66:Relativistic All-electron Approximations2013-06-21T17:31:33Z<p>Bert: 1 revision</p>
<hr />
<div>__NOTITLE__<br />
=Relativistic all-electron approximations= <br />
All methods which include treatment of relativistic effects are ultimately based on the Dirac equation, which has a four component wave function. The solutions to the Dirac equation describe both positrons (the "negative energy' states) and electrons (the "positive energy" states), as well as both spin orientations, hence the four components. The wave function may be broken down into two-component functions traditionally known as the large and small components; these may further be broken down into the spin components.<br />
<br />
The implementation of approximate all-electron relativistic methods in quantum chemical codes requires the removal of the negative energy states and the factoring out of the spin-free terms. Both of these may be achieved using a transformation of the Dirac Hamiltonian known in general as a Foldy-Wouthuysen transformation. Unfortunately this transformation cannot be represented in closed form for a general potential, and must be approximated. One popular approach is that originally formulated by Douglas and Kroll<ref><refbase>20</refbase></ref> and developed by Hess<ref><refbase>18</refbase></ref><ref><refbase>19</refbase></ref>. This approach decouples the positive and negative energy parts to second order in the external potential (and also fourth order in the fine structure constant, &alpha;). Other approaches include the Zeroth Order Regular Approximation (ZORA)<ref><refbase>21</refbase></ref><ref><refbase>22</refbase></ref><ref><refbase>23</refbase></ref><ref><refbase>30</refbase></ref> and modification of the Dirac equation by Dyall<ref><refbase>24</refbase></ref>, and involves an exact FW transformation on the atomic basis set level<ref><refbase>25</refbase></ref><ref><refbase>26</refbase></ref>.<br />
<br />
Since these approximations only modify the integrals, they can in principle be used at all levels of theory. At present the Douglas-Kroll and ZORA implementations can be used at all levels of theory whereas Dyall's approach is currently available at the Hartree-Fock level. The derivatives have been implemented, allowing both methods to be used in geometry optimizations and frequency calculations.<br />
<br />
The RELATIVISTIC directive provides input for the implemented relativistic approximations and is a compound directive that encloses additional directives specific to the approximations:<br />
<br />
RELATIVISTIC<br />
[DOUGLAS-KROLL [<string (ON||OFF) default ON> \<br />
<string (FPP||DKH||DKFULL||DK3||DK3FULL) default DKH>] ||<br />
ZORA [ (ON || OFF) default ON ] || <br />
DYALL-MOD-DIRAC [ (ON || OFF) default ON ] <br />
[ (NESC1E || NESC2E) default NESC1E ] ]<br />
[CLIGHT <real clight default 137.0359895>]<br />
END<br />
<br />
Only one of the methods may be chosen at a time. If both methods are found to be on in the input block, NWChem will stop and print an error message. There is one general option for both methods, the definition of the speed of light in atomic units:<br />
<br />
CLIGHT <real clight default 137.0359895><br />
<br />
The following sections describe the optional sub-directives that can be specified within the RELATIVISTIC block.<br />
<br />
==Douglas-Kroll approximation==<br />
<br />
The spin-free and spin-orbit one-electron Douglas-Kroll approximation have been implemented. The use of relativistic effects from this Douglas-Kroll approximation can be invoked by specifying:<br />
<br />
DOUGLAS-KROLL [<string (ON||OFF) default ON> \<br />
<string (FPP||DKH||DKFULL|DK3|DK3FULL) default DKH>]<br />
<br />
The ON|OFF string is used to turn on or off the Douglas-Kroll approximation. By default, if the DOUGLAS-KROLL keyword is found, the approximation will be used in the calculation. If the user wishes to calculate a non-relativistic quantity after turning on Douglas-Kroll, the user will need to define a new RELATIVISTIC block and turn the approximation OFF. The user could also simply put a blank RELATIVISTIC block in the input file and all options will be turned off.<br />
<br />
The FPP is the approximation based on free-particle projection operators<ref><refbase>18</refbase></ref> whereas the DKH and DKFULL approximations are based on external-field projection operators<ref><refbase>19</refbase></ref>. The latter two are considerably better approximations than the former. DKH is the Douglas-Kroll-Hess approach and is the approach that is generally implemented in quantum chemistry codes. DKFULL includes certain cross-product integral terms ignored in the DKH approach (see for example Häberlen and Rösch<ref><refbase>27</refbase></ref>). The third-order Douglas-Kroll approximation has been implemented by T. Nakajima and K. Hirao<ref><refbase>28</refbase></ref><ref><refbase>29</refbase></ref>. This approximation can be called using DK3 (DK3 without cross-product integral terms) or DK3FULL (DK3 with cross-product integral terms).<br />
<br />
The contracted basis sets used in the calculations should reflect the relativistic effects, i.e. one should use contracted basis sets which were generated using the Douglas-Kroll Hamiltonian. Basis sets that were contracted using the non-relativistic (Schödinger) Hamiltonian WILL PRODUCE ERRONEOUS RESULTS for elements beyond the first row. See appendix A for available basis sets and their naming convention.<br />
<br />
NOTE: we suggest that spherical basis sets are used in the calculation. The use of high quality cartesian basis sets can lead to numerical inaccuracies.<br />
<br />
In order to compute the integrals needed for the Douglas-Kroll approximation the implementation makes use of a fitting basis set (see literature given above for details). The current code will create this fitting basis set based on the given "ao basis" by simply uncontracting that basis. This again is what is commonly implemented in quantum chemistry codes that include the Douglas-Kroll method. Additional flexibility is available to the user by explicitly specifying a Douglas-Kroll fitting basis set. This basis set must be named "D-K basis" (see [[Basis|Basis Sets]]).<br />
<br />
==Zeroth Order regular approximation (ZORA)==<br />
<br />
The spin-free and spin-orbit one-electron zeroth-order regular approximation (ZORA) have been implemented. The use of relativistic effects with ZORA can be invoked by specifying:<br />
<br />
ZORA [<string (ON||OFF) default ON><br />
<br />
The ON|OFF string is used to turn on or off ZORA. By default, if the ZORA keyword is found, the approximation will be used in the calculation. If the user wishes to calculate a non-relativistic quantity after turning on ZORA, the user will need to define a new RELATIVISTIC block and turn the approximation OFF. The user can also simply put a blank RELATIVISTIC block in the input file and all options will be turned off.<br />
<br />
==<div id="Dyall-Mod-Dirac-Hamiltonian">Dyall's Modified Dirac Hamitonian approximation</div>==<br />
<br />
The approximate methods described in this section are all based on Dyall's modified Dirac Hamiltonian. This Hamiltonian is entirely equivalent to the original Dirac Hamiltonian, and its solutions have the same properties. The modification is achieved by a transformation on the small component, extracting out <math>\sigma\cdot{\mathbf{p}}/2mc</math>. This gives the modified small component the same symmetry as the large component, and in fact it differs from the large component only at order <math>\alpha^2</math>. The advantage of the modification is that the operators now resemble the operators of the Breit-Pauli Hamiltonian, and can be classified in a similar fashion into spin-free, spin-orbit and spin-spin terms. It is the spin-free terms which have been implemented in NWChem, with a number of further approximations.<br />
<br />
The first is that the negative energy states are removed by a normalized elimination of the small component (NESC), which is equivalent to an exact Foldy-Wouthuysen (EFW) transformation. The number of components in the wave function is thereby effectively reduced from 4 to 2. NESC on its own does not provide any advantages, and in fact complicates things because the transformation is energy-dependent. The second approximation therefore performs the elimination on an atom-by-atom basis, which is equivalent to neglecting blocks which couple different atoms in the EFW transformation. The advantage of this approximation is that all the energy dependence can be included in the contraction coefficients of the basis set. The tests which have been done show that this approximation gives results well within chemical accuracy. The third approximation neglects the commutator of the EFW transformation with the two-electron Coulomb interaction, so that the only corrections that need to be made are in the one-electron integrals. This is the equivalent of the Douglas-Kroll(-Hess) approximation as it is usually applied.<br />
<br />
The use of these approximations can be invoked with the use of the DYALL-MOD-DIRAC directive in the RELATIVISTIC directive block. The syntax is as follows.<br />
<br />
DYALL-MOD-DIRAC [ (ON || OFF) default ON ] <br />
[ (NESC1E || NESC2E) default NESC1E ]<br />
<br />
The ON|OFF string is used to turn on or off the Dyall's modified Dirac approximation. By default, if the DYALL-MOD-DIRAC keyword is found, the approximation will be used in the calculation. If the user wishes to calculate a non-relativistic quantity after turning on Dyall's modified Dirac, the user will need to define a new RELATIVISTIC block and turn the approximation OFF. The user could also simply put a blank RELATIVISTIC block in the input file and all options will be turned off.<br />
<br />
Both one- and two-electron approximations are available NESC1E || NESC2E, and both have analytic gradients. The one-electron approximation is the default. The two-electron approximation specified by NESC2E has some sub options which are placed on the same logical line as the DYALL-MOD-DIRAC directive, with the following syntax:<br />
<br />
NESC2E [ (SS1CENT [ (ON || OFF) default ON ] || SSALL) default SSALL ]<br />
[ (SSSS [ (ON || OFF) default ON ] || NOSSSS) default SSSS ]<br />
<br />
The first sub-option gives the capability to limit the two-electron corrections to those in which the small components in any density must be on the same center. This reduces the <math>(LL\vert SS)</math> contributions to at most three-center integrals and the <math>(SS\vert SS)</math> contributions to two centers. For a case with only one relativistic atom this option is redundant. The second controls the inclusion of the <math>(SS\vert SS)</math> integrals which are of order <math>\alpha^4</math>. For light atoms they may safely be neglected, but for heavy atoms they should be included.<br />
<br />
In addition to the selection of this keyword in the RELATIVISTIC directive block, it is necessary to supply basis sets in addition to the ao basis. For the one-electron approximation, three basis sets are needed: the atomic FW basis set, the large component basis set and the small component basis set. The atomic FW basis set should be included in the ao basis. The large and small components should similarly be incorporated in basis sets named large component and small component, respectively. For the two-electron approximation, only two basis sets are needed. These are the large component and the small component. The large component should be included in the ao basis and the small component is specified separately as small component, as for the one-electron approximation. This means that the two approximations can not be run correctly without changing the ao basis, and it is up to the user to ensure that the basis sets are correctly specified.<br />
<br />
There is one further requirement in the specification of the basis sets. In the ao basis, it is necessary to add the rel keyword either to the basis directive or the library tag line (See below for examples). The former marks the basis functions specified by the tag as relativistic, the latter marks the whole basis as relativistic. The marking is actually done at the unique shell level, so that it is possible not only to have relativistic and nonrelativistic atoms, it is also possible to have relativistic and nonrelativistic shells on a given atom. This would be useful, for example, for diffuse functions or for high angular momentum correlating functions, where the influence of relativity was small. The marking of shells as relativistic is necessary to set up a mapping between the ao basis and the large and/or small component basis sets. For the one-electron approximation the large and small component basis sets MUST be of the same size and construction, i.e. differing only in the contraction coefficients.<br />
<br />
It should also be noted that the relativistic code will NOT work with basis sets that contain sp shells, nor will it work with ECPs. Both of these are tested and flagged as an error.<br />
<br />
Some examples follow. The first example sets up the data for relativistic calculations on water with the one-electron approximation and the two-electron approximation, using the library basis sets.<br />
<br />
start h2o-dmd<br />
geometry units bohr<br />
symmetry c2v<br />
O 0.000000000 0.000000000 -0.009000000<br />
H 1.515260000 0.000000000 -1.058900000<br />
H -1.515260000 0.000000000 -1.058900000<br />
end<br />
basis "fw" rel<br />
oxygen library cc-pvdz_pt_sf_fw<br />
hydrogen library cc-pvdz_pt_sf_fw<br />
end<br />
basis "large"<br />
oxygen library cc-pvdz_pt_sf_lc<br />
hydrogen library cc-pvdz_pt_sf_lc<br />
end<br />
basis "large2" rel<br />
oxygen library cc-pvdz_pt_sf_lc<br />
hydrogen library cc-pvdz_pt_sf_lc<br />
end<br />
basis "small"<br />
oxygen library cc-pvdz_pt_sf_sc<br />
hydrogen library cc-pvdz_pt_sf_sc<br />
end<br />
set "ao basis" fw<br />
set "large component" large<br />
set "small component" small<br />
relativistic<br />
dyall-mod-dirac<br />
end<br />
task scf<br />
set "ao basis" large2<br />
unset "large component"<br />
set "small component" small<br />
relativistic<br />
dyall-mod-dirac nesc2e<br />
end<br />
task scf<br />
<br />
The second example has oxygen as a relativistic atom and hydrogen nonrelativistic.<br />
<br />
start h2o-dmd2<br />
geometry units bohr<br />
symmetry c2v<br />
O 0.000000000 0.000000000 -0.009000000<br />
H 1.515260000 0.000000000 -1.058900000<br />
H -1.515260000 0.000000000 -1.058900000<br />
end<br />
basis "ao basis"<br />
oxygen library cc-pvdz_pt_sf_fw rel<br />
hydrogen library cc-pvdz<br />
end<br />
basis "large component"<br />
oxygen library cc-pvdz_pt_sf_lc<br />
end<br />
basis "small component"<br />
oxygen library cc-pvdz_pt_sf_sc<br />
end<br />
relativistic<br />
dyall-mod-dirac<br />
end<br />
task scf<br />
<br />
<references/></div>Berthttp://www.nwchem-sw.org/index.php/Release65:RunningRelease65:Running2013-06-21T17:31:33Z<p>Bert: 1 revision</p>
<hr />
<div>__NOTITLE__<br />
=Running NWChem=<br />
<br />
The command required to invoke NWChem is machine dependent, whereas most of the NWChem input is machine independent.<br />
<br />
==Sequential execution==<br />
<br />
To run NWChem sequentially on nearly all UNIX-based platforms simply use the command nwchem and provide the name of the input file as an argument. This does assume that either nwchem is in your path or you have set an alias of nwchem to point to the appropriate executable.<br />
<br />
Output is to standard output, standard error and Fortran unit 6 (usually the same as standard output). Files are created by default in the current directory, though this may be [[Release64:Top-level#SCRATCH_DIR_.2F_PERMANENT_DIR|overridden in the input]].<br />
<br />
Generally, one will run a job with the following command:<br />
<br />
nwchem input.nw >& input.out &<br />
<br />
==Parallel execution on UNIX-based parallel machines including workstation clusters using TCGMSG==<br />
<br />
These platforms require the use of the TCGMSGD.2 parallel command and thus also require the definition of a process-group (or procgroup) file. The process-group file describes how many processes to start, what program to run, which machines to use, which directories to work in, and under which userid to run the processes. By convention the process-group file has a .p suffix.<br />
<br />
The process-group file is read to end-of-file. The character # (hash or pound sign) is used to indicate a comment which continues to the next new-line character. Each line describes a cluster of processes and consists of the following whitespace separated fields:<br />
<br />
userid hostname nslave executable workdir<br />
<br />
* userid - The user-name on the machine that will be executing the process.<br />
* hostname - The hostname of the machine to execute this process. If it is the same machine on which parallel was invoked the name must match the value returned by the command hostname. If a remote machine it must allow remote execution from this machine (see man pages for rlogin, rsh).<br />
* nslave - The total number of copies of this process to be executing on the specified machine. Only "clusters" of identical processes specified in this fashion can use shared memory to communicate. If no shared memory is supported on machine <hostname> then only the value one (1) is valid.<br />
* executable - Full path name on the host <hostname> of the image to execute. If <hostname> is the local machine then a local path will suffice.<br />
* workdir - Full path name on the host <hostname> of the directory to work in. Processes execute a chdir() to this directory before returning from pbegin(). If specified as a ""."" then remote processes will use the login directory on that machine and local processes (relative to where parallel was invoked) will use the current directory of parallel.<br />
<br />
For example, if your file "nwchem.p" contained the following<br />
<br />
d3g681 pc 4 /msrc/apps/bin/nwchem /scr22/rjh<br />
<br />
then 4 processes running NWChem would be started on the machine pc running as user d3g681 in directory "/scr22/rjh". To actually run this simply type:<br />
<br />
parallel nwchem big_molecule.nw<br />
<br />
N.B. : The first process specified (process zero) is the only process that<br />
<br />
* opens and reads the input file, and<br />
* opens and reads/updates the database.<br />
<br />
Thus, if your file systems are physically distributed (e.g., most workstation clusters) you must ensure that process zero can correctly resolve the paths for the input and database files.<br />
<br />
==Parallel execution on UNIX-based parallel machines including workstation clusters using MPI==<br />
<br />
To run with MPI, parallel should not be used. The way we usually run nwchem under MPI are the following<br />
<br />
* using mpirun: <br><br> mpirun -np 8 $NWCHEM_TOP/bin/$NWCHEM_TARGET/nwchem input.nw <br><br><br />
* If you have all nodes connected via shared memory and you have installed the ch_shmem version of MPICH, you can do <br><br> $NWCHEM_TOP/bin/$NWCHEM_TARGET/nwchem -np 8 h2o.nw <br><br><br />
<br />
==Parallel execution on MPPs==<br />
<br />
All of these machines require use of different commands in order to gain exclusive access to computational resources.</div>Berthttp://www.nwchem-sw.org/index.php/Release65:Relativistic_All-electron_ApproximationsRelease65:Relativistic All-electron Approximations2013-06-21T17:31:33Z<p>Bert: 1 revision</p>
<hr />
<div>__NOTITLE__<br />
=Relativistic all-electron approximations= <br />
All methods which include treatment of relativistic effects are ultimately based on the Dirac equation, which has a four component wave function. The solutions to the Dirac equation describe both positrons (the "negative energy' states) and electrons (the "positive energy" states), as well as both spin orientations, hence the four components. The wave function may be broken down into two-component functions traditionally known as the large and small components; these may further be broken down into the spin components.<br />
<br />
The implementation of approximate all-electron relativistic methods in quantum chemical codes requires the removal of the negative energy states and the factoring out of the spin-free terms. Both of these may be achieved using a transformation of the Dirac Hamiltonian known in general as a Foldy-Wouthuysen transformation. Unfortunately this transformation cannot be represented in closed form for a general potential, and must be approximated. One popular approach is that originally formulated by Douglas and Kroll<ref><refbase>20</refbase></ref> and developed by Hess<ref><refbase>18</refbase></ref><ref><refbase>19</refbase></ref>. This approach decouples the positive and negative energy parts to second order in the external potential (and also fourth order in the fine structure constant, &alpha;). Other approaches include the Zeroth Order Regular Approximation (ZORA)<ref><refbase>21</refbase></ref><ref><refbase>22</refbase></ref><ref><refbase>23</refbase></ref><ref><refbase>30</refbase></ref> and modification of the Dirac equation by Dyall<ref><refbase>24</refbase></ref>, and involves an exact FW transformation on the atomic basis set level<ref><refbase>25</refbase></ref><ref><refbase>26</refbase></ref>.<br />
<br />
Since these approximations only modify the integrals, they can in principle be used at all levels of theory. At present the Douglas-Kroll and ZORA implementations can be used at all levels of theory whereas Dyall's approach is currently available at the Hartree-Fock level. The derivatives have been implemented, allowing both methods to be used in geometry optimizations and frequency calculations.<br />
<br />
The RELATIVISTIC directive provides input for the implemented relativistic approximations and is a compound directive that encloses additional directives specific to the approximations:<br />
<br />
RELATIVISTIC<br />
[DOUGLAS-KROLL [<string (ON||OFF) default ON> \<br />
<string (FPP||DKH||DKFULL||DK3||DK3FULL) default DKH>] ||<br />
ZORA [ (ON || OFF) default ON ] || <br />
DYALL-MOD-DIRAC [ (ON || OFF) default ON ] <br />
[ (NESC1E || NESC2E) default NESC1E ] ]<br />
[CLIGHT <real clight default 137.0359895>]<br />
END<br />
<br />
Only one of the methods may be chosen at a time. If both methods are found to be on in the input block, NWChem will stop and print an error message. There is one general option for both methods, the definition of the speed of light in atomic units:<br />
<br />
CLIGHT <real clight default 137.0359895><br />
<br />
The following sections describe the optional sub-directives that can be specified within the RELATIVISTIC block.<br />
<br />
==Douglas-Kroll approximation==<br />
<br />
The spin-free and spin-orbit one-electron Douglas-Kroll approximation have been implemented. The use of relativistic effects from this Douglas-Kroll approximation can be invoked by specifying:<br />
<br />
DOUGLAS-KROLL [<string (ON||OFF) default ON> \<br />
<string (FPP||DKH||DKFULL|DK3|DK3FULL) default DKH>]<br />
<br />
The ON|OFF string is used to turn on or off the Douglas-Kroll approximation. By default, if the DOUGLAS-KROLL keyword is found, the approximation will be used in the calculation. If the user wishes to calculate a non-relativistic quantity after turning on Douglas-Kroll, the user will need to define a new RELATIVISTIC block and turn the approximation OFF. The user could also simply put a blank RELATIVISTIC block in the input file and all options will be turned off.<br />
<br />
The FPP is the approximation based on free-particle projection operators<ref><refbase>18</refbase></ref> whereas the DKH and DKFULL approximations are based on external-field projection operators<ref><refbase>19</refbase></ref>. The latter two are considerably better approximations than the former. DKH is the Douglas-Kroll-Hess approach and is the approach that is generally implemented in quantum chemistry codes. DKFULL includes certain cross-product integral terms ignored in the DKH approach (see for example Häberlen and Rösch<ref><refbase>27</refbase></ref>). The third-order Douglas-Kroll approximation has been implemented by T. Nakajima and K. Hirao<ref><refbase>28</refbase></ref><ref><refbase>29</refbase></ref>. This approximation can be called using DK3 (DK3 without cross-product integral terms) or DK3FULL (DK3 with cross-product integral terms).<br />
<br />
The contracted basis sets used in the calculations should reflect the relativistic effects, i.e. one should use contracted basis sets which were generated using the Douglas-Kroll Hamiltonian. Basis sets that were contracted using the non-relativistic (Schödinger) Hamiltonian WILL PRODUCE ERRONEOUS RESULTS for elements beyond the first row. See appendix A for available basis sets and their naming convention.<br />
<br />
NOTE: we suggest that spherical basis sets are used in the calculation. The use of high quality cartesian basis sets can lead to numerical inaccuracies.<br />
<br />
In order to compute the integrals needed for the Douglas-Kroll approximation the implementation makes use of a fitting basis set (see literature given above for details). The current code will create this fitting basis set based on the given "ao basis" by simply uncontracting that basis. This again is what is commonly implemented in quantum chemistry codes that include the Douglas-Kroll method. Additional flexibility is available to the user by explicitly specifying a Douglas-Kroll fitting basis set. This basis set must be named "D-K basis" (see [[Basis|Basis Sets]]).<br />
<br />
==Zeroth Order regular approximation (ZORA)==<br />
<br />
The spin-free and spin-orbit one-electron zeroth-order regular approximation (ZORA) have been implemented. The use of relativistic effects with ZORA can be invoked by specifying:<br />
<br />
ZORA [<string (ON||OFF) default ON><br />
<br />
The ON|OFF string is used to turn on or off ZORA. By default, if the ZORA keyword is found, the approximation will be used in the calculation. If the user wishes to calculate a non-relativistic quantity after turning on ZORA, the user will need to define a new RELATIVISTIC block and turn the approximation OFF. The user can also simply put a blank RELATIVISTIC block in the input file and all options will be turned off.<br />
<br />
==<div id="Dyall-Mod-Dirac-Hamiltonian">Dyall's Modified Dirac Hamitonian approximation</div>==<br />
<br />
The approximate methods described in this section are all based on Dyall's modified Dirac Hamiltonian. This Hamiltonian is entirely equivalent to the original Dirac Hamiltonian, and its solutions have the same properties. The modification is achieved by a transformation on the small component, extracting out <math>\sigma\cdot{\mathbf{p}}/2mc</math>. This gives the modified small component the same symmetry as the large component, and in fact it differs from the large component only at order <math>\alpha^2</math>. The advantage of the modification is that the operators now resemble the operators of the Breit-Pauli Hamiltonian, and can be classified in a similar fashion into spin-free, spin-orbit and spin-spin terms. It is the spin-free terms which have been implemented in NWChem, with a number of further approximations.<br />
<br />
The first is that the negative energy states are removed by a normalized elimination of the small component (NESC), which is equivalent to an exact Foldy-Wouthuysen (EFW) transformation. The number of components in the wave function is thereby effectively reduced from 4 to 2. NESC on its own does not provide any advantages, and in fact complicates things because the transformation is energy-dependent. The second approximation therefore performs the elimination on an atom-by-atom basis, which is equivalent to neglecting blocks which couple different atoms in the EFW transformation. The advantage of this approximation is that all the energy dependence can be included in the contraction coefficients of the basis set. The tests which have been done show that this approximation gives results well within chemical accuracy. The third approximation neglects the commutator of the EFW transformation with the two-electron Coulomb interaction, so that the only corrections that need to be made are in the one-electron integrals. This is the equivalent of the Douglas-Kroll(-Hess) approximation as it is usually applied.<br />
<br />
The use of these approximations can be invoked with the use of the DYALL-MOD-DIRAC directive in the RELATIVISTIC directive block. The syntax is as follows.<br />
<br />
DYALL-MOD-DIRAC [ (ON || OFF) default ON ] <br />
[ (NESC1E || NESC2E) default NESC1E ]<br />
<br />
The ON|OFF string is used to turn on or off the Dyall's modified Dirac approximation. By default, if the DYALL-MOD-DIRAC keyword is found, the approximation will be used in the calculation. If the user wishes to calculate a non-relativistic quantity after turning on Dyall's modified Dirac, the user will need to define a new RELATIVISTIC block and turn the approximation OFF. The user could also simply put a blank RELATIVISTIC block in the input file and all options will be turned off.<br />
<br />
Both one- and two-electron approximations are available NESC1E || NESC2E, and both have analytic gradients. The one-electron approximation is the default. The two-electron approximation specified by NESC2E has some sub options which are placed on the same logical line as the DYALL-MOD-DIRAC directive, with the following syntax:<br />
<br />
NESC2E [ (SS1CENT [ (ON || OFF) default ON ] || SSALL) default SSALL ]<br />
[ (SSSS [ (ON || OFF) default ON ] || NOSSSS) default SSSS ]<br />
<br />
The first sub-option gives the capability to limit the two-electron corrections to those in which the small components in any density must be on the same center. This reduces the <math>(LL\vert SS)</math> contributions to at most three-center integrals and the <math>(SS\vert SS)</math> contributions to two centers. For a case with only one relativistic atom this option is redundant. The second controls the inclusion of the <math>(SS\vert SS)</math> integrals which are of order <math>\alpha^4</math>. For light atoms they may safely be neglected, but for heavy atoms they should be included.<br />
<br />
In addition to the selection of this keyword in the RELATIVISTIC directive block, it is necessary to supply basis sets in addition to the ao basis. For the one-electron approximation, three basis sets are needed: the atomic FW basis set, the large component basis set and the small component basis set. The atomic FW basis set should be included in the ao basis. The large and small components should similarly be incorporated in basis sets named large component and small component, respectively. For the two-electron approximation, only two basis sets are needed. These are the large component and the small component. The large component should be included in the ao basis and the small component is specified separately as small component, as for the one-electron approximation. This means that the two approximations can not be run correctly without changing the ao basis, and it is up to the user to ensure that the basis sets are correctly specified.<br />
<br />
There is one further requirement in the specification of the basis sets. In the ao basis, it is necessary to add the rel keyword either to the basis directive or the library tag line (See below for examples). The former marks the basis functions specified by the tag as relativistic, the latter marks the whole basis as relativistic. The marking is actually done at the unique shell level, so that it is possible not only to have relativistic and nonrelativistic atoms, it is also possible to have relativistic and nonrelativistic shells on a given atom. This would be useful, for example, for diffuse functions or for high angular momentum correlating functions, where the influence of relativity was small. The marking of shells as relativistic is necessary to set up a mapping between the ao basis and the large and/or small component basis sets. For the one-electron approximation the large and small component basis sets MUST be of the same size and construction, i.e. differing only in the contraction coefficients.<br />
<br />
It should also be noted that the relativistic code will NOT work with basis sets that contain sp shells, nor will it work with ECPs. Both of these are tested and flagged as an error.<br />
<br />
Some examples follow. The first example sets up the data for relativistic calculations on water with the one-electron approximation and the two-electron approximation, using the library basis sets.<br />
<br />
start h2o-dmd<br />
geometry units bohr<br />
symmetry c2v<br />
O 0.000000000 0.000000000 -0.009000000<br />
H 1.515260000 0.000000000 -1.058900000<br />
H -1.515260000 0.000000000 -1.058900000<br />
end<br />
basis "fw" rel<br />
oxygen library cc-pvdz_pt_sf_fw<br />
hydrogen library cc-pvdz_pt_sf_fw<br />
end<br />
basis "large"<br />
oxygen library cc-pvdz_pt_sf_lc<br />
hydrogen library cc-pvdz_pt_sf_lc<br />
end<br />
basis "large2" rel<br />
oxygen library cc-pvdz_pt_sf_lc<br />
hydrogen library cc-pvdz_pt_sf_lc<br />
end<br />
basis "small"<br />
oxygen library cc-pvdz_pt_sf_sc<br />
hydrogen library cc-pvdz_pt_sf_sc<br />
end<br />
set "ao basis" fw<br />
set "large component" large<br />
set "small component" small<br />
relativistic<br />
dyall-mod-dirac<br />
end<br />
task scf<br />
set "ao basis" large2<br />
unset "large component"<br />
set "small component" small<br />
relativistic<br />
dyall-mod-dirac nesc2e<br />
end<br />
task scf<br />
<br />
The second example has oxygen as a relativistic atom and hydrogen nonrelativistic.<br />
<br />
start h2o-dmd2<br />
geometry units bohr<br />
symmetry c2v<br />
O 0.000000000 0.000000000 -0.009000000<br />
H 1.515260000 0.000000000 -1.058900000<br />
H -1.515260000 0.000000000 -1.058900000<br />
end<br />
basis "ao basis"<br />
oxygen library cc-pvdz_pt_sf_fw rel<br />
hydrogen library cc-pvdz<br />
end<br />
basis "large component"<br />
oxygen library cc-pvdz_pt_sf_lc<br />
end<br />
basis "small component"<br />
oxygen library cc-pvdz_pt_sf_sc<br />
end<br />
relativistic<br />
dyall-mod-dirac<br />
end<br />
task scf<br />
<br />
<references/></div>Berthttp://www.nwchem-sw.org/index.php/Release66:RT-TDDFTRelease66:RT-TDDFT2013-06-21T17:31:32Z<p>Bert: 1 revision</p>
<hr />
<div>__NOTITLE__<br />
= Real-time TDDFT =<br />
== Overview ==<br />
Real-time time-dependent density functional theory (RT-TDDFT) is a DFT-based approach to electronic excited states based on integrating the time-dependent Kohn-Sham (TDKS) equations in time. The theoretical underpinnings, strengths, and limitations are similar to traditional linear-response (LR) [[Excited-State_Calculations|TDDFT]] methods, but instead of a frequency domain solution to the TDKS equations, RT-TDDFT yields a full time-resolved, potentially non-linear solution. Real-time simulations can be used to compute not only spectroscopic properties (e.g., absorption spectra, polarizabilites, etc), but also the time and space-resolved electronic response to arbitrary external stimuli (e.g., electron charge dynamics after laser excitation). For theoretical and computational details, please refer to the following paper:<br />
<br />
#K. Lopata, N. Govind,"Modeling Fast Electron Dynamics with Real-Time Time-Dependent Density Functional Theory: Application to Small Molecules and Chromophores", J. Chem. Theory Comput., 7, 1344 (2011) <br />
<br />
This functionality is built on the [[Density Functional Theory for Molecules|Gaussian basis set DFT]] module, and will work for closed-shell (spin-restricted) and open-shell (spin unrestricted) calculations with essentially any combination of basis set and exchange-correlation functional in NWChem. The current implementation assumes frozen nuclei (Born-Oppenheimer approximation).<br />
<br />
In a nutshell, running a RT-TDDFT calculation takes the following form:<br />
#Compute ground state density matrix with DFT module<br />
#Propagate density matrix using RT-TDDFT<br />
#Post-process resulting time-dependent observables (e.g., dipole moment)<br />
<br />
== Units ==<br />
Unless specified otherwise, all inputs and outputs are in '''atomic units'''. Some useful conversions are:<br />
<table border="1"><br />
<tr><th> Quantity </th><th> Conversion </th></tr><br />
<tr><td> Time </td><td> 1 au = 0.02419 fs </td></tr><br />
<tr><td> Length </td><td> 1 au = 0.5292 A </td></tr><br />
<tr><td> Energy </td><td> 1 au = 27.2114 eV </td></tr><br />
<tr><td> Electric field </td><td> 1 au = 514.2 V/nm </td></tr><br />
<tr><td> Dipole moment </td><td> 1 au = 2.542 D </td></tr><br />
</table><br />
<br />
== Syntax ==<br />
The [[Charge|charge]], [[Geometry|geometry]], [[Basis|basis set]], and [[Density Functional Theory for Molecules|DFT]] options are all specified as normal, using their respective syntax. Real-time TDDFT parameters are supplied in the RT_TDDFT block (note, nothing is case-sensitive), with all possible options summarized below, and each discussed in detail afterwards.<br />
<br />
RT_TDDFT<br />
[TMAX <double default 1000>]<br />
[DT <double default 0.1>]<br />
[TAG <string default "<rt_tddft>: "]<br />
[LOAD (scf || vectors <string>)]<br />
[NCHECKS <integer default 10>]<br />
[NPRINTS (* || <integer>)]<br />
[NRESTARTS (* || <integer>)]<br />
[TOLERANCES (zero <double default 1e-8> || series <double default 1e-10> || interpol <double default 1e-7>)]<br />
[PROPAGATOR (euler || rk4 || magnus) default magnus]<br />
[EXP (diag || pseries)]<br />
[PROF]<br />
[NOPROP]<br />
[STATIC]<br />
[PRINT (*, dipole, quadrupole, field, moocc, field, energy, cputime, charge, convergence, s2)]<br />
[EXCITE <string geomname> with <string fieldname>]<br />
[FIELD]<br />
...<br />
[END]<br />
[VISUALIZATION]<br />
...<br />
[END]<br />
END<br />
<br />
=== TMAX -- Simulation time ===<br />
This option specifies the maximum time (in au) to run the simulation before stopping, which must be a positive real number. In practice, you can just stop the simulation early, so in most cases it is simplest to just set this to a large value to ensure you capture all the important dynamics (see [[Release66:RT-TDDFT#Hints and Tricks|Hints and Tricks]]). For most valence excitations, for example, 1000 au is overkill so you might want to automatically stop at 500 au: <br />
rt_tddft<br />
...<br />
tmax 500.0<br />
...<br />
end<br />
<br />
=== DT -- Time step ===<br />
This specifies the electronic time step for time integration. A larger time step results in a faster simulation, but there are two issues which limit the size of the time step. First, the integration algorithm can become unstable and/or inaccurate for larger time steps, which depends on the integrator used. Very roughly speaking, the second order Magnus integrator should be reliable for time steps up to 0.2 au. Second, you must choose a time step small enough to capture the oscillations of interest, i.e., to resolve an excitation of energy <math>\omega</math>, your time step needs to be smaller than <math>\pi / \omega</math>, and typically a tenth of that for accuracy. For example, to capture high energy oscillations such as core-level excitations (e.g., <math>\omega = 50</math> au) you might want a relative small time step:<br />
rt_tddft<br />
...<br />
dt 0.01<br />
...<br />
end<br />
It is always good practice to check that your results are independent of time step.<br />
<br />
=== TAG -- Output label ===<br />
This option sets a label for the output for convenient parsing (e.g., with "grep"). Every output line with time-dependent data will begin with this string (set to "<rt_tddft>: " by default). For example setting:<br />
rt_tddft<br />
...<br />
tag "nameofrun"<br />
...<br />
end<br />
will result in outputs that look like:<br />
...<br />
nameofrun 2.20000 -7.589146713114E+001 # Etot<br />
...<br />
<br />
=== NCHECKS -- Number of run-time check points ===<br />
This option takes an integer number (default 10), or "*" which means every step, which sets the total of number of run-time checkpoints, where various sanity checks are made such as symmetries, idempotency, traces, etc. These checks are not terribly efficient (e.g., involve re-building the TD Fock matrix) so excessive checking will slow down execution.<br />
rt_tddft<br />
...<br />
nchecks 10<br />
...<br />
end<br />
<br />
=== NPRINTS -- Number of print points ===<br />
This sets the number of print points, i.e., the total number of time-dependent observables (e.g., dipole, charge, energy) that are computed and printed. It either takes an integer number or "*" which means every time step (this is the default). Since there is no appreciable cost to computing and printing these quantities, there is usually no need to change this from "*".<br />
rt_tddft<br />
...<br />
nprints *<br />
...<br />
end<br />
<br />
=== NRESTARTS -- Number of restart checkpoints ===<br />
This sets the number of run-time check points where the time-dependent complex density matrix is saved to file, allowing the simulation to be [[Release66:RT-TDDFT#Restarts|restarted]]) from that point. By default this is set to 0. There is no significant computational cost to restart checkpointing, but of course there is some disk I/O cost (which may become somewhat significant for larger systems). For example, in the following example there will be 100 restart points, which corresponds to 1 backup every 100 time steps. <br />
rt_tddft<br />
...<br />
tmax 1000.0<br />
dt 0.1<br />
nrestarts 100<br />
...<br />
end<br />
<br />
=== TOLERANCES -- Controlling numerical tolerances ===<br />
This option controls various numerical tolerances:<br />
* zero: threshold for checks that quantities are zero, e.g., in symmetry checks (default 1e-8)<br />
* series: numerical convergence for series, e.g., matrix exponentiation (default 1e-10)<br />
* interpol: numerical convergence for interpolation, e.g., in Magnus propagator (default 1e-7)<br />
Occasionally it is useful to loosen the interpolation tolerances if the Magnus interpolator requires an excessive amount of steps; usually this will not impact accuracy. For example, this sets the tolerances to their defaults with a looser interpolation tolerance:<br />
rt_tddft<br />
...<br />
tolerances zero 1d-8 series 1d-10 interpol 1e-5<br />
end<br />
<br />
=== PROPAGATOR -- Selecting the integrator method ===<br />
This selects the propagtor (i.e., time integrator) method. Possible choices include "euler" for Euler integration (terrible, you should never use this), "rk4" for 4th order Runge-Kutta, and "magnus" for 2nd order Magnus with self-consistent interpolation. In virtually all cases Magnus is superior in terms of stability. Euler or rk4 are perhaps only useful for debugging or simplicity (e.g., for code development).<br />
rt_tddft<br />
...<br />
propagator magnus<br />
...<br />
end<br />
<br />
=== EXP -- Selecting the matrix exponentiation method ===<br />
This selects the method for exponentiation matrices. For now this can either be "pseries" for a contractive power series or "diag" for diagonalization. In general the power series (default) is faster.<br />
rt_tddft<br />
...<br />
exp diag<br />
...<br />
end<br />
<br />
=== PROF -- Run-time profiling ===<br />
This turns on run-time profiling, which will display time spent in each component of the code (e.g., building components of the TD Fock matrix, properites, etc). This slows code down slightly and results in very verbose output.<br />
rt_tddft<br />
...<br />
prof<br />
...<br />
end<br />
<br />
=== NOPROP -- Skipping propagation ===<br />
This options causes the RT-TDDFT module skip propagation, i.e., to initialize and finalize. For now this is largely useful for skipping to visualization post-processing without having to re-run a simulation.<br />
rt_tddft<br />
...<br />
noprop<br />
...<br />
end<br />
<br />
=== STATIC -- Force static Fock matrix ===<br />
This option sets the static Fock matrix flag, meaning the time-dependent Fock matrix will not be recalculated at each time, but instead use the t=0 value. This will drastically increase the simulation speed since the bulk of the work is spent rebuilding the TD Fock matrix, but will give non-physical results. For example, using "static" to compute an absorption spectrum will result in excitations corresponding to the raw eigenvalue differences without electron-hole relaxation. This option has few uses besides dry-runs and debugging.<br />
rt_tddft<br />
...<br />
static<br />
...<br />
end<br />
<br />
=== PRINT -- Selecting time-dependent quantities to be printed ===<br />
This sets the various time-dependent properties that are to be computed and printed at each print point. Note that for many of these options, the values are computed and printed for each geometry specified in the input deck, not only the active one (i.e., the one set using "set geometry ..." in the input deck). Possible choices are:<br />
* dipole: Dipole moment<br />
* quadrupole: Quadrupole moment<br />
* field: External (applied) electric field<br />
* moocc: Molecular orbital occupations<br />
* energy: Components of system energy (e.g., core, XC, total, etc)<br />
* cputime: CPU time taken in simulation so far (useful for checking scaling)<br />
* charge: Electronic charge (computed from density matrix, not from the XC grid)<br />
* convergence: Convergence information (e.g., from Magnus)<br />
* s2: <S2> value (openshell only)<br />
* *: Print all quantities<br />
The defaults correspond to:<br />
rt_tddft<br />
...<br />
print dipole field energy convergence<br />
...<br />
end<br />
<br />
=== FIELD -- Sub-block for specifying external electric fields ===<br />
This sub-block is used to specify external electric fields, each of which must be given a unique name. Numerous fields can be specified, but each will applied to the system only if an appropriate [[Release66:RT-TDDFT#EXCITE -- Excitation rules|excitation rule]] is set. There are a few preset field types; others would have to be manually coded. Note the names are arbitrary, but chosen here to be descriptive:<br />
<br />
field "kick"<br />
type delta # E(t=0) = max; E(t>0) = 0<br />
polarization x # = x, y, z<br />
max 0.0001 # maximum value of electric field<br />
spin total # = alpha, beta, total (only valid for open-shell)<br />
end<br />
<br />
field "gpulse"<br />
type gaussian # Gaussian enveloped quasi-monochromatic pulse: E(t) = exp( -(t-t0)^2 / 2s^2)<br />
polarization x # = x, y, z<br />
frequency 0.12 # frequency of laser pulse in au (e.g., 0.12 au = 3.27 eV)<br />
center 200.0 # center of Gaussian envelope (in au time)<br />
width 50.0 # width of Gaussian pulse (in au time)<br />
max 0.0001 # maximum value of electric field<br />
spin total # = alpha, beta, total (only valid for open-shell)<br />
end<br />
<br />
field "hpulse"<br />
type hann # sin^2 (Hann) enveloped quasi-monochromatic pulse<br />
polarization x # = x, y, z<br />
frequency 0.12 # frequency of laser pulse in au (e.g., 0.12 au = 3.27 eV)<br />
center 200.0 # center of Hann envelope (in au time)<br />
width 50.0 # width of Hann pulse (in au time)<br />
max 0.0001 # maximum value of electric field<br />
spin total # = alpha, beta, total (only valid for open-shell)<br />
end<br />
<br />
field "resonant"<br />
type cw # monochromatic continuous wave<br />
frequency 0.12 # frequency of laser pulse in au (e.g., 0.12 au = 3.27 eV)<br />
polarization x # = x, y, z<br />
max 0.0001 # maximum value of electric field<br />
spin total # = alpha, beta, total (only valid for open-shell)<br />
end<br />
<br />
=== EXCITE -- Excitation rules ===<br />
This sets the rules for applying external fields to the system. It takes the form "excite <geom> with <field>", where <geom> is the name of a geometry fragment (defaults to "geometry" which is the default geometry name), and <field> is the name of a [[Release66:RT-TDDFT#FIELD -- Sub-block for specifying external electric fields|field structure]]. Assuming, for example, you have defined a field name "kick" this option takes the form (note that quotes are optional and shown for clarity):<br />
rt_tddft<br />
...<br />
excite "geometry" with "kick"<br />
...<br />
end<br />
<br />
=== VISUALIZATION -- Sub-block for controlling 3D visualization ===<br />
This block is used to control visualization of the electronic charge density, which is typically used during a resonant excitation. This is a two stage process. During the propagation, a series of density matrices will be dumped to file (see options below). After propagation, if the "dplot" option is set, the code will read in options from a separate DPLOT block and convert the density matrix snapshots to a corresponding series of real-space charge density "cube" files.<br />
<br />
visualization<br />
tstart 0.0 # start visualization at this time<br />
tend 100.0 # stop visualization at this time<br />
treference 0.0 # subtract density matrix at this time (useful for difference densities)<br />
dplot # post-process density matrices into cube files after propagation<br />
end<br />
<br />
== Worked Examples ==<br />
=== Absorption spectrum of water ===<br />
Here, we compute the 6-31G/TD-PBE0 absorption spectrum of gas-phase water using RT-TDDFT. In the weak-field limit, these results are essentially identical to those obtained via traditional linear-response TDDFT. Although it involves significantly more work do use RT-TDDFT in this case, for very large systems with many roots a real-time approach becomes advantageous computationally and also does not suffer from algorithm stability issues.<br />
<br />
To compute the absorption, we find the ground state of the system and then subject it to three delta-function excitations (x,y,z), which simultaneously excites all electronic modes of that polarization. The three resulting dipole moments are then Fourier transformed to give the frequency-dependent linear polarizabilty, and thus the absorption spectrum. The full input deck is [[media:RT_TDDFT_h2o_abs.nw]] and the corresponding output is [[media:RT_TDDFT_h2o_abs.nwo.gz]].<br />
<br />
title "Water TD-PBE0 absorption spectrum"<br />
echo<br />
scratch_dir ./scratch<br />
permanent_dir ./perm<br />
<br />
start water<br />
<br />
## <br />
## aug-cc-pvtz / pbe0 optimized <br />
## <br />
## Note: you are required to explicitly name the geometry <br />
## <br />
geometry "system" units angstroms nocenter noautoz noautosym<br />
O 0.00000000 -0.00001441 -0.34824012<br />
H -0.00000000 0.76001092 -0.93285191<br />
H 0.00000000 -0.75999650 -0.93290797<br />
end<br />
<br />
## Note: We need to explicitly set the "active" geometry even though there is only one geom. <br />
set geometry "system"<br />
<br />
## All DFT and basis parameters are inherited by the RT-TDDFT code <br />
basis<br />
* library 6-31G<br />
end<br />
<br />
dft<br />
xc pbe0<br />
end<br />
<br />
## Compute ground state of the system <br />
task dft energy<br />
<br />
## <br />
## Now, we compute an x, y, and z kick simulation, which we give separate "tags" for post-processing. <br />
## <br />
<br />
unset rt_tddft:*<br />
rt_tddft<br />
tmax 200.0<br />
dt 0.2<br />
<br />
tag "kick_x"<br />
<br />
field "kick"<br />
type delta<br />
polarization x<br />
max 0.0001<br />
end<br />
<br />
excite "system" with "kick"<br />
end<br />
task dft rt_tddft<br />
<br />
unset rt_tddft:*<br />
rt_tddft<br />
tmax 200.0<br />
dt 0.2<br />
<br />
tag "kick_y"<br />
<br />
field "kick"<br />
type delta<br />
polarization y<br />
max 0.0001<br />
end<br />
<br />
excite "system" with "kick"<br />
end<br />
task dft rt_tddft<br />
<br />
unset rt_tddft:*<br />
rt_tddft<br />
tmax 200.0<br />
dt 0.2<br />
<br />
tag "kick_z"<br />
<br />
field "kick"<br />
type delta<br />
polarization z<br />
max 0.0001<br />
end<br />
<br />
excite "system" with "kick"<br />
end<br />
task dft rt_tddft<br />
<br />
After running the simulation, we extract the x-dipole moment for the x-kick and similarly for the y and z-kicks (see "contrib/parsers" directory for this script or download here: [[media:RT_TDDFT_scripts.tgz]] ).<br />
<br />
nw_rtparse.py -xdipole -px -tkick_x h2o_abs.nwo > x.dat<br />
nw_rtparse.py -xdipole -py -tkick_y h2o_abs.nwo > y.dat<br />
nw_rtparse.py -xdipole -pz -tkick_z h2o_abs.nwo > z.dat<br />
<br />
Note, the syntax for extracting the x polarization for the x-kick, etc. Alternatively, we could grep and cut, or whatnot. This will give use the resulting time-dependent dipole moments:<br />
<br />
[[File:RT_TDDFT_h2o_td_dipoles.png|center|900px|Time-dependent dipole moments]]<br />
<br />
Now, we need to take the Fourier transforms of these dipole moments to yield the the x,x element of the 3x3 linear polarizability tensor, and similarly for the y,y and z,z elements. Here I am using an FFT utility, although any discrete Fourier transform will do. To accelerate convergence of the FFT, I have damped the time signals by <math>\exp(-t / \tau)</math> which results in Lorentzians with FWHM of <math>2 / \tau </math> and have also "zero padded" the data with 50000 points. This is not critical for extracting frequencies, but creates "cleaner" spectra, although care must be taken to damp sufficiently if padding to avoid artifacts (see small ripples around 23 eV in plot below). After Fourier transform, I "paste" the three files together to easily plot the absorption, which is constructed from the trace of the polarizability matrix, i.e., the sum of the imaginary parts of the FFTs of the dipole moments.<br />
<br />
<math> S (\omega) = \frac{4 \pi \omega}{3 c \kappa} \mathrm{Tr} [ \mathrm{Im} \alpha(\omega) ] </math> ,<br />
<br />
where <math>c</math> is the speed of light (137 in atomic units), <math>\kappa</math> is the kick electric field strength, and <math>\alpha(\omega)</math> is the linear polarizabilty tensor computed from the Fourier transforms of the time-dependent dipole moments. For example,<br />
<br />
fft1d -d50 -z -p50000 < x.dat | rotate_fft > xw.dat<br />
fft1d -d50 -z -p50000 < y.dat | rotate_fft > yw.dat<br />
fft1d -d50 -z -p50000 < z.dat | rotate_fft > zw.dat<br />
paste xw.dat yw.dat zw.day > s.dat<br />
<br />
Here, you can just use your favorite Fourier transform utility or analysis software, but for convenience there is also a simple GNU Octave fft1d.m utility in the "contrib/parsers" directory of the trunk or download here: [[media:RT_TDDFT_scripts.tgz]] Note, options are hardcoded at the moment, so the switches above are not correct instead edit the file and run (also it reads file rather than redirect from stdin). Assuming the FFT output takes the form (w, Re, Im, Abs), to plot using gnuplot we would do:<br />
<br />
gnuplot> plot "s.dat" u ($1*27.2114):($1*($3+$7+$11))<br />
<br />
where we have scaled by 27.2114 to output in eV instead of atomic units, and we have not properly scaled to get the absolute oscillator strengths (thus our magnitudes are in "arbitrary units"). The real-time spectrum is shown below, along with the corresponding linear-response TDDFT excitations are shown in orange for comparison. Since we are in the weak field regime, the two are identical. Note the oscillator strengths are arbitrary and scaled, if not scaled the area under each RT-TDDFT curve should integrate to the linear response oscillator strength. <br />
<br />
[[File:RT_TDDFT_h2o_abs_spectrum.png|center|400px|Linear absorption spectrum]]<br />
<br />
=== Resonant ultraviolet excitation of water ===<br />
In this example we compute the time-dependent electron response to a quasi-monochromatic laser pulse tuned to a particular transition. We will use the results of the previous example (6-31G/PBE0 gas-phase water). First, we consider the absorption spectrum (computed previously) but plotted for the three polarizations (x,y,z) rather then as a sum. Say we are interested in the excitation near 10 eV. We can clearly see this is a z-polarized transition (green on curve). To selectively excite this we could use a continuous wave E-field, which has a delta-function, i.e., single frequency, bandwidth but since we are doing finite simulations we need a suitable envelope. The broader the envelope in time the narrower the excitation in frequency domain, but of course long simulations become costly so we need to put some thought into the choice of our envelope. In this case the peak of interest is spectrally isolated from other z-polarized peaks, so this is quite straightforward. The procedure is outlined below, and the corresponding frequency extent of the pulse is shown on the absorption figure in orange. Note that it only covers one excitation, i.e., the field selectively excites one mode. The full input deck is [[media:RT_TDDFT_h2o_resonant.nw]] and the output is [[media:RT_TDDFT_h2o_resonant.nwo.gz]].<br />
<br />
[[File:RT_TDDFT_h2o_resonant_spec_field.png|center|400px|Absorption spectrum and excitation bandwidth]]<br />
<br />
title "Water TD-PBE0 resonant excitation" <br />
echo<br />
scratch_dir ./scratch<br />
permanent_dir ./perm<br />
<br />
start water<br />
<br />
##<br />
## aug-cc-pvtz / pbe0 optimized<br />
##<br />
## Note: you are required to explicitly name the geometry<br />
##<br />
geometry "system" units angstroms nocenter noautoz noautosym<br />
O 0.00000000 -0.00001441 -0.34824012<br />
H -0.00000000 0.76001092 -0.93285191<br />
H 0.00000000 -0.75999650 -0.93290797<br />
end<br />
<br />
## Note: We need to explicitly set the "active" geometry even though there is only one geom.<br />
set geometry "system" <br />
<br />
## All DFT and basis parameters are inherited by the RT-TDDFT code<br />
basis<br />
* library 6-31G<br />
end<br />
<br />
dft<br />
xc pbe0<br />
end<br />
<br />
## Compute ground state of the system<br />
task dft energy<br />
<br />
##<br />
## We excite the system with a quasi-monochromatic<br />
## (Gaussian-enveloped) z-polarized E-field tuned to a transition at<br />
## 10.25 eV. The envelope takes the form:<br />
##<br />
## G(t) = exp(-(t-t0)^ / 2s^2)<br />
##<br />
## The target excitation has an energy (frequency) of w = 0.3768 au<br />
## and thus an oscillation period of T = 2 pi / w = 16.68 au<br />
##<br />
## Since we are doing a Gaussian envelope in time, we will get a<br />
## Gaussian envelope in frequency (Gaussians are eigenfunctions of a<br />
## Fourier transform), with width equal to the inverse of the width in<br />
## time. Say, we want a Gaussian in frequency with FWHM = 1 eV<br />
## (recall FWHM = 2 sqrt (2ln2) s_freq) we want an s_freq = 0.42 eV =<br />
## 0.0154 au, thus in time we need s_time = 1 / s_time = 64.8 au.<br />
##<br />
## Now we want the envelope to be effectively zero at t=0, say 1e-8<br />
## (otherwise we get "windowing" effects). Reordering G(t):<br />
##<br />
## t0 = t - sqrt(-2 s^2 ln G(t))<br />
##<br />
## That means our Gaussian needs to be centered at t0 = 393.3 au.<br />
##<br />
## The total simulation time will be 1000 au to leave lots of time to<br />
## see oscillations after the field has passed.<br />
##<br />
rt_tddft<br />
tmax 1000.0<br />
dt 0.2<br />
<br />
field "driver"<br />
type gaussian<br />
polarization z<br />
frequency 0.3768 # = 10.25 eV<br />
center 393.3<br />
width 64.8<br />
max 0.0001<br />
end<br />
<br />
excite "system" with "driver"<br />
end<br />
task dft rt_tddft<br />
<br />
[[File:RT_TDDFT_h2o_resonant_td.png|center|450px|Time dependent electric field and dipole moment during resonant excitation]]<br />
<br />
From the time-dependent dipole moment you can see the field driving the system into a superposition of the ground state and the one excited state, which manifests as monochromatic oscillations. After the field has passed the dipole oscillations continue forever as there is no damping in the system.<br />
<br />
=== Charge transfer between a TCNE dimer ===<br />
Here we compute the time-dependent charge oscillations between a TCNE (tetracyanoethylene) dimer separated by 3 Angstroms, where the top molecule starts neutral and the bottom one starts with a -1 charge. This somewhat non-physical starting point will lead to far-from-equilibrium dynamics as the charge violently sloshes between the two molecules, with the oscillation period a function of the molecular separation. The trick here is to use fragments by have multiple geometries in the input deck, where each fragment is converged separately, then assembled together without SCF to use as a starting point. We use a small but diffuse basis and a range-separated functional (CAM-B3LYP). The input deck is [[media:RT_TDDFT_tcne_dimer.nw]] and the full output is [[media:RT_TDDFT_tcne_dimer.nwo.gz]].<br />
<br />
title "Tetracyanoethylene dimer charge transfer"<br />
<br />
echo<br />
scratch_dir ./scratch<br />
permanent_dir ./perm<br />
<br />
start tcne<br />
echo<br />
<br />
##<br />
## Each fragment optimized with cc-pvdz/B3LYP<br />
##<br />
geometry "bottom" units angstroms noautosym nocenter noautoz<br />
C -1.77576486 0.66496556 0.00004199<br />
N -2.94676621 0.71379797 0.00004388<br />
C -0.36046718 0.62491168 0.00003506<br />
C 0.36049301 -0.62492429 -0.00004895<br />
C 1.77579907 -0.66504145 -0.00006082<br />
N 2.94680364 -0.71382258 -0.00006592<br />
C -0.31262746 -1.87038951 -0.00011201<br />
N -0.85519492 -2.90926164 -0.00016331<br />
C 0.31276207 1.87031662 0.00010870<br />
N 0.85498782 2.90938919 0.00016857<br />
end<br />
<br />
geometry "top" units angstroms noautosym nocenter noautoz<br />
C -1.77576486 0.66496556 3.00004199<br />
N -2.94676621 0.71379797 3.00004388<br />
C -0.36046718 0.62491168 3.00003506<br />
C 0.36049301 -0.62492429 2.99995105<br />
C 1.77579907 -0.66504145 2.99993918<br />
N 2.94680364 -0.71382258 2.99993408<br />
C -0.31262746 -1.87038951 2.99988799<br />
N -0.85519492 -2.90926164 2.99983669<br />
C 0.31276207 1.87031662 3.00010870<br />
N 0.85498782 2.90938919 3.00016857<br />
end<br />
<br />
<br />
## dimer geometry is the union of bottom and top geometry<br />
geometry "dimer" units angstroms noautosym nocenter noautoz<br />
C -1.77576486 0.66496556 0.00004199<br />
N -2.94676621 0.71379797 0.00004388<br />
C -0.36046718 0.62491168 0.00003506<br />
C 0.36049301 -0.62492429 -0.00004895<br />
C 1.77579907 -0.66504145 -0.00006082<br />
N 2.94680364 -0.71382258 -0.00006592<br />
C -0.31262746 -1.87038951 -0.00011201<br />
N -0.85519492 -2.90926164 -0.00016331<br />
C 0.31276207 1.87031662 0.00010870<br />
N 0.85498782 2.90938919 0.00016857<br />
#---<br />
C -1.77576486 0.66496556 3.00004199<br />
N -2.94676621 0.71379797 3.00004388<br />
C -0.36046718 0.62491168 3.00003506<br />
C 0.36049301 -0.62492429 2.99995105<br />
C 1.77579907 -0.66504145 2.99993918<br />
N 2.94680364 -0.71382258 2.99993408<br />
C -0.31262746 -1.87038951 2.99988799<br />
N -0.85519492 -2.90926164 2.99983669<br />
C 0.31276207 1.87031662 3.00010870<br />
N 0.85498782 2.90938919 3.00016857<br />
end<br />
<br />
<br />
##<br />
## C, N: 3-21++G<br />
##<br />
basis spherical<br />
C S<br />
172.2560000 0.0617669 <br />
25.9109000 0.3587940 <br />
5.5333500 0.7007130 <br />
C SP<br />
3.6649800 -0.3958970 0.2364600 <br />
0.7705450 1.2158400 0.8606190 <br />
C SP<br />
0.1958570 1.0000000 1.0000000 <br />
C SP<br />
0.0438000 1.0000000 1.0000000 <br />
N S<br />
242.7660000 0.0598657 <br />
36.4851000 0.3529550 <br />
7.8144900 0.7065130 <br />
N SP<br />
5.4252200 -0.4133010 0.2379720 <br />
1.1491500 1.2244200 0.8589530 <br />
N SP<br />
0.2832050 1.0000000 1.0000000 <br />
N SP<br />
0.0639000 1.0000000 1.0000000 <br />
end<br />
<br />
<br />
##<br />
## Charge density fitting basis.<br />
##<br />
basis "cd basis"<br />
C S<br />
5.91553927E+02 0.31582020<br />
1.72117940E+02 0.87503863<br />
5.47992590E+01 2.30760524<br />
C S<br />
1.89590940E+01 1.0000000<br />
C S<br />
7.05993000E+00 1.0000000<br />
C S<br />
2.79484900E+00 1.0000000<br />
C S<br />
1.15863400E+00 1.0000000<br />
C S<br />
4.94324000E-01 1.0000000<br />
C S<br />
2.12969000E-01 1.0000000<br />
C P<br />
3.27847358E-01 1.0000000<br />
C P<br />
7.86833659E-01 1.0000000<br />
C P<br />
1.97101832E+00 1.0000000<br />
C D<br />
4.01330100E+00 1.0000000<br />
C D<br />
1.24750500E+00 1.0000000<br />
C D<br />
4.08148000E-01 1.0000000<br />
C F<br />
9.00000000E-01 1.0000000<br />
N S<br />
7.91076935E+02 0.41567506<br />
2.29450184E+02 1.14750694<br />
7.28869600E+01 3.01935767<br />
N S<br />
2.51815960E+01 1.0000000<br />
N S<br />
9.37169700E+00 1.0000000<br />
N S<br />
3.71065500E+00 1.0000000<br />
N S<br />
1.53946300E+00 1.0000000<br />
N S<br />
6.57553000E-01 1.0000000<br />
N S<br />
2.83654000E-01 1.0000000<br />
N P<br />
4.70739194E-01 1.0000000<br />
N P<br />
1.12977407E+00 1.0000000<br />
N P<br />
2.83008403E+00 1.0000000<br />
N D<br />
5.83298650E+00 1.0000000<br />
N D<br />
1.73268650E+00 1.0000000<br />
N D<br />
5.45242500E-01 1.0000000<br />
N F<br />
1.82648000E+00 1.0000000<br />
end<br />
<br />
<br />
##<br />
## Universal DFT parameters. Note, we are doing open-shell even for<br />
## the neutral fragment so the movecs have the correct size. <br />
##<br />
## We are using the CAM-B3LYP functional (no need to use "direct"<br />
## since we are doing CD fitting).<br />
##<br />
dft<br />
xc xcamb88 1.00 lyp 0.81 vwn_5 0.19 hfexch 1.00<br />
cam 0.33 cam_alpha 0.19 cam_beta 0.46<br />
odft<br />
convergence density 1d-9<br />
grid fine<br />
maxiter 1000<br />
end<br />
<br />
<br />
##<br />
## Converge bottom fragment with extra electron and top fragment as<br />
## neutral.<br />
##<br />
charge -1<br />
set geometry "bottom"<br />
dft<br />
mult 2<br />
vectors input atomic output "bottom.movecs"<br />
end<br />
task dft energy<br />
<br />
charge 0<br />
set geometry "top"<br />
dft<br />
mult 1<br />
vectors input atomic output "top.movecs"<br />
end<br />
task dft energy<br />
<br />
<br />
##<br />
## Assemble the two fragments but don't do SCF--this keeps the system<br />
## in a far-from-equilibrium state from which we will watch the<br />
## dynamics.<br />
##<br />
charge -1<br />
set geometry "dimer"<br />
dft<br />
mult 2<br />
vectors input fragment "bottom.movecs" "top.movecs" output "dimer.movecs"<br />
noscf<br />
end<br />
task dft energy<br />
<br />
<br />
##<br />
## Now do RT-TDDFT from this crazy state without any electric fields.<br />
##<br />
rt_tddft<br />
tmax 500.0<br />
dt 0.2<br />
load vectors "dimer.movecs"<br />
<br />
print dipole field energy s2 charge<br />
end<br />
task dft rt_tddft<br />
<br />
[[File:RT_TDDFT_tcne_td_charge.png|center|600px|Time dependent charge oscillation between a TCNE dimer]]<br />
<br />
The time-dependent charge shows that the excess electron starts on the "bottom" molecule (i.e., a total electronic charge of -65), then swings to completely occupy the "top" molecule then oscillates back and forth. The frequency of this oscillation is dependent on the separation, with larger separations leading to lower frequencies. It is important to note, however, this starting point is highly non-physical, specifically converging the two fragments together and "gluing" them together introduces an indeterminate amount of energy to the system, but this simulation shows how charge dynamics simulations can be done.</div>Berthttp://www.nwchem-sw.org/index.php/Release66:Quantum_Mechanical_MethodsRelease66:Quantum Mechanical Methods2013-06-21T17:31:32Z<p>Bert: 1 revision</p>
<hr />
<div>__NOTITLE__<br />
*[[Release66:Hartree-Fock Theory for Molecules|Hartree-Fock (HF) Theory]]<br />
<br />
*[[Release66:Density Functional Theory for Molecules|Density Functional Theory (DFT)]]<br />
<br />
*[[Release66:Excited-State_Calculations|Excited-State Calculations (CIS, TDHF, TDDFT)]]<br />
<br />
*[[Release66:RT-TDDFT|Real-time TDDFT]]<br />
<br />
*[[Release66:Plane-Wave Density Functional Theory|Plane-Wave Density Functional Theory (plane-wave DFT)]]<br />
<br />
*[[Release66:TCE|Tensor Contraction Engine: CI, MBPT, and CC]]<br />
<br />
*[[Release66:MP2|MP2]]<br />
<br />
*[[Release66:CCSD|Coupled Cluster Calculations]]<br />
<br />
*[[Release66:Multiconfiguration SCF|Multiconfiguration SCF]]<br />
<br />
*[[Release66:SELCI|Selected CI]]</div>Berthttp://www.nwchem-sw.org/index.php/Release66:Qmmm_xyzRelease66:Qmmm xyz2013-06-21T17:31:32Z<p>Bert: 1 revision</p>
<hr />
<div>__NOTITLE__<br />
xyz [filename1] [filename2] [filename3]<br />
<br />
This directive triggers generation for numbered xyz files during QM/MM optimization. Files are saved into the permanent directory in the following form <br />
system_nnn_kkk.xyz<br />
where nnn is a optimization cycle number and kkk is the iteration counter. No xyz output will be performed for solvent region.</div>Berthttp://www.nwchem-sw.org/index.php/Release66:Qmmm_sp_propertyRelease66:Qmmm sp property2013-06-21T17:31:32Z<p>Bert: 1 revision</p>
<hr />
<div>__NOTITLE__<br />
{{Template:Release66:QMMM_Single_Point_Calculations}}<br />
A number of electronic structure properties can be calculated with QM/MM using capabilities provided by [[Release66:Properties|property]], [[Release66:ESP|esp]], and [[Release66:DPLOT|dplot modules]].<br />
<br />
{{:Release66:qmmm_example5}}<br />
<br />
===[[Release66:qmmm_example6|<small>Example QM/MM ESP Calculation:</small>]]===<br />
;Example QM/MM ESP Calculation:<br />
{{:Release66:qmmm_example6}}</div>Berthttp://www.nwchem-sw.org/index.php/Release65:RT-TDDFTRelease65:RT-TDDFT2013-06-21T17:31:32Z<p>Bert: 1 revision</p>
<hr />
<div>__NOTITLE__<br />
= Real-time TDDFT =<br />
== Overview ==<br />
Real-time time-dependent density functional theory (RT-TDDFT) is a DFT-based approach to electronic excited states based on integrating the time-dependent Kohn-Sham (TDKS) equations in time. The theoretical underpinnings, strengths, and limitations are similar to traditional linear-response (LR) [[Excited-State_Calculations|TDDFT]] methods, but instead of a frequency domain solution to the TDKS equations, RT-TDDFT yields a full time-resolved, potentially non-linear solution. Real-time simulations can be used to compute not only spectroscopic properties (e.g., absorption spectra, polarizabilites, etc), but also the time and space-resolved electronic response to arbitrary external stimuli (e.g., electron charge dynamics after laser excitation). For theoretical and computational details, please refer to the following paper:<br />
<br />
#K. Lopata, N. Govind,"Modeling Fast Electron Dynamics with Real-Time Time-Dependent Density Functional Theory: Application to Small Molecules and Chromophores", J. Chem. Theory Comput., 7, 1344 (2011) <br />
<br />
This functionality is built on the [[Density Functional Theory for Molecules|Gaussian basis set DFT]] module, and will work for closed-shell (spin-restricted) and open-shell (spin unrestricted) calculations with essentially any combination of basis set and exchange-correlation functional in NWChem. The current implementation assumes frozen nuclei (Born-Oppenheimer approximation).<br />
<br />
In a nutshell, running a RT-TDDFT calculation takes the following form:<br />
#Compute ground state density matrix with DFT module<br />
#Propagate density matrix using RT-TDDFT<br />
#Post-process resulting time-dependent observables (e.g., dipole moment)<br />
<br />
== Units ==<br />
Unless specified otherwise, all inputs and outputs are in '''atomic units'''. Some useful conversions are:<br />
<table border="1"><br />
<tr><th> Quantity </th><th> Conversion </th></tr><br />
<tr><td> Time </td><td> 1 au = 0.02419 fs </td></tr><br />
<tr><td> Length </td><td> 1 au = 0.5292 A </td></tr><br />
<tr><td> Energy </td><td> 1 au = 27.2114 eV </td></tr><br />
<tr><td> Electric field </td><td> 1 au = 514.2 V/nm </td></tr><br />
<tr><td> Dipole moment </td><td> 1 au = 2.542 D </td></tr><br />
</table><br />
<br />
== Syntax ==<br />
The [[Charge|charge]], [[Geometry|geometry]], [[Basis|basis set]], and [[Density Functional Theory for Molecules|DFT]] options are all specified as normal, using their respective syntax. Real-time TDDFT parameters are supplied in the RT_TDDFT block (note, nothing is case-sensitive), with all possible options summarized below, and each discussed in detail afterwards.<br />
<br />
RT_TDDFT<br />
[TMAX <double default 1000>]<br />
[DT <double default 0.1>]<br />
[TAG <string default "<rt_tddft>: "]<br />
[LOAD (scf || vectors <string>)]<br />
[NCHECKS <integer default 10>]<br />
[NPRINTS (* || <integer>)]<br />
[NRESTARTS (* || <integer>)]<br />
[TOLERANCES (zero <double default 1e-8> || series <double default 1e-10> || interpol <double default 1e-7>)]<br />
[PROPAGATOR (euler || rk4 || magnus) default magnus]<br />
[EXP (diag || pseries)]<br />
[PROF]<br />
[NOPROP]<br />
[STATIC]<br />
[PRINT (*, dipole, quadrupole, field, moocc, field, energy, cputime, charge, convergence, s2)]<br />
[EXCITE <string geomname> with <string fieldname>]<br />
[FIELD]<br />
...<br />
[END]<br />
[VISUALIZATION]<br />
...<br />
[END]<br />
END<br />
<br />
=== TMAX -- Simulation time ===<br />
This option specifies the maximum time (in au) to run the simulation before stopping, which must be a positive real number. In practice, you can just stop the simulation early, so in most cases it is simplest to just set this to a large value to ensure you capture all the important dynamics (see [[Release64:RT-TDDFT#Hints and Tricks|Hints and Tricks]]). For most valence excitations, for example, 1000 au is overkill so you might want to automatically stop at 500 au: <br />
rt_tddft<br />
...<br />
tmax 500.0<br />
...<br />
end<br />
<br />
=== DT -- Time step ===<br />
This specifies the electronic time step for time integration. A larger time step results in a faster simulation, but there are two issues which limit the size of the time step. First, the integration algorithm can become unstable and/or inaccurate for larger time steps, which depends on the integrator used. Very roughly speaking, the second order Magnus integrator should be reliable for time steps up to 0.2 au. Second, you must choose a time step small enough to capture the oscillations of interest, i.e., to resolve an excitation of energy <math>\omega</math>, your time step needs to be smaller than <math>\pi / \omega</math>, and typically a tenth of that for accuracy. For example, to capture high energy oscillations such as core-level excitations (e.g., <math>\omega = 50</math> au) you might want a relative small time step:<br />
rt_tddft<br />
...<br />
dt 0.01<br />
...<br />
end<br />
It is always good practice to check that your results are independent of time step.<br />
<br />
=== TAG -- Output label ===<br />
This option sets a label for the output for convenient parsing (e.g., with "grep"). Every output line with time-dependent data will begin with this string (set to "<rt_tddft>: " by default). For example setting:<br />
rt_tddft<br />
...<br />
tag "nameofrun"<br />
...<br />
end<br />
will result in outputs that look like:<br />
...<br />
nameofrun 2.20000 -7.589146713114E+001 # Etot<br />
...<br />
<br />
=== NCHECKS -- Number of run-time check points ===<br />
This option takes an integer number (default 10), or "*" which means every step, which sets the total of number of run-time checkpoints, where various sanity checks are made such as symmetries, idempotency, traces, etc. These checks are not terribly efficient (e.g., involve re-building the TD Fock matrix) so excessive checking will slow down execution.<br />
rt_tddft<br />
...<br />
nchecks 10<br />
...<br />
end<br />
<br />
=== NPRINTS -- Number of print points ===<br />
This sets the number of print points, i.e., the total number of time-dependent observables (e.g., dipole, charge, energy) that are computed and printed. It either takes an integer number or "*" which means every time step (this is the default). Since there is no appreciable cost to computing and printing these quantities, there is usually no need to change this from "*".<br />
rt_tddft<br />
...<br />
nprints *<br />
...<br />
end<br />
<br />
=== NRESTARTS -- Number of restart checkpoints ===<br />
This sets the number of run-time check points where the time-dependent complex density matrix is saved to file, allowing the simulation to be [[Release64:RT-TDDFT#Restarts|restarted]]) from that point. By default this is set to 0. There is no significant computational cost to restart checkpointing, but of course there is some disk I/O cost (which may become somewhat significant for larger systems). For example, in the following example there will be 100 restart points, which corresponds to 1 backup every 100 time steps. <br />
rt_tddft<br />
...<br />
tmax 1000.0<br />
dt 0.1<br />
nrestarts 100<br />
...<br />
end<br />
<br />
=== TOLERANCES -- Controlling numerical tolerances ===<br />
This option controls various numerical tolerances:<br />
* zero: threshold for checks that quantities are zero, e.g., in symmetry checks (default 1e-8)<br />
* series: numerical convergence for series, e.g., matrix exponentiation (default 1e-10)<br />
* interpol: numerical convergence for interpolation, e.g., in Magnus propagator (default 1e-7)<br />
Occasionally it is useful to loosen the interpolation tolerances if the Magnus interpolator requires an excessive amount of steps; usually this will not impact accuracy. For example, this sets the tolerances to their defaults with a looser interpolation tolerance:<br />
rt_tddft<br />
...<br />
tolerances zero 1d-8 series 1d-10 interpol 1e-5<br />
end<br />
<br />
=== PROPAGATOR -- Selecting the integrator method ===<br />
This selects the propagtor (i.e., time integrator) method. Possible choices include "euler" for Euler integration (terrible, you should never use this), "rk4" for 4th order Runge-Kutta, and "magnus" for 2nd order Magnus with self-consistent interpolation. In virtually all cases Magnus is superior in terms of stability. Euler or rk4 are perhaps only useful for debugging or simplicity (e.g., for code development).<br />
rt_tddft<br />
...<br />
propagator magnus<br />
...<br />
end<br />
<br />
=== EXP -- Selecting the matrix exponentiation method ===<br />
This selects the method for exponentiation matrices. For now this can either be "pseries" for a contractive power series or "diag" for diagonalization. In general the power series (default) is faster.<br />
rt_tddft<br />
...<br />
exp diag<br />
...<br />
end<br />
<br />
=== PROF -- Run-time profiling ===<br />
This turns on run-time profiling, which will display time spent in each component of the code (e.g., building components of the TD Fock matrix, properites, etc). This slows code down slightly and results in very verbose output.<br />
rt_tddft<br />
...<br />
prof<br />
...<br />
end<br />
<br />
=== NOPROP -- Skipping propagation ===<br />
This options causes the RT-TDDFT module skip propagation, i.e., to initialize and finalize. For now this is largely useful for skipping to visualization post-processing without having to re-run a simulation.<br />
rt_tddft<br />
...<br />
noprop<br />
...<br />
end<br />
<br />
=== STATIC -- Force static Fock matrix ===<br />
This option sets the static Fock matrix flag, meaning the time-dependent Fock matrix will not be recalculated at each time, but instead use the t=0 value. This will drastically increase the simulation speed since the bulk of the work is spent rebuilding the TD Fock matrix, but will give non-physical results. For example, using "static" to compute an absorption spectrum will result in excitations corresponding to the raw eigenvalue differences without electron-hole relaxation. This option has few uses besides dry-runs and debugging.<br />
rt_tddft<br />
...<br />
static<br />
...<br />
end<br />
<br />
=== PRINT -- Selecting time-dependent quantities to be printed ===<br />
This sets the various time-dependent properties that are to be computed and printed at each print point. Note that for many of these options, the values are computed and printed for each geometry specified in the input deck, not only the active one (i.e., the one set using "set geometry ..." in the input deck). Possible choices are:<br />
* dipole: Dipole moment<br />
* quadrupole: Quadrupole moment<br />
* field: External (applied) electric field<br />
* moocc: Molecular orbital occupations<br />
* energy: Components of system energy (e.g., core, XC, total, etc)<br />
* cputime: CPU time taken in simulation so far (useful for checking scaling)<br />
* charge: Electronic charge (computed from density matrix, not from the XC grid)<br />
* convergence: Convergence information (e.g., from Magnus)<br />
* s2: <S2> value (openshell only)<br />
* *: Print all quantities<br />
The defaults correspond to:<br />
rt_tddft<br />
...<br />
print dipole field energy convergence<br />
...<br />
end<br />
<br />
=== FIELD -- Sub-block for specifying external electric fields ===<br />
This sub-block is used to specify external electric fields, each of which must be given a unique name. Numerous fields can be specified, but each will applied to the system only if an appropriate [[Release64:RT-TDDFT#EXCITE -- Excitation rules|excitation rule]] is set. There are a few preset field types; others would have to be manually coded. Note the names are arbitrary, but chosen here to be descriptive:<br />
<br />
field "kick"<br />
type delta # E(t=0) = max; E(t>0) = 0<br />
polarization x # = x, y, z<br />
max 0.0001 # maximum value of electric field<br />
spin total # = alpha, beta, total (only valid for open-shell)<br />
end<br />
<br />
field "gpulse"<br />
type gaussian # Gaussian enveloped quasi-monochromatic pulse: E(t) = exp( -(t-t0)^2 / 2s^2)<br />
polarization x # = x, y, z<br />
frequency 0.12 # frequency of laser pulse in au (e.g., 0.12 au = 3.27 eV)<br />
center 200.0 # center of Gaussian envelope (in au time)<br />
width 50.0 # width of Gaussian pulse (in au time)<br />
max 0.0001 # maximum value of electric field<br />
spin total # = alpha, beta, total (only valid for open-shell)<br />
end<br />
<br />
field "hpulse"<br />
type hann # sin^2 (Hann) enveloped quasi-monochromatic pulse<br />
polarization x # = x, y, z<br />
frequency 0.12 # frequency of laser pulse in au (e.g., 0.12 au = 3.27 eV)<br />
center 200.0 # center of Hann envelope (in au time)<br />
width 50.0 # width of Hann pulse (in au time)<br />
max 0.0001 # maximum value of electric field<br />
spin total # = alpha, beta, total (only valid for open-shell)<br />
end<br />
<br />
field "resonant"<br />
type cw # monochromatic continuous wave<br />
frequency 0.12 # frequency of laser pulse in au (e.g., 0.12 au = 3.27 eV)<br />
polarization x # = x, y, z<br />
max 0.0001 # maximum value of electric field<br />
spin total # = alpha, beta, total (only valid for open-shell)<br />
end<br />
<br />
=== EXCITE -- Excitation rules ===<br />
This sets the rules for applying external fields to the system. It takes the form "excite <geom> with <field>", where <geom> is the name of a geometry fragment (defaults to "geometry" which is the default geometry name), and <field> is the name of a [[Release64:RT-TDDFT#FIELD -- Sub-block for specifying external electric fields|field structure]]. Assuming, for example, you have defined a field name "kick" this option takes the form (note that quotes are optional and shown for clarity):<br />
rt_tddft<br />
...<br />
excite "geometry" with "kick"<br />
...<br />
end<br />
<br />
=== VISUALIZATION -- Sub-block for controlling 3D visualization ===<br />
This block is used to control visualization of the electronic charge density, which is typically used during a resonant excitation. This is a two stage process. During the propagation, a series of density matrices will be dumped to file (see options below). After propagation, if the "dplot" option is set, the code will read in options from a separate DPLOT block and convert the density matrix snapshots to a corresponding series of real-space charge density "cube" files.<br />
<br />
visualization<br />
tstart 0.0 # start visualization at this time<br />
tend 100.0 # stop visualization at this time<br />
treference 0.0 # subtract density matrix at this time (useful for difference densities)<br />
dplot # post-process density matrices into cube files after propagation<br />
end<br />
<br />
== Worked Examples ==<br />
=== Absorption spectrum of water ===<br />
Here, we compute the 6-31G/TD-PBE0 absorption spectrum of gas-phase water using RT-TDDFT. In the weak-field limit, these results are essentially identical to those obtained via traditional linear-response TDDFT. Although it involves significantly more work do use RT-TDDFT in this case, for very large systems with many roots a real-time approach becomes advantageous computationally and also does not suffer from algorithm stability issues.<br />
<br />
To compute the absorption, we find the ground state of the system and then subject it to three delta-function excitations (x,y,z), which simultaneously excites all electronic modes of that polarization. The three resulting dipole moments are then Fourier transformed to give the frequency-dependent linear polarizabilty, and thus the absorption spectrum. The full input deck is [[media:RT_TDDFT_h2o_abs.nw]] and the corresponding output is [[media:RT_TDDFT_h2o_abs.nwo.gz]].<br />
<br />
title "Water TD-PBE0 absorption spectrum"<br />
echo<br />
scratch_dir ./scratch<br />
permanent_dir ./perm<br />
<br />
start water<br />
<br />
## <br />
## aug-cc-pvtz / pbe0 optimized <br />
## <br />
## Note: you are required to explicitly name the geometry <br />
## <br />
geometry "system" units angstroms nocenter noautoz noautosym<br />
O 0.00000000 -0.00001441 -0.34824012<br />
H -0.00000000 0.76001092 -0.93285191<br />
H 0.00000000 -0.75999650 -0.93290797<br />
end<br />
<br />
## Note: We need to explicitly set the "active" geometry even though there is only one geom. <br />
set geometry "system"<br />
<br />
## All DFT and basis parameters are inherited by the RT-TDDFT code <br />
basis<br />
* library 6-31G<br />
end<br />
<br />
dft<br />
xc pbe0<br />
end<br />
<br />
## Compute ground state of the system <br />
task dft energy<br />
<br />
## <br />
## Now, we compute an x, y, and z kick simulation, which we give separate "tags" for post-processing. <br />
## <br />
<br />
unset rt_tddft:*<br />
rt_tddft<br />
tmax 200.0<br />
dt 0.2<br />
<br />
tag "kick_x"<br />
<br />
field "kick"<br />
type delta<br />
polarization x<br />
max 0.0001<br />
end<br />
<br />
excite "system" with "kick"<br />
end<br />
task dft rt_tddft<br />
<br />
unset rt_tddft:*<br />
rt_tddft<br />
tmax 200.0<br />
dt 0.2<br />
<br />
tag "kick_y"<br />
<br />
field "kick"<br />
type delta<br />
polarization y<br />
max 0.0001<br />
end<br />
<br />
excite "system" with "kick"<br />
end<br />
task dft rt_tddft<br />
<br />
unset rt_tddft:*<br />
rt_tddft<br />
tmax 200.0<br />
dt 0.2<br />
<br />
tag "kick_z"<br />
<br />
field "kick"<br />
type delta<br />
polarization z<br />
max 0.0001<br />
end<br />
<br />
excite "system" with "kick"<br />
end<br />
task dft rt_tddft<br />
<br />
After running the simulation, we extract the x-dipole moment for the x-kick and similarly for the y and z-kicks (see "contrib/parsers" directory for this script or download here: [[media:RT_TDDFT_scripts.tgz]] ).<br />
<br />
nw_rtparse.py -xdipole -px -tkick_x h2o_abs.nwo > x.dat<br />
nw_rtparse.py -xdipole -py -tkick_y h2o_abs.nwo > y.dat<br />
nw_rtparse.py -xdipole -pz -tkick_z h2o_abs.nwo > z.dat<br />
<br />
Note, the syntax for extracting the x polarization for the x-kick, etc. Alternatively, we could grep and cut, or whatnot. This will give use the resulting time-dependent dipole moments:<br />
<br />
[[File:RT_TDDFT_h2o_td_dipoles.png|center|900px|Time-dependent dipole moments]]<br />
<br />
Now, we need to take the Fourier transforms of these dipole moments to yield the the x,x element of the 3x3 linear polarizability tensor, and similarly for the y,y and z,z elements. Here I am using an FFT utility, although any discrete Fourier transform will do. To accelerate convergence of the FFT, I have damped the time signals by <math>\exp(-t / \tau)</math> which results in Lorentzians with FWHM of <math>2 / \tau </math> and have also "zero padded" the data with 50000 points. This is not critical for extracting frequencies, but creates "cleaner" spectra, although care must be taken to damp sufficiently if padding to avoid artifacts (see small ripples around 23 eV in plot below). After Fourier transform, I "paste" the three files together to easily plot the absorption, which is constructed from the trace of the polarizability matrix, i.e., the sum of the imaginary parts of the FFTs of the dipole moments.<br />
<br />
<math> S (\omega) = \frac{4 \pi \omega}{3 c \kappa} \mathrm{Tr} [ \mathrm{Im} \alpha(\omega) ] </math> ,<br />
<br />
where <math>c</math> is the speed of light (137 in atomic units), <math>\kappa</math> is the kick electric field strength, and <math>\alpha(\omega)</math> is the linear polarizabilty tensor computed from the Fourier transforms of the time-dependent dipole moments. For example,<br />
<br />
fft1d -d50 -z -p50000 < x.dat | rotate_fft > xw.dat<br />
fft1d -d50 -z -p50000 < y.dat | rotate_fft > yw.dat<br />
fft1d -d50 -z -p50000 < z.dat | rotate_fft > zw.dat<br />
paste xw.dat yw.dat zw.day > s.dat<br />
<br />
Here, you can just use your favorite Fourier transform utility or analysis software, but for convenience there is also a simple GNU Octave fft1d.m utility in the "contrib/parsers" directory of the trunk or download here: [[media:RT_TDDFT_scripts.tgz]] Note, options are hardcoded at the moment, so the switches above are not correct instead edit the file and run (also it reads file rather than redirect from stdin). Assuming the FFT output takes the form (w, Re, Im, Abs), to plot using gnuplot we would do:<br />
<br />
gnuplot> plot "s.dat" u ($1*27.2114):($1*($3+$7+$11))<br />
<br />
where we have scaled by 27.2114 to output in eV instead of atomic units, and we have not properly scaled to get the absolute oscillator strengths (thus our magnitudes are in "arbitrary units"). The real-time spectrum is shown below, along with the corresponding linear-response TDDFT excitations are shown in orange for comparison. Since we are in the weak field regime, the two are identical. Note the oscillator strengths are arbitrary and scaled, if not scaled the area under each RT-TDDFT curve should integrate to the linear response oscillator strength. <br />
<br />
[[File:RT_TDDFT_h2o_abs_spectrum.png|center|400px|Linear absorption spectrum]]<br />
<br />
=== Resonant ultraviolet excitation of water ===<br />
In this example we compute the time-dependent electron response to a quasi-monochromatic laser pulse tuned to a particular transition. We will use the results of the previous example (6-31G/PBE0 gas-phase water). First, we consider the absorption spectrum (computed previously) but plotted for the three polarizations (x,y,z) rather then as a sum. Say we are interested in the excitation near 10 eV. We can clearly see this is a z-polarized transition (green on curve). To selectively excite this we could use a continuous wave E-field, which has a delta-function, i.e., single frequency, bandwidth but since we are doing finite simulations we need a suitable envelope. The broader the envelope in time the narrower the excitation in frequency domain, but of course long simulations become costly so we need to put some thought into the choice of our envelope. In this case the peak of interest is spectrally isolated from other z-polarized peaks, so this is quite straightforward. The procedure is outlined below, and the corresponding frequency extent of the pulse is shown on the absorption figure in orange. Note that it only covers one excitation, i.e., the field selectively excites one mode. The full input deck is [[media:RT_TDDFT_h2o_resonant.nw]] and the output is [[media:RT_TDDFT_h2o_resonant.nwo.gz]].<br />
<br />
[[File:RT_TDDFT_h2o_resonant_spec_field.png|center|400px|Absorption spectrum and excitation bandwidth]]<br />
<br />
title "Water TD-PBE0 resonant excitation" <br />
echo<br />
scratch_dir ./scratch<br />
permanent_dir ./perm<br />
<br />
start water<br />
<br />
##<br />
## aug-cc-pvtz / pbe0 optimized<br />
##<br />
## Note: you are required to explicitly name the geometry<br />
##<br />
geometry "system" units angstroms nocenter noautoz noautosym<br />
O 0.00000000 -0.00001441 -0.34824012<br />
H -0.00000000 0.76001092 -0.93285191<br />
H 0.00000000 -0.75999650 -0.93290797<br />
end<br />
<br />
## Note: We need to explicitly set the "active" geometry even though there is only one geom.<br />
set geometry "system" <br />
<br />
## All DFT and basis parameters are inherited by the RT-TDDFT code<br />
basis<br />
* library 6-31G<br />
end<br />
<br />
dft<br />
xc pbe0<br />
end<br />
<br />
## Compute ground state of the system<br />
task dft energy<br />
<br />
##<br />
## We excite the system with a quasi-monochromatic<br />
## (Gaussian-enveloped) z-polarized E-field tuned to a transition at<br />
## 10.25 eV. The envelope takes the form:<br />
##<br />
## G(t) = exp(-(t-t0)^ / 2s^2)<br />
##<br />
## The target excitation has an energy (frequency) of w = 0.3768 au<br />
## and thus an oscillation period of T = 2 pi / w = 16.68 au<br />
##<br />
## Since we are doing a Gaussian envelope in time, we will get a<br />
## Gaussian envelope in frequency (Gaussians are eigenfunctions of a<br />
## Fourier transform), with width equal to the inverse of the width in<br />
## time. Say, we want a Gaussian in frequency with FWHM = 1 eV<br />
## (recall FWHM = 2 sqrt (2ln2) s_freq) we want an s_freq = 0.42 eV =<br />
## 0.0154 au, thus in time we need s_time = 1 / s_time = 64.8 au.<br />
##<br />
## Now we want the envelope to be effectively zero at t=0, say 1e-8<br />
## (otherwise we get "windowing" effects). Reordering G(t):<br />
##<br />
## t0 = t - sqrt(-2 s^2 ln G(t))<br />
##<br />
## That means our Gaussian needs to be centered at t0 = 393.3 au.<br />
##<br />
## The total simulation time will be 1000 au to leave lots of time to<br />
## see oscillations after the field has passed.<br />
##<br />
rt_tddft<br />
tmax 1000.0<br />
dt 0.2<br />
<br />
field "driver"<br />
type gaussian<br />
polarization z<br />
frequency 0.3768 # = 10.25 eV<br />
center 393.3<br />
width 64.8<br />
max 0.0001<br />
end<br />
<br />
excite "system" with "driver"<br />
end<br />
task dft rt_tddft<br />
<br />
[[File:RT_TDDFT_h2o_resonant_td.png|center|450px|Time dependent electric field and dipole moment during resonant excitation]]<br />
<br />
From the time-dependent dipole moment you can see the field driving the system into a superposition of the ground state and the one excited state, which manifests as monochromatic oscillations. After the field has passed the dipole oscillations continue forever as there is no damping in the system.<br />
<br />
=== Charge transfer between a TCNE dimer ===<br />
Here we compute the time-dependent charge oscillations between a TCNE (tetracyanoethylene) dimer separated by 3 Angstroms, where the top molecule starts neutral and the bottom one starts with a -1 charge. This somewhat non-physical starting point will lead to far-from-equilibrium dynamics as the charge violently sloshes between the two molecules, with the oscillation period a function of the molecular separation. The trick here is to use fragments by have multiple geometries in the input deck, where each fragment is converged separately, then assembled together without SCF to use as a starting point. We use a small but diffuse basis and a range-separated functional (CAM-B3LYP). The input deck is [[media:RT_TDDFT_tcne_dimer.nw]] and the full output is [[media:RT_TDDFT_tcne_dimer.nwo.gz]].<br />
<br />
title "Tetracyanoethylene dimer charge transfer"<br />
<br />
echo<br />
scratch_dir ./scratch<br />
permanent_dir ./perm<br />
<br />
start tcne<br />
echo<br />
<br />
##<br />
## Each fragment optimized with cc-pvdz/B3LYP<br />
##<br />
geometry "bottom" units angstroms noautosym nocenter noautoz<br />
C -1.77576486 0.66496556 0.00004199<br />
N -2.94676621 0.71379797 0.00004388<br />
C -0.36046718 0.62491168 0.00003506<br />
C 0.36049301 -0.62492429 -0.00004895<br />
C 1.77579907 -0.66504145 -0.00006082<br />
N 2.94680364 -0.71382258 -0.00006592<br />
C -0.31262746 -1.87038951 -0.00011201<br />
N -0.85519492 -2.90926164 -0.00016331<br />
C 0.31276207 1.87031662 0.00010870<br />
N 0.85498782 2.90938919 0.00016857<br />
end<br />
<br />
geometry "top" units angstroms noautosym nocenter noautoz<br />
C -1.77576486 0.66496556 3.00004199<br />
N -2.94676621 0.71379797 3.00004388<br />
C -0.36046718 0.62491168 3.00003506<br />
C 0.36049301 -0.62492429 2.99995105<br />
C 1.77579907 -0.66504145 2.99993918<br />
N 2.94680364 -0.71382258 2.99993408<br />
C -0.31262746 -1.87038951 2.99988799<br />
N -0.85519492 -2.90926164 2.99983669<br />
C 0.31276207 1.87031662 3.00010870<br />
N 0.85498782 2.90938919 3.00016857<br />
end<br />
<br />
<br />
## dimer geometry is the union of bottom and top geometry<br />
geometry "dimer" units angstroms noautosym nocenter noautoz<br />
C -1.77576486 0.66496556 0.00004199<br />
N -2.94676621 0.71379797 0.00004388<br />
C -0.36046718 0.62491168 0.00003506<br />
C 0.36049301 -0.62492429 -0.00004895<br />
C 1.77579907 -0.66504145 -0.00006082<br />
N 2.94680364 -0.71382258 -0.00006592<br />
C -0.31262746 -1.87038951 -0.00011201<br />
N -0.85519492 -2.90926164 -0.00016331<br />
C 0.31276207 1.87031662 0.00010870<br />
N 0.85498782 2.90938919 0.00016857<br />
#---<br />
C -1.77576486 0.66496556 3.00004199<br />
N -2.94676621 0.71379797 3.00004388<br />
C -0.36046718 0.62491168 3.00003506<br />
C 0.36049301 -0.62492429 2.99995105<br />
C 1.77579907 -0.66504145 2.99993918<br />
N 2.94680364 -0.71382258 2.99993408<br />
C -0.31262746 -1.87038951 2.99988799<br />
N -0.85519492 -2.90926164 2.99983669<br />
C 0.31276207 1.87031662 3.00010870<br />
N 0.85498782 2.90938919 3.00016857<br />
end<br />
<br />
<br />
##<br />
## C, N: 3-21++G<br />
##<br />
basis spherical<br />
C S<br />
172.2560000 0.0617669 <br />
25.9109000 0.3587940 <br />
5.5333500 0.7007130 <br />
C SP<br />
3.6649800 -0.3958970 0.2364600 <br />
0.7705450 1.2158400 0.8606190 <br />
C SP<br />
0.1958570 1.0000000 1.0000000 <br />
C SP<br />
0.0438000 1.0000000 1.0000000 <br />
N S<br />
242.7660000 0.0598657 <br />
36.4851000 0.3529550 <br />
7.8144900 0.7065130 <br />
N SP<br />
5.4252200 -0.4133010 0.2379720 <br />
1.1491500 1.2244200 0.8589530 <br />
N SP<br />
0.2832050 1.0000000 1.0000000 <br />
N SP<br />
0.0639000 1.0000000 1.0000000 <br />
end<br />
<br />
<br />
##<br />
## Charge density fitting basis.<br />
##<br />
basis "cd basis"<br />
C S<br />
5.91553927E+02 0.31582020<br />
1.72117940E+02 0.87503863<br />
5.47992590E+01 2.30760524<br />
C S<br />
1.89590940E+01 1.0000000<br />
C S<br />
7.05993000E+00 1.0000000<br />
C S<br />
2.79484900E+00 1.0000000<br />
C S<br />
1.15863400E+00 1.0000000<br />
C S<br />
4.94324000E-01 1.0000000<br />
C S<br />
2.12969000E-01 1.0000000<br />
C P<br />
3.27847358E-01 1.0000000<br />
C P<br />
7.86833659E-01 1.0000000<br />
C P<br />
1.97101832E+00 1.0000000<br />
C D<br />
4.01330100E+00 1.0000000<br />
C D<br />
1.24750500E+00 1.0000000<br />
C D<br />
4.08148000E-01 1.0000000<br />
C F<br />
9.00000000E-01 1.0000000<br />
N S<br />
7.91076935E+02 0.41567506<br />
2.29450184E+02 1.14750694<br />
7.28869600E+01 3.01935767<br />
N S<br />
2.51815960E+01 1.0000000<br />
N S<br />
9.37169700E+00 1.0000000<br />
N S<br />
3.71065500E+00 1.0000000<br />
N S<br />
1.53946300E+00 1.0000000<br />
N S<br />
6.57553000E-01 1.0000000<br />
N S<br />
2.83654000E-01 1.0000000<br />
N P<br />
4.70739194E-01 1.0000000<br />
N P<br />
1.12977407E+00 1.0000000<br />
N P<br />
2.83008403E+00 1.0000000<br />
N D<br />
5.83298650E+00 1.0000000<br />
N D<br />
1.73268650E+00 1.0000000<br />
N D<br />
5.45242500E-01 1.0000000<br />
N F<br />
1.82648000E+00 1.0000000<br />
end<br />
<br />
<br />
##<br />
## Universal DFT parameters. Note, we are doing open-shell even for<br />
## the neutral fragment so the movecs have the correct size. <br />
##<br />
## We are using the CAM-B3LYP functional (no need to use "direct"<br />
## since we are doing CD fitting).<br />
##<br />
dft<br />
xc xcamb88 1.00 lyp 0.81 vwn_5 0.19 hfexch 1.00<br />
cam 0.33 cam_alpha 0.19 cam_beta 0.46<br />
odft<br />
convergence density 1d-9<br />
grid fine<br />
maxiter 1000<br />
end<br />
<br />
<br />
##<br />
## Converge bottom fragment with extra electron and top fragment as<br />
## neutral.<br />
##<br />
charge -1<br />
set geometry "bottom"<br />
dft<br />
mult 2<br />
vectors input atomic output "bottom.movecs"<br />
end<br />
task dft energy<br />
<br />
charge 0<br />
set geometry "top"<br />
dft<br />
mult 1<br />
vectors input atomic output "top.movecs"<br />
end<br />
task dft energy<br />
<br />
<br />
##<br />
## Assemble the two fragments but don't do SCF--this keeps the system<br />
## in a far-from-equilibrium state from which we will watch the<br />
## dynamics.<br />
##<br />
charge -1<br />
set geometry "dimer"<br />
dft<br />
mult 2<br />
vectors input fragment "bottom.movecs" "top.movecs" output "dimer.movecs"<br />
noscf<br />
end<br />
task dft energy<br />
<br />
<br />
##<br />
## Now do RT-TDDFT from this crazy state without any electric fields.<br />
##<br />
rt_tddft<br />
tmax 500.0<br />
dt 0.2<br />
load vectors "dimer.movecs"<br />
<br />
print dipole field energy s2 charge<br />
end<br />
task dft rt_tddft<br />
<br />
[[File:RT_TDDFT_tcne_td_charge.png|center|600px|Time dependent charge oscillation between a TCNE dimer]]<br />
<br />
The time-dependent charge shows that the excess electron starts on the "bottom" molecule (i.e., a total electronic charge of -65), then swings to completely occupy the "top" molecule then oscillates back and forth. The frequency of this oscillation is dependent on the separation, with larger separations leading to lower frequencies. It is important to note, however, this starting point is highly non-physical, specifically converging the two fragments together and "gluing" them together introduces an indeterminate amount of energy to the system, but this simulation shows how charge dynamics simulations can be done.</div>Berthttp://www.nwchem-sw.org/index.php/Release65:Quantum_Mechanical_MethodsRelease65:Quantum Mechanical Methods2013-06-21T17:31:32Z<p>Bert: 1 revision</p>
<hr />
<div>__NOTITLE__<br />
*[[Release64:Hartree-Fock Theory for Molecules|Hartree-Fock (HF) Theory]]<br />
<br />
*[[Release64:Density Functional Theory for Molecules|Density Functional Theory (DFT)]]<br />
<br />
*[[Release64:Excited-State_Calculations|Excited-State Calculations (CIS, TDHF, TDDFT)]]<br />
<br />
*[[Release64:RT-TDDFT|Real-time TDDFT]]<br />
<br />
*[[Release64:Plane-Wave Density Functional Theory|Plane-Wave Density Functional Theory (plane-wave DFT)]]<br />
<br />
*[[Release64:TCE|Tensor Contraction Engine: CI, MBPT, and CC]]<br />
<br />
*[[Release64:MP2|MP2]]<br />
<br />
*[[Release64:CCSD|Coupled Cluster Calculations]]<br />
<br />
*[[Release64:Multiconfiguration SCF|Multiconfiguration SCF]]<br />
<br />
*[[Release64:SELCI|Selected CI]]</div>Berthttp://www.nwchem-sw.org/index.php/Release64:Qmmm_xyzRelease64:Qmmm xyz2013-06-21T17:31:32Z<p>Bert: 1 revision</p>
<hr />
<div>__NOTITLE__<br />
xyz [filename1] [filename2] [filename3]<br />
<br />
This directive triggers generation for numbered xyz files during QM/MM optimization. Files are saved into the permanent directory in the following form <br />
system_nnn_kkk.xyz<br />
where nnn is a optimization cycle number and kkk is the iteration counter. No xyz output will be performed for solvent region.</div>Berthttp://www.nwchem-sw.org/index.php/Release64:Qmmm_sp_propertyRelease64:Qmmm sp property2013-06-21T17:31:32Z<p>Bert: 1 revision</p>
<hr />
<div>__NOTITLE__<br />
{{Template:Release64:QMMM_Single_Point_Calculations}}<br />
A number of electronic structure properties can be calculated with QM/MM using capabilities provided by [[Release64:Properties|property]], [[Release64:ESP|esp]], and [[Release64:DPLOT|dplot modules]].<br />
<br />
{{:Release64:qmmm_example5}}<br />
<br />
===[[Release64:qmmm_example6|<small>Example QM/MM ESP Calculation:</small>]]===<br />
;Example QM/MM ESP Calculation:<br />
{{:Release64:qmmm_example6}}</div>Berthttp://www.nwchem-sw.org/index.php/Release66:Qmmm_sp_energyRelease66:Qmmm sp energy2013-06-21T17:31:31Z<p>Bert: 1 revision</p>
<hr />
<div>__NOTITLE__<br />
{{Template:Release66:QMMM_Single_Point_Calculations}}<br />
The task directive for QM/MM single point energy and gradient calculations is given by<br />
task qmmm <qmtheory> energy<br />
or<br />
task qmmm <qmtheory> gradient [numerical]<br />
where qmtheory refers to the level of QM theory (e.g. dft, tce, mp2, ...). <br />
<br />
The ground state QM/MM energy calculations should be possible with<br />
all QM descriptions available in NWChem, however most of testing was performed using core QM methods (scf,dft,mp2,tce). The ground state QM/MM gradient<br />
calculations can be performed analytically with scf,dft,mp2 levels of theory and numerically for all the others.<br />
<br />
<br />
The relevant settings for QM/MM interface block for energy and gradient calculations<br />
include <br />
*[[Release66:qmmm_bq_zone |bqzone]]<br />
*[[Release66:qmmm_mm_charges |mm_charges]]<br />
*[[Release66:qmmm_link_atoms |link_atoms]]<br />
*[[Release66:qmmm_link_ecp |link_ecp]].<br />
<br />
{{:qmmm_example3}}</div>Berthttp://www.nwchem-sw.org/index.php/Release66:Qmmm_regionRelease66:Qmmm region2013-06-21T17:31:31Z<p>Bert: 1 revision</p>
<hr />
<div>__NOTITLE__<br />
region < [region1] [region2] [region3] ><br />
<br />
This directive specifies active region(s) for optimization, dynamics, frequency, and free energy calculations. Up to three regions can be specified, those are limited to<br />
<br />
*"qm" - all quantum atoms <span id="qm">some text</span><br />
*"qmlink" - quantum and link atoms <span id="qmlink"></span><br />
*"mm_solute" - all classical solute atoms excluding link atoms<br />
*"solute" - all solute atoms including quantum<br />
*"solvent" all solvent atoms<br />
*"mm" all classical solute and solvent atoms, excluding link atoms<br />
*"all" all atoms<br />
<br />
Only the first region will be used in dynamics, frequency, and free energy calculations. In the geometry optimizations, all three regions will be optimized using the following optimization<br />
methods<br />
<br />
if (region.eq."qm") then<br />
method = "bfgs"<br />
else if (region.eq."qmlink") then<br />
method = "bfgs"<br />
else if (region.eq."mm_solute") then<br />
method = "lbfgs"<br />
else if (region.eq."mm") then<br />
method = "sd"<br />
else if (region.eq."solute") then<br />
method = "sd"<br />
else if (region.eq."solvent") then<br />
method = "sd"<br />
else if (region.eq."all") then<br />
method = "sd"<br />
end if<br />
<br />
where "bfgs" stands for Broyden–Fletcher–Goldfarb–Shanno (BFGS) optimization method, "lbfgs" limited memory version of quasi-newton, and "sd" simple steepest descent algorithm. These assignments can be potentially altered using [[Release66:qmmm_method|method]] directive.</div>Bert