> Dear WFD folks,
>
> I haven't heard from anybody regarding the fix for the WFD problem
> I e-mailed you about last Tuesday. I'll assume everybody's happy with
Hi Eric,
Thanks for all of the hard work. I'm sorry I haven't been active in
the discussion. I'm going crazy right now trying to finish my thesis.
I wanted to say a little bit about the fast stop proposal. In my
experience, in the WFD analysis the biggest problems have been caused by
the STOP masters. You absolutely need them to work correctly otherwise
you will look in the wrong place for the data. Unfortunately, they are
plagued by a host of problems. It is somewhat tricky to write the
code to catch all of them because of things like the fact that the
STOP masters count to different maximum values depending on the run
and the SM. For this reason I have found it is best to use the
triggers themselves to make decisions about where the data should be
and just check the STOP masters for errors.
Because of this I am a little worried about making the STOP more
complicated. I would think at a minimum you should create another
trigger for this condition. It would be a bad idea to rely on the
STOP master times themselves to figure out if a fast STOP happened.
The most important thing is that you need to be able to *reliably* and
deterministically figure where the data should be on an event by event
basis.
So try to keep this in mind and keep up the good work.
Thanks,
-Chris
> without the fast stop will lose ALL WAVEFORM INFO. COULD THIS FAST
> STOP BE A SOLUTION BY ITSELF (no hardware modification)?
So you are saying this would work completely except for a certain range
of betas we would only have one face? Have I understood correctly?