<!-- Title: 04:45:17  Mon Aug 19 2002 -->
<!-- Crewchief: Co's of the world -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Consumer Operators elog</pre>


<!-- Date: Mon Aug 19 04:46:01 2002 -->
<pre>DAQMon crashed and was restarted several times (4.6.0int4f).  
However it crashed each time right after the restart. I changed  
the startup script. DAQMon now uses the previous version   
4.6.0int4e with startSubConsumer_test and seems to run stable. 
</pre>
<!-- Author: Martin Hennecke -->


<!-- Date: Fri Aug 30 11:45:30 2002 -->
<pre>TrigMon crashed, core file print out is below: 
 
Core was generated by `TrigMon Consumer/TrigMon/runTrigMon.tcl'. 
Program terminated with signal 11, Segmentation fault. 
#0  0x417a1ae8 in ?? () 
(gdb) where 
#0  0x417a1ae8 in ?? () 
#1  0x417a410a in ?? () 
#2  0x879c4ca in calor::CalTriggerDataMaker::TC2D_monitor (this=0x41e8f008,  
    __403104_45_record=0x24cd1) 
    at /home/cdfsoft/dist/releases/4.6.0int4/include/StorableBanks/StorableBank.hh:384 
#3  0x876fa7f in calor::CalTriggerDataMaker::TC1D_monitor (this=0x41e8f008,  
    __403106_46_record=0xbfff4eb4) 
    at /home/cdfsoft/dist/packages/CalTrigger/V00-00-65/src/CalTriggerMonitors.cc:477 
#4  0x8774606 in calor::CalTriggerDataMaker::TC1D_monitor (this=0x41e8f008,  
    __403106_46_record=0xbfff9738) 
    at /home/cdfsoft/dist/packages/CalTrigger/V00-00-65/src/CalTriggerMonitors.cc:688 
#5  0x8940972 in AppPathMemento::Dump_tcl (this=0xb029a70,  
    __150164_46_o=0xbfff97d0) 
    at /home/cdfsoft/dist/packages/Framework/V00-07-14/src/APPPathMemento.cc:131 
#6  0x892ee2c in AppActionCommand::turnHandler (this=0xb0287a0,  
    __157734_36_argc=-1073768240, __157734_48_argv=0xb825f90,  
    __157734_62_OnOrOff=8 '\b') 
    at /home/cdfsoft/dist/packages/Framework/V00-07-14/src/AppActionCommand.cc:265 
</pre>
<!-- Author: Wolfgang Wagner -->
<!-- Comment: Fri Aug 30 12;28;34 comment by...Wolfgang -->
<pre>I checked the code lines indicated by the core file. 
According what I can see they do not match the actual code.</pre>


<!-- Date: Fri Aug 30 16:10:54 2002 -->
<pre>Last result files transfered to the new storage area at July 
18 were for run 148529 or 148531 depending on the consumers.</pre>
<!-- Author: Wolfgang -->


<!-- Date: Fri Aug 30 17:11:31 2002 -->
<pre>b0dap53 slowed down substantially.  Two HistoDisplayMain process 
were started, one attached to XMon and other attached to  
LumMon, BeamMon and DAQMon.  No canvas were open.  One with 
XMon was using very little memory, but the other was taking 
up 757M(size) and 462M (RSS), which causing swapping Free to be 
very small.  Don' t know why this is happening.  We just 
started both GUI not so long ago, and have not opened any 
canvas to display histos....</pre>
<!-- Author: kaori -->


<!-- Date: Sat Aug 31 10:12:38 2002 -->
<pre>Connection between DisplayServer and HistoDisplay seems to get 
lost for TrigMon once a while: 
 
DisplayServer::pollClients(): Terminating connection to b0dap71.fnal.gov. 
DisplayServer: connectClient(): Client connected from b0dap71.fnal.gov on port 1590. 
DisplayServer::pollClients(): Terminating connection to b0dap71.fnal.gov. 
</pre>
<!-- Author: Wolfgang Wagner -->


<!-- Date: Sat Aug 31 11:07:33 2002 -->
<pre>TrigMon is running extremely slow. I restarted the program assuming it was hanging, was stuck at 1910 events for a long time. At b0dap70 TrigMon was still consuming CPU, about 1 - 3% 
of the CPU time, YMon running on the machine was using &gt; 95% 
of the CPU time. I attached with gdb to TrigMon but could not  
get into stepping mode for some reason. Probably the shared 
libraries need to be loaded by hand. 
 
After the restart TrigMon was still running very slow. No consuming about 8 - 10 % of the CPU time.</pre>
<!-- Author: Wolfgang Wagner -->
<!-- Comment: Sat Aug 31 11;29;13 comment by...Wolfgang Wagner -->
<pre>TrigMon is in fact processing events but at a very low rate.
From the update time of the canvases I conclude that it
is took 16 minutes to process 10 events, i.e. about 0.01 Hz.</pre>

<!-- Comment: Sat Aug 31 12;57;09 comment by...Wolfgang -->
<pre>After starting the new run 150805 TrigMon is doing better
for unknown reasons. It has now already processed 710 events.</pre>

<!-- Comment: Sat Aug 31 12;58;03 comment by...Wolfgang -->
<pre>PS: I did not restart TrigMon though, the program kept running.
 There might be an issue with data bases?</pre>


<!-- Date: Sat Aug 31 15:59:16 2002 -->
<pre>I checked that the automatic archiving of the consumer results 
worked fine for 
 
BeamMon 
DaqMon 
LumMon 
ObjectMon 
SVXMon 
SiliMon 
Stage0 
 
The last files copied for these consumers were for run 150802. 
The first files were for run 148531, 148537, respectively. 
 
I removed those files from /data1/consumer/results/. 
 
</pre>
<!-- Author: Wolfgang -->


<!-- Date: Sun Sep 1 14:04:16 2002 -->
<pre>Evelyn Thompson (XFT expert) told us that the XFT errors  
reported by TrigMon (canvas # 133 LinkerBoard Track Occupancy, 
histogram TrigSim vs. Linker Track Occ.) cannot reproduced by 
offline analysis. The error message can therefore be ignored 
for the time being.</pre>
<!-- Author: Wolfgang  -->


<!-- Date: Thu Sep 5 09:04:10 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-288&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-288  width='300' align='top'></td><td>I post this plot to trigger future improvement by the responsible expert (probably Matt?) During all my shifts of this week this plot showed red boxes in thise two lines, as seen on pad 4 (lower right). The maximum is set to a 0.0004. The deviations are about 0.0005 that's why they are red.  The threshold for the CO to get  alerted is 0.001. So, it's no problem.  This can be found out when changing manually the color scheme, as done in the plot on pad 3 (lower left).   However, many COs are not able to do that since you need  to know a bit about root.   I suggest to set the maximum to a value above the threshold, say 0.0015. Than it would be more clear and easier to see there is no problem.</a></td></tr></table>
<!-- Author: Wolfgang Wagner -->


<!-- Date: Thu Sep 5 11:47:58 2002 -->
<pre>When playing with the YMon display (setting Maximum of histogram 
and zooming in on the plots the HistoDisplay crashed and  
disappeared from the screen, including the shell from which 
it was started. 
 
As a result the xServer was somehow damaged. I could not  
open any new window, neither start a new YMon display via 
the script from b0dap51 nor locally a simple xterm. 
 
I logged in at another terminal  (non X) and kill myXseesion, 
the startx process (running under the cdfdaq account). 
That recovered the machine and I could open windows again, 
also start new YMon and TrigMon displays. 
 
Below I post the log messages of the Xserver: 
 
AUDIT: Wed Sep  4 16:01:09 2002: 16970 X: client 12 rejected from local host 
AUDIT: Thu Sep  5 08:40:48 2002: 16970 X: client 12 rejected from local host 
AUDIT: Thu Sep  5 11:05:27 2002: 16970 X: client 9 rejected from local host 
AUDIT: Thu Sep  5 11:05:28 2002: 16970 X: client 9 rejected from IP 131.225.236. 
165 port 1741 
AUDIT: Thu Sep  5 11:13:02 2002: 16970 X: client 9 rejected from local host 
AUDIT: Thu Sep  5 11:13:03 2002: 16970 X: client 9 rejected from IP 131.225.236. 
165 port 1743 
AUDIT: Thu Sep  5 11:13:18 2002: 16970 X: client 9 rejected from local host 
AUDIT: Thu Sep  5 11:13:22 2002: 16970 X: client 9 rejected from local host 
AUDIT: Thu Sep  5 11:13:34 2002: 16970 X: client 9 rejected from local host 
AUDIT: Thu Sep  5 11:13:52 2002: 16970 X: client 9 rejected from local host 
AUDIT: Thu Sep  5 11:14:48 2002: 16970 X: client 9 rejected from local host 
AUDIT: Thu Sep  5 11:14:48 2002: 16970 X: client 9 rejected from local host 
 
Unfortunately, they do not provide much more insight than  
showing my failed attempts to open a window (message from  
Sep 5 11 am) 
There are no entries documenting the HistoDisplay crash. 
 
Question is whether there is more info available than 
I was looking at. 
 
</pre>
<!-- Author: Wolfgang Wagner -->


<!-- Date: Mon Sep 9 05:38:48 2002 -->
<pre>For reference, the following regions in the CHA tower plot 
are currently hot (flagged as red in occupancy plot): 
W6, pi 3 
E1, phi1 
E7, phi23 </pre>
<!-- Author: Gary Barker -->


<!-- Date: Tue Sep 10 03:28:11 2002 -->
<pre>TrigMon seems to get stuck when a new run is started and 
continues to process the old run. Had to stop/re-start TRigMon  
several times.</pre>
<!-- Author: Gary Barker -->


<!-- Date: Thu Sep 12 06:00:19 2002 -->
<pre>L2 SVT plots at the moment do not appear to be filled although 
the SVT SPYMon plots are (Run # 151434)</pre>
<!-- Author: Gary Barker -->


<!-- Date: Thu Sep 12 06:04:47 2002 -->
<pre>The L2 SVT plots are back again -so no problem!</pre>
<!-- Author: Gary Barker -->


<!-- Date: Thu Sep 12 06:19:09 2002 -->
<pre>Please check SVX distributions for which reference plots are  
placed in front of the SVX monitor (b0dap56). There are some red 
spots. Only page the SVX experts if the red areas increase in size (run # 151434)</pre>
<!-- Author: Gary Barker -->


<!-- Date: Sun Sep 15 01:32:29 2002 -->
<pre>Error rate for TrigMon #2 CLIST energy word errors &gt; 0.01, but there are no errors in the plot.</pre>
<!-- Author: Tiffany Wilkes -->


<!-- Date: Sun Sep 15 01:48:13 2002 -->
<pre>Note solution to above problem:  histrogram was not updated on the screen.  Why don't the plots update regularly?</pre>
<!-- Author: Tiffany Wilkes -->


<!-- Date: Sun Sep 15 03:51:36 2002 -->
<pre>TrigMon is not updating correctly, even with AutoUpdate selected.</pre>
<!-- Author: Tiffany Wilkes -->


<!-- Date: Sun Sep 15 06:37:48 2002 -->
<pre>Regarding error rates in TrigMon #116: 
Expert says that there are not errors in the Trigger.  It is more likely errors in simulation.  Marking Level 1 and Level 2 as good.</pre>
<!-- Author: Tiffany Wilkes -->


<!-- Date: Sun Sep 15 07:48:27 2002 -->
<pre>b0dap70 has been responding very slowly.  It often "freezes up" for a minute or more.</pre>
<!-- Author: Tiffany Wilkes -->


<!-- Date: Sun Sep 15 18:12:05 2002 -->
<pre>It would be nice to have EventStatus option enaibled by default 
in all monitors..</pre>
<!-- Author: Elena Vataga -->


<!-- Date: Sun Sep 15 22:59:23 2002 -->
<pre>Restarting TrigMon for run 151573. 
Since the begining of run other monitors processing 
Trigger 2841819 or so while TrigMin has stopped after ~4000 events.</pre>
<!-- Author: Elena -->


<!-- Date: Tue Sep 17 15:46:51 2002 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>Some guidance for interpreting CPR Wedge Wire Occupancies in YMON: 
 
The CPR has a much stronger luminosity dependence than other detector systems.  So, if you have the good fortune to be taking data at high luminosity, you may see some strange behavior. 
 
On SlideShowerMax, the CPR Wedge Wire Occupancy may be off the scale.  If so, please change the scale by hand.  Right click on the red, reference points.  You should get a menu with title  "TH1FCPRWedgeWireOccupancyRef".  If you get "TH1FCPRWedgeWireOccupancy" you've accidentally clicked on the black data histogram instead.  From  "TH1FCPRWedgeWireOccupancyRef" select "Set Maximum". 0.1 should be high enough for luminosities at least as high as 25E30. 
The reference values may be different than the data, but the shape should be similar. 
 
When you reload the slide the default values will reassert themselves. 
 
Similarly, the 2D CPR wire plots may be off the scale (e.g. you may see a lot of red, or the overflow turquoise color).  Right click on the histogram and "Set Maximum" to 0.1 or something reasonable. 
 
YMon will eventually handle these issues more intelligently.</pre></td></tr></td></table>
<!-- Author: Adam Gibson -->


<!-- Date: Fri Sep 20 18:04:54 2002 -->
<pre>b0dap70:11:~&gt; ps -u cdfdaq 
  PID TTY          TIME CMD 
30791 ?        00:00:00 tcsh 
30910 ?        05:25:11 xterm 
30914 pts/0    00:00:00 tcsh 
30967 pts/0    00:00:00 startSubConsume 
31650 pts/0    00:00:00 runTrigMon 
32419 pts/0    00:00:00 runTrigMon 
32420 pts/0    00:00:03 grep 
32423 pts/1    00:00:00 tcsh 
32503 pts/1    00:00:00 ps 
 
 
2 runTrigMon running</pre>
<!-- Author: Elena -->


<!-- Date: Wed Sep 25 14:32:37 2002 -->
<pre>The problem that we had on b0dap51 (loss of control of mouse) appears to have been solved by replacing the mouse.  However, the same problem appears to have infected the neighboring computer, b0dap50.  It has been fixed, at least temporarily, by rebooting.</pre>
<!-- Author: Robert Miller -->


<!-- Date: Fri Sep 27 19:37:49 2002 -->
<pre>Karen says that printed copies of the SMX calibrations are not useful.  I suspect this is not the only system that printed copies are not useful for, but at least the SMX does not need to be preserved in paper.  Also a "block" of channels that are bad means &gt;32 for the CPR/CES/PPR/PES. 
 
</pre>
<!-- Author: Robert Blair -->


<!-- Date: Sun Sep 29 21:57:11 2002 -->
<pre>We call CMP pager because a spike (one not in the reference plots for YMON) shows up in the slide show for "CMP Occupancy for Part N" at stack 32.  We are a little unsure, since this is cosmic running, whether this is a real problem.  The CMP folks are not concerned since the 2d plot has only a known "red box".</pre>
<!-- Author: R. Blair -->


<!-- Date: Sun Sep 29 21:59:01 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-289&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-289  width='300' align='top'></td><td>Cosmic ray run - Muon slide (see above)</a></td></tr></table>
<!-- Author: R, Blair -->


<!-- Date: Wed Oct 2 20:52:04 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-290&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-290  width='300' align='top'></td><td>Again during CR running we see similar CMP bumps to above.  The 2d plots look like they did before so we surmise this must be okay.</a></td></tr></table>
<!-- Author: R. Blair -->


<!-- Date: Sat Oct 5 07:15:56 2002 -->
When running startDisplay, terminal spits out message 
~/consumer_scripts> aklog: can't get afs configuration (afsconf_Open(/usr/vice/etc)) .  Kaori does not know 
what generates this error. Just a small research project for 
someone.
<!-- Author: JJ -->


<!-- Date: Sat Oct 5 12:29:42 2002 -->
<pre> 
I tried to follow up on red ObjectMon with hadron TDC. It looks like this should be ignored for some time .... 
 
------------------------------------------------------------- 
 
Hi, 
  the red color shows for two reasons - I made a mistake in calculating chi2 difference between reference and actuall histograms, and the cutoff on chi2 should be highier. I can not update anything for some time since I am stuck in Russia waiting for visa. 
  Anyway, hadron TDC information is not used right now by any physics group as far as I know, so there is no reason to worry about those distributions. People get much more detailed information about HADTDC system from YMON. 
 
                                                         --Max 
 
 &gt; 
 &gt; 
 &gt; Hi, I'm DAY CO on shift and we notice ObjectMon showing bad energy plots for CHA, PHA, and WHA. The reference plot says to contact you by email and not to be alarmed. 
 &gt; 
Let me know if CO's should continue to not be alarmed. 
 &gt; 
William 
</pre>
<!-- Author: W. Wester -->


<!-- Date: Sat Oct 5 12:36:26 2002 -->
<pre>Consumer Summary for many recent runs show ObjectMon saying MUONS are BAD. Muon plots look green on the display. This discrepancy causes some confusion. 
 
Is the ObjectMon good MUON descriptor important?</pre>
<!-- Author: W. Wester -->
<!-- Comment: Sun Oct  6 10;36;30 comment by...W. Wester -->
<pre>Expert notified (Muon person on ObjectMon page).		</pre>
<!-- Comment: Mon Oct  7 03;46;04 comment by...slava -->
<pre>There's really something wrong with CMU stubs Z position (the reason for the BAD decision has a description in the appropriate ObjectMon log file). I'll notify the muon experts.</pre>
<!-- Date: Sat Oct 5 16:06:30 2002 -->
<pre>Event Display crashed when I tried to follow the instructions to select a particular trigger. It seemed to cause Xwindows to crash too. There was a screen saver type "Enter password" message on a black (both monitors) background. CTRL-ALT-DEL by a visiting ace seemed to get things back so that Event Display could be restarted.</pre>
<!-- Author: W. Wester -->
<!-- Comment: Sun Oct  6 08;38;46 comment by...W. Wester -->
<pre>This was reported to experts.	</pre>
<!-- Date: Sun Oct 6 00:56:09 2002 -->
<pre>It is unclear (to me at least) what to check for TOF 
calibration run. DBANA popped up only empty plots for 
run 152543.</pre>
<!-- Author: JJ -->
<!-- Comment: Sun Oct  6 14;39;39 comment by...W. Wester -->
<pre>I find TOF plots when I select TOF QIE2 and TOF QIEPED (separatly) and then list runs for them. Plots appear under Options Single. No plots appear if I also LIST other TOF options such as TOFPEDLOOKUP.</pre>


<!-- Date: Mon Oct 7 02:17:29 2002 -->
<pre> 
In the (web) Detector Check List instrustions for CO, the  
instructions say that WHA PMT East wedge 12, eta 10 right  
is dead. The reference book says East 1 Left, eta 9. The 
web page appears to need updating.</pre>
<!-- Author: JJ -->



<!-- Date: Mon Oct 7 05:38:19 2002 -->
<pre>Buried in notes for some of the monitors are instructions to 
make hard copies of plots and save them in such and such a 
binder. If the CO is suupose to preserve printed copies of 
any plots on a regular basis, could we have a summary of 
what/when/where written and linked from the CO web page? 
(Or a note that there are NO plots to print and save on 
a regular basis.)</pre>
<!-- Author: JJ -->


<!-- Date: Tue Oct 8 15:50:06 2002 -->
<pre>Event display just completely disappeared. It seems to be able to be restarted OK. All windows just disappeared.		</pre>
<!-- Author: W. Wester -->


<!-- Date: Thu Oct 10 11:56:40 2002 -->
<pre>Making plots from DBANA (using Save As canvas.ps) always produced a file c1.ps (so additional plots overwrite previous files). I sent an email to DBANA people asking that they address this issue.</pre>
<!-- Author: W. Wester -->


<!-- Date: Thu Oct 10 17:41:37 2002 -->
<pre>Notice SVXMon not showing up on the Consumer Display. SVXMon was absent also under "Consumer Status". Kaori suggests (and it works) to stop the display and then re-start it. She says she put a recent eLog on this subject, but I also put this here.</pre>
<!-- Author: W. Wester -->


<!-- Date: Sat Oct 12 00:31:51 2002 -->
<pre>SiliMon died. restarted successfully.</pre>
<!-- Author: Daniel Jeans -->


<!-- Date: Sat Oct 12 06:12:38 2002 -->
<pre>SiliMon died again.</pre>
<!-- Author: Daniel -->


<!-- Date: Mon Oct 14 13:45:05 2002 -->
<pre>Muon type ObjectMOn plot was red for run 152810; all entries with CMX were lower than expected. Expert thinks it might be due to a reduction in background coming from new Trigger Table. 
Do not need to worry (expecially if CMX phi Stub distribution in 
MuonMonitor Slide show if flat)</pre>
<!-- Author: monica -->


<!-- Date: Sat Oct 19 12:50:08 2002 -->
<pre>With given number of PC assigned for consumer monitoring, 
I am still experimenting where (which pc) to run which processes. 
Some use more memories, more cpu, more network band-width, 
etc., etc.  Idealy, we should have more resources (memory, etc.) 
and we should be getting more, soon.  Meanwhile, it is clear  
now that running Event_display, SiliMon process and SiliMon  
display on b0dap50 was too much which b0dap50 can handle. 
I move siliMon display back to b0dap56 together with SVXMon 
for now.</pre>
<!-- Author: kaori -->


<!-- Date: Mon Oct 21 02:17:57 2002 -->
<pre>modified startDisplay.sh so that SiliMon display will appear 
on b0dap53 top monitor together with XMon. 
Bottom monitor of b0dap56 HistoDisplay shows only SVXMon. 
Hopefully this configuration causes less 'stuck pc's'. 
B0dap50 should only display EventDisplay.  </pre>
<!-- Author: kaori -->


<!-- Date: Mon Oct 21 12:44:53 2002 -->
<pre>I have informed a couple of the ObjectMon experts about red plots we are seeing in ObjectMon: 
 
TauMonitor:  Tau Mass and Track Multiplicity.  Tau Mass is particularly confusing, because it was red with chi squared = 4.6, but the histogram says the cut is 5.  Both plots had 9,235 entries.  The TauMonitor expert said he already knew about these problems. 
 
Muon:  CMU Z (Stub) and CMX Z (Stub) both have chi squared = 2.6, cut is at 2.5.  Also, the Muon Type histogram is always red, even though by eye the distribution is quite similar to the blue reference.</pre>
<!-- Author: cathy n-h -->


<!-- Date: Mon Oct 21 12:54:00 2002 -->
<pre>XMon just disappeared.  Restarted.</pre>
<!-- Author: cathy n-h -->


<!-- Date: Tue Oct 22 00:59:33 2002 -->
<pre>SiliMon turned red. I killed it with ctrl-d and restarted. 
</pre>
<!-- Author: Arnold Pompos -->


<!-- Date: Fri Oct 25 11:27:14 2002 -->
<pre>CONSUMER/STAGE0 
 
Stage0 died for unknown reasons during run 153320.  
We restarted it</pre>
<!-- Author: Jack Cranshaw -->


<!-- Date: Sat Oct 26 10:56:38 2002 -->
<pre>CONSUMER/OBJECTMON 
 
Track Phi bad. CMX Z stub intermittently bad.</pre>
<!-- Author: J. Cranshaw -->


<!-- Date: Sat Oct 26 21:12:26 2002 -->
<b>For COs on shift after the saturday evening Oct 26th</b><br> 
<br> 
We have diagnosed the problem with QIE calibration runs (why some channels have 0 or very wide RMS).  The pedestals are definitely affected, but we don't know the impact on real physics data.  The first store that comes in (after Saturday evening), please check the WHA tower plots, occupancy and mean energy.  We want to check if wcal04 is behaving differently from the other WHA crates.  Whether the answer is yes or no, please make a note in the shift e-log.  Thank you.<br> 
<br> 
wcal04 covers phi 0-5, east side, all eta.  When we looked at run 153327 (friday through saturday morning), we could not see a difference.  We want to confirm what the situation is.
<!-- Author: M Mattson -->


<!-- Date: Mon Oct 28 10:35:19 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-291&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-291  width='300' align='top'></td><td>when i do setup cdfsoftb0 on an online machine and try to open up an old TrigMon file, i get this. Tried 2 different files, result is the same.HistDisp.. program works file and root works fine with, for ex. Ymon files.. What could  be happening here? thanks! NB. i also get   *** Break *** illegal instruction when i click on try to click on these two tabloids.  </a></td></tr></table>
<!-- Author: Muge Karagoz Unel -->


<!-- Date: Sat Dec 14 10:59:12 2002 -->
<pre>SiliMon died so I restarted it.  Everything else is running great.</pre>
<!-- Author: Rick Field -->


<!-- Date: Mon Dec 23 13:58:29 2002 -->
Following the problem of large event size we had yesterday with 
new physics trigger table (run 155711), I have looked at the different silicon banks to check if there were any unexpected behaviour. In the following I am going to attach 3 plots 
<!-- Author: Subir -->


<!-- Date: Mon Dec 23 14:09:12 2002 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-294&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-294' width='300'></a></center>
<!-- Author: Subir -->
<!-- Comment: Mon Dec 23 14;10;05 comment by...Subir -->
Run 155711, New Physics trigger table, ISL Wedge B0 W4 in


<!-- Date: Mon Dec 23 14:10:37 2002 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-295&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-295' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-296&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-296' width='300'></a></center>
<!-- Author: Subir -->
<!-- Comment: Mon Dec 23 14;11;53 comment by...Subir -->
1. Run 155712, New physics trigger table, ISL wedge B0 W4 out
2. Run 155714, Old physics trigger table, ISL wedge B0 W4 out

<!-- Comment: Mon Dec 23 14;13;45 comment by...Subir -->
<pre>Please avoid using sophisticated HTML codes in comments. (click to clear this message)
</pre>

<!-- Comment: Mon Dec 23 14;14;58 comment by...Subir -->
I am going to look at an old rum 154799 (Dec 1) where similar
problem was found. 


<!-- Date: Fri Jan 10 00:57:52 2003 -->
<pre>Consumer ObjectMon ended few times during last hour with 
value 8. Restarted.</pre>
<!-- Author: O. Pukhov -->


<!-- Date: Fri Jan 10 17:43:30 2003 -->
<pre>ObjectMon is crashing the crash is in TimeMonitor: 
 
This is from core_31394 in the runarea. 
 
(gdb) where 
#0  DetEnergy__11TimeMonitorSFP7CellKeyPC8CalTower (__553571_39_key=0xbfff950c, __553571_60_tower=0xe3d87f0) 
    at /cdf/code-Linux/cdfoffline/dist/cdfsoftb0/4.9.0int1g/Consumer/ObjectMon/TimeMonitor.cc:908 
#1  0x84f4d8f in TimeMonitor::addEvent (this=0x41cc1008, __553166_38_anEvent=0xb7e4c18) 
    at /cdf/code-Linux/cdfoffline/dist/cdfsoftb0/4.9.0int1g/Consumer/ObjectMon/TimeMonitor.cc:551 
#2  0x8557515 in ConsumerFramework::addEvent (this=0xae11690, __218557_47_record=0xb7e4c18) 
    at /cdf/code-Linux/cdfoffline/dist/cdfsoftb0/4.9.0int1g/ConsumerFramework/src/ConsumerFramework.cc:170 
#3  0x855baf0 in ConsumerFrameworkModule::event (this=0xae10e08, __T156153560=0xbfff9700,  
    __281427_52_anEvent=0xb7e4c18) 
    at /cdf/code-Linux/cdfoffline/dist/cdfsoftb0/4.9.0int1g/ConsumerFramework/src/ConsumerFrameworkModule.cc:189 
#4  0x86efab1 in APPSequence::event (this=0xadda5f8, __T149128040=0xbfff97c8, __150922_31_anEvent=0xb7e4c18) 
    at /home/cdfsoft/dist/packages/Framework/V00-07-22/src/APPSequence.cc:211 
#5  0x86ddc6c in AppFramework::event (this=0xadd9328, __T153127488=0xbfff9890, __189876_32_anEvent=0xb7e4c18) 
    at /home/cdfsoft/dist/packages/Framework/V00-07-22/src/APPFramework.cc:450 
#6  0x86e01a5 in AppFramework::continueHandler (this=0xadd9328, __190274_36_nEvents=2147483647) 
    at /home/cdfsoft/dist/packages/Framework/V00-07-22/src/APPFramework.cc:878 
#7  0x86dfdf6 in AppFramework::beginHandler (this=0xadd9328, __190261_33_nEvents=2147483647) 
    at /home/cdfsoft/dist/packages/Framework/V00-07-22/src/APPFramework.cc:814 
#8  0x870bf6d in APPEventsCommand::beginHandler (this=0xadd94f4, __151260_37_argc=2, __151260_49_argv=0xbfff99f8) 
    at /home/cdfsoft/dist/packages/Framework/V00-07-22/src/APPEventsCommand.cc:145 
#9  0x870bc2e in APPEventsCommand::handle (this=0xadd94f4, __151230_31_argc=2, __151230_43_argv=0xbfff99f8) 
    at /home/cdfsoft/dist/packages/Framework/V00-07-22/src/APPEventsCommand.cc:91 
</pre>
<!-- Author: Wolfgang -->
<!-- Comment: Fri Jan 10 17;46;41 comment by...Wolfgang -->
<pre>core_31852 is the same</pre>

<!-- Comment: Fri Jan 10 17;48;35 comment by...Wolfgang -->
<pre>core_2810 is the same.</pre>

<!-- Comment: Fri Jan 10 17;50;02 comment by...Wolfgang -->
<pre>core_27299 is the same
</pre>


<!-- Date: Sat Jan 11 04:03:54 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-299&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-299  width='300' align='top'></td><td>ObjectMon #77 (Muon slide) - bad fits for CMU Z, CMX Z and CMP delta x. ObjectMon #78 (Muon slide 1) - hi^2 is more than 2.5 (3.2).</a></td></tr></table>
<!-- Author: O. Pukhov -->


<!-- Date: Sat Jan 11 06:11:27 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-300&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-300  width='300' align='top'></td><td>New bad plots in ObjectMon.</a></td></tr></table>
<!-- Author: Oleg -->


<!-- Date: Sat Jan 11 06:12:28 2003 -->
<pre>TrigMon consumer died few times during the shift.</pre>
<!-- Author: Oleg -->


<!-- Date: Sat Jan 18 10:18:57 2003 -->
<pre>#9  0x89b560c in AppFramework::beginRun (this=0xb1d52a8, __T152493828=0xbfff9f74, __189694_35_anEvent=0xc956a30) 
    at /home/cdfsoft/dist/packages/Framework/V00-07-20/src/APPFramework.cc:365 
#10 0x89b80dd in AppFramework::continueHandler (this=0xb1d52a8, __190162_36_nEvents=2147483647) 
    at /home/cdfsoft/dist/packages/Framework/V00-07-20/src/APPFramework.cc:884 
#11 0x89b7cd6 in AppFramework::beginHandler (this=0xb1d52a8, __190149_33_nEvents=2147483647) 
    at /home/cdfsoft/dist/packages/Framework/V00-07-20/src/APPFramework.cc:814 
#12 0x89e35ed in APPEventsCommand::beginHandler (this=0xb1d5474, __151260_37_argc=4, __151260_49_argv=0xbfffa0a8) 
    at /home/cdfsoft/dist/packages/Framework/V00-07-20/src/APPEventsCommand.cc:145 
</pre>
<!-- Author: Wolfgang -->
<!-- Comment: Sat Jan 18 10;19;38 comment by...Wolfgang -->
<pre>#0  0x97a391f in otl_cursor::open (this=0xc96d648, __137132_42_connect=0x0)
    at /home/cdfsoft/dist/packages/DBObjects/V00-00-64/src/otl/utilsOTL.cc:733
#1  0x97a3887 in otl_cursor::__ct (this=0xc96d648, __137099_15_connect=0x0)
    at /home/cdfsoft/dist/packages/DBObjects/V00-00-64/src/otl/utilsOTL.cc:705
#2  0x97a508a in otl_select_cursor::__ct (this=0xc96d648, __137888_15_db=0x0, __137889_8_arr_size=100)
    at /home/cdfsoft/dist/packages/DBObjects/V00-00-64/src/otl/utilsOTL.cc:1489
#3  0x97a5dc2 in otl_select_stream::__ct (this=0xc96d648, __138453_14_arr_size=100, 
    __138454_14_sqlstm=0xc95937c " SELECT RS.PHYSICSTABLENAME||'_v-'||RS.PHYSICSTABLETAG  FROM RUNCONFIGURATIONS RC, RUNSETS RS  WHERE RC.RUNNUMBER = 156831 AND RC.RS_NAME = RS.NAME ", __138455_15_db=0x0)
    at /home/cdfsoft/dist/packages/DBObjects/V00-00-64/src/otl/utilsOTL.cc:2059
#4  0x97acc42 in otl_stream::open (this=0xbfff9b9c, __140267_10_arr_size=100, 
    __140268_16_sqlstm=0xc95937c " SELECT RS.PHYSICSTABLENAME||'_v-'||RS.PHYSICSTABLETAG  FROM RUNCONFIGURATIONS RC, RUNSETS RS  WHERE RC.RUNNUMBER = 156831 AND RC.RS_NAME = RS.NAME ", __140269_17_db=0x0, __140270_16_ref_cur_placeholder=0x0)
    at /home/cdfsoft/dist/packages/DBObjects/V00-00-64/src/otl/utilsOTL.cc:3885
#5  0x97ac7d7 in otl_stream::__ct (this=0xbfff9b9c, __140239_10_arr_size=1, 
    __140240_16_sqlstm=0xc95937c " SELECT RS.PHYSICSTABLENAME||'_v-'||RS.PHYSICSTABLETAG  FROM RUNCONFIGURATIONS RC, RUNSETS RS  WHERE RC.RUNNUMBER = 156831 AND RC.RS_NAME = RS.NAME ", __140241_17_db=0x0, __140242_16_ref_cur_placeholder=0x0)
    at /home/cdfsoft/dist/packages/DBObjects/V00-00-64/src/otl/utilsOTL.cc:3849
#6  0x87d41ea in _c::__ct__10TriggerMapFQ2_3std78basic_string__tm__58_cQ2_3std20char_traits__tm__2_cQ2_3std18allocator__tm (
    this=0xc959138, __157279_31_databaseForTrigger=0xbfff9e58)
    at /home/cdfsoft/dist/packages/Level3Mods/V00-00-83/src/TriggerMap.cc:106
#7  0x877f848 in APPConsumerInputModule::mergeBitLists (this=0xb209810)
    at /home/cdfsoft/dist/packages/ConsumerInterface/V00-00-50/src/APPConsumerInputModule.cc:327
#8  0x877ba23 in APPConsumerInputModule::beginRun (this=0xb209810, __T155562204=0xbfff9ef8, __255093_45_anEvent=0xc956a30)
    at /home/cdfsoft/dist/packages/ConsumerInterface/V00-00-50/src/APPConsumerInputModule.cc:261
#9  0x89b560c in AppFramework::beginRun (this=0xb1d52a8, __T152493828=0xbfff9f74, __189694_35_anEvent=0xc956a30)
    at /home/cdfsoft/dist/packages/Framework/V00-07-20/src/APPFramework.cc:365
#10 0x89b80dd in AppFramework::continueHandler (this=0xb1d52a8, __190162_36_nEvents=2147483647)
    at /home/cdfsoft/dist/packages/Framework/V00-07-20/src/APPFramework.cc:884
#11 0x89b7cd6 in AppFramework::beginHandler (this=0xb1d52a8, __190149_33_nEvents=2147483647)
    at /home/cdfsoft/dist/packages/Framework/V00-07-20/src/APPFramework.cc:814
#12 0x89e35ed in APPEventsCommand::beginHandler (this=0xb1d5474, __151260_37_argc=4, __151260_49_argv=0xbfffa0a8)
    at /home/cdfsoft/dist/packages/Framework/V00-07-20/src/APPEventsCommand.cc:145
</pre>

<!-- Comment: Sat Jan 18 10;20;08 comment by...Wolfgang -->
<pre>These are the outputs from TrigMon core files.</pre>

<!-- Comment: Sat Jan 18 15;57;30 comment by...Wolfgang -->
<pre>This crash was due to a data base access in ConsumerInputModule
to retrieve trigger information when specifying a particular 
trigger in the tcl. Once this passage is disabled, TrigMon
did not crash anymore.</pre>


<!-- Date: Sat Jan 18 16:07:01 2003 -->
<pre>Status of Consumers: 
 
Consumers have been modified to run with cdfonint. 
 
startSubConsumer.csh script is modified to start the 
run...Mon scripts with more variables which specify the 
CSL machine and the DATABASETAG. 
 
YMon tcl has been modified in the runarea, i.e. the 
CalibrationManager talk-to. 
 
ObjectMon tcl has been modified. RunSummary access is disabled, 
some Monitors are turned off because we don't have COT running. 
I.E.: TrackMonitor, JpsiMonittor, TauMonitor 
 
DAQMon is now run with a tcl from the runarea, previously it used 
the tcl from the release. A view lines had to be changed. 
 
Hope these explanations help to get things back to normal when 
the cdfonprd is back running again which is supposed to happen 
early next week.</pre>
<!-- Author: Wolfgang -->
<!-- Comment: Sat Jan 18 16;31;14 comment by...Wolfgang -->
<pre>I have also globally disabled the access to the Consumer Summary
data base. So no consumer currently attempts to write a summary
to the data base. That is also done in startSubConsumer, pretty much on the top. If the variables
CONSUMER_WRITE_SUMMARY_DB 
WRITE_ERROR_MESSAGE_SUMMARY_TO_DB 
are not defined, i.e. setenv commented out there is no access.</pre>


<!-- Date: Tue Feb 18 06:27:45 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-301&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-301  width='300' align='top'></td><td>SVTList error in L2 Magic bus during a Rick's Run. This is ok, because SVT is not used.</a></td></tr></table>
<!-- Author: santi -->