4.10 Defining orbital subspaces

In the SCF, MCSCF, and CI programs it may be necessary to specify how many orbitals in each symmetry are occupied (or internal in CI), and which of these are core or closed shell (doubly occupied in all CSFs). This information is provided on the OCC, CORE, and CLOSED cards in the following way:

OCC, $m_1,m_2,\ldots,m_8$; CORE, $co_1,co_2,\ldots,co_8$; CLOSED, $cl_1,cl_2,\ldots,cl_8$; FROZEN, $fr_1,fr_2,\ldots,fr_8$;

where $m_i$ is the number of occupied orbitals (including core/frozen and closed), $co_i$ the number of core orbitals, and $cl_i$ is the number of closed-shell orbitals (including the core orbitals) in the irreducible representation $i$. In general, $m_i \ge
cl_i$, and $cl_i \ge co_i$. It is assumed that these numbers refer to the first orbitals in each irrep. FROZEN only exists in the MCSCF program and denotes frozen core orbitals that are not optimized (note that in older MOLPRO versions frozen core orbitals were denoted CORE).

Note that the OCC and CLOSED cards have slightly different meanings in the SCF, MCSCF and CI or CCSD programs. In SCF and MCSCF, occupied orbitals are those which occur in any of the CSFs. In electron correlation methods (CI, MPn, CCSD etc), however, OCC denotes the orbitals which are occupied in any of the reference CSFs. In the MCSCF, FROZEN orbitals are doubly occupied in all CSFs and frozen (not optimized), while closed denotes all doubly occupied orbitals (frozen plus optimized). In the CI and CCSD programs, core orbitals are those which are not correlated and closed orbitals are those which are doubly occupied in all reference CSFs.

OCC, CORE and CLOSED directives are generally required in each program module where they are relevant; however, the program remembers the most recently used values, and so the directives may be omitted if the orbital spaces are not to be changed from their previous values. Note that this information is also preserved across restarts. Note also, as with the WF information, sensible defaults are assumed for these orbital spaces. For full details, see the appropriate program description.

The orbital spaces may also be defined outside command blocks, and then the directive is treated as global, i.e., it is used in all subsequent programs. Spaces specific to certain wavefunction types can be defined by specifiying the program name with a CONTEXT option, e.g.,


Alternatively, the context can be appended to the directive name with an underscore. For example


is equivalent to the previous form.

Local input given within command blocks has preference over global input.

molpro@molpro.net 2018-11-16