Agenda:

• LUT's for CTT to STT translation [Bill Lee]
• about road calculation [Stephan Linn]
• STT simulator status and plans [Silvia Tentindo-Repond]
• CPU order [Bill Lee]
• Nes about beam spot monitoring [Yi Dai]
• AoB

Minutes:

1. Status of LUT for CFT to SMT translation [Bill Lee]
   (see Bill's transparencies ppt, pdf)
   Bill has generated first LUT for one detector, using the algorithm in Sailesh's code. We'll need a separate LUT for each detector (barrel/layer/side). Code takes now about 3 minutes per detector.

   To do and questions:

   • generalize, do other tables
   • determine allowed CTT sectors for STT sectants
   • what radius to use?
     
     average radius of detector? of ladder?

     road width?

     note road width in Sailesh's code is hard-coded, not clear where it comes from, and is about 2 times wider than what is given in Uli's note
     (see also SLL's presentation)

   Details about the first LUT (from message by Bill Lee to Shweta):
   There are two files: the short version and the long version.

   The difference is that the long version has all possible values of a 17 bit number as the index. The short version has only the valid bit values of a track.

   Both tables are the LUT for the detector located at Barrel 1, Layer 1, and Ladder 1. Next I will generate a table(s) for all possible detectors. would you like this as 432 tables like this one, or would you like one big table?

   For both tables, the format is the same. A couple of example lines are:

   0 77 10b
   23 6f 102
   5aff 13e 17f
   6000 17f 17f
   6001 7ff 7ff
   6002 7ff 7ff
   faff 0 1f
   10000 0 5e
   11111 4 9e
   13aff 39 ce

   The first column is the 17 bit index. The first (most significant) five bits are the CTT Sector mod 20. The second six bits is the H fiber (0 - 43). The next bit is the ptsign. The next 2 bits is the ptbin and the last 3 bits is the ptext. Or,

   int idx = ptext + (ptbin << 3) + (ptsign << 5) + (HFiber << 6) + ((CTTSector%20) << 12);

   I understand that this is probably not the ordering of bits that you would like, so if you will send me the proper order, I will fix it.

   The second column is the low (more clockwise in phi) chip and channel packed in 11 bits, with the high 4 bits the chip and the remaining 7 bits the channel. The third column is the high chip and channel.

   Would you like for the leading zeros to be printed? For instance the second example line would become:

   00023 06f 102

   For this detector, the minimum chip and channel is 0 while the max is 17f. On other detectors, the maximum chip and channel could be as high as 27f.

   Note that this means that we only need 10 bits of information for chip and channel. This is reduced by 1 bit because we don't use the stereo chips.

   You will also see some values where both the high and low chip/channel equal 7ff. These are the cases where either the road misses the detector completely, or the the 17 bit index is not valid.

2. About roads for the STC hit filter [Stephan Linn]
   (see Steve's note ps)
   • need better understanding of what CTT FPGA does
     
   • information received from Kin Yip is not complete; note Kin Yip is leaving -- person replacing him is Jain Vivek;
   • SLL will talk to him and try to complete information;
   • long discussion about road definition --
     consensus:
     • for the moment it is important to get some reasonable estimate of what roads should look like, to be used for testing of FPGA code;
     • should implement code using LUTs in simulator ; can use MC or real data to check and optimize roads;
     • now, have to make sure that all tools are developed which are needed to generate, optimize and download LUTs.

3. STT simulator status [Silvia Tentindo-Repond]
   (see Silvia's transparencies ppt, pdf)
   the 2nd cluster algorithm has been implemented [SLL],
   work on getting rid of TranslationManager is continuing,
   still some problems with releasing.

4. CPU purchase [Bill Lee]
   Bill points out that CPU's lent by Fritz need to be given back sooner than expected (see message from Fritz Bartlett ppt, pdf), so we have to get moving on ordering them.
   After some discussion, there is a consensus that individual institutions BU, Columbia, Stony Brook) will do that on their own.

5. Report from on-line vertex meeting [Yi Dai]
   

   Yi Dai has started to work on questions related to communication of beam parametres to the accelerator, and logging of this information in the relevant data bases. There was a meeting on 23 August (organized by Michael Begel) to discuss issues related to beam monitoring.
   Here is the summary slide:
   
   

   The D0 to accelerator communications are organized as follows:
   The EPICS control system communicates with the accelarator through the EPICS/ACNET gateway via ACNET. The luminosity server, FPD, radiation monitoring and Vertex EXAMINE send information to the EPICS control system which also handles the connection to the Archiver.
   

   
   At the meeting, a list of items to be sent to the accelerator by the Vertex EXAMINE was established:
   

   X(z=0)
   SIGX
   TIMEX (timestamp)
   Y(z=0)
   SIGY
   TIMEY
   DXDZ
   SIGDXDZ
   TIMEDXDZ
   DYDZ
   SIGDYDZ
   TIMEDYDZ
   XYCORR
   SIGXYCORR
   TIMEXYC
   XZCORR
   SIGXZCORR
   TIMEXZC
   YZCORR
   SIGYZCORR
   TIMESIGYZC

   According to Stu Fuess, the expected rate of events available to be processed in Examine is limited by the Examine processing time itself. I quoted that, after optimizations, we expect to be able to handle at least 10 Hz, provided that the tracks are immediately available.
   At this point, no one is sure about how often one will need to update the database. The current estimate is somewhere between 1 to 5 minutes.

   One of the questions raised was whether the beam information had to be written onto a data base, and Yi posed this question to the STT group. There was a very strong consensus that everytime beam information is sent to the acccelarator for use in the beam position feedback system, it has to be also written to a database.

   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   presently existing D0 ACNET Devices (Name and Description)
   -----------------------------------------------------------
   Device Name.... Description
   -----------------------------------------------------------
   C:D0XIP .......... D0 Xip [microns]
   C:D0YIP .......... D0 Yip [microns]
   C:D0SIGX ....... D0 X IP Sigma [microns]
   C:D0SIGY ....... D0 Y IP Sigma [microns]
   C:D0DX .......... D0 X IP Slope [microns/meter]
   C:D0DY .......... D0 Y IP Slope [microns/meter]
   C:D0XTD ........ D0 Xip Time to Date [sec since 1-1-70]
   C:D0YTD ........ D0 Yip Time to Date [sec since 1-1-70]
   C:D0SXTD ...... D0 X IP Sigma Time to Date [sec since 1-1-70]
   C:D0SYTD ...... D0 Y IP Sigma Time to Date [sec since 1-1-70]
   C:D0DXTD ...... D0 X IP Slope Time to Date [sec since 1-1-70]
   C:D0DYTD ...... D0 Y IP Slope Time to Date [sec since 1-1-70]
   ------------------------------------------------------------
   

   STT infrastructure needs
   Jerry Blazey points out that he needs information about infrastructure needs for the STT, e.g.:

   • cabling
   • rack monitors
   • power supply supports
   • etc.

   Jerry and Bill Lee will get together next week (4 Sept.?) to talk about this.