> implementations. For instance, I don't think that it would be a big
> disaster if the WFD's have some small probability of not getting
> re-started occasionally. This doesn't lead to bad data, just a tiny
> inefficiency.
Umm no, it *does* lead to bad data. In the next event you will send a
stop but the WFDs will already be stopped. Then when you read out the
channels for the tanks(which will be different then the last event)
you will get random radioactivity.
Look I want two make two points:
First, as to the implication that I am being "paranoid". As far as I
know I am the *only* person on the experiment to do a full end to end
analysis using the WFDs. The problems I described with the STOP
scheme do not happen extremely rarely; they happen on the event per run
level.
Secondly, I'm not trying to stop this fix from being implemented.
What I have done is make two concrete suggestions as to how to give
the system enough redundancy based on my experience to allow us to
catch the times where something goes wrong. If it takes an extra two
days to add an extra trigger then OK. But neither of the things I
suggested should add a lot of time to the procedure and I claim you
may be protecting yourself from a background problem.
-Chris