Experimental Equipment

Part of the information we want to store about an experiment is the equipment used to conduct the experiment.

Note that this is only used to identify and provide static information about the equipment, any information which is dynamic, such as configuration settings, will be stored as parameters against the relevant datafiles or datasets.

The benefits of explicitly identifying the equipment used in the experiment include:

• Being able to take any quirks of the equipment in to account when analysing the data.
• Being able to find all data collected by a piece of equipment to facilitate analysis of the equipment performance.
• Notifying users of any normalisation that needs to be performed on raw data, e.g. if part of the detector is accidentally burnt out.

We considered a number of approaches to the design:

1. Adding an Equipment table to TARDIS core schema
2. Extending ParameterSets to allow them to be shared between projects and creating an Equipment schema
3. Leaving Equipment out of TARDIS core functionality, implementing an Equipment register as a separate Django application and referencing the entry from a parameter

We are currently working on the third approach, using a separate Equipment register, for the following reasons:

• A facility may already have an equipment register, or web pages describing the equipment, in which case the functionality is not required.
• Maintaining information on equipment is not core functionality for TARDIS, which is about experimental metadata.
• How the equipment information should be federated isn’t clear.  Using a separate register allows the link to be valid from any location while avoiding the replication problems.
• Django’s architecture makes it easy to implement and deploy multiple small applications (such as an Equipment Register).