<!-- Title: 16:20:50  Fri Aug 10 2001 -->
<!-- Crewchief: Rick Field -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Starting a new CO log file... the old one is getting too long.</pre>


<!-- Date: Fri Aug 10 16:33:37 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-79&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-79  width='300' align='top'></td><td>Showing Franco how to put a picture in the log book.</a></td></tr></table>
<!-- Author: Rick Field -->


<!-- Date: Fri Aug 10 20:39:46 2001 -->
<pre>First night on the job</pre>
<!-- Author: Franco Rimondi -->
<!-- Comment: Fri Aug 10 20;40;38 comment by...Franco Rimondi -->
<pre>Having good time</pre>


<!-- Date: Sat Aug 11 01:16:57 2001 -->
<pre>XMom table canvas shows no level 3 accepts. we checked with ace level three is working perhaps XMon level three accept not implemented or is broken.</pre>
<!-- Author: flanagan -->


<!-- Date: Sat Aug 11 02:16:19 2001 -->
<table><tr><td><a href=/elog/notebooks/consumer-ops/Sat_Aug_11_2001_021604.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-81  align='top'></td><td>test add graph YMon showermax plot has spikes.</a></td></tr></table>
<!-- Author: flanagan -->


<!-- Date: Sat Aug 11 06:20:38 2001 -->
<pre>A new CO Home Page apppears under Bookmarks, Consumer Operator.</pre>
<!-- Author: W. Wester -->


<!-- Date: Sat Aug 11 08:57:40 2001 -->
<pre>=================== 
How to STOP SVXMon 
=================== 
As you know, to stop consumer monitors (YMon, TrigMon, etc...), 
normally we go to the little x-window running the monitor, and 
hit CTL-C to kill it.  However, SVXMon does not stop by doing 
this.  So I asked Igor (SVXMon writer) how to stop SVXMon and 
here is his reply: 
 
 
Hi Kaori, 
 
SVXMon produces an interactive prompt after Ctrl-C. You may 
need to wait a few seconds because it may be in the middle 
of some event processing. Type "stop" at the prompt, and it 
will exit after writing a root file. 
 
If SVXMon gets into an infinite loop or something like that 
then Ctrl-Z should help (and then kill). 
 
Regards, 
Igor 
===================== 
So, the key is type "stop" at the SVXMon prompt.</pre>
<!-- Author: Kaori -->


<!-- Date: Sun Aug 12 10:59:16 2001 -->
<pre>The screens on nodes b0dap51 and b0dap52 are frozen (do not respond to mouse action). However, consumer monitoring processes of TrigMon and YMon are running fine. So I guess the screens are 
simply hung. I do not know how to recover them. Paged Kaori.</pre>
<!-- Author: Soo-Bong Kim -->


<!-- Date: Mon Aug 13 11:40:27 2001 -->
<pre>Looked at the calibration result of COT for run 123634. 
(DBANA)</pre>
<!-- Author: Soo-Bong Kim -->


<!-- Date: Mon Aug 13 14:54:21 2001 -->
<pre>Checked the calibration results of CEM LED (run 123681) 
and Xenon (run 123686). OK.</pre>
<!-- Author: Soo-Bong Kim -->


<!-- Date: Mon Aug 13 14:58:39 2001 -->
<pre>Checked TOF calibration results of run 123690. OK. 
(DBANA)</pre>
<!-- Author: Soo-Bong Kim -->


<!-- Date: Wed Aug 15 01:28:19 2001 -->
CO's - please watch TrigMon slideshow - L2 Magic Bus slide.  In the space on the x axis from 4 -5 there should always be at least 1 word.  This corresponds to the CLIST board in the L2de00 crate.  If CLIST does not send out a word for an event then the data will be out of sync and you will be taking garbage.
<!-- Author: hray -->


<!-- Date: Thu Aug 16 09:11:25 2001 -->
<pre>Checked calibration results using DBANA: 
  CEMLED (run 123924) 
  CEMXEF (run 123926) 
  COTCHANT0 (run 123928) 
  TOF (run 123931) 
 
OK!</pre>
<!-- Author: Soo-Bong Kim -->


<!-- Date: Sat Aug 18 10:58:17 2001 -->
<pre>Last store killed before day shift.  Waiting for next store.  Preparing for cosmic run in the meantime.  Checked COT calibs (run 124114) using DBANA.  (Slow Saturday morning.)</pre>
<!-- Author: Hung-Chung -->


<!-- Date: Sat Aug 18 12:33:37 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-82&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-82  width='300' align='top'></td><td>CMP spike.  Hyunsoo noticed it yesterday and is on the job.</a></td></tr></table>
<!-- Author: Hung-Chung Fang -->


<!-- Date: Sat Aug 18 14:29:31 2001 -->
<pre>b0dap55, b0dap56 X servers are constantly crashing.  quite annoying.</pre>
<!-- Author: Hung-Chung Fang -->


<!-- Date: Sat Aug 18 15:14:23 2001 -->
<pre>Store #643.  Very low intensity (0.18 E30).</pre>
<!-- Author: Hung-Chung Fang -->


<!-- Date: Sat Aug 18 20:56:16 2001 -->
<pre>There was a problem with the monitor display of b0dap51. It was blinking and was not possible to control it. 
 
After calling an expert we have to reboot</pre>
<!-- Author: Alberto Ruiz -->


<!-- Date: Sun Aug 19 04:51:22 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-83&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-83  width='300' align='top'></td><td>Bin 28 in the CES plots is much higher than normal.</a></td></tr></table>
<!-- Author: Robert Harr -->


<!-- Date: Sun Aug 19 05:23:58 2001 -->
<pre>No histograms appear in the "Cluster MonCanvasAll" slide.  No 
axes, nothing.  The 3 HitMap slides have empty histograms.  Is  
there a problem with these histos?</pre>
<!-- Author: Robert Harr -->


<!-- Date: Sun Aug 19 12:16:17 2001 -->
<pre>Continuing with store #643 at very low luminosity. Nominal luminosity at B0 is .12E30.  No stacking will occur until tomorrow.  Looks like another slow shift for today (and maybe tomorrow).</pre>
<!-- Author: Hung-Chung Fang -->


<!-- Date: Sun Aug 19 15:27:57 2001 -->
<pre>Trip on COT SL2 P12. Same one as a few days ago. Experts called.</pre>
<!-- Author: Hung-Chung Fang -->


<!-- Date: Sun Aug 19 20:01:14 2001 -->
<pre>A new DBANA manual (note 5697) has just been posted 
ands a hard copy of it is located in the beginning of the current  
DBANA folder.</pre>
<!-- Author: vaia -->


<!-- Date: Sun Aug 19 22:28:38 2001 -->
<pre>DBANA :look at the COT calibration results of Run 124177 
</pre>
<!-- Author: Alberto Ruiz -->


<!-- Date: Sun Aug 19 22:41:27 2001 -->
<pre>looking at the DBANA results of the TOF calibration for run 124179. Ok</pre>
<!-- Author: Alberto Ruiz -->


<!-- Date: Sun Aug 19 23:38:52 2001 -->
<pre>Look at the results of the DBANA for the calibration of Calorimeters from run 124180: 
 
Bad channels reported: 
CEMQIE : Wedge  5E, Ch. 7 
CHAQIE : Wedge  8E, Ch 13 
         Wedge 16E, Ch  4 
PEMQIE : Wedge  4W, Ch  0 
         Wedge 17W, Ch 19 
WHAQIE : Wedge 21W, Ch  7 
PHAPED : Wedge  0W, Ch  0 
CEMPED : !! When trying to open the window gaves a Break                      segmentation violation !! 
 
 
For Run 124181, the results for CEMLED are: 
          Wedge 21W, tower 3, PMT 0 ADC-Count 0. </pre>
<!-- Author: Alberto Ruiz -->


<!-- Date: Mon Aug 20 04:10:27 2001 -->
<pre>Tonight we are having problems with lost connections (broken  
pipes), twice with b0dap55 and once with b0dap56.  The consumer 
displays die after the connection is lost, and before they can 
be restart, "xhost +" must be issued from the afflicted machine. 
A similar problem seems to happen to the event display on  
b0dap50.  What should be done?  Perhaps the scripts could ensure 
that the appropriate authorizations are set for the displays.</pre>
<!-- Author: Robert Harr -->


<!-- Date: Mon Aug 20 07:44:53 2001 -->
<pre>Apparently two problems: 
1.  TrigMon consumer fails repeatedly.  Process aborts with  
"signal 11". 
2.  YMon and BeamMon displays terminate abruptly.  After  
DisplayServer: connectClient(): Client conneted from ... 
comes immediatly: 
DisplayServer::pollClients(): Terminating connection to... 
 
I did issue "xhost +" commands on the appropriate machines.</pre>
<!-- Author: Robert Harr -->


<!-- Date: Mon Aug 20 09:39:26 2001 -->
<pre>We put new online monitor release (3.18.0int3e) as "current".  
Since there are no colliding beam, we tested with partition 14.  
TrigMon and L3RegionalMon aborted.  Others are ok.  
We leave the new release as default for now.</pre>
<!-- Author: Kaori -->
<!-- Comment: Wed Aug 22 18;05;32 comment by...Matt -->
TrigMon crashes due to problems in the database access in CalTrigSim.  I have put a new runTrigMon.tcl file in /data1/consumer/runarea/TrigMon/Consumer/TrigMon which has CalTriggerDataMaker and CalTriggerMonitor turned off.  This file will be picked up automatically with the normal CO startup scripts.
<!-- Date: Mon Aug 20 23:45:18 2001 -->
<pre>All the consumers are running with the new release without any problems</pre>
<!-- Author: Alberto Ruiz -->


<!-- Date: Tue Aug 21 00:29:21 2001 -->
<pre>Experiencing troubles with TrigMon.  Trying to use Matt's  
development version.</pre>
<!-- Author: Robert Harr -->


<!-- Date: Tue Aug 21 01:13:24 2001 -->
<pre>Some of the reference plots are outdated.  For instance, the  
ObjectMon plots are substantially changed.  Updated versions 
will be appreciated.</pre>
<!-- Author: Robert Harr -->


<!-- Date: Tue Aug 21 07:19:01 2001 -->
<pre>Matt's version of TrigMon has run for most of the night without 
crashing! 
 
There were some event display crashes, one while I was watching. 
No discernable reason for that crash.</pre>
<!-- Author: Robert Harr -->


<!-- Date: Tue Aug 21 22:43:59 2001 -->
<pre>TrigMon consumer is crashing continuosly !. 
 
There is a mistake in the Consumer Status Page run numbers. They said 124337 instead 124397, but they are really running 124397 !!</pre>
<!-- Author: Alberto Ruiz -->


<!-- Date: Tue Aug 21 23:15:45 2001 -->
<table><tr><td><a href=/elog/notebooks/consumer-ops/Tue_Aug_21_2001_231407.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-89  align='top'></td><td>Hole in tracking efficiency reflected in the EMCluster efficiency</a></td></tr></table>
<!-- Author: Alberto Ruiz -->


<!-- Date: Wed Aug 22 11:57:38 2001 -->
<pre>QIE calibrations (run 124443) performed. Results checked in DBANA.  Waiting for shots.</pre>
<!-- Author: Hung-Chung Fang -->


<!-- Date: Wed Aug 22 15:22:31 2001 -->
<pre>Erratic behavior of DBANA. Calor LED calib checked.  An expert should double check this.  See main CDF E-log.  Run 124446.</pre>
<!-- Author: Hung-Chung Fang -->


<!-- Date: Wed Aug 22 15:25:00 2001 -->
<pre>EVD and various consumers consuming at very low rate.  Expert (Hartmut): problems may be due to corrupt TCMD bank.  Waiting for more data to see if problem goes away.</pre>
<!-- Author: Hung-Chung Fang -->


<!-- Date: Wed Aug 22 15:58:35 2001 -->
<pre>The YMon display is experiencing difficulties.  For non-slide show plots (esp. the CMX2d canvases), the plots persist on the canvas for approx 5 sec. before they disappear; the axes and titles, etc. remain, but the plot content disappears.  This is causing the CMX expert grief.  Restarting the display has no effect upon the problem.</pre>
<!-- Author: Hung-Chung Fang -->


<!-- Date: Wed Aug 22 16:02:51 2001 -->
<pre>New script ~/consumer_scripts/killAllDisplays.sh created.  This script, as its name suggests, slaughters all the consumer displays.  I'm working on a script that kills individual (or all) displays, which will replace this one.  For now, killing displays one by one by hand is still the method of choice. 
</pre>
<!-- Author: Hung-Chung Fang -->


<!-- Date: Wed Aug 22 16:07:25 2001 -->
<pre>Consumer processes have been quite unstable today, probably due too the recent recovery from DAQ and Trigger problems.  </pre>
<!-- Author: Hung-Chung Fang -->



<!-- Date: Wed Aug 22 18:25:09 2001 -->
COs:<br> 
Problems with TrigMon or XMon?  If yes, please call me at 605-1204.  Thanks.
<!-- Author: Matt -->


<!-- Date: Wed Aug 22 21:49:39 2001 -->
<pre>XMon is working , but takes too long time to access Trigger DB</pre>
<!-- Author: Alberto Ruiz -->


<!-- Date: Thu Aug 23 01:46:07 2001 -->
<pre>It's 1:42 and all's well.  
 
Still need updates for some of the reference plots.  For  
instance, there is no reference for the ObjectMon JetCluModule 
plots.  We don't know if the dips around eta=+/-1 are expected, 
or if the difference between eta=+1 and eta=-1 is okay.</pre>
<!-- Author: Robert Harr -->


<!-- Date: Thu Aug 23 02:20:18 2001 -->
<pre>There's a strange feature in the XFT Linker plots.  There are 
no tracks for Linker Boards 18 to 24.  The simulation reproduces 
the data.  Is this effect due to the dead quadrant in COT layer 
2?</pre>
<!-- Author: Robert Harr -->
<!-- Comment: Wed Aug 29 14;16;28 comment by...Evelyn Thomson -->
<pre>Yes, see XFT elog</pre>
<!-- Date: Thu Aug 23 02:50:59 2001 -->
<pre>Event display died for unknown reason.  This seems to happen 
regularly.</pre>
<!-- Author: Robert Harr -->


<!-- Date: Fri Aug 24 00:44:20 2001 -->
<pre>TRIGMON is again dying on startup.  We are at a loss for a 
solution, and since this is a known problem, don't see much 
point in waking someone up to look at it now.  But this should 
be noted and repaired.</pre>
<!-- Author: Robert Harr -->


<!-- Date: Fri Aug 24 00:45:10 2001 -->
<pre>Please use caution if you choose to put HTML into an entry.  Forgetting to use a close tag for each open tag will certainly cause problems. 
 
If you choose to use plain text, PLEASE USE CR's since this text window automatically wraps the text and gives the illusion of CR's.   (click to clear this message) 
</pre>
<!-- Author: test -->


<!-- Date: Fri Aug 24 02:58:21 2001 -->
<pre>We received e-mail from Sungwon Lee about the track phi  
distribution seen in ObjectMon.  The phi distribution is not 
flat due to the sections of the COT with HV switched off.  A  
section in layer 2 has been off all week, and its effect on  
reconstruction noted in &lt;a href= 
'/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=3&frame=2&anchor=23:15:45'&gt; 
a previous entry.&lt;/a&gt;   The efficiency hole is even more  
pronounced tonight, presumably because more sections of the COT 
are switched off.  HV is off in sections of SL1, 2, 4, 5, and 8. 
</pre>
<!-- Author: Robert Harr -->


<!-- Date: Fri Aug 24 11:13:12 2001 -->
<pre>*PLEASE NOTE* 
 
There is a database that contains a list of  
known problems in the calorimeter.  It can be accessed via the ace calibration help page (to which you can find a link in the calibration section of the CO info page) which is at 
 
 /ace2help/ace_calibrations.html 
 
Click on  
 
	 Known QIE calibration problems       or 
	 Known LED calibration problems       or 
         Known PMT spike problems.  
</pre>
<!-- Author: Hung-Chung Fang -->


<!-- Date: Fri Aug 24 11:21:23 2001 -->
<pre>As reported before, certain monitor displays, including the YMon display, have a "blank-out" problem: if the display is not in slide show mode AND "Automatical Update" is switched on, the plot one selects is displayed for 2 or 3 seconds before the plot content disappears. Note that the plot title and coordinate frame ,etc. do not vanish; only the actual content does. 
 
This problem has surfaced only in the past few days.</pre>
<!-- Author: Hung-Chung Fang -->


<!-- Date: Fri Aug 24 11:24:02 2001 -->
<pre>Repeated crashes of TrigMon upon starting.  TrigMon disabled.</pre>
<!-- Author: Hung-Chung Fang -->


<!-- Date: Fri Aug 24 11:46:16 2001 -->
<pre>Evd: 
 
The Event Display consuming rate has been very low.  It usually takes 20-30 seconds to refresh.  Many complaints from casual onlookers. 
 
 
The avg. rate for the various consumers from the Ace Consumer Display: 
 
	L3RegionalMon	0.007 
	ObjectMon	0.263 
	YMon		0.026  
	BeamMon		0.091 
	SiliMon		0.097 
	LumMon		0.150 
	Stage0_		0.028 
	SVXMon		0.007 
	EventDisplay	0.009</pre>
<!-- Author: Hung-Chung Fang -->


<!-- Date: Fri Aug 24 11:53:34 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-91&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-91  width='300' align='top'></td><td>Effect of COT HV crate off.</a></td></tr></table>
<!-- Author: Hung-Chung Fang -->


<!-- Date: Fri Aug 24 11:54:37 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-92&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-92  width='300' align='top'></td><td>more COT plots</a></td></tr></table>
<!-- Author: Hung-Chung -->


<!-- Date: Fri Aug 24 12:08:35 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-93&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-93  width='300' align='top'></td><td>Track phi plot.</a></td></tr></table>
<!-- Author: Ja-Wook Koo -->


<!-- Date: Fri Aug 24 12:26:30 2001 -->
<pre>BeamMon display starts and then fails (both remotely from b0dap51 and from b0dap55:0.0). Kaori's diagnosis is a bad socket connection to b0dap66, the node where BeamMon lives. 
 
TrigMon crashes upon starting.  This problem is well-known.  Kaori's diagnosis: trigger bank formats are in a state of flux.</pre>
<!-- Author: H.C. Fang, J. Koo -->


<!-- Date: Fri Aug 24 12:35:21 2001 -->
<pre>Hartmut came and looked at the BeamMon display.  He was able to make things run.  Socket connection may potentially go bad again at end of run.</pre>
<!-- Author: Hung-Chung Fang -->


<!-- Date: Fri Aug 24 14:20:15 2001 -->
<pre>Evd consuming at ultra low rate-- 0.002. 
Greg V. replacing tcl file for YMon.</pre>
<!-- Author: Hung-Chung Fang -->


<!-- Date: Fri Aug 24 19:30:54 2001 -->
The frequent TrigMon crashes as of the new cdfsoftb0 release are due to an old version of L2TriggerMonitor crashing when no TL2D bank (no level2 decision crate) was present in the run.  That is why sometimes TrigMon ran fine for days, and others it died after only a few events.  L2TriggerMonitor has been turned off in the consumer runarea runTrigMon.tcl script.<p>The current L2TriggerMonitor in development has been tested with no TL2D bank and runs fine.  Waiting for a new cdfsoftb0 to update it.
<!-- Author: Matt and Nate -->


<!-- Date: Fri Aug 24 21:00:04 2001 -->
<pre>TrigMon running on b0dap65 is just for test(?).</pre>
<!-- Author: Ryuichi Takashima -->


<!-- Date: Fri Aug 24 23:08:14 2001 -->
<pre>In the event display, Silicon hits are shown with the same 
magnitude of ADC counts. Time bucket may not be a correct 
position.</pre>
<!-- Author: Ryuichi Takashima -->
<!-- Comment: Tue Aug 28 22;06;09 comment by...ryuichi takashima -->
<pre>cluster charge is shown in log scale.</pre>
<!-- Date: Sat Aug 25 08:33:24 2001 -->
<pre>All monitors are died at once except SVXMon.</pre>
<!-- Author: Ja-Wook Koo -->


<!-- Date: Sat Aug 25 10:05:19 2001 -->
<pre>SVX still dead, thunder and lightening alive.</pre>
<!-- Author: Ja-Wook Koo -->


<!-- Date: Sat Aug 25 22:59:16 2001 -->
<pre>XMon crashed. It takes time for XMon to be working condition. 
Matt says it is accessing DB at first.</pre>
<!-- Author: Ryuichi Takashima -->


<!-- Date: Sun Aug 26 03:18:49 2001 -->
<pre>XMon's L1 Accepts vs L2 Accepts + Rejects looks funny.  L2 is accepting more total than L1 due to the stuff in the right hand corner.</pre>
<!-- Author: William Cottrell -->
<!-- Comment: Sun Aug 26 03;49;57 comment by...william cottrell -->
<pre>- Also, deadtime is high, 3.14% BUSY today as opposed to .00058 yesterday with around 5% deadtime.</pre>


<!-- Comment: Mon Aug 27 20;41;45 comment by...Matt -->
The problem is that during a HRR some L1A will be flushed out of the DAQ pipeline before L2 can make a decision on those events.  That means that over a long run, the L2A + L2R number will become less than the L1A number.  This is what the plot below shows.  The reason some events show up in the lower right hand corner is that the plot is actually L1A%500 and (L2A+L2R)%500.  This lets the entire run be captured on one plot without having X and Y axes going up into the millions.
<!-- Date: Sun Aug 26 03:55:37 2001 -->
<table><tr><td><a href=/elog/notebooks/consumer-ops/Sun_Aug_26_2001_035515.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-95  align='top'></td><td>Graph too thick, note bottom right hand corner </a></td></tr></table>
<!-- Author: William Cottrell -->


<!-- Date: Sun Aug 26 19:45:24 2001 -->
<pre>Level 3 accept number is not shown on Xmon slide of table canvas.</pre>
<!-- Author: ryuichi takashima -->


<!-- Date: Sun Aug 26 21:30:28 2001 -->
<pre>On LumMon log window, the phrase "no connection to socket...b0dap66" shows up during the slide show.  
The socket should be connected to b0dap55. 
</pre>
<!-- Author: Ryuichi Takashima -->


<!-- Date: Sun Aug 26 22:10:11 2001 -->
<table><tr><td><a href=/elog/notebooks/consumer-ops/Sun_Aug_26_2001_220943.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-100  align='top'></td><td>No level3 accept number in Xmon slide. I made a directory ~cdfdaq/co-aug-24-01 to put in graphics.</a></td></tr></table>
<!-- Author: ryuichi takashima -->


<!-- Date: Sun Aug 26 22:28:51 2001 -->
<table><tr><td><a href=/elog/notebooks/consumer-ops/Sun_Aug_26_2001_222833.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-102  align='top'></td><td>cot02 is removed from integration.</a></td></tr></table>
<!-- Author: ryuichi takashima -->


<!-- Date: Sun Aug 26 23:10:06 2001 -->
<pre>In Trigmon display, slide show stops or its canvas disapears, and 
other canvas named Warning/Error canvas apears to start slide 
show of its own. </pre>
<!-- Author: ryuichi takashima -->


<!-- Date: Mon Aug 27 05:38:10 2001 -->
<pre>BeamMon has been dead for about an hour.  When I attempt to start it, it complains that the start_downDisplay process is running and that I shoud stop it, but no such process appears when doing top.  </pre>
<!-- Author: william cottrell -->
<!-- Comment: Mon Aug 27 07;39;11 comment by...william cottrell -->
<pre>BeamMon still dead at 7:36.  The BeamMon window says that it is working but I can't get a consumer display to come up.</pre>

<!-- Comment: Mon Aug 27 07;53;11 comment by...william cottrell -->
<pre>BeamMon now working, 7:50am.  I don't know why.</pre>


<!-- Date: Mon Aug 27 08:14:05 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-103&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-103  width='300' align='top'></td><td>One point have extreamly high value(looks 1 or more) on bottom left graph, YMon Central Muon Slide</a></td></tr></table>
<!-- Author: Ja-Wook Koo -->
<!-- Comment: Mon Aug 27 08;16;55 comment by...Ja-Wook Koo -->
<pre>Sorry... bottom right graph. not bottom left.</pre>


<!-- Date: Mon Aug 27 08:24:50 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-104&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-104  width='300' align='top'></td><td>Some PMTs doesn't work. Look two graphs on the top.</a></td></tr></table>
<!-- Author: Ja-Wook Koo -->


<!-- Date: Mon Aug 27 08:53:21 2001 -->
<pre>It was reported that Event Display was running very slow.  
mom.exe was using more than 90% if memory.  Kill the process  
and restart Event Display to fix the problem. 
There are slow memory leaks in many of the processes. 
So, in general, it is a good idea to stop and restart  
programs in convenient times.</pre>
<!-- Author: Kaori -->
<!-- Comment: Mon Aug 27 09;09;37 comment by...Ja-Wook Koo -->
<pre>Event Display problem revisited.
Running with enough menory by killing mon.exe shows the same problem. Actually, if I don't execute looping process, evd is fast enough. I'll report to Kaori again.</pre>


<!-- Comment: Mon Aug 27 11;06;22 comment by...Ja-Wook Koo -->
<pre>Kaori said, two things are related to Event Display problem. CPU, and memory. For about CPU, it is a long term problem related tcl file. 

Memory problem is from memory leakage. It is too fast!!! 2~3MB per 1 loop. Maybe you have to kill mon.exe and restart them at least per 1 hour. Check 'SIZE' and 'RSS' using top command.</pre>
<!-- Date: Mon Aug 27 09:35:31 2001 -->
<pre>TrigMon Display dies too often when I try to save histograms.</pre>
<!-- Author: Ja-Wook Koo -->


<!-- Date: Mon Aug 27 09:59:08 2001 -->
<pre>BeamMon died again. It died when I try to save histogram. And when I tried to startDisplay on b0dap51, it died without error message. On b0dap55, I executed HistoDisplayMain and pressed select button. But when I selected BeamMon and pressed open, it died again with following error message. 
 
 Opening hostport = "b0dap66.fnal.gov:9091" ... 
 Socket Server = b0dap66.fnal.gov:9091 
 Failed to get ConsumerInfo 
socket closed 
 
</pre>
<!-- Author: Ja-Wook Koo -->
<!-- Comment: Mon Aug 27 10;27;24 comment by...Ja-Wook Koo -->
<pre>Now it works! What was wrong?</pre>



<!-- Date: Mon Aug 27 14:13:55 2001 -->
<pre>XMon crashed at 13:00 and I restarted it. After that, XMon retrieving physics table from Trigger DB ,run 124792 and 124793 until now (for more than an hour). That's why I cannot execute XMon display. 
</pre>
<!-- Author: Ja-Wook Koo -->
<!-- Comment: Mon Aug 27 15;57;08 comment by...Ja-Wook Koo -->
<pre>I called Kaori. Matt is an expert on XMon but he took owl shift. 
She said if ace changed physics table, it could be happened. Sarah tried to change physics table near 2pm, and XMon problem happened earlier than that. So she will ask someone who can manage this problem.</pre>


<!-- Date: Mon Aug 27 19:53:57 2001 -->
<pre>Script to run Xmon is changed by Matt. DB access is now off for XMon. </pre>
<!-- Author: ryuichi takashima -->
<!-- Comment: Mon Aug 27 20;28;43 comment by...Matt -->
XMon should lose none of its functionality as far as the slideshow histograms are concerned.  However, the T\trigger Rate and X-section plots will no longer be created, and the summary log file and webpage will be pretty hard to decipher.



<!-- Date: Mon Aug 27 21:28:44 2001 -->
<pre>When the slide show stops, I simply stop the Display  job then 
start it again. It works.</pre>
<!-- Author: ryuichi takashima -->


<!-- Date: Tue Aug 28 01:01:39 2001 -->
<pre>We did a callibration and it appears that Tower -9, wedge 11 and 12 L are dead in addition to 0 E wedge 7 L and 0 W wedge 15 R which is only half dead.</pre>
<!-- Author: william cottrell -->


<!-- Date: Tue Aug 28 01:57:48 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-105&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-105  width='300' align='top'></td><td>CEM LED callibration for run 124838</a></td></tr></table>
<!-- Author: William Cottrell -->


<!-- Date: Tue Aug 28 02:38:46 2001 -->
<table><tr><td><a href=/elog/notebooks/consumer-ops/Tue_Aug_28_2001_023833.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-107  align='top'></td><td>Crate 16 looks dead, also, crate 2 has a dead chip.</a></td></tr></table>
<!-- Author: William Cottrell -->


<!-- Date: Tue Aug 28 08:54:06 2001 -->
<pre>There are so many histograms without reference plot. I cannot find reference histogram anywhere( not in control room, web page.). Someone who is an expert on each Mon need to update reference histograms.</pre>
<!-- Author: Ja-Wook Koo -->


<!-- Date: Tue Aug 28 09:18:33 2001 -->
<pre>I find that CES and CPR have dead at phi wedge 5. And CLC channel 14 is dead. But I cannot remember these ones were dead before.</pre>
<!-- Author: Ja-Wook Koo -->
<!-- Comment: Tue Aug 28 09;37;36 comment by...Ja-Wook Koo -->
<pre>CES and CPR have extreamly high gain relatively. It looks like dead on some histograms. Now it looks ok.</pre>


<!-- Date: Tue Aug 28 11:10:00 2001 -->
<pre>Event Display works very well and fast. It has no delay when looping.</pre>
<!-- Author: Ja-Wook Koo -->


<!-- Date: Tue Aug 28 11:26:38 2001 -->
<pre>Bottom left histogram on ObjectMon Track Monitor on ObjectMon Slides is missing.</pre>
<!-- Author: Ja-Wook Koo -->


<!-- Date: Tue Aug 28 14:58:16 2001 -->
<pre>TrigMon SVXMon are dead almost simultaneously with failure attemps for restarting. It looks that error is caused by run number mismatching. Current run number is 12. ACEs doing something.</pre>
<!-- Author: Ja-Wook Koo -->


<!-- Date: Tue Aug 28 15:24:43 2001 -->
<pre>Run number recovered. TrigMon and SVXMon now working.  
 
TrigMon have one blank canvas( i.e., no axis and title.). 
Look 'TrigMon-&gt;L1TriggerMonitor-&gt;Track Bit 1' on TrigMon Display Main.</pre>
<!-- Author: Ja-Wook Koo -->


<!-- Date: Tue Aug 28 17:21:42 2001 -->
TOF system has had its PMT HV raised this afternoon.  
This will make the new TOF 
YMON plots to have different average values and higher 
occupancies. As well, some channels will increase a little 
more than others, so the pattern seen in YMON will not 
quantitatively be identical, but the qualitative uniformity 
should be preserved.<BR>     
  ----For more info on TOF in YMON look 
  <A HREF="/internal/mon/consumer/ymon/TOF.html">HERE</A>   
<!-- Author: bauer -->


<!-- Date: Tue Aug 28 21:26:13 2001 -->
<pre>We lost the beam.</pre>
<!-- Author: ryuichi takashima -->
<!-- Comment: Tue Aug 28 22;03;12 comment by...ryuichi takashima -->
<pre>quebch at D1. Stacking pbar.</pre>



<!-- Date: Tue Aug 28 22:21:52 2001 -->
<table><tr><td><a href=/elog/notebooks/consumer-ops/Tue_Aug_28_2001_222117.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-109  align='top'></td><td>cot16 is now in the data taking. Almost recoverd but some region in SL2.</a></td></tr></table>
<!-- Author: ryuichi takashima -->


<!-- Date: Tue Aug 28 23:20:33 2001 -->
<table><tr><td><a href=/elog/notebooks/consumer-ops/Tue_Aug_28_2001_231949.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-111  align='top'></td><td>Hot wire in CMP S part has disapeared.</a></td></tr></table>
<!-- Author: ryuichi takashima -->


<!-- Date: Wed Aug 29 11:09:14 2001 -->
<pre>Someone used netscape-communicator on bodap55 about 2500m ago. Sevear memory leackage happened, XMon, LumMon, and BeamMon cannot update their canvases on time. If updating interval is much longer than 5 sec, please check memory usage and kill other programs.</pre>
<!-- Author: Ja-Wook Koo -->


<!-- Date: Wed Aug 29 11:40:00 2001 -->
<pre>All CLLD histograms on LumMon Display shows inexact time which is 5-hour faster. It said their histograms are at 16:35 whereas current time is 11:35. Other histograms are OK. </pre>
<!-- Author: Ja-Wook Koo -->


<!-- Date: Wed Aug 29 12:10:17 2001 -->
<pre>We got the beam now.</pre>
<!-- Author: Ja-Wook Koo -->


<!-- Date: Wed Aug 29 12:16:35 2001 -->
<pre>No(or negligibly small) memory leackage on Event Display today. Did someone fix it? or just temporarily?</pre>
<!-- Author: Ja-Wook Koo -->


<!-- Date: Wed Aug 29 13:29:47 2001 -->
<pre>YMon didn't reponse and I cannot find even mouse pointer. I tried to kill using ./murderDisplay.sh, but failed. So I kill all displays and restart all. I cannot find mouse pointer on b0dap52 either. I think this is from computer itself. </pre>
<!-- Author: Ja-Wook Koo -->
<!-- Comment: Wed Aug 29 13;40;01 comment by...Ja-Wook Koo -->
<pre>I found mouse pointer!!! I didn't do anything, actually, couldn't. How strange.</pre>


<!-- Date: Wed Aug 29 13:42:46 2001 -->
<pre>I report to XFT e-log about blank area ( of XFT slides on TrigMon Display. It was reported only in CO e-log at Aug 23. I wonder experts know this problem or not. </pre>
<!-- Author: Ja-Wook Koo -->
<!-- Comment: Wed Aug 29 14;24;21 comment by...Evelyn Thomson -->
<pre>Sorry, I don't check the consumer elog often. Yes, this is the
effect of no HV on COT SL2 quadrant C.  Nice to know you're
looking at these plots!  Please don't hesitate to post any xft
questions/concerns you have in the xft elog too. 

/cohelp/reference_histo.html
has a link to TrigMon then to XFT for help understanding the
histograms.  There should be a copy of this in the white folder. too.</pre>

<!-- Comment: Wed Aug 29 14;25;43 comment by...Evelyn Thomson -->
<pre>Please look in the XFT elog for some plots about your question.</pre>


<!-- Date: Wed Aug 29 23:30:14 2001 -->
<pre>I saved all slide plots of run 125036 in directory co-aug-24-01/XxxMon-125036 and printed out all of them.</pre>
<!-- Author: ryuichi takashima -->


<!-- Date: Thu Aug 30 05:34:34 2001 -->
<pre>General Complaint:  The EVD takes approximately one minute to go 
through a ten second loop.  More if you want to see anything  
interesting or try to click on something.  I think the program  
suffers from memory leakage- if I start the EVD at 24M of used memory it initially jumps to around 45M and then gradually works its way up to 51M of used Mem and then dies.</pre>
<!-- Author: william cottrell -->
<!-- Comment: Thu Aug 30 08;17;00 comment by...Ja-Wook Koo -->
<pre>I checked your complaint and found no memory remaining to run event display. As Kaori stated somewhere in this e-log before, you have to check SIZE and RSS of mon.exe. Check its memory usage and if it's over than 400MB, kill it and restart it.

One more. If data taking is stopped during looping, then Event Display don't give us any response. Then, wait until it response or wait for another data taking(most recommended) or kill it(least recommended).
</pre>


<!-- Comment: Fri Aug 31 09;50;23 comment by...Kaori -->
<pre>I reported the problem of memory leak and slowness of the
Event Display program to Andrey Loginov who maintains the
program.  He is looking into the memory leak problem.
As for the slowness, following is what he says:

===========
I had a look at the evd in the control room, and it seems to work much
faster if we disable silicon (too many hits to unpack/draw).

What one should do is
1. to disable silicon modules
2. set "ReadSiData set false" in the DataMenu:

root[0] .q
AC++&gt; talk evd
evd&gt; DataMenu
evd/DataMenu&gt;
evd/DataMenu&gt; ReadAllData set false
evd/DataMenu&gt; ReadMuData set true
evd/DataMenu&gt; ReadCalData set true
evd/DataMenu&gt; ReadPlugData set true
evd/DataMenu&gt; ReadXftData set true
evd/DataMenu&gt; ReadSiData set false
evd/DataMenu&gt; exit
evd&gt; exit
AC++&gt; root

==========
So, you might want to try this to speed up the display,
but you might have more (faster) problem with memory leak
by doing this.  Anyway, Andrey is looking into the problem.</pre>
<!-- Date: Thu Aug 30 11:09:31 2001 -->
<pre>Lost beam again.</pre>
<!-- Author: Ja-Wook Koo -->


<!-- Date: Thu Aug 30 20:51:27 2001 -->
<pre>During shot setup, Tev quenched. Cal-QIE, LED and Xenon 
calibration have been done with run # 12532, 125136 and 125137. 
CEM East 7(eta) 15L(phi) has 0 pedestal value. </pre>
<!-- Author: ryuichi takashima -->



<!-- Date: Fri Aug 31 09:54:59 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-112&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-112  width='300' align='top'></td><td>test</a></td></tr></table>
<!-- Author: test -->


<!-- Date: Fri Aug 31 09:56:23 2001 -->
<pre>Through the YMon web page, TOF has a very nice web page now. 
Please check it out when you have time. 
Also, starting yesterday (8/30/2001), I put another white folder 
in front of b0dap50 (event display pc), which says: "Event Display". </pre>
<!-- Author: Kaori -->


<!-- Date: Fri Aug 31 12:01:15 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-113&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-113  width='300' align='top'></td><td>test graph</a></td></tr></table>
<!-- Author: test2 -->


<!-- Date: Sat Sep 1 16:54:44 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-115&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-115  width='300' align='top'></td><td>Noticed a noisy ISL ladder in layer 6. In the attached SiliMon plot yit appears that this are chips 36 to 39 in phi-wedge 14. We saw the same thing already yesterday but there a silicon expert took care of it.</a></td></tr></table>
<!-- Author: Alexander Skiba -->


<!-- Date: Sun Sep 2 13:20:06 2001 -->
<pre>Event display froze twice during running without beam and high  
voltage. Silicon modules had been disabled during the previous evening shift and thus are not the source of all freezes. This requires some attention. </pre>
<!-- Author: J. Friedman -->


<!-- Date: Sun Sep 2 14:52:02 2001 -->
<pre>A number of silicon layers are out of sync, SciCo and aces have been alerted. At 1430 we are running with beam and all displays are functioning.</pre>
<!-- Author: J. Friedman -->


<!-- Date: Tue Sep 4 04:04:41 2001 -->
<pre> Have had problems starting the Consumers in the normal way. 
 All windows (on b0dap51 upper screen) display the same error 
 msg: bombing out due to: 
 Xlib: Client is not authorised to connect to Server.  
 
 To start the Consumers indivudally on their respective machines 
 you can do the following: 
 
 a) Note on which machine the consumer you want to start is 
    running. For example TrigMon is on b0dap52 
 
 b) from b0dap51 open an Xterm and do: 
    ssh b0dap52 (for example) 
    setenv Display b0dap51:0 
    source ~cdfsoft/cdf2.cshrc 
    setup cdfsoftb0 
    cd /data1/consumer/runarea/xxxMon 
                           (where xxx = Trig,Object,Beam,etc) 
    run xxxMon 0 
           
    Only slight exception to this is the Stage0 Consumer for 
    which you just type : run Stage0 0 
</pre>
<!-- Author: Barry King -->


<!-- Date: Tue Sep 4 10:24:16 2001 -->
<pre>I looked into why the startup script did not work last night. 
Reason is not quite clear, but most likely that it was caused by 
not enough memory on b0dap51.  DBANA process was running taking 
up quite a large chunk of memory.  No problem starting up all the 
consumers with the startup script this morning. 
 
In ~cdfdaq/consumer_scripts area, there is a script called 
watchMem.sh.   If you type: 
./watchMem.sh 
the script starts, monitoring the memory available in 
b0dap50, 51, 52, 55, 56, 66 and 67.  If any of the machines have 
less than 50M memory left, background of the monitor screen will 
start flushing at you with Yellow/Blue. When that happens, please 
identify which machine has the memory problem by looking at the 
window where 'watchMem' is running, go to that machine, find 
which process is taking up the large amount of memory (run top, 
type M, then find out PID of the process) then stop the process 
to free up memory. 
</pre>
<!-- Author: Kaori -->


<!-- Date: Wed Sep 5 10:02:11 2001 -->
<pre>All monitors dropped out simultaneously in a non-running 
condition (10am). There is ample memory in b0dap51, so this was not the problem. All monitors have been turned on again. We are now in shot setup status.</pre>
<!-- Author: J. Friedman -->


<!-- Date: Wed Sep 5 15:50:08 2001 -->
<pre>Just modified startEvd.sh script so that Event Display 
will come up with default, Silicon Data OFF.  This is done 
to speed up the display.  If you want to turn on Silicon data, 
do followings: 
 
root[0] .q 
AC++&gt; talk evd 
evd&gt; DataMenu 
evd/DataMenu&gt;ReadSiData set true 
evd/DataMenu&gt; exit 
evd&gt; exit 
AC++&gt; root 
 
====== 
If you want to turn it back off, then do the same stuff 
as above, but "ReadSiData set false", instead of true. 
</pre>
<!-- Author: Kaori -->


<!-- Date: Thu Sep 6 11:24:22 2001 -->
<pre>In the event display, there is a blue track in COT that appears in every event.</pre>
<!-- Author: J. Friedman -->


<!-- Date: Sat Sep 8 08:50:06 2001 -->
<pre>Came in to find that LumMon/BeamMon display on b0dap55 had 
stopped updating.  Tried usual solution (Reset, then choosing a 
new socket connection.)  This resulted in the display monitor 
shutting down.  To try fix this, we had to kill all the other 
displays, and all the consumer monitors.  Then, we had to restart 
all of the consumer monitors, wait until they had been running 
for some time, then restarted all of the displays. 
 
Have also been reminded by other people here that since there is an access on Monday, we should try and identify as many detector problems as possible to they can be fixed.</pre>
<!-- Author: Dan MacQueen -->


<!-- Date: Sun Sep 9 21:02:51 2001 -->
<pre>Hans Jensen finds that it is marked "Myron mode 0" in the 
Event Display when we are taking real data. 
In the Event Display manual holder, it is written that 
the default value is -1. Puzzled why 0 is written.</pre>
<!-- Author: Rei Tanaka -->


<!-- Date: Sun Sep 9 21:12:24 2001 -->
<pre>Is there any way to perform fitting any histogram written on canvas at Consumer Display ? 
 
Ex. we wanted to perform linear curve fit on beam profile 
slope at BeamMon, but couldn't find how to do that.</pre>
<!-- Author: Rei Tanaka -->


<!-- Date: Sun Sep 9 22:56:15 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-120&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-120  width='300' align='top'></td><td>Hereafter RUN 126117, COT_05, 13, 14, and 15, and COT12 slots 9 and 17 are removed. </a></td></tr></table>
<!-- Author: Rei Tanaka -->


<!-- Date: Sun Sep 9 22:58:22 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-121&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-121  width='300' align='top'></td><td>.</a></td></tr></table>
<!-- Author: Rei Tanaka -->


<!-- Date: Tue Sep 11 14:33:53 2001 -->
<pre>Note: When Xwindows is restarted on the b0dap machines, the 
monitors may have trouble running.  Issue the command "xhost +" 
on a terminal on b0dap51 if you get a message from the monitors 
saying that it cannot open the display.</pre>
<!-- Author: Dan MacQueen -->


<!-- Date: Fri Sep 14 18:03:26 2001 -->
<pre>New consumer monitor release 4.0.0b is made by Hartmut today. 
SVXMon and ObjectMon should work with this release. 
We made this new release to be the default cdfsoftb0 release, 
so now when we type the standard startup scripts (eg. startMon.sh 
without _new) will start the new monitors.</pre>
<!-- Author: Kaori -->


<!-- Date: Fri Sep 14 21:40:24 2001 -->
<pre>Consumer XMon does not start but gives a message like: 
 
couldn't read file "Consumer/XMon/runXMon.tcl": no such file or directory 
 
</pre>
<!-- Author: Mario Spezziga -->
<!-- Comment: Tue Sep 18 10;05;37 comment by...Matt -->
Please page the XMon expert when problems like this occur.
<!-- Date: Fri Sep 14 23:49:44 2001 -->
<pre>Consumer ObjectMon and its display keep on crashing 
</pre>
<!-- Author: Mario Spezziga -->


<!-- Date: Sat Sep 15 21:01:34 2001 -->
Problems with TrigMon: it crashed, I restarted it, it pops up the regular window, but eventually stops writin messages, does not appear running in the <a href=/internal/mon/consumer/consumer_status.html>"consumer status page"</a> and the consumer display can't work with it ("No consumer TrigMon").  
<!-- Author: Mario Spezziga -->
<!-- Comment: Sat Sep 15 21;23;27 comment by...Mario Spezziga -->
<pre>TrigMon is working again
</pre>


<!-- Comment: Tue Sep 18 10;06;23 comment by...Matt -->
This is probably due to TrigMon taking a long time to access the Trigger database on startup.


<!-- Date: Tue Sep 18 10:08:15 2001 -->
I've put new tcl files in the runarea for TrigMon and XMon that have the Trigger database access disabled.  Now they should start much faster.  Please report any problems to Matt at  mworcest@physics.ucla.edu.
<!-- Author: Matt -->


<!-- Date: Sat Sep 22 20:33:26 2001 -->
<pre>Too many consumer processes are crashing too frequently -- have 
been spending the majority of the time this shift trying to  
restart them --  particularly the b0dap56 set of processes.  
I note a lot of text appearing in the "Konsole"  window on b0dap51 that appears to be Kerberos-related, when restarting  
processes -- is that a clue?  As  I type this, two more processes  
have crashed -- L3RegionalMon and ObjectMon.  It is impossible 
to do the actual CO job of looking at graphs when having to 
 constantly restart processes.  Now SVXMon has also crashed -- that's three to restart. 
 
Second complaint:  There is a Track Filter Errors Warning window 
in the TrigMon monitor that is bugging us about too many hits in  
the roads, or too many combinations.  An expert tells me that  
this situation is a feature, not a serious error, and the  
monitoring  software should not be "crying wolf" about it.</pre>
<!-- Author: Virgil Barnes -->
<!-- Comment: Mon Sep 24 04;25;51 comment by...Kaori -->
<pre>SVXMon crash problem has been reported to Igor (SVXMon auther)
several times.  He is looking into the problem.
L3RegionalMon seems to have relatively large memory leak problem
which is causing some crashes.  TrigMon warning canvas problem
has been identified.  This will be fixed in the next release.</pre>
<!-- Date: Sat Sep 22 22:47:46 2001 -->
<pre>SVXMon has been crashing repeatedly</pre>
<!-- Author: Virgil Barnes -->


<!-- Date: Sat Sep 22 23:08:50 2001 -->
<pre>Restarted SVXMon.  Display slides look normal -- BUT the SiliMon 
text window states "No consumer SVXMon".   
 
Also, the ObjectMon display then froze, and had to be killed and 
(just the display) restarted from b0dap51.  Seemed to work OK 
 
Then a few minutes later, ObjectMon crashes.</pre>
<!-- Author: Virgil Barnes -->


<!-- Date: Sat Sep 22 23:56:39 2001 -->
<pre>SVXMon crashes again.  text window  at display says "broken 
pipe",  "closing socket"  "please open again" 
 
Apparently have restarted SVXMon, having killed all b0dap56 
displays first, then restarted them.  BUT there is still a red background on  both b0dap51 monitors (nowhere else).</pre>
<!-- Author: Virgil Barnes -->


<!-- Date: Sun Sep 23 02:27:32 2001 -->
<pre>Appearance of CMP plots in YMON is changing because CMP is 
tripping and HV status is changing time to time. </pre>
<!-- Author: Fujii Y. -->


<!-- Date: Sun Sep 23 05:23:57 2001 -->
<pre>Two ObjectMon is running on b0dap67(original) and b0dap57(extra). 
This seems to be causing slow startup of display job, and some 
freezing. I do not know how to kill extra one. Otherwise OK.</pre>
<!-- Author: Fujii Y. -->


<!-- Date: Sun Sep 23 07:54:53 2001 -->
<pre>ObjectMon di-muon mass plot (expanded) can not 
set vertical axis correctly. Not serious because 
upper plot shows normal.</pre>
<!-- Author: Fujii Y. -->


<!-- Date: Sun Sep 23 16:15:56 2001 -->
<pre>Monitoring consumers continue to crash frequently, especially 
SVXMon.  Am killing all displays and all  Mon consumers and 
starting clean. </pre>
<!-- Author: Virgil Barnes -->


<!-- Date: Sun Sep 23 17:12:56 2001 -->
<pre>Restart ALL consumers and try to restart all Displays.  SVXMon 
crashes within 2 minutes.   
 
LumMon window pops up in  wrong location in monitor (trivial but 
 annoying). 
 
b0dap52 won't respond to the mouse, and some undesired x-window  
is reported to be running -- experts struggling with problem. 
Forced to reboot.  Now we're told connection to b0dap52 refused 
 by server, client is not authorized to connect to server,can't 
 open display (Ymon  and TrigMon).  HOWEVER, apparently TrigMon 
itself IS running on b0dap52.  </pre>
<!-- Author: Virgil Barnes -->


<!-- Date: Sun Sep 23 17:42:57 2001 -->
<pre>fixed YMon/TrigMon problem by typing     xhost + 
on  b0dap52.  Further problems with launching displays, until 
 events are flowing --  then it all works. 
A  more complete set of cheat sheets for the inexperienced would 
be useful.</pre>
<!-- Author: Virgil Barnes -->
<!-- Comment: Mon Sep 24 04;38;33 comment by...Kaori -->
<pre>One of the things we can do to prevent less crashes is to run
a watchmem script.  To run: From consumer_scripts area, type:
./watchmem.sh    (This script checks free memory size in each
of the PC running monitors and warns you when the reminder size
gets very small.)</pre>
<!-- Date: Sun Sep 23 23:58:08 2001 -->
<pre>Among the LumMon slides,  the three involving Lumi have date/ 
time   Monday 24  Sept,  04:55, which is about five hours 
ahead of the actual time.   
 
Also the plots for the previous 12 hours only go back about 4 hours.   
 
</pre>
<!-- Author: Virgil  Barnes -->
<!-- Comment: Thu Sep 27 10;46;03 comment by...Kaori -->
<pre>Accelerator wants the Greenwich mean time, and that is
why you see the funny (future) time.  LumMon will modify
the time axis label so it is not confusing.</pre>
<!-- Date: Mon Sep 24 05:55:50 2001 -->
J/psi mass plot (lower one) in ObjectMon quite often fails 
to adjust the vertical axis automatically. Sent an e-mail 
to Dmitri.dap56: 591656kB available  
<!-- Author: Fujii, Y. -->


<!-- Date: Mon Sep 24 06:06:52 2001 -->
<BR> 
  Kaori showed up and worked on frequent-death of VTXMon.  
Stage0 is running on the same node as VTXMon (b0dap56),  
and it is leaking memory. Memory shortage caused by this 
seems the cause of the trouble. 
<BR> 
  At present, watchMem program seems NOT watching actual free 
memory, but swap memory. So it can not diagonostic properly. 
This should be fixed.
<!-- Author: Fujii Y. -->
<!-- Comment: Thu Sep 27 10;39;20 comment by...Kaori -->
<pre>I learnt later that watching the swap memory left is the right 
thing to do.  So, the watchMem is doing the right thing.</pre>
<!-- Date: Wed Sep 26 05:26:19 2001 -->
<pre>ObjectMon freezes quite frequently.  
After showing ObjectMon_JetMonitor_Slides, it issues one or two 
lines of warnigs as below. 
  
Warning in &lt;TObjectTable::Remove&gt;: 0x08928dc0 not found at 7605 
Warning in &lt;TObjectTable::Remove&gt;: 0x08928ef0 not found at 4227 
Warning in &lt;TObjectTable::Remove&gt;: 0x088a0230 not found at 5561   
 
Then sooner or later, mostly sooner, it freezes. 
 
------------------------------------------------- 
SVXMon still dies, but less frequent than before. 
 
A guy showed up and worked on EventDisplay. I forgot to ask his 
name. He's gone while I was out of the room. So I could not ask 
his progress.</pre>
<!-- Author: Fujii Y. -->
<!-- Comment: Thu Sep 27 10;49;32 comment by...Kaori -->
<pre>We are looking into why the Display freezes.
One of the causes of SVXMon is identified and fixed (ROOT3
Latex problem).
So, should crash less.

The guy showed up for the EventDisplay is Andrey Loginov
(I think.  He is the EventDisplay person.)</pre>


<!-- Date: Fri Sep 28 00:47:18 2001 -->
ObjectMon#8 JetMonitor is empty, constantly issuing TObject warning, and eventualy let ObjectMon freeze.  
Sent mail to Wolf.
<!-- Author: Y.Fujii -->


<!-- Date: Fri Sep 28 07:44:51 2001 -->
Around 5:30, all the monitor program stopped data processing. 
MonitorDisplay jobs are working, but repeating the same data to display. New data are not transfered at all. So killed all the display jobs, all the monitoring jobs, and restarted all the monitoring jobs again. Quite unfortunately, before restarting display jobs, data taking stopped for trigger work. So display jobs are not yet started.<BR><BR> 
Besides, ObjectMon was very bad tonight. Empty histos here and there, and freezes every ten minutes. e-mail sent to relevant guy.
<!-- Author: Fujii Y. -->


<!-- Date: Fri Sep 28 22:06:58 2001 -->
<pre>Several of us have noticed inconsistencies in the numbers 
reported in XMon,   plot #3  SL1D 
 
It reports 285 live seconds, 40 dead seconds, 
85% live 
 
Lum = 4.5E30 
Integrated Lum   Tot  9 nb-1,  GLIVE  5 nb-1 
 
Two inconsistencies:   
 
livetime fraction as expressed in integ. 
Lum is much less than 85% 
 
Glive Integ. Lum seems to imply 20 live minutes, not 5 live 
 minutes. 
 
</pre>
<!-- Author: Virgil Barnes -->


<!-- Date: Fri Sep 28 22:11:42 2001 -->
<table><tr><td><a href=/elog/notebooks/consumer-ops/Fri_Sep_28_2001_221104.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-123  align='top'></td><td>see previous entry</a></td></tr></table>
<!-- Author: Olga Lobban -->


<!-- Date: Sat Sep 29 04:00:11 2001 -->
<pre>SvxMon crashes often (almost every 15 minutes) and we notice that b0dap67 is running out of memory using watchMem. Available memory is always less than 20Mb. </pre>
<!-- Author: Lorenzo Moneta -->


<!-- Date: Sat Sep 29 18:24:56 2001 -->
<pre>I've already had to kill and restart Object and SiliMon twice because b0dap67 keeps running out of memory.  </pre>
<!-- Author: olga -->


<!-- Date: Sat Sep 29 18:50:59 2001 -->
The numbers in XMon slide #3 do not make sense.  GLIVE integrated luminosity is about a factor of 5 too big.  For instance, in Run 127920, the GLIVE instantaneous luminosity iw 5.0 e+30.  The Live time in seconds is ~700 seconds.  Multiplying these two results in an integrated luminosity of ~3.5 nb-1.  But the XMon slide says the integrated luminosity is ~16 nb-1.   
<p> 
Is this a bug in the consumer or am I overlooking something???
<!-- Author: olga -->


<!-- Date: Sat Sep 29 19:03:44 2001 -->
i can't keep SiliMon running!  b0dap67 keeps running out of memory!!! 
  
<!-- Author: olga -->


<!-- Date: Sun Sep 30 21:38:30 2001 -->
<pre>ObjectMon keeps crashing with the following messages: 
 
Error in &lt;THistPainter::PaintInit&gt;: log scale requested with zero or negative argument (0.000000) 
Error in &lt;THistPainter::PaintInit&gt;: log scale requested with zero or negative argument (0.000000) 
Warning in &lt;TObjectTable::Remove&gt;: 0x089ec8f8 not found at 5640 
Warning in &lt;TObjectTable::Remove&gt;: 0x089eca28 not found at 8849 
Warning in &lt;TObjectTable::Remove&gt;: 0x0893e9e8 not found at 7969 
Warning in &lt;TObjectTable::Remove&gt;: 0x0893e9e8 not found at 7969 
Warning in &lt;TObjectTable::Remove&gt;: 0x0893e9e8 not found at 7969 
Warning in &lt;TObjectTable::Remove&gt;: 0x0893e9e8 not found at 7969 
Warning in &lt;TObjectTable::Remove&gt;: 0x0893e9e8 not found at 7969 
&lt;ad infinitum...&gt; 
 
these errors/warnings and the crash happens when ObjectMon switches to the Met plots. 
</pre>
<!-- Author: olga -->


<!-- Date: Mon Oct 1 13:55:19 2001 -->
<pre>Moun slide was removed on the ObjectMon tcl; 
(MuonMonitor set to false) because  
CMX crashes the Display</pre>
<!-- Author: M. Iori -->


<!-- Date: Mon Oct 1 18:13:07 2001 -->
<pre>Plots in SVXMon are not picking up the current run number. 
The current run number is 128027, but the SVXMon plots  
quote 127967.  </pre>
<!-- Author: olga -->


<!-- Date: Mon Oct 1 18:18:28 2001 -->
<pre>TrigMon display crashes for the second time this shift.</pre>
<!-- Author: olga -->


<!-- Date: Mon Oct 1 18:51:19 2001 -->
<pre>LumMon display crashed.</pre>
<!-- Author: olga -->


<!-- Date: Mon Oct 1 19:24:24 2001 -->
<pre>Event Display crashed.</pre>
<!-- Author: olga -->


<!-- Date: Mon Oct 1 20:01:14 2001 -->
<pre>ObjectMon crashed with the following messages: 
 
Warning in &lt;TObjectTable::Remove&gt;: 0x08925018 not found at 6075 
Warning in &lt;TObjectTable::Remove&gt;: 0x08925018 not found at 6075 
Warning in &lt;TObjectTable::Remove&gt;: 0x08925018 not found at 6075 
Warning in &lt;TObjectTable::Remove&gt;: 0x08925018 not found at 6075 
</pre>
<!-- Author: olga -->


<!-- Date: Mon Oct 1 21:15:31 2001 -->
<pre>ObjectMon crashed again with same message as in previous entry.</pre>
<!-- Author: olga -->


<!-- Date: Mon Oct 1 21:18:10 2001 -->
<pre>ObjectMon display crashed AGAIN with same messages as in previous two entries!!! </pre>
<!-- Author: olga -->


<!-- Date: Mon Oct 1 22:08:54 2001 -->
<pre>ObjectMon display crashed again with same messages.</pre>
<!-- Author: olga -->


<!-- Date: Mon Oct 1 22:20:22 2001 -->
<pre>I feel like a broken record, but oh well... 
 
ObjectMon display crashed again with the same messages as in previous entries.</pre>
<!-- Author: olga -->


<!-- Date: Mon Oct 1 22:26:27 2001 -->
<pre>guess what?  ObjectMon display crashed again with same messages. 
</pre>
<!-- Author: olga -->


<!-- Date: Mon Oct 1 22:48:48 2001 -->
<pre>Are the SVT_Tracks and SVT_Tracks_Chi2 slides in SVXMon supposed to be empty? 
 
 </pre>
<!-- Author: olga -->


<!-- Date: Thu Oct 4 20:40:34 2001 -->
<pre>I tried to save a plot on TrigMon, and it crashed on me.   
When I hit the save button, the histo display main, the 
plots, and the xterm all disappeared!  Poof!  just like 
that!  amazing! 
Matt was able to repeat the poofing.  he's sending mail  
to Kaori. 
</pre>
<!-- Author: olga -->


<!-- Date: Thu Oct 4 22:47:51 2001 -->
<pre>The YMon results file from Run 128338 did not 
show up in /data1/consumer/results/YMon/ 
Is there a reason for that?  Does it take a long 
time?  (it's been at least an hour since the run 
ended)</pre>
<!-- Author: olga -->


<!-- Date: Fri Oct 5 23:20:38 2001 -->
<pre>The TrigMon monitoring window refuses to get the next run automatically. Reads always the same run. We had to kill  
TrigMon in order to be able to see the next run.</pre>
<!-- Author: Olga & Arnold -->


<!-- Date: Mon Nov 19 09:40:49 2001 -->
<pre>This is a test. I am learning how to store messages 
  
on the Consumer e-log. 
</pre>
<!-- Author: giorgiob -->


<!-- Date: Mon Nov 19 15:44:02 2001 -->
<pre>I noticed a minor problem in the CLC information page.. 
 
Within "General Informations on Viewing LumMon plots" one gets the same information (Plots to view) when clicking both on "CLC Plots to View" as well as when clicking on Error/Warning messages. 
 
Similarly, one gets the same info (Expert List) when clicking on CLC Expert List,as well as when clicking on Example Snap-Shots of Plots. 
</pre>
<!-- Author: Giorgiob -->


<!-- Date: Mon Nov 19 21:21:23 2001 -->
<pre>SVXMon looks like running on b0dap66. 
But I can not find SVXMon entry on the consumer status web page and list of consumer display. 
The other consumers are OK. 
 
</pre>
<!-- Author: hirokazu -->


<!-- Date: Tue Nov 20 05:41:41 2001 -->
<pre>TrigMOn doesn't get the right run number automatically.  
Stopped/Restarted same problem.  
Stopped and restarted again it doesn't appear anymore in the Consumer Status Page. ??????</pre>
<!-- Author: ciro  -->


<!-- Date: Tue Nov 20 11:36:25 2001 -->
<table><tr><td><a href=/elog/notebooks/consumer-ops/Tue_Nov_20_2001_113547.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-125  align='top'></td><td>Practising how to paste info from a consumer output.</a></td></tr></table>
<!-- Author: giorgiob -->


<!-- Date: Tue Nov 20 17:06:53 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-129&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-129  width='300' align='top'></td><td>This is CMP fixed pint in YMon view.</a></td></tr></table>
<!-- Author: hirokazu -->


<!-- Date: Tue Nov 20 17:09:26 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-130&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-130  width='300' align='top'></td><td>This is CMP fixed point in YMon view too.</a></td></tr></table>
<!-- Author: hirokazu -->


<!-- Date: Tue Nov 20 17:30:41 2001 -->
<pre> L3RegionalMon died in Run=132907. 
it issued %ERLOG-s as below.  
 
%ERLOG-s Abnormal termination: caused by signal:  11 Fr 
amework abortJob()  
         20-Nov-2001 16:45:55 run = 132907 event = 1010 
5</pre>
<!-- Author: hirokazu -->


<!-- Date: Wed Nov 21 06:21:04 2001 -->
<pre>L3RegionalMon died again 6 times during run 132931 with error message:   
 
%ERLOG-s Abnormal termination: caused by signal:  11 
Framework abortJob()</pre>
<!-- Author: ciro -->


<!-- Date: Wed Nov 21 06:25:13 2001 -->
<pre>TrigMon died during run 132933. Error message:  
 
Abnormal Termination Signal Number 110 </pre>
<!-- Author: ciro  -->


<!-- Date: Wed Nov 21 06:57:05 2001 -->
<pre>L3RegionalMon died again 2 times during run 132941 with the same  
erroro message (see above).</pre>
<!-- Author: ciro  -->


<!-- Date: Wed Nov 21 07:32:57 2001 -->
<pre>Again L3RegionalMonitor died during run 132942 with the same error message as before. </pre>
<!-- Author: ciro  -->


<!-- Date: Fri Nov 23 17:10:00 2001 -->
<pre>Event Display dies during startup. We were trying to start it many times and it was crashing at the very beginning.</pre>
<!-- Author: Hirokazu/Sasha -->


<!-- Date: Sat Nov 24 01:36:35 2001 -->
<pre>Since L3Regional Mon keeps crashing at a rate of about once every three minutes, I gave up on it. 
 
The Event Display crashed and wouldn't start up again - it failed during startup, and the startup-window disappeared before I could read the error message. Oddly, it worked when I tried for the fourth time.</pre>
<!-- Author: Jonas -->


<!-- Date: Sat Nov 24 08:00:43 2001 -->
<pre>Nothing happened, except for a few crashes of Stage0 and ObjectMon, and the constant crashes of L3RegionalTracking (I didn't start it again since the last entry). 
</pre>
<!-- Author: Jonas -->


<!-- Date: Sat Nov 24 16:47:54 2001 -->
<pre>Kernel log daemon (klogd) on b0dap55 gets crazy - it consumes all free CPU time and its running time is about 2800 minutes.</pre>
<!-- Author: Sasha -->


<!-- Date: Sat Nov 24 23:04:41 2001 -->
<p> 
L3RegionalMon crashed several times in run 133257. The following error message showed up in L3RegionalMon xterm window when I was trying to restart the consumer: 
<p> 
*** Error OCI_ERROR  [-1] [1]<br> 
*** Error: ORA-00001: unique constraint (RUNDB_PRD.CNS_UNIQUE) violated 
<p> 
And after that consumer crashed again.
<!-- Author: Sasha -->


<!-- Date: Sat Nov 24 23:43:18 2001 -->
<p> 
ObjectMon and Stage0 crashed in run 133257 
<p>
<!-- Author: Sasha -->


<!-- Date: Sun Nov 25 00:23:29 2001 -->
<center><a href='/elog/notebooks/consumer-ops/Sun_Nov_25_2001_001416.ps'><img src='/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-134' ></a><a href='/elog/notebooks/consumer-ops/Sun_Nov_25_2001_002143.ps'><img src='/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-136' ></a></center>
<!-- Author: Jonas -->


<!-- Date: Sun Nov 25 00:27:27 2001 -->
<h3> This is the text for the picture in the previous entry</h3> 
 
One CMU wedge keeps lighting up completely once in a while with no Calorimeter signal associated with this. This happens roughtly once every 5 events (guesstimate).
<!-- Author: Jonas -->


<!-- Date: Sun Nov 25 01:37:47 2001 -->
<pre>L3RegionalMon crashes right at the beginning (tried twice). It seems that it fails to get Si calibrations from the database which causes an abort (as it should). As we are running without Si, this is probably completely OK. Anyway, here's the output until the abort signal: 
 
 
         ============================================== 
========= 
 
         Error Log established 
         25-Nov-2001 01:25:08 
 
         ============================================== 
========= 
          
SiPatternRecModule: using SimpleSiliconIntegrator (defa 
ult). 
============================================= 
Initialization report from siPatternRecModule 
Pass all candidates is 0 
Pt ranges are 0 &lt; pt  
Bank writing flag is 1 
============================================= 
SiPatternRec: Creating 2 nominate, pursue and accept ti 
mers. 
SysError in &lt;TUnixSystem::UnixTcpService&gt;: bind (Addres 
s already in use) 
SysError in &lt;TUnixSystem::UnixTcpService&gt;: bind (Addres 
s already in use) 
DisplayServer: Connected successfully to CONSUMER socke 
t at port 9052 
                              on host b0dap67.fnal.gov. 
SysError in &lt;TUnixSystem::UnixTcpService&gt;: bind (Addres 
s already in use) 
SysError in &lt;TUnixSystem::UnixTcpService&gt;: bind (Addres 
s already in use) 
======================================================= 
==================== 
 
DisplayServer::openClientServerSocket(): Server socket  
for HISTO DISPLAY 
               clients at PORT 9093 available. 
 
               Use   b0dap67.fnal.gov:9093 
               as input stream to connect from the Hist 
oDisplay 
               to the Display Server. 
 
======================================================= 
==================== 
 
SiPatternRecModule: using SimpleSiliconIntegrator (defa 
ult). 
============================================= 
Initialization report from siPatternRecModule 
Pass all candidates is 0 
Pt ranges are 0 &lt; pt  
Bank writing flag is 1 
============================================= 
SiPatternRec: Creating 2 nominate, pursue and accept ti 
mers. 
APPConsumerInputModule::initIOSystem ===&gt; CS_ConsSend p 
ort = 4031 
APPConsumerInputModule::initIOSystem ===&gt; CS_Receiver p 
ort = 4030 
SiAlignmentManager: turning off alignments ... source = 
 none 
SiAlignmentManager at beginRun: no DB requested 
doing unkeyed get 
 ave calib time = 305.742 
exiting CT_Cal class 
exiting CT_Cal class 
CT_Calibration::_setDriftModelConstants: Using values i 
n database 
CT_Calibration::_setDriftModelConstants: Doing unkeyed  
get from DB  
CT_Calibration::_setDriftModelConstants: Found Run 1332 
57      Version 2       Status COMPLETE 
MostRecentSiCalibration:: ChipStatus DB set to ofotl_pr 
d_read 
MostRecentSiCalibration:: ChipStatus DB set to ofotl_pr 
d_read 
PedestalUpdator: _target is 0, creating new info set 
%MostRecent: creating a 100% full SiDBInfoSet with dumm 
y SiDBInfos. 
             This may take a while. 
%MostRecent: done with creating a full SiDBInfoSet. 
 No silicon in this run!  
 0 records returned from db  
Object ChipStatus failed to create  
PedestalUpdator (ERROR): ChipStatus failed to retrieve  
chip 
         setup from the run-conditions database.  This  
means that 
         we don't know whether the chips were in DPS ON 
 or OFF state 
         and thus we can't tell how much to subtract fr 
om the pedestal 
         in the database.  You really need a Si databas 
e expert here.0x9c87ef0&gt;&gt;&gt;&gt; Pedestals are present for t 
his run. 
     Retrieved run=128525 version=1 status=COMPLETE fro 
m the database. 
&gt;&gt;&gt;&gt; Dead channels are present for this run. 
     Retrieved run=128523 version=1 status=COMPLETE fro 
m the database. 
%ERLOG-s Abnormal termination: caused by signal:  11Fra 
mework abortJob()  
         25-Nov-2001 01:26:14 run = 133258 event = 2338 
11 
Calling abortJob for DummyInput... 
Calling abortJob for FileInput... 
Calling abortJob for DHInput... 
Calling abortJob for ConsumerInput... 
</pre>
<!-- Author: Jonas -->
<!-- Comment: Sun Nov 25 01;53;06 comment by...Jonas -->
On closer inspection, this interpration seems wrong - it's a crash, not an abort after all.
<!-- Date: Sun Nov 25 01:46:51 2001 -->
On closer inspection, the interpretation for the L3RegionalMon crashes given in the 
<a href= 
'/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=3&frame=2&anchor=01:37:47'> 
previous entry </a>  
seems to be wrong - there is no "conrolled" Erlog-A abort, but a crash. But in any case, we are not using Si, so somewhat odd behaviour might be expected.
<!-- Author: Jonas -->



<!-- Date: Sun Nov 25 18:01:45 2001 -->
<p>Event Display crashed. When I was trying to restart it, print out in its xterm window stopped with the following line:<p> 
"APPConsumerInputModule::nextEvent : about to receive event"<p> 
and then, after few minutes, xterm window dissapeared.<p>  
<!-- Author: Sasha -->