<!-- Title: 22:47:52  Fri Nov  2 2001 -->
<!-- Crewchief: murat -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>trying to figure how to use it</pre>


<!-- Date: Fri Nov 2 22:48:41 2001 -->
<pre>looks like we can use it</pre>
<!-- Author: murat -->


<!-- Date: Fri Nov 2 22:51:50 2001 -->
<pre>Thanks Rick Vidal, we now have an offline electronic logbook - 
check out  
/cgi-bin/det-system-elog_res.pl?nb=offline</pre>
<!-- Author: murat -->


<!-- Date: Thu Nov 29 12:11:14 2001 -->
<pre>Startup the super expresss stream no fcdfsgi2 
 
Using calibration version 6 
 
     ProcessName set PROD_PHYSICS_CDF 
     Version set 6 
     parmSetName set PROD_PHYSICS_CDF6   
 
As we agreed at the offline operation meeting</pre>
<!-- Author: Yen-Chu Chen -->


<!-- Date: Thu Nov 29 12:13:25 2001 -->
<pre>The super express stream uses 4.1.0</pre>
<!-- Author: Yen-Chu Chen -->


<!-- Date: Fri Nov 30 09:23:43 2001 -->
<pre>The super express stream has been changed to process data with 
4.2.0 and with calibration version 6.</pre>
<!-- Author: Yen-Chu -->


<!-- Date: Fri Nov 30 12:09:05 2001 -->
<pre>The production farms are processing Stream J with 4.2.0 and 
calibration version 7. 
 
RUN range: 122621:128501 
 
Due to the worker node test which occupies most of the CPUs, 
the progress is slow. 
 
List to do: 
 
   Stream A, run: 122621:128501 
 
   Stream B, run: 126904:128501 
   Stream G, run: 126904:128501 
 
   Stream B, run: 122621:128903 
   Stream G, run: 122621:128903  
</pre>
<!-- Author: Yen-Chu Chen -->


<!-- Date: Mon Dec 3 10:02:50 2001 -->
<pre>Finally the super-express stream is working after Miro dig out 
QueryStatus for it to use.</pre>
<!-- Author: Yen-Chu Chen -->


<!-- Date: Mon Dec 3 10:37:01 2001 -->
<pre>Test entry</pre>
<!-- Author: Igor -->


<!-- Date: Mon Dec 3 15:15:50 2001 -->
<pre>First file produced by the super-express stream appeared in 
this afternoon, at 2:22 PM, Dec. 3, 2001. 
 
It is 
 
    fcdfsgi2:/cdf/data01/stream_a/aa020a19.0040phys 
 
and it has a file size of about 812 MB. 
 
More files to come!</pre>
<!-- Author: Yen-Chu Chen -->


<!-- Date: Tue Dec 4 12:22:51 2001 -->
<pre>Last night the production farm was restarted on Stream J to 
process data taken before shutdown. Previous processing was 
discarded since we can NOT concatenate compressed files. Will 
turn compression on when it is ready. 
 
Using 4.2.0a which is 4.2.0 withough compression plus two fixes 
in the code. Although it is still called 4.2.0 in the production. 
 
Using calibration version 7 which is default.</pre>
<!-- Author: Yen-Chu Chen -->


<!-- Date: Thu Dec 6 13:45:19 2001 -->
<pre>Super-express stream was restarted at noon today, Dec. 6, 2001. 
 
Again running with 4.2.0 and calibration version 6. 
 
</pre>
<!-- Author: Yen-Chu Chen -->


<!-- Date: Thu Dec 6 14:00:34 2001 -->
<pre>The super-express stream was restarted from run 133805 which 
is, according to Benn Tannenbaum &lt;benn@physics.ucla.edu&gt;, the 
first good run after the shutdown.</pre>
<!-- Author: Yen-Chu Chen -->


<!-- Date: Fri Dec 7 15:21:33 2001 -->
<pre>Due to the discovery of the tapes being smashed by the ROBOT 
(mis-alignment) the production farms has come to a stop to 
allow faster data logging to catch up with online data taking. 
 
Currently Stream A is done. Stream J is almost done. About 257 
files left to process.</pre>
<!-- Author: Yen-Chu Chen -->


<!-- Date: Fri Dec 7 15:22:51 2001 -->
<pre>As informed by the Paul of the DH group, two more stage in  
disks are assigned to the farms. Each has 0.5 TB space. 
 
These are /cdf/data05 and /cdf/data06.</pre>
<!-- Author: Yen-Chu Chen -->


<!-- Date: Fri Dec 7 15:55:38 2001 -->
<pre>Paul of the DH group made the correction that the additional 
disks are /cdf/data06 and /cdf/data07.</pre>
<!-- Author: yen-Chu Chen -->


<!-- Date: Sat Dec 8 15:03:21 2001 -->
<pre>Farms have started to produce MonteCarlo sample that should fill 1 tape. </pre>
<!-- Author: mirsi -->


<!-- Date: Sun Dec 9 04:03:59 2001 -->
<pre>Stream J finished processing with 4.2.0a. I've correctly updated version for both stream A and J in the farm internal DB. Web information should be therefore correct.</pre>
<!-- Author: mirsi -->


<!-- Date: Thu Dec 13 14:05:13 2001 -->
<pre>Since Dec. 12, 3 PMsuper-express stream runs with 4.2.0b with 
calibration version 6. 
 
Analyzing Stream A data starting from RUN 020b18(133912) due 
to the file available.</pre>
<!-- Author: Yen-Chu -->


<!-- Date: Fri Dec 14 12:56:29 2001 -->
<pre>Super-express stream has been switched to process newly taken 
data after Dec. 12. The first run being processed after this 
switching is 020e76 (134774). 
 
  EXE        : 4.2.0b 
  CALIBRATION: version 6 
 
</pre>
<!-- Author: Yen-Chu -->


<!-- Date: Fri Dec 14 13:01:22 2001 -->
<pre>Note about the naming of files produced from super-express stream 
 
Recently in processing stream A data the super-express stream used 4.2.0 which crashed much more often than 4.2.0b. Some files 
were generated with 4.2.0b. We tried to preserve files generated 
by the super-express stream before they have to go away due to 
the lack of disk space. 
 
The files produced by 4.2.0 were renamed and they have 
*.4_2_0 as the file name extension. 
 
The files produced by 4.2.0b have normal names and have no  
*.4_2_0 extension. There were at order of 40 files which failed 
in 4.2.0 due to BUS ERROR were produced by 4.2.0b. There were 
also some other files which were successfully produced by 4.2.0 
but were also reproduced before the switching.</pre>
<!-- Author: Yen-Chu -->


<!-- Date: Tue Dec 18 17:10:06 2001 -->
<pre>The production farms start to process stream A and stream J 
on the data after run 133896 with EXE 4.2.0b which seems to 
be doing OK with Stream A and Stream J data. Up to now no 
crash after 100K events in Stream A. 
 
Calibration version used is version 7, the default one.</pre>
<!-- Author: Yen-Chu -->


<!-- Date: Wed Dec 19 11:35:12 2001 -->
<pre>Collector of Stream A stopped working, had to restart it! 
 
************************************************************** 
 
The Stream A concatenator is waiting for the file "ac020b67.0001phys". 
 
Dec 19 11:21:36 2001: *** Concatenator Module Executing *** 
Dec 19 11:21:36 2001: max run is: 134931 
Dec 19 11:21:36 2001: Size so far: 3.9697540123 
Dec 19 11:21:36 2001: Waiting for ac020b67.0001phys 
 
There were 200 files to be collected but the collector of  
Stream A did nothing in the past few hours. 
 
Restart the collector of Stream A. 
 
</pre>
<!-- Author: Yen-Chu -->


<!-- Date: Wed Dec 19 22:19:58 2001 -->
<pre>calibration status for 4.3.x 
----------------------------- 
As things stand now, version 12 may be used for runs 
127262 to 128501 (inclusive). 
 
I was working on getting version 12 of PROD_PHYSICS_CDF 
prepared for use with production exe from 4.3.x. 
I believe I told you to use version 11 of PROD_PHYSICS_CDF 
when you were testing 4.3 on data from run 124759, 
and you can continue testing with this. 
However, my attempt to make version 11 for all good runs failed, 
for several bookekeeping/buggy reasons. 
I started to make version 12, but ran into some confusion. 
You should have a copy of my email to Jim K. about this, 
and I have pasted it into the offline_operations e-log. 
</pre>
<!-- Author: rob snihur -->


<!-- Date: Wed Dec 19 22:20:52 2001 -->
<pre>DBSetMerge problem? 
------------------- 
Hi Jim, 
After scratching my head for the longest time, 
I think I have uncovered some strange behaviour of DBSetMerge. 
Here's the command I tried, on b0dap30, setup cdfsoft2 development: 
DBSetMerge TESTMODE OTL /@cdfonprd used 122621 TEST PROD_PHYSICS_CDF 
 
The output shows it's not getting the highest version of PROD_PHYSICS_CDF! 
It should be getting version 11; instead it picks up version 9. 
The difference is obvious when you look at the CID for the CALDIGITOGEV3 table. 
You can see version 11 of PROD_PHYSICS_CDF at 
http://cdfdbb.fnal.gov:8520/cdfr2/databases?type=cal-us&do=r&nsrc=np&fsrc=fp&gsrc=fp&tbl=WHASLEWING&rc=n&dcbk=FILECATALOG&calbk=PUBLIC&cpn=PROD_PHYSICS_CDF&crun=122621&cver=11&usorder=-crjn 
 
Here are the tables contained in version 11 of PROD_PHYSICS_CDF| (output from an SQL script): 
[snihur@b0dap30 check_calib_table]$ sqlplus -s cdf_reader/reader@cdfonprd @tableids_from_run_and_name.sql 122621 PROD_PHYSICS_CDF 11 
CALDIGITOGEV              15835 20-MAR-01 
CALDIGITOGEV2             15403 20-MAR-01 
CALDIGITOGEV3             58413 07-DEC-01 
CALL1PEDS3                33259 14-JUN-01 
CALTRIGWEIGHTS            33755 18-JUN-01 
CEMLINERESPONSE           12385 21-DEC-00 
CHAEFFICIENCY             56075 15-NOV-01 
CHALINERESPONSE           58219 04-DEC-01 
CHASLEWING                56069 15-NOV-01 
CMPALL                    25195 12-MAY-01 
CMPCHANNEL                14371 20-MAR-01 
CMPPOSITION               47607 31-AUG-01 
CMPREGION                 14375 20-MAR-01 
CMPSTACK                  14379 20-MAR-01 
CMUALL                    25199 12-MAY-01 
CMUALL2                   52548 03-OCT-01 
CMUCHANNEL                14391 20-MAR-01 
CMUCHANNEL2               52546 03-OCT-01 
CMUPOSITION               47603 31-AUG-01 
CMUWEDGE                  14387 20-MAR-01 
CMXALL                    30019 30-MAY-01 
CMXCHANNEL                14403 20-MAR-01 
CMXPOSITION               47611 31-AUG-01 
CMXQUADRANT               14407 20-MAR-01 
CMXWEDGE                  14399 20-MAR-01 
COTCHANT0                 45703 16-AUG-01 
COTSTAGE0                 48179 02-SEP-01 
CSXCHAST                  47599 31-AUG-01 
CSXGLOBAL                 47595 31-AUG-01 
PEMLINERESPONSE           58385 07-DEC-01 
PESCALIB                  43379 03-AUG-01 
PESLASER                  43383 03-AUG-01 
PHAEFFICIENCY             56079 15-NOV-01 
PHALINERESPONSE           58387 07-DEC-01 
PHASLEWING                56073 15-NOV-01 
PPRLINERESPONSE           58285 06-DEC-01 
SICHIPPED                 51994 28-SEP-01 
SIFIBOFFSETS              22743 23-APR-01 
SISTRIPDH                 43447 04-AUG-01 
WHAEFFICIENCY             56077 15-NOV-01 
WHALINERESPONSE           58411 07-DEC-01 
WHASLEWING                56071 15-NOV-01 
 
 
The output of the DBSetMerge command above is: 
[snihur@b0dap30 v12]$ DBSetMerge TESTMODE OTL /@cdfonprd used 122621 TEST PROD_PHYSICS_CDF 
DBType=OTL 
DBConnect=/@cdfonprd 
Place=used 
fromValid=0 
run=122621 
onlyValid=0 
NewProcessName=TEST 
BaseProcessName=PROD_PHYSICS_CDF 
TestMode=1 
MergeNames= 
 
 
 
ERROR LOGGED WITHOUT DESTINATION! 
Attaching destination "cerr" to ELadministrator by default 
 
 
         ======================================================= 
 
         Error Log established 
         19-Dec-2001 21:36:56 
 
         ======================================================= 
 
%ERLOG-i USEDSET: Merging UsedSet: 
 
         Process=ProcessName=PROD_PHYSICS_CDFTag=1 
RunVersion=Run=122621 
Version=9 
Jobset=30853 
Status= 
Creation=Date=1007296487,Creator=SNIHUR 
 
          JobsetBuilder 19-Dec-2001 21:36:56 
########## PROCESSNAME = PROD_PHYSICS_CDF ########## 
DB=write 
 
CID=15835 table=CALDIGITOGEV runinfo=Run=109689 
Version=2 status=DOWNLOADED algo= creation=Date=985103607,Creator=LMARK 
CID=15403 table=CALDIGITOGEV2 runinfo=Run=109689 
Version=1 status=DOWNLOADED algo= creation=Date=985103608,Creator=LMARK 
CID=33263 table=CALDIGITOGEV3 runinfo=Run=122564 
Version=1 status=DOWNLOADED algo=UNDEFINED creation=Date=992558953,Creator=CDFDAQ 
CID=33259 table=CALL1PEDS3 runinfo=Run=122564 
Version=1 status=DOWNLOADED algo=UNDEFINED creation=Date=992558938,Creator=CDFDAQ 
CID=33755 table=CALTRIGWEIGHTS runinfo=Run=122564 
Version=1 status=DOWNLOADED algo=UNDEFINED creation=Date=992879065,Creator=CDFDAQ 
CID=12385 table=CEMLINERESPONSE runinfo=Run=109689 
Version=1 status=DOWNLOADED algo= creation=Date=977431017,Creator=CDFDAQ 
CID=12389 table=CHALINERESPONSE runinfo=Run=109689 
Version=1 status=DOWNLOADED algo= creation=Date=977431029,Creator=CDFDAQ 
CID=25195 table=CMPALL runinfo=Run=111175 
Version=2 status=COMPLETE algo= creation=Date=989641043,Creator=CDFDAQ 
CID=14371 table=CMPCHANNEL runinfo=Run=1 
Version=1 status=COMPLETE algo= creation=Date=985103611,Creator=LMARK 
CID=47607 table=CMPPOSITION runinfo=Run=120699 
Version=1 status=COMPLETE algo=UNDEFINED creation=Date=999231603,Creator=CDFDAQ 
CID=14375 table=CMPREGION runinfo=Run=1 
Version=1 status=COMPLETE algo= creation=Date=985103610,Creator=LMARK 
CID=14379 table=CMPSTACK runinfo=Run=1 
Version=1 status=COMPLETE algo= creation=Date=985103611,Creator=LMARK 
CID=25199 table=CMUALL runinfo=Run=111175 
Version=2 status=COMPLETE algo= creation=Date=989642387,Creator=CDFDAQ 
CID=52548 table=CMUALL2 runinfo=Run=111175 
Version=1 status=COMPLETE algo=UNDEFINED creation=Date=1002080033,Creator=VJMARTIN 
CID=14391 table=CMUCHANNEL runinfo=Run=1 
Version=1 status=COMPLETE algo= creation=Date=985103610,Creator=LMARK 
CID=52546 table=CMUCHANNEL2 runinfo=Run=1 
Version=1 status=COMPLETE algo=UNDEFINED creation=Date=1002079872,Creator=VJMARTIN 
CID=47603 table=CMUPOSITION runinfo=Run=2 
Version=1 status=COMPLETE algo=UNDEFINED creation=Date=999231506,Creator=CDFDAQ 
CID=14387 table=CMUWEDGE runinfo=Run=1 
Version=1 status=COMPLETE algo= creation=Date=985103610,Creator=LMARK 
CID=30019 table=CMXALL runinfo=Run=113500 
Version=1 status=COMPLETE algo= creation=Date=991252995,Creator=CDFDAQ 
CID=14403 table=CMXCHANNEL runinfo=Run=1 
Version=1 status=COMPLETE algo= creation=Date=985103609,Creator=LMARK 
CID=47611 table=CMXPOSITION runinfo=Run=123155 
Version=1 status=COMPLETE algo=UNDEFINED creation=Date=999232110,Creator=CDFDAQ 
CID=14407 table=CMXQUADRANT runinfo=Run=1 
Version=1 status=COMPLETE algo= creation=Date=985103609,Creator=LMARK 
CID=14399 table=CMXWEDGE runinfo=Run=1 
Version=1 status=COMPLETE algo= creation=Date=985103609,Creator=LMARK 
CID=45703 table=COTCHANT0 runinfo=Run=123920 
Version=1 status=COMPLETE algo=UNDEFINED creation=Date=997965216,Creator=CDFDAQ 
CID=48179 table=COTSTAGE0 runinfo=Run=125348 
Version=0 status=COMPLETE algo=UNDEFINED creation=Date=999463148,Creator=CDFDAQ 
CID=47599 table=CSXCHAST runinfo=Run=2 
Version=2 status=COMPLETE algo=UNDEFINED creation=Date=999231400,Creator=CDFDAQ 
CID=47595 table=CSXGLOBAL runinfo=Run=2 
Version=1 status=COMPLETE algo=UNDEFINED creation=Date=999229640,Creator=CDFDAQ 
CID=12397 table=PEMLINERESPONSE runinfo=Run=109689 
Version=1 status=DOWNLOADED algo= creation=Date=977431045,Creator=CDFDAQ 
CID=43379 table=PESCALIB runinfo=Run=122640 
Version=0 status=COMPLETE algo= creation=Date=996868835,Creator=TANNENBA 
CID=43383 table=PESLASER runinfo=Run=122640 
Version=0 status=COMPLETE algo= creation=Date=996868859,Creator=TANNENBA 
CID=12409 table=PHALINERESPONSE runinfo=Run=109689 
Version=1 status=DOWNLOADED algo= creation=Date=977434142,Creator=CDFDAQ 
CID=51994 table=SICHIPPED runinfo=Run=122606 
Version=1 status=COMPLETE_DPS algo=UNDEFINED creation=Date=1001672780,Creator=IGV 
CID=22743 table=SIFIBOFFSETS runinfo=Run=111193 
Version=1 status=COMPLETE algo= creation=Date=988048184,Creator=IGV 
CID=43447 table=SISTRIPDH runinfo=Run=122361 
Version=1 status=COMPLETE algo=UNDEFINED creation=Date=996942381,Creator=CERRI 
CID=12393 table=WHALINERESPONSE runinfo=Run=109689 
Version=1 status=DOWNLOADED algo= creation=Date=977431037,Creator=CDFDAQ 
 
 
Again, DBSetMerge picks up version 9, which has an old CALDIGITOGEV3 table. 
I saw the same behaviour with a much older version of the DBSetMerge executable. 
I then issued the DBSetMerge command, without the TESTMODE argument. 
The resulting used_set with process_name TEST was taken from verison 9 of PROD_PHYSICS_CDF, 
and can be viewed at: 
http://cdfdbb.fnal.gov:8520/cdfr2/databases?type=cal-us&do=r&limit=125&nsrc=np&fsrc=fp&gsrc=fp&tbl=WHALINERESPONSE&rc=n&dcbk=FILECATALOG&calbk=PUBLIC&cpn=TEST&crun=122621&usorder=-crjn 
 
Can you solve this puzzle? 
I had been hoping to make a complete calibration set for 4.3.0 
of production before I leave for holidays Thursday morning, 
but this problem got in the way. 
A workaround would be time consuming. 
 
thanks, 
-rob 
 
</pre>
<!-- Author: rob snihur -->


<!-- Date: Fri Dec 21 10:42:49 2001 -->
<pre>'100K' test on 4.2.0c done.  
 
No crash during the test! ;-) 
 
Typical usage of CPU time per event and file size are given 
below. 
 
On Stream G data: 
================= 
 
No crash in processing 99K events! 
 
Average CPU time:   2.05 s/event 
 
File size example of one file : 
 
Input: 
 
  fname               num_event    file size 
 
  gr020b11.0030phys   9137         106 GB 
 
Output: 
 
  fname               num_event    file size      L3 trigger 
 
  ge020b11.0030tst1   4489         772 MB         JET 
  ge020b11.0030tst2    433          71 MB         ET 
  ge020b11.0030tst3   4275         455 MB         BIAS 
 
 
 
On Stream J data: 
================= 
No crash within 47.5 K events processed. 
 
Average CPU time:   6.5 s/event 
 
File size example of one file: 
 
   Input: 
 
     fname               num_event    file size 
 
     jr020b0f.0001phys   6177         1.07 GB 
 
   Output: 
 
     fname               num_event    file size      L3 trigger 
 
     je020b0f.0001phys   6177         1.09 GB        MUON 
 
 
On Stream B data: 
================= 
 
No crash within 122.9 K events processed. 
 
Average CPU time:   4.2 s/event 
 
File size example of one file: 
 
   Input: 
 
     fname               num_event    file size 
 
     br020b0f.007cphys   5746         1.04 GB 
 
   Output: 
 
     fname               num_event    file size      L3 trigger 
 
     be020b0f.007ctst1   5567         1.04  GB       ELECTRON 
     be020b0f.007ctst2    205         0.035 GB       PHOTON 
 
 
 
 
</pre>
<!-- Author: Yen-Chu -->


<!-- Date: Sat Dec 22 14:44:12 2001 -->
<pre>10 K tests for 4.3.0pre1 done on: 
 
- three old "10K test" files: 
 
  gr01f5f5.0089phys-ana 
  ar01f5b8.0086phys-ana 
  jr01f5b5.0052phys-ana 
 
- and three new: 
 
  gr021040.0001phys-ana 
  br021040.0083phys-ana 
  jr021040.0001phys-ana 
 
 
No crashes, no major errors reported in the log files...</pre>
<!-- Author: Petar -->


<!-- Date: Sat Dec 22 14:46:18 2001 -->
<pre>For future reference, here's list of new files on fcdflnx1  
that can be picked up by the run10Ktest script: 
 
 
Hi Petar, 
 
I copied files of streams b,g,j of run 135232 to the place you specified: 
 
-rw-r--r--   1 cdfprod0 cdf      1062122392 Dec 21 18:05 jr021040.0001phys 
-rw-r--r--   1 cdfprod0 cdf      1041096529 Dec 21 18:11 jr021040.000cphys 
-rw-r--r--   1 cdfprod0 cdf      1066366247 Dec 21 18:25 jr021040.0017phys 
-rw-r--r--   1 cdfprod0 cdf      1024202937 Dec 21 19:03 jr021040.0023phys 
-rw-r--r--   1 cdfprod0 cdf      1031265297 Dec 21 18:41 gr021040.0001phys 
-rw-r--r--   1 cdfprod0 cdf      1078131020 Dec 21 19:42 gr021040.0019phys 
-rw-r--r--   1 cdfprod0 cdf      1021077481 Dec 21 19:48 gr021040.0026phys 
-rw-r--r--   1 cdfprod0 cdf      1033655259 Dec 21 19:53 gr021040.0032phys 
-rw-r--r--   1 cdfprod0 cdf      1043491795 Dec 21 20:01 br021040.0083phys 
-rw-r--r--   1 cdfprod0 cdf      1126461494 Dec 21 20:11 br021040.008aphys 
-rw-r--r--   1 cdfprod0 cdf      959947667 Dec 21 20:16 br021040.00a0phys 
-rw-r--r--   1 cdfprod0 cdf      1018744726 Dec 21 20:21 br021040.00a7phys 
 
this is a little more than 10K of each stream. Have fun 
 
Dmitri Litvintsev 
</pre>
<!-- Author: Petar for Dmitri -->


<!-- Date: Sun Dec 23 01:05:39 2001 -->
<pre> 
I processed 70 out of 140 files that crashed 4.2.0b production 
with the new 4.3.0pre1 executable. 
 
All 70 finished fine.  I expected this, since: 
 
- the non-memory-leak-related causes of crashes have been fixed 
 
- various 10K tests worked fine. 
 
This rules out memory-leaks caused by single events (e.g.  
running out of memory due to enormous number of track candidates 
caused by too many noise hits).  However, memory leaks still 
exist... 
</pre>
<!-- Author: Petar -->


<!-- Date: Fri Dec 28 14:19:36 2001 -->
<pre>Status of the production farm: 
 
The farm is currently stuck for various reasons. Still working 
on them. 
 
Started up the MC_MDC2 farmlet to generate the 6 x 25 MC files  
that the MC group requested. 80 CPU's are used for this  
procedure. 
 
Will verify the new EXE 4.3.0pre1. If the result from the 10K 
test was certified we will proceed to 100K test.</pre>
<!-- Author: Yen-Chu -->


<!-- Date: Fri Dec 28 15:06:55 2001 -->
<pre>The resulting plots of 10K tests of executable version 4.3.0pre1_a are available at 
 
        fcdflnx1:/cdf/scratch/cdfprod0/4.3.0pre1_a 
 
        subdirectories: 
 
        Stream_A 
        Stream_B 
        Stream_G 
        Stream_J 
 
PS files are in 'plots' directory 
 
Test were run on stream A,B,G,J files of 'older' runs 128440,128501 and on B,G,J stream files of 'newer' run 135232 
 
General comments: 
 
farms_hist.C fails due to the null pointer: 
 
Error: illegal pointer to class object h11 0x0 137 
FILE:/cdf/code/cdfsoft/dist/releases/development/FarmTools/hist/farms_hist.C LINE:3142 
*** Interpreter error recovered *** 
 
This is in RawMonitor: 
 
       TH2 *h11         =  (TH2*)gROOT.FindObject("hrawSVXRPhi"); 
       TH2 *h12         =  (TH2*)gROOT.FindObject("hrawSVXZ"); 
       TH2 *h13         =  (TH2*)gROOT.FindObject("hrawSVXcomp"); 
       TH2 *h14         = (TH2*)gROOT.FindObject("hrawSVXcompz"); 
       TH2 *h15         =  (TH2*)gROOT.FindObject("hrawL00"); 
       TH2 *h16         =  (TH2*)gROOT.FindObject("hrawL00comp"); 
all the pointers are null. 
 
 
1) RawMonitor is empty 
2) TowerValidation produced plots only for stream G data 
 
Plots for new run and older run look similar. New run has non-empty CMX related histograms in MuonValidation PS file 
 
We would like to hear if the produced 
validation plots are satisfactory so we can proceed with 100K 
test of 4.3.0pre1_a executable 
 
 
Darin & Dmitry , off-line shifters</pre>
<!-- Author: Dmitry Litvintsev -->


<!-- Date: Mon Dec 31 12:08:08 2001 -->
<pre>test</pre>
<!-- Author: Murat@fnal.gov -->


<!-- Date: Fri Jan 18 12:46:49 2002 -->
<pre>From: Mark Leininger &lt;markl@fnal.gov&gt; 
To: cdf_offline_operations@fnal.gov, cdf-farms@fnal.gov, cdfsys@fnal.gov, cdfdh_oper@fnal.gov 
Subject: 20 stream script running 
Date: Fri, 18 Jan 2002 11:47:46 -0600 
Sender: owner-cdf_offline_operations@listserv.fnal.gov 
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686) 
 
 We are running the scripts to support 20 streams on the farms. 
 Rich and Mark 
 
</pre>
<!-- Author: murat -->


<!-- Date: Fri Jan 18 12:47:54 2002 -->
<pre>From: Dmitri Litvintsev &lt;litvinse@fnal.gov&gt; 
To: Mark Leininger &lt;markl@fnal.gov&gt; 
Cc: cdf_offline_operations@fnal.gov, cdf-farms@fnal.gov, cdfsys@fnal.gov, cdfdh_oper@fnal.gov 
Subject: Re: 20 stream script running 
Date: Fri, 18 Jan 2002 12:30:40 -0600 
Sender: owner-cdf_offline_operations@listserv.fnal.gov 
 
 Hi, 
 
 I just entered the folowing datasets into DFC: 
 
 
 dataset_id : dataset_name 
 ------------------------- 
 aexp01 : EXPRESS-A-4.3.0-v13 
 bele01 : HIGH_ET_ELECTRON-B-4.3.0-v13 
 bmuo01 : HIGH_PT_MUON-B-4.3.0-v13 
 bsea01 : HIGH_PT_SEARCHES-B-4.3.0-v13 
 bwtp01 : OTHER_W_TOP-B-4.3.0-v13 
 cph101 : HIGH_ET_PHOTON-C-4.3.0-v13 
 cph201 : OTHER_PHOTON-C-4.3.0-v13 
 etau01 : TAU-E-4.3.0-v13 
 edil01 : SUSY_DILEPTON-E-4.3.0-v13 
 emjt01 : MET_JET-E-4.3.0-v13 
 emet01 : MET-E-4.3.0-v13 
 ebjt01 : HIGH_PT_B_JET-E-4.3.0-v13 
 gjtc01 : JET_CALIB-G-4.3.0-v13 
 gjts01 : SOFT_JET-G-4.3.0-v13 
 gjth01 : HIGH_ET_JET-G-4.3.0-v13 
 gcrs01 : ZERO_BIAS-G-4.3.0-v13 
 hbhd01 : B_HADRONIC-H-4.3.0-v13 
 jbsl01 : B_SEMILEPTONIC-J-4.3.0-v13 
 jbll01 : B_DIMUON-J-4.3.0-v13 
 dmon01 : MONITOR-D-4.3.0-v13 
 incl01 : INCLUSIVE-I-4.3.0-v13 
</pre>
<!-- Author: murat -->

<!-- Date: Fri Jan 18 18:08:52 2002 -->
<pre> 

attempt to make an entry into offline e-log from email

</pre>
<!-- Author: murat -->



<!-- Date: Sat Jan 19 12:05:48 2002 -->
<pre>I've started express production at fcdfsgi2 with cdfpatch 4.3.0b, starting production back from Jan 15th.</pre>
<!-- Author: mirsi -->