This section provides some organizational suggestions. First we will provide some suggestions that will guide you in writing and delivering setup scripts, then we will provide suggestions for directory structures.
It is normal for an integrated data acquisition system to run in more than one environment. For example, SeGA runs by itself, with the S800, and with the Beta endstation as well as other environments not listed here. When transplanted into a new environment we want our systems to satisfy the following objectives:
It should be easy to reconfigure our system for the special needs of each environment.
It should be easy for a third party to do this reconfiguration.
If our integrated system is being embedded into a larger system, the embedding should be easily reversible... that is it should be easy to remove our system from the larger system.
We have two tools that can be applied to meet these goals. De-facto standards, and modularity. De-facto standards address the way in which we achieve customization of our integrated DAQ system in the presence of other customized DAQ system, while modularity addresses how to deliver this customization to the user.
For the most part, configuration is done via environment variables and configuration files. Environment variables tend to be used to configure single valued entities while configuration files are used to deliver larger quantities of configuration data (e.g. the exact detector configuration used for an experiment).
The table below describes environment variables I have seen used and those I would think you should use to describe the variable components of an experiment or a section of an experiment.
Table 4-1. Environment variables existing and suggested
| Variable Name | Sample value | Meaning |
|---|---|---|
| DAQHOST | spdaq20.nscl.msu.edu | The computer system that is attached to the experimental electronics. This is where the Readout software will run. |
| EVTHOST | events.nscl.msu.edu | The computer system in which event data is written. Note that starting with nscldaq-8.0, direct writes to the event area are done rather than ftp based writes. |
| EVENTS | ~/stagearea | As of nscldaq8.1 and later this environment variable can be used to specify the location of the event stage area. The event stage area is where event data is actually written. If not defined, this defaults to ~/stagearea. See the subsection describing data organization for more information. |
| EXPDIR | ~/experiment | As of nscldaq8.1 and later, this environment variable can be used to specify where the data associated with each run is stored. If not defined, this defaults to ~/experiment. See the subsection describing data organization for more information. |
| EXPTITLE | Set a new title | As of nscldaq8.1 and later, this environment variable can be used to specify an initial run title. |
| SCALERINTERVAL | 10 | As of nscldaq8.1 and later this environment variable can be used to specify the initial scaler interval. |
| xxx_ROOT | ~/daq/xxx | I have not seen this but this could describe the top level of the local installation of the modifiable files for the DAQ subsystem named xxx (e.g. SEGA_ROOT). |
| xxx_CONFIGDIR | $xxx_ROOT/config | I have not seen this, but this could define the directory that has the configuration files for the detector subsystem xxx. Normally it would be defined relative to $xxx_ROOT, however if the configuraiton requirements of the run are substantially different than one of the standards it may be more convenient to move it to another directory, hence I would not recommend software that referred to $xxx_ROOT/config directly. |
| xxx_LIBDIR | ~xxx/current/lib e.g. | I have not seen this yet, but it could define a library directory for the current linkable objects distributed to the public by detector system xxx. See more about this in the best practices chapter, when we discuss how to manage code distribution. |