After many long hours in JFK-hell, I'm finally ensconced at LNGS...
here's an update on the current monitor situation, and comments about
that last burst.
First, the current status:
-- I'll be in Italy until July 5. Erik now has the beeper. When
he leaves for Italy around the first week of June or so, he'll
FedEx the beeper to Alec, who will keep it until I get back to Caltech.
-- All alarmees have now been officially added to the alarm mailing list.
-- A new version of the monitor, which I have been testing over the
past few weeks off disk files, will be ready within a few days.
The main changes are:
1. I have included a 2 ms coincidence cut, to allow veto
of inter-SM muons online (the coinc time window has to
be this large because the online synching of the different
SMs' ERP clocks is only good to a couple of ms).
2. Non-cut hit info is also kept and written out for burst candidates.
These changes required some fairly major gutting of the code, due to
the necessity of keeping much more info in memory in order to do the
ms-cut(and keep the intermediate info) I'll post more details about the
this new version to this mailing list when I officially graft the
changes onto the running monitor.
-- I'm working on a memo about the new monitor code, and if you are on
the alarm mailing list you should get a copy of this and read it when
it is ready. Estimated time of completion: 1 week. Meanwhile, I
wrote up smaller document for Erik, called "Instructions for
Beepersitters". Although this note contains some beeper-specific stuff,
along with the earlier ERP GC monitor memo it contains most of the
information you'll need to evaluate bursts. So if you're on the alarm
list you should check it out. I will put this on the Caltech MACRO
home page -- look under "MACRO notes".
Now, some notes about Thursday morning's burst:
As Erik and Alec have already pointed out, the highest probability of
a GC alarm seems to be when I am within 2 hours of getting picked
up by the Super Shuttle to go to LAX. I dunno if this works for
*real* GC's as well...
-----------------------------------------------------------
Erik> It was a combined search result with multiplicity 1 over threshhold.
Erik> I found the time structure intersting and the position and box
Erik> distribution pretty random.
Yes, the time structure is the most-GC-like thing about this
burst... about half the hits in the first couple of seconds. Energies
don't really match what you expect for a real GC though, so given that
it's just one over multiplicity threshold, this isn't a convincing
enough burst.
Erik> The 2 large energies must be associated
Erik> with muons.
Yes, probably-- anything with energy depositon around 40 MeV is
suspect as a muon. If they are inter-SM muons (and at least one is
according to Rich -- see below) at least one of these would have been
cut with the soon-to-be-installed version of the monitor with the 2 ms
coincidence cut.
Erik> BTW, here's the output file from VXMACB for the latest burst. Aren't
Erik> we supposed to receive this automatically?
Not yet -- right now only the summary-string gets sent (see the
beepersitter memo). Sending more complete burst info by email is one
of a long list of things on my to-do priority queue, which just hasn't
yet fought its way up to the top. One day it will.
Erik recently suggested to me that I put this large burst info file as
plan.txt, so you can get the info when you finger michpub@vxmacb.
Then you won't need to actually log on to get the info. I think this
is a good idea, and doing this has also gone onto my priority queue
(with relatively high weighting).
-------------------------------------------------------
Alec > SM's 1 and 6 are not reporting, and this was 2 hours into the run - have the
inefficiencies struck again?
Don't know, I'll check. They may have just happened to have had no
non-cut hits during the burst time period though (it will be possible
to check this better with the new monitor version which includes the
intermediate info.)
Alec> Good practice checking it out, though. Kate, having the monitor program write
Alec> a custom .com file is a good thing. I will expand that .com file to include a
Alec> logical pointing to the right ntuple, to make PAWing it easier.
Good idea.
Alec> Is there a .kumac that's useful for making the plots of interest quickly?
Nope, not yet-- that's another item on the queue...
----------------------------------------
Rich> Sorry to take so long to respond, but I've been adding some new stuff to
Rich> my analysis code to keep track of the hits that get tossed out, so I can
Rich> compare my burst search to Kate's.
< Rich's hit list deleted >
Rich> Notes: The good thing to note is that one of the two 40+ MeV events is
Rich> indeed a Muon since there was a time coincidence with one of the muon
Rich> triggers other than the ERP. Hit #11 is probably also a muon, but it
Rich> triggered nothing else in the detector. The three hits I marked with
Rich> ******** are not reported in my analysis either because they are not
Rich> single box hits, or because the energy reconstructed below 6 MeV. I
Rich> suspect that they are low energy hits associated with other ERP hits
Rich> on adjacent supermodules. It could be the calibration constants though.
Rich> I'm using the VAXGS::DISK$MACRO:[MACROCAL.DB] version of the calibration
Rich> constants. The three events I show bad TDCZ for I will have to look into
Rich> since Kate seems to get good positions for these hits.
In general, the monitor events seem to match Rich's analysis, which is
good. The main discrepancy that we need to understand seems to be in
the reconstructed positions of several events. The monitor code uses
low threshold TDC values if the high thresh TDC's give unreasonable
values, which I think we need to do in light of the fact that now the
front end TDC thresholds are higher than the MBT thresholds. (Also, I
do not reconstruct a position using ADC's to compare to the TDC
position). Rich, do you use low thresh TDC info? The discrepancy
could also be partly due to using different sets of calib constants as
Rich points out -- Rich, which run do you use? The monitor is using
the standard run 9819 constants (copied from VAXGS).
Another note: some of the hits which the monitor included but Rich's
analysis cut may end up getting cut by the new version of the monitor
which does a 2 ms coincidence cut, e.g. for the current monitor
version, a muon with 2 hits in one SM and 1 hit in another SM will
have the 2 hits cut but the single hit will remain; however the new version
will cut all three hits, as will an offline analysis with access to ERP
muon and ST info such as Rich's.
Kate.