Input
The input for densf is keyword oriented. The keywords may be specified in any order with one exception: INPUTFILE, if present, must be specified before any other option. Reading input by densf ends when it encounters the record EndInput or the end-of-file, whichever comes first.
The current version of densf does have reasonable defaults for all input. That means that in many cases you probably will not need to specify any input at all.
Below follows a list of the allowed keywords with their description.
Input/Output files
INPUTFILE {file}
INPUTFILE keyword specifies path to the TAPE21 file from which densf reads the input data. Absence of the keyword is treated as if INPUTFILE TAPE21 has been specified.
OUTPUTFILE {file}
OUTPUTFILE keyword specifies path to the (possibly existing) TAPE41 file. If the file exists, densf will read grid specifications from it ignoring GRID keyword in the input. Computed quantities are saved in the file overwriting existing data with the same name, if any.
VTKFILE {file}
VTKFILE keyword specifies path to a file in the format readable by VTK directly. This option exists primarily for better integration with ADF-GUI and the user should not specify it.
The OUTPUTFILE and VTKFILE options are mutually exclusive. Absence of both of these options is treated as if OUTPUTFILE TAPE41 has been specified.
Grid
The Grid key is available either as simple key, or as block key.
The simple key options are as follows:
GRID {save} {coarse|medium|fine}
If the word save is specified, the program will store all grid points on TAPE41 (in addition to the specification of the grid that is always stored). The default is NOT to store all grid points.
Either coarse, medium or fine may be specified. This instructs the program to generate the grid automatically within a box enclosing all atoms of the molecule. The distance between grid points is 0.5, 0.2 or 0.1 bohr for respectively a coarse, medium or fine grid. Evidently the size of the result file TAPE41 depends strongly on this specification. The default value (used when the user does not specify the grid) is to generate a coarse grid.
If GRID is used as a block key it must be followed by the word end in a later record. The records until the end are the data for the Grid keyword:
Grid {save}
x0, y0, z0
n1, n2, n3
v1x, v1y, v1z, length1
v2x, v2y, v2z, length2
v3x, v3y, v3z, length3
END
If the word save is specified, the program will store all grid points on TAPE41 (in addition to the specification of the grid that is always stored). The default is NOT to store all grid points.
The records in the data block must contain (in order!!):
- 1 Three coordinates for the 'origin' (lower-left corner) of the grid.
- 2 Three integers: the numbers of points in three independent directions.
If fewer integers are supplied the grid will accordingly be less-dimensional. - 3 Three records each containing the coordinates for the direction
of the independent vector (size irrelevant)
and the total length of the grid in that direction.
If a lower-dimensional grid is requested (see item #2), then fewer such direction-records are read and
the redundant ones, if any, are ignored.
The unit of length in which the grid size is input is by default Angstrom.
The default (Angstrom) can be overridden by using the input key UNITS, see below.
Notes:
- The second record ('three integers...') specifies the
number of grid points in the different directions.
The corresponding number of steps or intervals is one less! - If the TAPE41
result file is to be used by the contour generating program cntrs,
the grid used in the densf calculation must be two-dimensional. - If the TAPE41 result file is to be used by ADFview, the
grid used must be an three-dimensional orthogonal grid,
with a single step size for all three dimensions. - The unit of length used in the input file has no
relation to how the data are stored on the result file
and how the program processes the data internally.
Internal processing and storage on file is in bohr (atomic units).
Units
As in the ADF main program, the unit of length can be set with the block type key
UNITS Length unit_of_length END
In densf the only item that can be specified in the UNITS block is the length, so it seems a bit pointless to make UNITS a block type key rather than a simple key. However, to make its usage identical to the application in the adf main program the block form has been chosen to apply also here. The unit-of-length will apply to the grid specification in the input file. Default is angstrom.
Density
Generates the charge density in the grid. It is a simple keyword (not block-type).
density {fit} {frag} {ortho} {scf} {trans}
Occurrence of the word fit specifies that all densities specified in this record will be computed from the fit functions (an approximation to the exact density), rather than from the occupied molecular orbitals.
frag, ortho, scf, and trans causes each of the corresponding densities to be computed. frag stands for the sum-of-fragments (i.e. the initial) density, scf for the final result of the adf calculation, ortho for the orthogonalized fragments (orthogonalization to account for the Pauli repulsion, see the ADF User's Guide), and trans for excitation transition density.
Transition density is a product of initial and final states of an excitation. In the simplest case when initial and final states consist of one molecular orbital each, in this case the corresponding transition density is a product of the two MOs. To otain transition densities one needs to perform an excitations calculation with ADF, see EXCITATIONS keyword in ADF User's Guide. Transition densities for all excitations found in the input TAPE21 file will be calculated. The transition densities are always fit-densities.
If both the exact and the fit-densities are required the density keyword must be repeated, once with and once without the fit option specified.
The default (when the DENSITY key does not occur in the input file) is to calculate the final SCF density and the sum-of-fragments density.
Kinetic Energy Density and Electron Localization Function (ELF)
KinDens {frag} {orth} {scf}
Generates the Kinetic energy density and electron localization function on the grid.
Occurrence of any of the words requests calculation of the two quantities (KinDens and ELF) based on the corresponding density: sum-of-fragments, orthogonalized fragments, or SCF, respectively. If none of the options is present, scf is assumed.
Potential
Generates the coulomb and/or exchange-correlation potential in the grid.
potential {coul / XC} {frag} {ortho} {scf}
frag, ortho, and scf are as for the density: at least one must be specified.
coul and XC specify that the Coulomb potential, respectively the exchange-correlation potential must be computed. Precisely one of these options must be specified in the record. If both potential types are required, another input record with the potential key must be used.
In the present release the xc option is not yet operational.
The default (when the POTENTIAL key does not occur in the input) is to calculate the SCF Coulomb potential.
Orbitals
A block type key in which the required molecular orbitals are specified. The key can be repeated in input any number of times; all occurrences are read and applied.
Orbitals type (data) END
The argument of the orbitals key (type) must be scf (for the scf orbitals) or frag (for the fragment orbitals) or loc (for the localized molecular orbitals, see the ADF User's Guide).
The frag option is not operational in the present release.
In many data records in the ORBITALS block, as noted in the description of these data records, you may specify a HOMOLUMO range.
A HOMOLUMO range is the following:
{HOMO{{-}n}} {LUMO{{+}n}}
HOMO: the highest occupied orbital
HOMO-n, with n an integer: the highest (n+1) occupied orbitals
LUMO: the lowest virtual orbital
LUMO+n, with n an integer: the lowest (n+1) virtual orbitals.
The HOMO part, or the LUMO part, or both must be specified. The integer n with sign is always optional, and the sign is always optional (and has no meaning, it is intended to enhance readability).
Thus, as an example,
HOMO-1 LUMO+1
means a range of 4 orbitals: the two highest occupied ones, and the two lowest virtuals.
Each data record in the orbitals block must have either of the following formats:
1. the word alpha or beta.
This specifies that subsequent
records refer to spin-alpha or spin-beta orbitals respectively. In a restricted
calculation this has no meaning and beta must
not be specified.
alpha and/or beta may occur any
number of times in the orbitals
block. All records until the first occurrence of
alpha or beta are assumed to
refer to spin-alpha orbitals.
2. label n1, n2, n3, ...
label is one of the subspecies of the
point group symmetry used in the adf
calculation and n1 etc. are indices of
the molecular orbitals (in that subspecies) that are to be computed. This
format is meaningless and must not be used for the loc orbitals type, because
localized orbitals do not
(necessarily) belong anymore to a particular symmetry representation.
3. label HOMOLUMO
label is one of the subspecies of the
point group symmetry used in the calculation, the orbitals follow from the
HOMOLUMO range.
4. label occ or label virt
occ specifies all orbitals (in that
symmetry representation) up to and including the highest occupied one. virt specifies all orbitals above the
highest occupied one. In this context partially
occupied orbitals are considered occupied. Note carefully that if in a
particular symmetry representation an empty orbital is computed below the
highest occupied one in that same representation (excited state), that
particular empty one is included in the list of
occ.
Again, this format is meaningless and must therefore not be used for the loc type
of orbitals.
5. all occ or all virt or all HOMOLUMO
Specifies for each symmetry representation:
- all orbitals up to and including the highest occupied one (in that symmetry), or
- all orbitals above the highest occupied one, or
- all orbitals defined by the HOMOLUMO range.
This form is not to be used for the LOC
type of orbitals. However, using this for
LOC will not result in an
error but will be interpreted as identical to the following format.
6. all
This format must be used only for the LOC type of orbitals and simply
means: all computed localized orbitals (irrespective of occupation numbers).
7. n1, n2, ...
a simple list of integer indices.
This format must be used only for the loc type of orbitals since no
reference is made to any symmetry representation. The indices refer of course
to the list of localized orbitals as computed by adf, see the User's Guide.
The default value used when the ORBITALS key is not present is:
Orbitals SCF All HOMO-1 LUMO+1 End
Generic orbitals
There is also a possibility to calculate any orbital as long as it is present in the t21 file in the BAS representation. The input syntax is as follows:
Generic section1%variable1 section2%variable2 End
In the example above, each line contains the section and variable name of the orbital in the input t21 file. The length of the variable should be equal to the number of atomic functions (naos) and it is supposed to contain expansion coefficients of the orbital on the basis of atomic (primitive) functions.
The calculation results are stored in the output file in sections and variables with exactly the same names as specified in the input. The section and variable names may contain spaces although the leading and training spaces are discarded.
Memory usage
The default value for the maximum amount of memory that can be used by the program to perform the required computations is chosen and defined at the installation of the whole package and is identical to the value for the main programs (adf, band). As for these programs, the actual value can be adjusted for any particular run with certain keywords, in exactly the same way as for adf and band.
Apart from the maximum total amount of memory you can also adjust some related technical parameters. These should only affect efficiency issues and in general you should not adjust them.
For the total amount of memory in Mbytes:
maxmemoryusage n
The default is defined by the installation. The maxmemoryusage value will have been chosen specifically by the user/installer to accommodate his machine(s).
Input control of memory usage is applicable only if dynamical memory allocation has been turned on in the installation (which is the default, but you may have adjusted that).
