Overview
This is our view of how our part of the software should work:
Here is the calibration data chain:
Overview of components:
The whole chain has the potential of being parallellized
SCTDAQ Data:
A program called sct_api_server provides an interface similar to the one we expect SCTAPI to provide. On request, it puts SCTDAQ data from module testing into IS in the data format expected (i.e. a RawRODData object). A RawRODData object contains information about the scan, the module configuration, the histogram of triggers and the data histogram.
Fitting Service:
The Fitting Service (executable: FittingService) takes the RawRODData and then fits a functional form (e.g. an S-curve (erfc) for a threshold scan) appropriate to the type of scan. It then puts the fit back into IS.
Analysis:
The analysis takes groups of scans and analyses them appropriately. For instance, there are 10 threshold scans in a response curve. Currently supported tests are: 3-pt gain, response curve, strobe delay and noise occupancy.
Java UI:
The current Java UI (testgui) is a test UI. It shows the contents of the SCT IS servers and allows them to be deleted (press the <DELETE> key). It also communicates with sct_api_server to initiate data production. Using external tools it can display most of the data produced. It also has experimental scripting facilities.
Persistancy:
This component will save all the data stored in IS in a suitable form. It is being written by Alessandro Tricolli at Oxford. Raw data can be saved by changing to this directory: archiving/ArchivingServiceRaw and typing make. Then run: ArchivingService. This will save all the raw data. There is a program "Replay" that can put that data back into IS. It takes a run number, scan number, module name, and an integer expressing the scan type (1 for threshold scan).
IS:
Each IS box corresponds to a different IS server. This is for technical and data throughput reasons. The IS servers are currently called "EventData", "FittedData", "TestData" and "ControlData".