For the past couple weeks Chris Walter (aka Chris "Classic"), Chris
Orth (aka "the New Improved" Chris) and Nat and I have been exchanging
a lot of email about getting the wfd system going- much of it of a
technical and temporary nature. Well, we really should be getting the
news out to a wider audience, but nobody has the time to write summaries.
But we can get some of our technical discussions onto the new wfd mailing
list where you can read or delete at your own interest.
So right now, you may feel you have jumped into the middle of a
discussion. Recent shift reports probably give some flavor of the
debugging that is going on. The effort has two main themes: 1)
thoroughly check out the new data and triggers and ferret out bugs and
oddball behavior and 2) wrestle with the data size issue.
The data size issue is: it is too big. Although I guestimated a factor
of 2x increase at Indiana, it looks like if we do nothing we get a
factor of 3.5x. And that's without the attico TOHM. We turned on and
immediately crippled the Italian's data copying system. Although many of
us have some critical thoughts on how to upgrade the system, there is
actually no reason to record a lot of the junk in this 3.5x increase.
So we are talking about ways to cut back. Watch for a note from Nat
about a recent meeting at LNGS. There are two significant approaches,
both of which we shall use:
1) Disregard as much as possible of single face TOHM
triggers. Although the WFD readout s/w can easily know when only a
single box is hit by the TOHM, the trick is to try to also let it know
if another interesting trigger such as STMP is also present... there
is no need to cut these low rate coincidences and they may contain a
monopole event. This is probably doable by s/w within a uVaX; crossing
uVaXes is much harder, unless we use hardware.
2) Keep only a window of data around the muon events. This has been
planned all along, but we are trying to decide exactly how to do it.
One place is at the DAQ driver level- throw it away for good as we
read it out. Another possibilty is to run a job on the finished raw
data and cut back there. Each of these has pro's and con's.
Anyway, if you are getting this from the macro-wfd list, I am just
letting you know why you may be getting a bunch of technical emails
all-of-a-sudden. If you wish to get off the list, or have someone else
added, send mail to Chris "Classic".
Another good way to check out the latest on the WFD system is to use the
WWW at http://hep.bu.edu/~macro/wfd/. It is a little sparse right now,
but hopefully more stuff will be added soon, particularly software.
Regards,
Ed Kearns