Programs in Physics & Physical Chemistry
|[Licence| Download | New Version Template] adjf_v1_0.tar.gz(159 Kbytes)|
|Manuscript Title: Config: a GRACE tool for constructing configuration trees.|
|Authors: D. Maley, I. Spence, P. Kilpatrick|
|Program title: Config 1.0|
|Catalogue identifier: ADJF_v1_0|
Distribution format: tar.gz
|Journal reference: Comput. Phys. Commun. 114(1998)271|
|Programming language: C++, Motif.|
|Computer: SUN SPARCstation.|
|Operating system: Solaris 2.5.|
|RAM: 16M words|
|Keywords: General purpose, Rotation group, Database, Grace, Osf/motif, R-matrix, Object-orientation.|
|Classification: 4.1, 9.|
Nature of problem:
In the computation of atomic scattering properties and processes using the R-matrix method, each atomic state of the N-electron target atom can be represented by a configuration interaction wave function. This wave function is a linear combination of configurational wave functions built from one-electron functions (shells), such that the angular momenta are coupled according to the theory of Racah algebra to form a total orbital angular momentum, total spin and total parity common to all configurations. Config is a graphical tool to assist in determining which configurations contribute to a particular CI expansion. For example, given n electrons, a set of one-electron orbitals (1s, 2s, 2p), and the minimum and maximum numbers of electrons permitted in each orbital, this tool will display all the configurations that can be generated. Coupling information, intermediate and final, is displayed.
The computation of the configurations is comparatively straightforward. Object oriented techniques are extensively in the construction of the Graphical User Interface.
A simplifying constraint is introduced to the specification of the problem: shells beyond the d shell are allowed a maximum occupancy of one. The number of configurations possible in a given atomic state increases rapidly with additional shells and with increased orbital angular momenta. Clearly the size of the workstation RAM imposes a restriction on the extent of the generation process. Furthermore, the storage for most data structures used by the program is allocated dynamically, and as such there is the possiblity of 'memory leakage' . Work to make Config more space-efficient is ongoing.
The object-oriented architecture of Config makes extensive use of templates, or generic types. Different compilers handle template instantiation in different ways, and it is important to know how the host compiler handles this process. The practice adopted for the GNU C++ compiler was to declare explicitly each use of the template in the source file for that template. Thus the heavily utilised template LinkedList<T> contains the lines:
///////////////////////////////////////////////////////////// // // Commencing 'Help-the-Compiler' Section // template class LinkedList<ShellOccupancyRange>; template class LinkedList<RSTableElement>; template class LinkedList<RSTableRow>; template class LinkedList<ShellConfiguration>; template class LinkedList<ConfigurationTree>; template class LinkedList<CountListElement<ShellTerm> >; template class LinkedList<CountListElement<ElectronDistribution> >; // // End of Compiler Assistance Section // /////////////////////////////////////////////////////////////Adopting this approach requires that the declaration of the generic type (in the file LinkedList.h) is preceded by the statement
and that the implementation file (in the file LinkedList.C) declares itself to be the implementation of that interface
#pragma implementation "LinkedList.C"
It also requires that compilation is undertaken with the
|Disclaimer | ScienceDirect | CPC Journal | CPC | QUB|