Radphi Work Days January 16-17, 2003

(notes taken by Richard.Turk.Johannes@uconnecticut.educate.adsl.athelos.com )
University of Connecticut
Storrs, CT

agenda

The workday is a kind of extended internet meeting devoted to working on Radphi analysis and the NIM article. The general structure will be a sequence of working periods of a few hours interspersed by progress reports from various working groups. The following should be on the task list.
  1. Generate and collect input for NIM article
  2. Edit NIM article
  3. Frame up the kinematic fitting tool
  4. Produce benchmark samples that determine LGD resolution
  5. Find the pi0 signal in the BGV

work plan

  1. People will come and go as they need to. The schedule of presentations and periods of common discussion will be posted.
  2. There will be a vrvs conference room open during the entire period for shared discussions. Small groups will meet there and then go off to other rooms or one-on-one sessions if it gets congested.
  3. People are encouraged to work on more than one topic. While none of the above tasks will probably be finished in two days, the more we get done the closer we are to our goal of a physics result.
  4. For each project a kind of online log book will be generated by the end of the workshop, so that the results will be preserved and allow the shared development to be carried on with less interaction.

post-meeting summary

The workdays went very well. We met periodically via internet conferencing (vrvs) and then went away to carry out assigned tasks. The work focused on completing two projects that were started during our last collaboration meeting and launching two new ones. For each project there was a leader who was in charge of posting results and open questions on a project web site.

Existing projects being completed:

  1. gather missing materials for NIM article (S. Teige)
  2. collect final results from pass 0 (D. Steiner)

New projects being launched:

  1. kinematic fitter (D. Krop)
  2. benchmark samples for known reactions (M. Kornicer)
Please refer to the above web sites to see the progress made. In particular, Scott now has all of the input that he requested from various groups for input to the NIM article. I post my own input on gate widths here in case it has not yet made it onto the web site.

ADC gate width 125 ns (all channels)
BSD OR width 30 ns (within individual layers)
tBSD AND width 20 ns (between different layers)
Tagger OR width 5 ns (7 ns double-pulse resolution in scalers)

trailing note from C. Steffen

I am 95% sure that we had a different gate width for the ADC channels for the LGD as for the other detectors, due to the long pulse times of the FEU-85-3s. Unfortunately, it will take some digging in the log book to figure that out.

[from C. Steffen, June 10, 2003]

Sometime after the run, in the winter of 2000/2001, I logged on to the radphi account at Jlab and discovered that the xrdbFiles.map had a date of July 22, which I knew wasn't right. That file was, I'm sure, modified on our last day of running on August 1. I talked to the sys-admins at the lab, and had them restore the file to its state as soon after August 1, but not before. They did, and so that file (with the _RESTORED suffix) is the most complete listing of trigger settings for the whole run.

Lacking the tools to look at that file properly, I just fired it into emacs. The config file, which is what is stored there, is in plain text, and so easy to read. Looking at a point about half way thorugh the file, I see a section that looks like this: 

camac.cr.0.slot.11.module: LRS_2323
camac.cr.0.slot.11.ch.0.mantissa: 1000
camac.cr.0.slot.11.ch.0.exponent: 0x0
camac.cr.0.slot.11.ch.0.latch: FALSE
camac.cr.0.slot.11.ch.0.delayWidth: 0x0
camac.cr.0.slot.11.ch.1.mantissa: 250
camac.cr.0.slot.11.ch.1.exponent: 0x0
camac.cr.0.slot.11.ch.1.latch: FALSE
camac.cr.0.slot.11.ch.1.delayWidth: 0x0
(I verified in my LeCroy catalog that a 2323 is a variable delay module.) This corroborates what I vaguely remember about the earlier configuration of the gate generation, from perhaps the 1999 run. Channel 0 generates the very long gate for the basetest trigger, 1000 ns. The other gate is the normal gate for all the detectors, 250ns (the canonical photo-tube value pre-2000).

If I look at the corrosponding section near the bottom of the file (sometime late in the 2000 run): 

camac.cr.0.slot.11.module: LRS_2323
camac.cr.0.slot.11.ch.0.mantissa: 140
camac.cr.0.slot.11.ch.0.exponent: 0x0
camac.cr.0.slot.11.ch.0.latch: FALSE
camac.cr.0.slot.11.ch.0.delayWidth: 0x0
camac.cr.0.slot.11.ch.1.mantissa: 100
camac.cr.0.slot.11.ch.1.exponent: 0x0
camac.cr.0.slot.11.ch.1.latch: FALSE
camac.cr.0.slot.11.ch.1.delayWidth: 0x0
This also matches what I remember. The way I believe it was set up was an external moduel setting the 1000ns gate width for the basetest trigger (since we didn't expect to tune that one at all. Then the two halves of the 2323 were the LGD channels on the ch0 gate, and all the other detectors on the ch1 gate. We can ask Paul to check the electronics diagrams, but this verifies to me what I remembered, that the gate for the LGD and the other detectors was different, and what the values were.

ADC gate width 140 ns (LGD)
100 ns (all other detectors)
BSD OR width 30 ns (within individual layers)
tBSD AND width 20 ns (between different layers)
Tagger OR width 5 ns (7 ns double-pulse resolution in scalers)

This page is maintained by Mihajlo Kornicer