This is an old revision of the document!
Documentation of cp2k can be found on the website http://manual.cp2k.org and can also be generated by the cp2k executable itself using the flag
–xml (followed by xml2htm if you want an html documentation). The documentation generated by the executable is always consistent with its version, whereas the one on the website refers to the latest version.
OTsection has a logical default parameter that controls the activation of the OT method. So,
&OT ... &END OT
activates the OT method and
&OT FALSE ... &END OT
(or the absence of the OT section) deactivates it.
The basic idea of the input is to define the options for the method that you want to use to calculate the forces/energy in the
FORCE_EVAL section. If you use the ab-initio DFT part then the
QS subsections will probabily be of interest for you.
The method to use is choosen with
FORCE_EVAL%METHOD keyword, i.e. the keyword
METHOD in the
FORCE_EVAL section. So you can easily switch from one method to the another if you gave meaningful parameters to both.
Then parameters for the kind of calculation (run type) to do using that method (energy,force,molecular dynamics,langevin,…) are defined in the
Finally in the
GLOBAL section you can choose the run type to perform with the keyword
RUN_TYPE, the name of the project (
PROJECT), used to generate most of the output files, the
PRINT_LEVEL keyword that controls the general level of output, and other general flags. The
GLOBAL%PRINT%PHYSCON keyword enables a printout of the physical constants used by cp2k.
To control the output of information or properties often printkeys are used. A printkey is a section that has a default value that says at which print level to start printing the corresponding values, and keywords to control their output. Normally printkeys are kept together in a
To understand how to control the output it is necessary to first understand the iteration level. During the calculations cp2k keeps a global iteration level which is a set of integers that keep track which iteration one is doing at that moment.
The exact meaning of each iteration level depends on the run type, for example doing an MD with the QS GPW method an iteration level of 1_4_5 means that the program is doing the 5th scf step of the 4th md step, whereas 1_9 means the we are at the 9th md setp (outside the scf loop). The first 1 is a root iteration level that stays always 1 during a normal md run
ON, OFF, SILENT, LOW, MEDIUM, HIGH, DEBUG. No section means the default value, the presence of the prind sections implies a value of
ON(always printed), if one wants to selectively switch off the printkey it is possible the give it the explicit value OFF, i.e.
EACH: How often this proprety is printed, this is matched with the actual iteration level from the right replacing non present levels with 1. For example “2 1” for an scf property during an scf means to write each scf step each 2 md step. How to handle the last iteration is treated separately in ADD_LAST (this mean that EACH 0 might print the last iteration)
ADD_LAST: If the last iteration should be added, and if it should be marked symbolically (with l) or with the iteration number. Not every process is able to identify the last iteration early enough to be able to output. Valid keywords: NO, NUMERIC, SYMBOLIC
COMMON_ITERATION_LEVELS: How many iterations levels should be written in the same file (no extra information about the actual iteration level is written to the file). If it is 0 then all iterations go to different files, if it is 1 then (if the current property is an SCF property and one is doing an MD then each MD step goes to a separate file (but different scf steps are in the same file)
FILENAME: controls part of the filename for output.
STD_OUT(exactly as written here) for the screen or standard logger.