Input

The input for densf is keyword oriented. The order of keywords in input is immaterial. 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.

Follows a list of the admissible keywords with their meaning.

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}

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, and scf 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, and ortho for the orthogonalized fragments (orthogonalization to account for the Pauli repulsion, see the ADF User's Guide).

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.

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.

KinDens

Generates the kinetic energy and the Electron Localization Function (ELF) on a grid.

kindens {frag} {ortho} {scf}

frag, ortho, and scf are as for the density: at least one must be specified.

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

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 accomodate 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).