<!-- Title: 09:10:28  Tue Dec 18 2001 -->
<!-- Crewchief: co Yuri Gotra -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>starting new file</pre>


<!-- Date: Tue Dec 18 09:39:41 2001 -->
<pre>added SiliMon to the scripts runCosmic.sh and runPhysics.sh 
(switch between cosmic and physics runs)</pre>
<!-- Author: Yuri Gotra -->


<!-- Date: Tue Dec 18 15:48:49 2001 -->
<pre>Evd: crashed on lego Et, E plots when used with partition 14 
 
source ~cdfsoft/cdf2.cshrc 
setup cdfsoft2 4.2.0 
mon 14</pre>
<!-- Author: Yuri Gotra -->


<!-- Date: Tue Dec 18 16:29:11 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>please note: it's not allowed to execute "xhost +" 
this is a security breach 
use instead (for node b0dap55, for example:) 
b0dap55:&gt; xhost + b0dap51 + b0dap55 
enable both remote and local host, then it will work, you will 
be able to run:  
b0dap51:&gt; startDisplay.sh LumMon 0 
startDisplay.sh is being modified accordingly. 
     Thanks to the b0 system managers for the solution. 
</pre></td></tr></td></table>
<!-- Author: Yuri Gotra -->


<!-- Date: Wed Dec 19 04:09:23 2001 -->
<pre>SiliMOn crashed/restored</pre>
<!-- Author: Giuseppe -->


<!-- Date: Wed Dec 19 06:53:55 2001 -->
<pre>The SiliMon Consumer Display is continuously giving warning (red) plots indicating errors on Wedge 3 channels (0 ADC counts). 
The same kind of errors are present in correspondence in the  
"SiliMon******.sum" files. 
Expert paged. He said to do not worry about that !</pre>
<!-- Author: Giuseppe -->


<!-- Date: Wed Dec 19 10:01:40 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: Yuri Gotra -->


<!-- Date: Wed Dec 19 10:04:54 2001 -->
<pre>modified checksilogs to replace errsum with errtypes 
restarted SVX/SiliMon by request of SVX</pre>
<!-- Author: Yuri Gotra -->


<!-- Date: Wed Dec 19 11:08:22 2001 -->
<pre>running YMon and TrigMon on partition 4 by Ace's request</pre>
<!-- Author: Yuri Gotra -->


<!-- Date: Wed Dec 19 12:16:21 2001 -->
<pre>switched to cosmic runs 
switched to partition 14 for filming</pre>
<!-- Author: Yuri Gotra -->


<!-- Date: Wed Dec 19 14:01:36 2001 -->
<pre>switched back to part. 0</pre>
<!-- Author: Yuri -->


<!-- Date: Wed Dec 19 14:13:07 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>This is a note for all Consumer Operators:   
 
TrigMon XFT plots have some unusal features.  In particular, the finder segment occupancy for 
SL1(top plot of "XFT FINDER AND LINKER" canvas) shows an increase of about 30% for phi&lt;90deg.  
Furthermore, the "XFT FINDER Canvas Axial SL1" plot has a thick red horizontal band.    
 
 
These features are due to masking on sense wires 7 and 8 in the first quandrant of COT SL2.  The 
masking was done after the HV on those sense wires were lowered to avoid HV trips.  The mentioned 
features will remain until the HV for those wires are raised back to the nominal value. 
 
 - Cheng-Ju Lin  
</pre></td></tr></td></table>
<!-- Author: Yuri -->


<!-- Date: Wed Dec 19 16:09:54 2001 -->
<pre>run SVXMon on part. 6 (requested by Lester)</pre>
<!-- Author: Yuri -->


<!-- Date: Thu Dec 20 06:49:04 2001 -->
<pre>SiliMon crashed/restored several times.</pre>
<!-- Author: Giuseppe -->


<!-- Date: Thu Dec 20 08:34:45 2001 -->
<pre>added /cdf/people1/cdfdaq/consumer_scripts to $path</pre>
<!-- Author: Yuri Gotra -->


<!-- Date: Thu Dec 20 08:37:21 2001 -->
<pre>wrote xhost script for b0dap51: 
/cdf/people1/cdfdaq/consumer_scripts/setxhost.sh 
</pre>
<!-- Author: Yuri -->


<!-- Date: Thu Dec 20 15:19:25 2001 -->
<pre>New cdfsoftb0 release, 4.2.0int3a was made and tested 
with physics [6,232] table.  Except BeamMon, most of the 
consumers ran ok (no colliding beam).  EventDisplay was tested 
with [7,234] and did not work.  Aborted with the error -- 
not finding usedset (hardware event builder was used), 
so I don't really understand the problem. 
 
So, for now, I keep the default cdfsoftb0 as it was (4.2.0f). 
But it is setup now that: 
when the startup script, startMon.sh is ued, SVXMon and 
DAQMon will be running the new version (4.2.0int3a).</pre>
<!-- Author: Kaori -->


<!-- Date: Fri Dec 21 02:27:00 2001 -->
<pre>YMon, Silimon switched to beam data acquisition. 
SiliMOn crashed/restored.</pre>
<!-- Author: Giuseppe -->


<!-- Date: Fri Dec 21 19:12:14 2001 -->
<pre>I just installed another cdfsoftb0 version 4.2.0g. 
This is now decleared as 'current'. 
When one uses the normal startup script  (startMon.sh), 
all the consumers will be started with this default version.</pre>
<!-- Author: Kaori -->


<!-- Date: Sat Dec 22 22:24:04 2001 -->
<pre>Set YMon and SiliMon for Cosmic run</pre>
<!-- Author: PK Teng -->


<!-- Date: Sun Dec 23 23:21:54 2001 -->
<pre>LumMon/BeamMon Display getting worse and worse. 
Hang up all the time.</pre>
<!-- Author: PK -->


<!-- Date: Mon Dec 24 03:10:44 2001 -->
<pre>The LumMon Display gets frozen occasionally. It goes back to  
normal after it is restarted. 
 
</pre>
<!-- Author: Chunhui -->


<!-- Date: Mon Dec 24 04:49:41 2001 -->
<pre>The silicon monitoring binder is missing. Unable to complete  
the checklist for silicon.</pre>
<!-- Author: Chunhui -->


<!-- Date: Wed Dec 26 23:03:01 2001 -->
<pre>Part of COT is off 
SVX off 
L2 trig off</pre>
<!-- Author: PK -->


<!-- Date: Sat Dec 29 07:45:15 2001 -->
<pre>ObjectMon has stopped some times while owl shift. 
</pre>
<!-- Author: kato -->


<!-- Date: Sat Dec 29 18:04:32 2001 -->
<pre>Switches to physics run. Testing with PHYSICS_0_03[1,238]  
in preparation for data taking (run 135918)  
</pre>
<!-- Author: Oleg Poukhov -->


<!-- Date: Sun Dec 30 15:38:52 2001 -->
<pre>Owl CO reports several crashes of ObjectMon. 
Kaori suggests, in case of new crashes, to save a copy of 
the log file (and of core dump if any), which is in directory 
"/data1/consumer/runarea/ObjectMon/", 
then send e-mails to slee@fnal.gov, slava77@fnal.gov, and 
wgw@fnal.gov, specifying where you saved the log file. 
The current log file is overwritten when restarting the consumer process. 
 
Kaori will be out for about a week. 
In case of (unlike) severe problems with the consumer processes, 
e.g. general crashes after big changes in the run conditions, 
contact Hartmut Stadie. 
</pre>
<!-- Author: Mauro Dell&#39;Orso -->


<!-- Date: Sun Dec 30 23:55:41 2001 -->
<pre>switches to physics RUN. 
 
I couldn't run Trigmon, Ymon, Xmon and Lummon from b0dap51. 
I used b0dap52 and b0dap55 to run these consumers.</pre>
<!-- Author: Oleg Poukhov -->
<!-- Comment: Mon Dec 31 10;19;19 comment by...Mauro -->
<pre>In case your problems where with the displays, rather then with the monitoring processes,
sometimes you have to give the command "xhost + b0dap51 + b0dap52" on b0dap52
for TrigMon and Ymon, or "xhost + b0dap51 + b0dap55" on b0dap55
for XMon and LumMon, before starting the displays from b0dap51.</pre>


<!-- Comment: Mon Dec 31 14;16;36 comment by...Mauro -->
<pre>Sorry: I wrote "where" but I meant "were".</pre>
<!-- Date: Mon Dec 31 10:25:23 2001 -->
There is an SVX expert 
<a href= 
'/cgi/elog/elog.pl?nb=2001&action=view&page=953&frame=2&anchor=17:49:52'> 
request</a>  
to watch if SiliMon errors disappear.
<!-- Author: Mauro Dell&#39;Orso -->


<!-- Date: Mon Dec 31 14:05:42 2001 -->
<pre>There are some old instructions for the CO which say: 
"You should not have the normal consumer monitors (YMon, TrigMon, 
etc.) running on the same partition as a calibration run! This 
will hose things up and confuse the Ace." 
 
See: 
/COGuide/gettingReady.html 
 
Is this still true ? 
</pre>
<!-- Author: Mauro Dell&#39;Orso -->



<!-- Date: Mon Aug 16 20:45:48 2021 -->
<pre>Can not access main E-Log...</pre>
<!-- Author: Oleg Poukhov -->


<!-- Date: Mon Aug 16 20:57:39 2021 -->
To access main e-log I used address: 
  /cgi-bin/elog.pl?nb=2001 
given by Ayana.   
<!-- Author: Oleg Poukhov -->


<!-- Date: Mon Aug 16 21:06:40 2021 -->
<pre>sorry for spam, but previous 2 messages were written 
on December'31, not in August... :) 
</pre>
<!-- Author: Oleg Poukhov -->


<!-- Date: Mon Aug 16 23:14:37 2021 -->
<pre>I discovered that now is August 16 of 2021 year!!! 
Look at the date of YMon136006ab.root file, which is 
in directory: 
/data1/consumer/results/YMon 
 
(the real time now is Dec 31 22:12)</pre>
<!-- Author: Oleg Poukhov -->


<!-- Date: Tue Jan 1 06:59:13 2002 -->
<pre>When checking the WHA dead channel, the much events 
are needed. For example, there are many dead channels 
on WHA Tower at about 1000 events in run 136020. But  
there is no dead channel on WHA Tower at about 10000 
events in the same run. 
 
 </pre>
<!-- Author: kato -->


<!-- Date: Wed Jan 2 08:28:36 2002 -->
<pre>The on-call expert for the consumer processes is Koji. 
Long range pager: 266-2705 
</pre>
<!-- Author: Mauro Dell&#39;Orso -->


<!-- Date: Wed Jan 2 21:31:27 2002 -->
<pre>1. when I run consumer monitor terminals from b0dap51, 
consumer status page shows the absence of these  
consumers; 
 
2. when I run displays on b0dap52, b0dap55, I get 
refused messages from there, even if I typed  
xhost +b0dap51 +b0dap52 (or 55) before. The same 
situation is when I try to run event display.</pre>
<!-- Author: Oleg Poukhov -->


<!-- Date: Wed Jan 2 22:55:49 2002 -->
<pre>Consumer status web-page is OK now, but b0dap52 and b0dap55 
refuse to open displays. I paged to expert (Koji), but he says 
that I should type  
xhost + b0dap51 + b0dap55, for example. I did it, but no 
result. 
 
to run TrigMon, YMon, XMon and BeamMon I did the following 
(on b0dap52 and b0dap55): 
 
source ~cdfsoft/cdf2.cshrc 
setup cdfsoftb0 
HistoDisplayMain & 
 
Now I try to load Event Display. The error is the same - 
connection refused by server.</pre>
<!-- Author: Oleg Poukhov -->


<!-- Date: Wed Jan 2 23:11:44 2002 -->
<pre>Event Display program is loaded as usually!</pre>
<!-- Author: Oleg Poukhov -->


<!-- Date: Thu Jan 3 00:33:34 2002 -->
<pre>Display problem is resolved. I logout b0dap52, b0dap55,  
b0dap56, and b0dap50 and I login them. After this  
procedure, I can show the all consumer displays to 
them from b0dap50. </pre>
<!-- Author: Y.kato -->


<!-- Date: Thu Jan 3 17:48:46 2002 -->
<pre>there seems to be some weird time stamps for some recent files on 
 the online machines. i noticed it looking in the YMon results 
 directory. maybe this is not the elog to report it, but i will 
 still do so: 
 
 936 -rw-r--r--   1 cdfdaq   root     954754 Aug 16  2021 YMon136010aa.root 
   4 -rw-r--r--   1 cdfdaq   root        367 Aug 16  2021 YMon136010.sum 
 
etc..</pre>
<!-- Author: muge -->


<!-- Date: Fri Jan 11 21:17:37 2002 -->
<pre>Heather has added L2 information to the TrigMon page link: 
 
   "Consumer Operator Instructions" --&gt; "Level 2 Triggers" 
 
which tells you what to look for in the slide show plots.  Please 
take a look here.  Thanks.</pre>
<!-- Author: dave ambrose -->


<!-- Date: Sat Jan 12 07:59:08 2002 -->
Quiet night.  SiliMon crashed several times, and ObjectMon and BeamMon each crashed a time or two.  Spent much of the evening receiving tutorials on SiliMon and trying to make sense of monitor distributions.
<!-- Author: Bruce Knuteson -->


<!-- Date: Sun Jan 13 06:47:04 2002 -->
SiliMon seems to crash whenever the Silicon is not being integrated.  A description of the problem has been sent to Tara, the SiliMon author.
<!-- Author: Bruce Knuteson -->


<!-- Date: Sun Jan 13 12:17:33 2002 -->
<pre>Run 136923 and Run 136812 L1 and L2 Triggers Rates were compared. 
There was found to be no significant difference in the trigger 
cross-sections which would give rise to a change in the physics.</pre>
<!-- Author: Justin Lancaster -->


<!-- Date: Mon Jan 14 06:35:29 2002 -->
Symptom:  Had difficulty starting a calibration run -- run control seemed unable to find TrigMon and YMon, although they both appeared to be running.  The shells in which they were running were displayed on the upper monitor of b0dap51, as expected.  The TrigMon and YMon consumer status web page display programs were unable to find their respective sockets, and the Consumer Status web page showed both TrigMon and YMon but did not update their time stamps. 
 
Solution:  TrigMon was brought back into shape when Joel restarted run control.  YMon turned out to be due to a different problem -- the script was not changed from runPhysics to runCosmic when we changed from physics to cosmic ray running yesterday.
<!-- Author: Bruce Knuteson -->


<!-- Date: Tue Jan 15 04:38:05 2002 -->
We see errors in SiliMon:  several warning screens indicating that al ADC counts are zero in perhaps three dozen chips.  An email has been sent to the silicon folks.
<!-- Author: Bruce Knuteson -->


<!-- Date: Tue Jan 15 04:45:00 2002 -->
I have set up a directory in which to save canvases for which COs have questions.  The idea is that if a CO has a question for an expert on a particular plot, he should have the canvas (using "Save As" in Root) in the directory ~cdfdaq/questionPlots/ with the filename <monitorname>_<date>_<shift>_<xx>.ps, where <monitorname> = trigmon, silimon, etc., <date> = 15Jan2002, 02Feb2002, etc., <shift> = owl, day, or eve, and <xx> is 01, 02, 03, etc.  This canvas can then be referred to in an email to the experts, and can be saved for comparisons by future COs.
<!-- Author: Bruce Knuteson -->


<!-- Date: Thu Jan 17 03:58:57 2002 -->
Consumer difficulties:  I am having difficulty keeping the BeamMon display alive -- it crashes rather frequently.  The event display does not work; according to Weiming (evening shift CO), Koji is looking into this.  Having some trouble keeping the SiliMon display alive as well.<p> 
Noted detector problems:  Thus far tonight TrigMon has suggested a detector problem with XTRP; less urgent problems are noted with CES occupancies, and a strange feature is observed in a stage0 plot.
<!-- Author: Bruce Knuteson -->


<!-- Date: Sat Jan 19 04:04:53 2002 -->
<pre>SVXMon still has to be started with the startMon.sh script (rather than with the new startMon_new.sh script). Henri has been playing with SVXMon, but it keeps crashing with the new script. 
</pre>
<!-- Author: Henri / Matthias -->


<!-- Date: Sat Jan 19 05:36:03 2002 -->
<pre>The BeamMon / LumMon display freezes about every 5 minutes. Who is responsible? This problem has been seen &lt;a href= '/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=6&frame=2&anchor=03:58:57'&gt; 
before&lt;/a&gt; and &lt;a href= 
'/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=6&frame=2&anchor=23:21:54'&gt;before&lt;/a&gt;. 
</pre>
<!-- Author: Matthias -->


<!-- Date: Sat Jan 19 05:37:58 2002 -->
The BeamMon / LumMon display freezes about every 5 minutes. Who is responsible? This problem has been seen <a href= '/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=6&frame=2&anchor=03:58:57'> 
before</a> and <a href= 
'/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=6&frame=2&anchor=23:21:54'>before</a>.  
<!-- Author: Matthias -->


<!-- Date: Sat Jan 19 08:05:03 2002 -->
<pre>Compared YMon plots to reference plots. 
 
- Hot channel in CEM PMT plot: 7 East, phi = 15L 
 
- Hot channels in CPR West: phi = 7, wires 0-15 and in phi = 6, wire 1 
 
- Some hot channels in CCR pads (based on low statistics though) 
 
- TOF Z Position plot: average number of hits per event &lt; 50 (reference: 150) 
 
- CMP occupancy in all stacks of Parts N and T empty, many empty stacks in Part S 
 
- High MPAD occupancies 
</pre>
<!-- Author: Matthias -->


<!-- Date: Sat Jan 19 08:09:07 2002 -->
<pre>To prevent the LumMon / BeamMon / DAQMon display from freezing, delete LumMon and only load BeamMon / DAQMon. 
 
To check CLAD and CLTD plots (required for the detector check-list), one should start a HistoDisplay and connect it to the LumMon only. 
</pre>
<!-- Author: Matthias -->


<!-- Date: Sun Jan 20 02:14:17 2002 -->
<table border=0><td><tr><td bgcolor=#e0e030>Please read <a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=50&frame=2&anchor=08:28:30'> 
this e-log entry</a> for an explanation of the empty stacks in the CMP YMon plots. In addition, in the detector check-list a "0" should be entered for the CMP HV, even though the HVMon shows two green bars. 
 
CMX west wedges are turned off, too. 
</td></tr></td></table>
<!-- Author: Matthias -->


<!-- Date: Sun Jan 20 02:19:53 2002 -->
<pre>Please take note of the new instructions for "CMP Data 
Validation for the Shift Crew" (to be found in the detector 
check-list folder). 
</pre>
<!-- Author: Matthias -->


<!-- Date: Sun Jan 20 09:41:50 2002 -->
<pre>Hot PMT occupancy in CEM 7E 15L which was noticed earlier disappeared </pre>
<!-- Author: Intae Yu -->


<!-- Date: Sun Jan 20 10:43:24 2002 -->
<pre>High Occupancy in Stack 29 of the CMP South Part is consistently 
observed.  e-mail to the experts</pre>
<!-- Author: Intae Yu -->


<!-- Date: Sun Jan 20 15:55:13 2002 -->
<pre>dead channels in CEM 8E Wedge 5 and 9E Wedge 5. 
dead channels in CHA 4-8E, Wedge 5</pre>
<!-- Author: Intae Yu -->


<!-- Date: Mon Jan 21 11:09:38 2002 -->
<pre>&gt; 
&gt; Hi Evelyn, 
&gt; 
&gt; I am looking at some track trigger data and I have noticed 
&gt; that there are some spikes in the XFLD phibin distribution 
&gt; (bin 103, 105, 107, 187, 189, 191, 211, 213, 215), see the 
&gt; attached plot. I wonder if you see the same thing. The data 
&gt; is from run 137548. 
&gt; 
&gt;                                     Cheers, 
&gt; 
&gt;                                     Xin 
&gt; =========================================================   
 
You should page XTRP - they will try to reseat the XTRP boards to 
improve the connections.  Details below: 
                                                         
Thank you very much for noticing this and for telling me.  The 
problems are due to bad connections between the XTRP boards and 
the backplane.  The structure of groups of n,n+2,n+4 hot bins in 
phi are because three bins are sent over the same connection. 
  
The bad connections changes the track pt at XTRP and this must be 
increasing the the track/electron/muon trigger rate.  These extra triggers all have a track in the problem phi bins, so there are 
spikes in the linker track occupancy plot. 
 </pre>
<!-- Author: Evelyn Thomson -->


<!-- Date: Mon Jan 21 11:48:22 2002 -->
<pre>Wolfgang Wagner sent a reply to my e-mail about the ObjectMon 
display not showing any Jet/CalData distributions. 
 
For the time being the CO should restart the ObjectMon at the 
beginning of each run. 
</pre>
<!-- Author: Matthias -->


<!-- Date: Sat Jan 26 04:29:21 2002 -->
<pre>Test -- please ignore.</pre>
<!-- Author: CO&#39;s -->


<!-- Date: Fri Feb 8 22:27:39 2002 -->
<pre>The Print... dialogue box does not appear - at least not on the local display monitor - when attempting to print DBANA histograms. As a workaround, one can save the plots as .ps files and then manually route the files.</pre>
<!-- Author: Lenny Spiegel -->


<!-- Date: Sat Feb 9 15:38:25 2002 -->
<pre>Request for next CO shifter : can we get a hardcopy of all the plots on the checklist (and other relevant ones) today. The  
detector is doing well after some problems this morning and we 
need some updated reference histograms. 
</pre>
<!-- Author: Dave Waters -->
<!-- Comment: Sat Feb  9 18;27;34 comment by...Lenny Spiegel -->
<pre>2/9 Evening shift

I've made hardcopies of all of the reference plots.</pre>
<!-- Date: Sat Feb 9 15:56:06 2002 -->
<pre>YMon is not performing well. It suffers from freezes of several seconds, making it sometime painful to use. I am not sure of the reasons. One possibility is that TrigMon is affecting performance. I've noticed it can take a large fraction of the CPU.</pre>
<!-- Author: Dave Waters -->


<!-- Date: Sat Feb 9 17:33:30 2002 -->
<pre>On the Detector Check-List for the Calorimeter bit 1 is determined by 
 
# of consecutive dead(white box) channels&lt;30 for CES,CPR,CCR,PES,PPR 
 
     YMon "ShowerMax/xxxTowerCanvas",xxx=CES,CPR,CCR,PES,PPR 
 
The actual folder names are: 
 
                  CESStripCanvas 
                  CESWireCanvas 
 
                  CPRWireCanvas 
 
                  CCRPadCanvas 
 
                  PESEastCanvas 
                  PESWestCanvas 
 
                  PPRTowerCanvas (!) 
 
with implied bit OR'ing</pre>
<!-- Author: Lenny Spiegel -->



<!-- Date: Sat Feb 9 20:30:32 2002 -->
<pre>DBANA SMX Bad Channels (slope) and SMX Ped Summary plots added to log book for calibration run 138814.</pre>
<!-- Author: Lenny Spiegel -->


<!-- Date: Sat Feb 9 21:55:42 2002 -->
<pre>Store has been ended and Mario is setting up for a quiet time SMX calibration.</pre>
<!-- Author: Lenny Spiegel -->


<!-- Date: Sun Feb 10 01:51:33 2002 -->
<pre>ObjectMon appeared to have frozen at end-of-run. Killed and restarted ok.</pre>
<!-- Author: Tara -->


<!-- Date: Sun Feb 10 03:08:40 2002 -->
<pre>JetMonitor error screen appeared. #81: Check:[-3.0;1.0]^1.25 &gt;[1.0;3.0] FAILED. Mail sent to Wolfgang.</pre>
<!-- Author: Tara -->


<!-- Date: Sun Feb 10 06:57:25 2002 -->
<pre>ObjectMon just aborted (I did not see a helpful error message, just abort messages). Restarted.</pre>
<!-- Author: Tara -->


<!-- Date: Sun Feb 10 20:46:15 2002 -->
<pre>Made DBANA plots for recent COT calibration (138852, BAD COTCHANT0). 
 
Attempts to produce CLC:CLACQIE plots lead to segmentation violations! 
 
    </pre>
<!-- Author: Lenny Spiegel -->


<!-- Date: Mon Feb 11 00:13:55 2002 -->
<pre>ObjectMon had died at the end of run 138838. However runObjectMon and the Server were still active on b0dap56, which meant that the consumer screen hadnt turned red when ObjectMon died, and that slideshow histograms could e picked up by the display.  
I noticed this happening on last nights shift as well. No other consumer seems to die in this fashion.</pre>
<!-- Author: Tara -->


<!-- Date: Mon Feb 11 01:37:20 2002 -->
<pre>ObjectMon died (properly), restarted.</pre>
<!-- Author: Tara -->


<!-- Date: Mon Feb 11 02:08:22 2002 -->
<pre>ObjectMon died, restarted.</pre>
<!-- Author: Tara -->


<!-- Date: Mon Feb 11 03:09:44 2002 -->
<pre>ObjectMon died at end of run 138864, but runObjectmon and Server  
kept running. Killed runObjectMon and restarted.</pre>
<!-- Author: Tara -->


<!-- Date: Mon Feb 11 04:07:55 2002 -->
<pre>TrigMon died at the end of run 138866. This coincided with an error screen being displayed. Restarted.</pre>
<!-- Author: Tara -->


<!-- Date: Mon Feb 11 04:16:25 2002 -->
<pre>TrigMon crashes again (run 138867). Two error screens were produced just before it crashed. Restarted.</pre>
<!-- Author: Tara -->


<!-- Date: Mon Feb 11 14:54:32 2002 -->
<pre>The default version of DBANA (after doing ~cdfcalib/runDBANA) seems to crash when trying to look at CLACQIE calibrations : 
 
... 
Filling tablelist CLACQIE 
1 tables for this entry 
 Table run reference time= 35125922 
TLsize 1 
0: 'CLACQIE' 
In template GetData 
run  138901  version  1 
  
 *** Break *** segmentation violation     
</pre>
<!-- Author: Dave Waters -->


<!-- Date: Mon Feb 11 16:09:01 2002 -->
The 2nd L2 Decision crate b0l2de01 has been turned back on.  It has a new MagicBus backplane installed.
<!-- Author: Peter Wilson -->


<!-- Date: Mon Feb 11 16:40:58 2002 -->
<pre>SiliMon has crashed, perhaps due to the start of calibration runs?! Restart consumer.</pre>
<!-- Author: Lenny Spiegel -->


<!-- Date: Mon Feb 11 16:47:17 2002 -->
<pre>TrigMon just crashed at the start of 138922. Restart.</pre>
<!-- Author: Lenny -->


<!-- Date: Tue Feb 12 22:24:29 2002 -->
<pre>Went through the DBANA procedure for calibration run 138998 calorimeter PED and QIE2 categories. Not much else to do.</pre>
<!-- Author: Lenny Spiegel -->


<!-- Date: Thu Feb 14 11:05:40 2002 -->
<pre>Message from Kaori regarding Consumers : 
======================================== 
I just changed cdfsoftb0 default version from 
4.3.0int2a to 4.3.0int2b. 
Normal consumer startup scripts (startMon.sh, startDisplay.sh, 
startEvd.sh) will pick up the new version. 
 
=&gt; USE NORMAL START-UP SCRIPTS (startMon, startDisplay, startEvd)</pre>
<!-- Author: Dave Waters -->


<!-- Date: Thu Feb 14 13:14:35 2002 -->
<pre>YMon did not automatically pick up the new run and seemed 
to be stuck processing an old run. Had to restart YMon to 
solve this problem.</pre>
<!-- Author: Dave Waters -->


<!-- Date: Thu Feb 14 18:09:05 2002 -->
<table><tr><td><a href=/elog/notebooks/consumer-ops/Thu_Feb_14_2002_180840.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-174  align='top'></td><td>Rick Tesarek questioned the lack of phi symmetry in  the TrigMon #71 CalTriggerMonitor Dirac Tot Triggers  Occupancy. I'll send e-mail to the trigger experts.</a></td></tr></table>
<!-- Author: Lenny Spiegel -->


<!-- Date: Fri Feb 15 15:55:38 2002 -->
<pre>Problem with YMon ? 
 
On the status page, YMon indicates it is processing run 139209. 
 
In the YMon windoe it indicates that Prereq::beginRun has been called for run 139216. 
 
The most recent run was 139217. All the other consumers have caught up with the latest run OK. 
 
 
Here is the end of the YMon log file : 
 
Prereq:: beginRun, Trigger list for run 139216 
L1 Triggers and Bits 
1  L1_TWO_JET1.0_v-1 (Id#764) 
23  L1_MB_XING_PS1M_v-2 (Id#850) 
L2 Triggers and Bits 
0  L2_AUTO_L1_MB_XING_v-1 (Id#851) 
1  L2_AUTO_L1_TWO_JET1.0_v-1 (Id#765) 
L3 Triggers and Bits 
0  NULLPATH_v1 (Id#1482) 
SiAlignmentManager at beginRun: no DB requested 
RunSummary dbName = database 
ConsumerErrorAdministrator::attachStat(): ERROR 
Could not create _destStatCTRL instance. Pointer not NULL. 
</pre>
<!-- Author: Dave Waters -->
<!-- Comment: Fri Feb 15 18;31;25 comment by...Kaori -->
<pre>Since run 139209 was the last physics run, we
needed to switch YMon tcl (./runCosmic.sh) in
order YMon to get events for the runs after 139209.</pre>


<!-- Date: Sat Feb 16 03:48:42 2002 -->
<pre>We noticed that the list of consumer servers stopped updating at quarter past midnight - presumably due to the problem with b0dap30? For the moment we have connected to the monitors directly via hostname:port number, as it seems that histograms NOT on the quarter past midnight list of consumers are not automatically connected. Neither Andy (Ace) nor I know which process to restart to get this list updated. Kaori, do you know?</pre>
<!-- Author: Tara -->


<!-- Date: Sat Feb 16 15:13:46 2002 -->
<pre>Please CO's read this: 
---------------------- 
as many of us (Co's) has noticed  
the "Level 1, bit 1" item 
in the "Detector Check-list" does not match the  
present "Slides/DIRAC Canvas" in TrigMon  
(which has recently been updated) 
 
Waiting for the check-list to be updated accordingly,  
we should just COMPARE the "Dirac Canvas" slide with the reference one (in the binder) 
 
By the way, 
Matt Worcester has just provided us a complete set of  
Trigmon reference slides. 
 
</pre>
<!-- Author: Irene -->


<!-- Date: Sun Feb 17 04:01:59 2002 -->
<pre>XMon was EXTREMELY slow, so I decided to kill it and restart again. But after I typed Ctrl-C in its window it didn't die, 
but started working much faster! 
 
&lt;p&gt; Could there be two XMon processes running in the same window? 
May be I killed one of them and another became faster?</pre>
<!-- Author: Sasha R. -->


<!-- Date: Sun Feb 17 04:37:59 2002 -->
<pre>Oops - wrong assumption... XMon did die, I restarted it, but 
the display did not want to connect to it again, even 
when the host:port were typed by hands. Probably, this happened 
because the run was stopped (I don't know if it could have 
any impact...)</pre>
<!-- Author: Sasha R. -->


<!-- Date: Sun Feb 17 07:26:54 2002 -->
<pre>Because we were doing comics run I switched the monitors 
to cosmic (./runCosmic.sh), but no servers were available  
(except for SVTSPYMON), so I am switching back to physics  
now (./runPhysics.sh) anticipating next physics run</pre>
<!-- Author: Sasha R. -->


<!-- Date: Mon Feb 18 03:35:24 2002 -->
<pre>I had problems starting YMon on b0dap51 - it refused to connect 
to it's own screen even after  
xhost + b0dap51 
xhost + b0dap51.fnal.gov 
repeated a few times. So, I did "xhost + ", then started YMOn, 
then did "zhost - ". 
 
Similar problem occured with b0dap56 - solved the same way: 
xhost + 
start all monitors 
xhost - 
 
</pre>
<!-- Author: Sasha R. -->


<!-- Date: Mon Feb 18 04:28:11 2002 -->
<pre>It looks like TrigMon and YMon pick the new run automatically, 
while all the others have to be restarted for every new run. 
Is it a bug or a feature? 
</pre>
<!-- Author: Sasha R. -->


<!-- Date: Mon Feb 18 06:02:12 2002 -->
<pre>Oops - I didn't have to restart the monitor, I only had to restart the slide show...</pre>
<!-- Author: Sasha R. -->


<!-- Date: Mon Feb 18 06:03:08 2002 -->
<pre>ObjectMon has crashed and was restarted</pre>
<!-- Author: Sasha R. -->


<!-- Date: Mon Feb 18 06:13:22 2002 -->
<pre>ObjectMon has crashed again</pre>
<!-- Author: Sasha R. -->


<!-- Date: Tue Feb 19 05:01:35 2002 -->
<pre>The X server crahed on b0dap52 beacuse of my inaccurate handling... I had to power-cycle the machine. I forgot to  
kill TrigMon properly, so it lost all the histograms for the  
first part of the run 139375. </pre>
<!-- Author: Sasha R. -->


<!-- Date: Sun Feb 24 07:16:38 2002 -->
<pre>LumMon stoped, w/ message: 
 
INFO: LumMon sent message: END CONNECTION 
Going to terminate connection to LumMon running on 
b0dap67.fnal.gov 
%ERLOG-s Abnormal termination: caused by signal:   
6 Framework abortJob() 24-Feb-2002 06:58:50  
run = 139772 event = 0 
Framework::abortJob has been called a second time.   
User termination entry points will be skipped this time... 
tee: LumMon.cdfdaq.log: No space left on device 
runLumMon: Consumer ended with value  1. 
</pre>
<!-- Author: Nuno -->


<!-- Date: Tue Feb 26 20:52:00 2002 -->
Just to let you know that we're given today an <a href="/ops/cohelp/detector_checklist.html">updated</a> detector Check List. 
<br> 
Now We will set only one bit for L1 (and L2) by looking at 24 plots (!) and compaire them to the reference ones in the binder. 
<br> 
Make sure to use this new list from now on. 
<!-- Author: Nuno -->


<!-- Date: Fri Mar 1 15:41:52 2002 -->
<pre>ObjectMon and SiliMon crashed several times during the day.</pre>
<!-- Author: D. Lucchesi -->


<!-- Date: Sat Mar 2 17:00:01 2002 -->
<pre>The display servers for TrigMon and ObjectMon died. 
After reporting  
DisplayServer: Got an unexpected string from the consumer. 
 
Hartmut. 
</pre>
<!-- Author: Hartmut -->
<!-- Comment: Sat Mar  2 21;38;30 comment by...Hartmut -->
<pre>So I was mislead as well by the ouput. In fact it was the other 
way around. The consumer crashed, but the display server kept on
running. I guess it misinterpreted the end connection message
from the consumer. Somehow the run script gets stuck when this happens. It seems to wait for the server. 
  I have updated the run scripts to allow core files when a
consumer crashes.
</pre>


<!-- Date: Wed Mar 6 08:16:56 2002 -->
<pre>Dear COs, 
 
if you look at the SVXMon Chip Status Maps (in the SVXMon slide show), you will notice that there are much less red and yellow areas on them: I have masked most of the problematic chips.  
 
So if you see many red or yellow chips on the map (a few is OK), it means that there is a new problem ! Please check with the ACEs that everything is fine with the Silicon, and send me an email (bachacou@fnal.gov) or try to call me (x6412). 
 
This is still in its development stage. I will put more precise instructions (such as when you should page the Silicon expert and what you should check with the ACE) and update reference plots in the binder soon. 
 
Thanks !</pre>
<!-- Author: Henri -->


<!-- Date: Sat Mar 9 04:50:59 2002 -->
<pre>If you already know, please ignore this. 
SiliMon will crash if silicon crates are not included in the run, 
as of March 9, 2002. SVXMon won't crash but it cannot get events 
via socket connection. 
 </pre>
<!-- Author: K. Terashi -->


<!-- Date: Thu Mar 21 18:10:03 2002 -->
<pre>XMon crashed and restored</pre>
<!-- Author: Franco -->


<!-- Date: Thu Mar 28 08:57:43 2002 -->
<pre>Event display hung, restarted.</pre>
<!-- Author: Camille Ginsburg -->


<!-- Date: Mon Apr 1 16:36:33 2002 -->
<pre>It sometimes happens that a display process hangs, and cannot be re-started by using Choose and won't respond to Exit.  You can get out simply by opening a new xterm on that system, then closing it again.</pre>
<!-- Author: McIntyre -->


<!-- Date: Sat Apr 13 16:30:21 2002 -->
Please read  
<a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=308&frame=2&anchor=15:59:51'> 
note on Trigmon crashes </a>  in the shift logbook.
<!-- Author: Giovanni Punzi -->


<!-- Date: Sun Apr 14 19:29:58 2002 -->
<pre>Clicking and examining plots on the YMON canvas caused the YMON display to crash. Restarted with startDisplay.sh</pre>
<!-- Author: Giovanni -->


<!-- Date: Mon Apr 15 22:33:18 2002 -->
<pre>XMon crashes for the second time during this shift (related to 
the peculiar kind of data we are collecting ?)  
Messages reported below: 
 
Getting L3 trigger paths. 
Done. 
Error in &lt;TPad::Range&gt;: illegal world coordinates range: x1=-0.125000, y1=-13601085099.553354, x2=0.125000, y2=-58938032468.446648 
Error in &lt;TPad::RangeAxis&gt;: illegal axis coordinates range: xmin=-0.100000, ymin=-18134779904.000000, xmax=0.100000, ymax=-54404337664.000000 
%ERLOG-s Abnormal termination: caused by signal:  8 Framework abortJob()  
         15-Apr-2002 21:50:15 run = 143316 event = 1133 
</pre>
<!-- Author: Giovanni -->


<!-- Date: Sun Apr 21 19:05:29 2002 -->
<pre>ObjectMon JetMonitor shows empty canvas. We take jet triggers and  
I see jets on the event display. Restart of theObjectMon does not help.</pre>
<!-- Author: G.Velev -->
<!-- Comment: Mon Apr 22 11;34;46 comment by...Wolfgang Wagner -->
<pre>PuffModule has to be enabled to read CdfJets in JetMonitor.
That has now been changed in the runarea runObjectMon.tcl.
The PuffModule default for being disabled changed when 
going from 4.4.0int6 to 4.5.0int1 in consumer base release.</pre>
<!-- Date: Mon Apr 22 06:47:01 2002 -->
<pre>XMon shows error messages from SL1DMonitor; talked to ACES:  
it seems this is a presently occurring problem with L2 trig., known to the experts, and which is going to be fixed soon;  
for the time being data taking proceeds like this...</pre>
<!-- Author: Aldo -->



<!-- Date: Fri May 17 16:49:36 2002 -->
<table><tr><td><a href=/elog/notebooks/consumer-ops/Fri_May_17_2002_164854.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-178  align='top'></td><td>Testing Plots...</a></td></tr></table>
<!-- Author: Andrea Sansoni -->


<!-- Date: Fri May 17 16:54:40 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-179&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=-179  width='300' align='top'></td><td>Testing gif...</a></td></tr></table>
<!-- Author: Andrea Sansoni -->


<!-- Date: Fri May 24 18:38:45 2002 -->
<pre>YMon did not start sucessfully whit trigger table: 
PHYSICS_TEST_1_01[256,62,2xx]. 
The log files shows that YMon get staked after (or during)  
have read the L3 triggers and bits. 
Doing ps ax | grep YMon on b0dap51 give: 
 
2211 pts/2    S      0:08 YMon Consumer/YMon/runYMon.tcl 
2212 pts/2    S      0:00 tee -i YMon.cdfdaq.log 
 
Restarting YMon does not fix the problem. 
</pre>
<!-- Author: Stefano Giagu -->
<!-- Comment: Fri May 24 18;48;54 comment by...Stefano -->
<pre>I was able to restart YMon using cosmic setup 
(i.e. ./runCosmic.sh) ...
Maybe something wrong on the PHYSICS_TEST_1_01[25,..] 
table?</pre>


<!-- Date: Wed May 29 02:30:18 2002 -->
<pre>SiliMon dies soon even before it appears in the consumers status 
 
Run 145453</pre>
<!-- Author: Fiodar Prakoshyn (CO) -->


<!-- Date: Fri May 31 01:14:43 2002 -->
<pre>Silimon stil dying...</pre>
<!-- Author: CO -->


<!-- Date: Fri May 31 05:11:08 2002 -->
<pre>SiliMon now working!</pre>
<!-- Author: Fiodar Prakoshyn -->