Back to the
Table of Contents
It is necessary to provide the program with information about the collision system of interest. In particular, one must specify the types of collision partners -- e.g., linear rigid rotors, vibrating diatomic molecules, asymmetric top rotors -- and specify which rotational (and possibly vibrational) levels of each to include in the expansion of the total wavefunction. It is necessary to describe the intermolecular forces between the two collision partners. It is also necessary to describe the collision energies of interest. It may be desirable to specify a less computationally intensive approximate method. From these data the program can set up the required coupled equations. MOLSCAT implements several numerical methods for solving the coupled equations and it is necessary to specify which one of these to use and to provide some parameters to control numerical accuracy. Other input parameters may be used to provide finer control of the calculation, specify optional processing such as the calculation of line shape cross sections, or options such as saving the S-matrices to a data set so they may be used to calculate further scattering properties.
These parameters are input to the program in NAMELIST format as described below. The supported collision types are summarized in Section 1.2 and the implemented numerical methods for solving the coupled differential equations are summarized in Section 1.3.
&INPUT, read in subroutine DRIVER, provides overall control of the calculation (collision energies, partial wave limits), print options, optional calculations (line shape cross sections, resonance searches, output data sets), and choice of and tolerances for the numerical propagator. Allowed parameters are described in detail in Section 2.
&BASIS, read in entry BASIN of subroutine BASE, describes the collision type, the rotation-vibration basis set, and dynamical approximations. Input parameters are described in Section 3.
&POTL, read in the initialisation call of subroutine POTENL if the general-purpose version of POTENL is used, describes the intermolecular potential. Input parameters are described in Section 4. For some cases it may be desirable to substitute a user-supplied POTENL routine (which does not necessarily read &POTL input data); specifications for this routine are given in Section 5.
&CONV, read in subroutine CONVRG if the automatic convergence testing option is selected (&INPUT ICONV = 1). Input parameters are described in Section 6.
Each NAMELIST block starts with &<name>, where <name> is INPUT, BASIS, POTL or CONV as appropriate, and is terminated by &END. Between these delimiters, the NAMELIST input data consist of <KEYWORD>=value entries in the data file, where KEYWORD is the variable name. Note that all lines of data must start in column 2 or later; characters in column 1 will cause errors. In some implementations of NAMELIST, every value must be terminated by a comma. Many of the variables have sensible default values, which are used if the variable is not listed in the data file.
Atom - linear rigid rotor scattering
Atom - vibrating diatom scattering (rotationally and/or vibrationally inelastic)
Linear rigid rotor - linear rigid rotor scattering
Asymmetric top - linear molecule scattering
Atom - symmetric top scattering (also handles near-symmetric tops)
Atom - asymmetric top scattering (also handles spherical tops)
A generalised form of ITYPE = 2, allowing the intermolecular potential matrix elements to depend on the diatom j quantum number
Atom - corrugated surface diffractive (elastic) scattering. At present, the code is restricted to centrosymmetric lattices, for which the potential matrices are real
MOLSCAT calls user-supplied routines to define the coupling case
The computer time required to solve a set of N coupled equations is nominally proportional to N**3, and in practice the limit on N is from 30 to 500, depending on the speed of the computer and the amount of memory available. The basis sets necessary for converged close-coupling calculations quickly exceed this limit as scattering energies increase or rotational constants decrease, particularly for collision types 2 to 7. However, MOLSCAT also provides for various approximate (decoupling) methods which reduce the dimensionality of the coupled equations. The methods supported at present are
Effective potential approximation
Coupled states (centrifugal sudden) approximation
Decoupled l-dominant approximation
Infinite order sudden approximation
These approximate methods are invoked by adding the appropriate value of IADD to the ITYPE values listed above: thus, for example, ITYPE = 22 invokes the coupled states approximation for atom - vibrating diatom scattering.
Not all these approximations are supported for all collision types, though the most common ones are. The program will print a warning message and exit if you request an option that is not supported.
DeVogelaere's method. This is a reliable and accurate method, but is rather slow, especially for large reduced masses or high scattering energies. It is not well suited to problems with very long-range potentials.
R-matrix propagator. This is a very stable method. It is very simple to use, but has relatively poor step size convergence properties, so that it is not generally suitable for obtaining very high accuracy. It has largely been superseded by the modified log- derivative propagators available as INTFLG = 6 to 8 (see below).
The VIVAS hybrid propagator, using the log-derivative method at small R and the variable interval variable step (VIVS) method at large R. This is sometimes the most efficient propagator if many different energies are required, but control of it is rather more complicated than for other propagators. In particular, it requires the first and second derivatives of the potential for maximum efficiency. It sometimes presents stability problems, and is not generally recommended for inexperienced users.With appropriate choices of the switchover distance, either the log-derivative method or VIVS can be used over the whole range of R if desired. This will usually be useful only in special cases.
Log-derivative propagator of Johnson. This is a very stable and reliable propagator, and is particularly efficient on vector processors. However, it has now largely been superseded by the diabatic modified log- derivative propagator available as INTFLG = 6 (see below).
Diabatic modified log-derivative method of Manolopoulos. This is a very efficient and stable method, especially at short range. INTFLG = 6 automatically detects single- channel cases (including IOS cases) and uses a more efficient implementation of the propagator.
Quasiadiabatic modified log-derivative method of Manolopoulos. This method offers better accuracy than INTFLG = 6 for very strongly coupled problems, but is relatively expensive (even at subsequent energies). It is recommended for very strongly coupled problems only.
Hybrid modified log-derivative Airy propagator of Manolopoulos and Alexander. Uses the same method as INTFLG = 6 at short range, but changes to the Airy propagator at long range. This is the recommended general-purpose propagator for cross section calculations.
WKB semi-classical solution using Gauss-Mehler quadrature. This is suitable only for 1-channel problems and hence is usually useful only for IOS (ITYPE.gt.100) cases.
Note that Gordon's propagator, which was available as INTFLG = 1 in early versions of MOLSCAT, is not implemented in this version.
All these propagators have options which allow them to use potential matrices stored at the first total energy when doing calculations at subsequent energies. For the R-matrix propagator, VIVS, and the modified log-derivative propagators, some of the remaining work is also avoided at subsequent energies, so that they may cost only 30% as much as the first. Parameters which control accuracy of the propagators are in put in &INPUT; details are given in Section 2.12.
Dimensions in common block CMBASE which contains information about the basis set (see Section 3) have been significantly increased to accomodate larger calculations; this may necessitate changes to user-supplied BASE9 (and related) routines.
Dimensions in the common block ANGLES, which provides communication with VRTP routines have been increased; see Section 4.3. Existing VRTP routines, which use this common block for communication, must be modified accordingly.
The format of the S-matrix save tape (ISAVEU) has been changed. The number of open channels for each JTOT, parity case, energy set is now in the record which describes the set, rather than in the next record which lists levels, partial waves, and wavevectors; see Section 2.5.
The value of JTOTU required to request automatic checking of partial wave convergence for state-to-state cross sections has been increased from 999 to 999999 and the default value has also been increased accordingly; see Section 2.3.
Interpretation of IFEGEN, the flag to specify using the ENERGY values as kinetic energies for pressure broadening calculations, has been changed; see Section 2.9. Beginning in version 14, for IFEGEN .gt. 0, values in the ENERGY list will be retained in the expanded list of total energies ONLY if they match a total energy required for a requested pressure broadening calculation. Further, for IFEGEN .gt. 1, calculations for some JTOT, parity case, energy sets may be skipped if they are not required for the requested pressure broadening. This may result in state-to-state cross sections which are incomplete for some cases.
FINDRM has been completely rewritten to provide a more robust algorithm for choosing a starting point for the propagation; however, the new routine does not generally obtain the same value as the earlier versions and this may cause results to vary slightly from those in earlier versions.
The "FILE=filename" parameters have been removed from OPEN statements. See Section 10.8.
J. M. Hutson and S. Green, MOLSCAT computer code, version 14 (1994), distributed by Collaborative Computational Project No. 6 of the Engineering and Physical Sciences Research Council (UK).The date that the program was last updated is usually held in the variable PDATE in subroutine DRIVER, and is printed out in each run. PDATE is used to keep track of minor modifications, but the version number is only incremented when major changes are made.
On to Section 2