The software for the IMU consists of the following pieces:
 |
There is a fully-detailed GEANT
simulation of the IMU detector systems and responses. One can use a
simpler (and faster) model by selecting that option, though the IMU simulation
does not take much time in any case. The simulation is FORTRAN code in a
C++ wrapper. This runs in the standard Run II GEANT environment, and
generates IMUE banks.
Changes to the WSU are not yet fully agreed-on, and only a
tentative mockup of the new arrangement is included. The simulation
includes accurate models of the toroid iron, the outer snout, and the
inner snout.
Minjeong Kim translated the IMU (and iron) system into C++ in the CDF geometry system. Currently Jim is trying to track a hang that may or may not be related to how CDF generates GEANT volumes from this. A third version of the IMU geometry is written and available for use. Some infrastructure was missing in the overall manager at the time this was written, and thus the IMU code is not tested. |
|
IMUE_Bank code is in place and functioning to describe the IMUE bank within the TRYBos/AC++ environment. This is written in C++. |
|
Stub finding code for the IMU is complete. This takes the IMUE bank from the
TRYBos record and generates
a <vector> of IMU_Candidate objects.
This is written in C++, and IMUStubModule
is a standard AC++ module. It writes IMUS banks into the Trybos record as
well.
Modifications are being made to reflect experience with the data. For example, requiring that at least one hit have an echo hit in its jumpered neighbor seems to cut the background. This is being implemented in the main code. |
|
IMUTrig is a AC++ module which checks the IMUE bank to find if there were triggers, and writes the results to the standard output. When a trigger bank is defined it will create that instead. |
|
A preliminary IMUS_Bank works. It will be modified later to provide accessors needed by CMLNK when those are decided. |
| CMLNK | Matching the CMU/IMU/etc to silicon or COT tracks is being worked on by others. |
| - | A cosmic ray tracker is in place: BmuCosmic. It does not write any data to output at this time, and will require a little more tuning. |
| - | We have already decided on a jumpering configuration. The following is now of historical interest only. The IMUCross module is nearly complete. It will take an existing IMUE bank and modify it to simulate various jumpering configurations under consideration. The jumpering is to allow measurement of the Z of hits. A FORTRAN version for crosschecking works. Project was abandoned--the simulation code has this built in and the FORTRAN was adequate for calculations. |
|
Raw data bank definitions are complete. These are for BMUD (barrel drift chamber hits), BSUD (barrel scintillator hits), and TSUD (toroid scintillator hits) TRYBos banks from the IMUE bank. (The WSU will not be built.) | |
IMUE to D routines generate BMUD, BSUD, and TSUD TRYBos banks from an IMUE bank. Code is in place to cut down on crosstalk. |
|
IMU DtoE code is finished. It takes the BMUD, BSUD, and TSUD banks and generates the IMUE bank. The EtoD package generates the D banks from (at the moment) simulated E banks, and then the DtoE regenerates an identical IMUE bank. An AC++ module (IMUStubModule) to drive this exists in imuMods. |
|
YMON-like code to monitor IMU performance is in place. |
| June 2001 | TRIGMON-like code to compare IMU rates with reconstructed triggers will be needed. Something of this exists in the YMON code. |
| June 2001 | We will need procedures and code for pulsing the amplifiers and running diagnostics. The calibration package is supposed to do the pulsing, and we will have to process the resulting files to run our own diagnostics. This is a bit more awkward than the integrated schemes we used in Run I. |
to CDF Run II Computing and Software