3.3 Data for Examples

In order to make examples simpler to present, it helps to have hypothetical data files to refer to. I will assume the existence of several data files that I hope will be familiar to many readers. An ASCII version of each file is provided in the SDDS distribution package. This gives new users some data to “play with” in getting familiar with SDDS. These files are also used in several demonstration scripts provided in the package.

For each file, I’ve listed the names of the columns and parameters, and described each. I’ve given the data types in detail, even though only the distinction between numerical and nonnumerical data is relevant, just to emphasize that data types can be freely mixed. I’ve tried to include as little data as is necessary to make useful demonstrations, without simplifying so much as to be trivial.

3.3.1 Twiss Parameters

The example of Twiss parameters for an accelerator is a familiar one. Throughout these pages, it is assumed that two files, A  PS0.twi and APS.twi, exist containing the following data (a simplification of the Twiss output from the accelerator simulation code elegant):

To make it more interesting, APS0.twi is a single-page file containing the APS design lattice, while APS.twi is a multi-page file with each page corresponding to a different configuration.

In passing, it is appropriate to mention the style of the names used. It has been found helpful to use capitalization at word boundaries to make long names more readable. (In some cases, like betax, a certain case is used because it is significant.) When doing so will not create confusion, we also tend to capitalize the first letter of a name, which helps the name to stand out on the command line. Abiding by these conventions tends to result in readable names being created by Toolkit programs that have automatic name generation. Underscores in names are avoided because they increase the length of a name while adding less readability than capitalization.

3.3.2 Data Logging Over Time

One of the most common applications of SDDS for APS commissioning and operation is logging of measured data values at intervals. A set of generic EPICS monitoring programs sddsmonitor, sddsvmonitor (vector monitoring), and sddswmonitor (waveform monitoring) are used for this. One example is the vacuum pressure in the APS ring, which is logged continuously by sddsvmonitor; this data consists of readings from ion gauges around the ring. Another example is logging of beam-position-monitor readouts in the Positron Accumulator Ring (PAR) and its input and output beam transport lines using the program sddsmonitor.

For use in examples, I’ll assume the existence of two files called SR.vac and par.bpm. These are simplified from actual files collected with the programs just mentioned.

SR.vac is a file containing an arbitrary series of data pages, each consisting of a snapshot of the vacuum gauge readings around the ring. There are 40 such readings, one for each sector of the accelerator. Typically, one set of readings is taken every 15 minutes.

par.bpm is a file containing a single page of data with any arbitrary number of rows. The PAR has 16 beam-position-monitors (BPMs), each providing a horizontal (x) and vertical (y) readout. In addition, the beam transport line downstream of PAR (known as the PTB line), contains five BPMs for x and five for y. The data included in the distribution contains only the x values, since these are more interesting: