This document describes the design of the WIDAR correlator backend software, from general principles to design details. This is an evolving document, and should remain the most up-to-date source of information about the design of the backend software.
It is expected that the backend software will be used by both the EVLA and eMERLIN WIDAR correlators from the early development stage to the production stage (as well as WIDAR development and testing at DRAO), and therefore the design is based on a generic framework, allowing customized extensions as needed at every stage of development and deployment of any WIDAR correlator installation. The diversity of environments in which the backend software will be used has significantly affected the design of the software, in an attempt to meet the following design goals.
Design goals
This is perhaps the goal with the greatest effect on the design of the backend software. Each correlator development or installation site may have unique requirements for the processing or output required of the backend, and development of backend functionality will be an evolutionary process keeping pace with requirements imposed by the correlator and other subsystem development and deployment processes. Flexibility in both software development and system configuration is a necessary quality of the backend software design.
Required to resist the effects of flexibility's evil twin, instability. While parts of the backend software require great flexibility to be useful, other parts, which may be described as common functionality, do not. The design must guard against failures in the common functionality that may be triggered by faults in the flexible parts.
The backend software, generally, is deployed on a computing cluster, consisting of a head node and one or more compute nodes. Backend cluster processes, and the software they run, are classified according to whether they execute on the head node or a compute node in a fully deployed cluster. A configuration in which the cluster consists of a single node will be common during development and early correlator deployment, but this configuration does not change the logical distinction of head and compute node processes and software.