CP2K Open Source Molecular Dynamics

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 –html or –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.

• the input is subdivided in sections that start with “&” and end with “&END”
• each section can contain other sections and keywords followed by values
• both the section names and the keyword names are case insensitive
• the special characters “#” and “!” denote the beginning of a comment that goes until the end of the line
• If the value of the keyword is experssed in units, perceding the value by the units in square bracket changes them. In the square brackets the units should have no space. For example “[m]” switches to meters.
• A long line of input can be split using the “\” character at the end of the line
• keywords with a logical value (flags), often have a value that is false when the keyword is missing; the value true when one writes just the keyword (lone_keyword_value), or they can be given an explicit value after the keyword as normal (for example KEYWORD FALSE).
• Sections can have a default parameter that comes right after the section value. For example the OT section 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 DFT and 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 MOTION section

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 PRINT section.

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

• section parameter: Level starting at which this property is printed, valid values are 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. &SECTION OFF
• 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.
  • Use STD_OUT (exactly as written here) for the screen or standard logger.
  • Use “filename” to get “projectname-filename[-middlename]-iteration.extension”
  • Use “./filename” (or any path that contains at least one “/”) to get “./filename[-middlename]-iteration.extension”
  • Use “=filename” to get exactly filename as output file (please note that this can be dangerous because different output/iterations might write on the same file