- creating a <TestResult> object which contains the information about how a particular module has respoded during the test.
- finding whether there are any problems, which might be highlighted by adding <ModuleDefect> s.
- if the test might lead to an updated configuration (e.g. modifying the TrimDac registers on the ASICs), then the AnalysisService must decide what the new values of the ASIC parameters should be and add those to the <TestResult>.
The AnalysisService has various callbacks. They are involved in maintaining a list of the tests currently in IS. For each test, there exists one instance of an <AnalysisAlgorithm> for each module. When new <ScanResult> objects arrive, either <FitScanResult> or <RawScanResult>, they are added to (creating if necessary) the appropriate <AnalysisAlgorithm>. This algorithm then proceeds as and how it sees fit, often waiting until it has all the <ScanResult>s it needs before trying to do the analysis itself.
It makes use of the SctService implimentation of the listener-thread, worker-thread, so that the computationally heavy part is separate from the communication.
The end result is a <TestResult>, which is published back into IS.
Question for experts - should the larger analyses e.g. trim range start doing analysis as the first testresults arrive. This may be difficult. e.g. for the trim range one must be sure that one has all scans for a particular range are present before proceeding with the analysis for that range. Currently the IS reading is done immediately, everything else is postponed until the last scan result arrives. -- Alan