XA Report, Approach "Atom data structure"

Approach

Atom data structure

The first step in the design process was to think of an appropriate data structure which is able to fulfils the following points:

flexible
Data has to be added or removed while running the XA.
accessible
A quick and easy access of data values is necessary.

The best representation for these points is a linked list. It does not waste too much memory by predefined boundaries, it is flexible if more memory is needed and due to the structure a quick access is possible. The main disadvantage is the higher complexity of data representation.

I decided to use a linked list, because of the possibilities to store data while a new file is read in, to add and remove pseudo orbitals easily and to neglect array boundaries.

The atom data structure looks like follows:

atom_ptr
:......... orbital_type_ptr
           :    :............. shell_ptr 
           :                   :       :... orbital_value_ptr
           :                   :            :
           :                   :            orbital_value_ptr
           :                   :            :
           :                   :            NULL
           :                   shell_ptr
           :                   :       :... . . .
           :                   NULL
           :
           orbital_type_ptr
           :    :............. . . .
           :
           NULL

At the top of the hierarchy is the orbital type, e.g. S or P, then follow the orbital/shell numbers and finally the data blocks. I have chosen to use this hierarchy because normally it is not necessary to switch between orbital types when getting data from the data structure. For example, when creating a new pseudo orbital only values of the same orbital type are needed to calculate the new data.

When a atom data file is read in by XA, orbital types are stored in LIFO order whereas shells and data blocks use FIFO order. At the beginning of the specification phase I thought that the last orbital type is needed more often for creating new pseudo orbitals than the first ones. Therefore XA will not have to look for the right data so long if orbital types are stored as a LIFO list.

Normally this irregularity will not affect the development of extensions to XA because data can be accessed by using the Access functions. Nevertheless it may be necessary to keep the internal structure in mind, especially when calling the function XAOrbitalArray, which returns the orbital names of the atom which is currently stored in the memory.

[<] [Index] [>]