<!-- Title: 21:31:56  Mon Feb 17 2003 -->
<!-- Crewchief: Joao Guimaraes -->
<!-- Op1: Wolfgang Wagner -->
<!-- Op2: Ray Culberston -->
<!-- Op3: Karen Gibson -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
This elog is used for Beamline Operations and related issues. The elog was started after the January 2003 shutdown and it will contain information about the runs taken after starting of collisions on Feb 10, 2003.


<!-- Date: Tue Feb 18 14:52:39 2003 -->
<table border=0><td><tr><td bgcolor=#e0e030>I have built a new executable to process the beamlines for runs after the shutdown. The new executable was needed to access data through dCache. It was built with 4.9.1hpt2 and the vertex code version tag v4_9_1_beam: VertexMods, VertexAlg and TrackingUserMods. No changes are expected from the previous executable since hpt2 only adds some patches for dCache. 
<br><br> 
The code was built under cdfopr account and the working directory is: fcdflnx3:/cdf/opr/cdfopr/beamlines/4.9.1hpt2_beam 
<br> <br> 
In order to run on the CAF we will need to setup 4.9.1hpt2 and 
dcap v2_24_f0203 within the CAF script. 
</td></tr></td></table>
<!-- Author: Joao -->


<!-- Date: Fri Feb 21 17:49:09 2003 -->
<pre>First pass at post-shutdown beamline histograms for runs 
 
158644  
158731 
158732 
 
submitted to dCache on CAF2... wait and see if dCache submission works.</pre>
<!-- Author: Karen -->


<!-- Date: Mon Feb 24 14:53:41 2003 -->
<pre>Another try at submitting makeBeamHists job to dCache (cdfopr now has access to dCache on caf2.)</pre>
<!-- Author: Karen -->
<!-- Comment: Mon Feb 24 16;45;42 comment by...Karen -->
<pre>All 3 runs (158644, 158731, and 158732) have successfully completed. Checked the log/root files and things look good... next step is fitbeamjob_refit. What do we want to do w/the generic CAF log files and *.tgz files?   </pre>


<!-- Date: Thu Feb 27 08:50:58 2003 -->
<pre>I made the first DB entires today for the post-shotdown data  
(runs 158644, 158731, 158732) from the cdfopr account. The log file is  
 
[cdfopr@fcdflnx3 4.9.1hpt2_beam]$ pwd 
/cdf/opr/cdfopr/beamlines/4.9.1hpt2_beam 
[cdfopr@fcdflnx3 4.9.1hpt2_beam]$ less fitbeam022703.log 
 
SVX was off in all three runs, and I get messages like  
 
 MakeUsedValidSet: no table SVXBEAMPOSITION for run 158732 found. 
 
Is this okay?  </pre>
<!-- Author: Karen -->
<!-- Comment: Thu Feb 27 13;51;37 comment by...Wolfgang -->
<pre>Looking at the log file, I would say it is okay. The message
comes because there is no svx beamline. The fit failed because
there was no silicon.</pre>


<!-- Comment: Fri Feb 28 13;53;21 comment by...Wolfgang -->
<pre>Just checked the data base. All 3 runs have COT beamlines.</pre>
<!-- Date: Fri Feb 28 04:13:07 2003 -->
<pre>I have finished to create new version of PAD_PHYSICS_SVXBEAM pass 08 and PAD_PHYSICS_COTBEAM pass 07. 
</pre>
<!-- Author: Hartmut -->



<!-- Date: Wed Mar 5 10:50:58 2003 -->
<pre>Submitted 38 runs to CAF2 (JID 11107) to be processed: 
 
set run_number(1) 158733 
set run_number(2) 158799 
set run_number(3) 158811 
set run_number(4) 158821 
set run_number(5) 158822 
set run_number(6) 158826 
set run_number(7) 158827 
set run_number(8) 158829 
set run_number(9) 158830 
set run_number(10) 158873 
set run_number(11) 158874 
set run_number(12) 158875 
set run_number(13) 158876 
set run_number(14) 158877 
set run_number(15) 158879 
set run_number(16) 158880 
set run_number(17) 158894 
set run_number(18) 158895 
set run_number(19) 158976 
set run_number(20) 158977 
set run_number(21) 158978 
set run_number(22) 159141 
set run_number(23) 159175 
set run_number(24) 159176 
set run_number(25) 159189 
set run_number(26) 159199 
set run_number(27) 159202 
set run_number(28) 159203 
set run_number(29) 159227 
set run_number(30) 159228 
set run_number(31) 159259 
set run_number(32) 159260 
set run_number(33) 159261 
set run_number(34) 159264 
set run_number(35) 159288 
set run_number(36) 159289 
set run_number(37) 159608 
set run_number(38) 159609 
 
The runs are now in directory /cdf/scratch/cdfprod0/4.8.4a_09/Stream_G/hist/ 
so I changed the scripts accordingly. 
 
If everything is successful, I'll make the DB entries later today. 
</pre>
<!-- Author: Karen -->
<!-- Comment: Wed Mar  5 11;17;18 comment by...Karen -->
<pre>Processing of runs failed.  I get error messages like 

%ERLOG-w TrackRefitter: /home/cdfsoft/dist/packages/TrackingUserHL/V00-00-10/src/TrackRefitter.cc
        : 70  SiliMapIntegrator(): Map not initialized.
         Use proper SimInitManager Option  GlobalLibraryLogger
          5-Mar-2003 10:49:01 run = 0 event = 0
%ERLOG-w RCP put failure: unable to store RCP for vxprim-svx  write failed.
         vxprim-svx  5-Mar-2003 10:49:01 run = 0 event = 0
%ERLOG-w RCP put failure: unable to store RCP for vxprim-cot  write failed.
         vxprim-cot  5-Mar-2003 10:49:01 run = 0 event = 0
%ERLOG-w DHInputDataList-&gt;: everything is done  GlobalLibraryLogger
         DHInputDataList::prepareNextFile()  5-Mar-2003 10:49:01
         run = 0 event = 0
%ERLOG-e readNextEvent-pre: TFile pointer is null. File is not open.
         GlobalLibraryLogger MultiRootInputFile::readNextEvent()
          5-Mar-2003 10:49:01 run = 0 event = 0

Will recompile the libraries and makeBeamHists and try again.  </pre>

<!-- Comment: Wed Mar  5 11;59;45 comment by...Karen -->
<pre>I remade the libraries and executable and tried submitting the jobs again; JID: 11143 on CAF2.  Wait and see what happens...</pre>

<!-- Comment: Wed Mar  5 12;05;32 comment by...Karen -->
<pre>Again no luck... In addition to the errors mentioned above, I also noticed this error

%ERLOG-w RCP put failure: unable to store RCP for vxprim-cot  write failed.
         vxprim-cot  5-Mar-2003 11:58:47 run = 0 event = 0
%ERLOG-w RCP put failure: unable to store RCP for vxprim-svx  write failed.
         vxprim-svx  5-Mar-2003 11:58:47 run = 0 event = 0
GetFiles error. Reason: DataNotFound

which I had overlooked in the first set of log files.  Maybe a problem w/dCache?  Our problem?  </pre>


<!-- Date: Wed Mar 5 21:00:03 2003 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>The dataset we have to use now is gjet09.  
This dataset starts with run 158733. 
So far, the last run available in the DFC is 158978. 
 
As karen pointed out, the histograms are now in 
/cdf/scratch/cdfprod0/4.8.4a_09/Stream_G/hist/</pre></td></tr></td></table>
<!-- Author: Joao -->


<!-- Date: Thu Mar 6 17:54:24 2003 -->
<pre>I re-submitted the makeBeamHists jobs to CAF2 at ~12:00pm.  This time accessing the gjet09 dataset.  There are now 42 runs to be processed.  At present, the jobs are still running. 
 
set run_number(1) 158733 
set run_number(2) 158799 
set run_number(3) 158811 
set run_number(4) 158821 
set run_number(5) 158822 
set run_number(6) 158826 
set run_number(7) 158827 
set run_number(8) 158829 
set run_number(9) 158830 
set run_number(10) 158873 
set run_number(11) 158874 
set run_number(12) 158875 
set run_number(13) 158876 
set run_number(14) 158877 
set run_number(15) 158879 
set run_number(16) 158880 
set run_number(17) 158894 
set run_number(18) 158895 
set run_number(19) 158976 
set run_number(20) 158977 
set run_number(21) 158978 
set run_number(22) 159141 
set run_number(23) 159175 
set run_number(24) 159176 
set run_number(25) 159189 
set run_number(26) 159199 
set run_number(27) 159202 
set run_number(28) 159203 
set run_number(29) 159227 
set run_number(30) 159228 
set run_number(31) 159259 
set run_number(32) 159260 
set run_number(33) 159261 
set run_number(34) 159264 
set run_number(35) 159288 
set run_number(36) 159289 
set run_number(37) 159603 
set run_number(38) 159607 
set run_number(39) 159608 
set run_number(40) 159609 
set run_number(41) 159610 
set run_number(42) 159611</pre>
<!-- Author: Karen -->


<!-- Date: Mon Mar 10 14:26:13 2003 -->
<pre>I made FitBeam entries for all 31 runs that successfully ran on the CAF.  A comprehensive summary table of the run status is now in the cdfopr directory /cdf/opr/cdfopr/beamlines/4.9.1hpt2_beam/runCompletionStatus.  It lists the completion status of all runs submitted to the CAF and DB entries made.  
 
Of note: 12/34 runs successfully processed from the post-shutdown period have no COT vxprim DB beamline, while all 12 of the runs in question do have a COT d-phi beamline. (SVX was off for all runs processed.) </pre>
<!-- Author: Karen -->

<!-- Date: Mon Mar 10 16:08:54 2003 -->
<pre>
To make entries by email in the elog see the documentation:
http://www-cdfonline.fnal.gov/e-log/cdf_elog_hints.html
under "New Feature".

One can email text (only) but needs some html tags in the email.
</pre>
<!-- Author: Joao -->


<!-- Date: Mon Mar 10 17:00:56 2003 -->
<pre>
Created a directory on fcdflnx3 to store information to be accessible on 
the web. The directory is: /cdf/home/www/usr/cdfopr/Beamline/

The table by Karen with the list of processed runs was moved there and 
it is now accessible on the web: 
http://fcdfhome.fnal.gov/usr/cdfopr/Beamline/runCompletionStatus
The list has a symlink in /cdf/opr/cdfopr/beamlines/4.9.1hpt2_beam point 
to the web directory.

This information is also available at the bottom of our vertex/beamline 
webpage under the "Beamline Operations:" section.
</pre>
<!-- Author: Joao -->



<!-- Date: Wed Mar 19 14:10:30 2003 -->
<pre>Re-submitted 45 previous runs in addition to 17 new runs to CAF2 job 13959. The list of runs is as follows. 
 
158644 
158731 
158732 
158733 
158799 
158811 
158821 
158822 
158826 
158827 
158829 
158830 
158873 
158874 
158875 
158876 
158877 
158879 
158880 
158894 
158895 
158976 
158977 
158978 
159141 
159175 
159176 
159189 
159199 
159202 
159203 
159227 
159228 
159259 
159260 
159261 
159264 
159288 
159289 
159603 
159607 
159608 
159609 
159610 
159611 
160090 
160091 
160092 
160150 
160151 
160152 
160153 
160157 
160175 
160227 
160229 
160230 
160259 
160300 
160301 
160302 
160303 
</pre>
<!-- Author: Karen -->
<!-- Comment: Wed Mar 19 16;54;10 comment by...Karen -->
<pre>Re-submitted first 7 runs, job 13976, b/c of library problems and my initial failure to also include dataset gjet08.</pre>


<!-- Date: Thu Mar 20 13:08:50 2003 -->
<pre>Finished checking 62 runs sent to CAF yesterday... 
 
62 runs successfully completed 
21 runs w/o Si tracks -&gt; 41 runs w/Si  
 
Next step, make DB entries (& UsedValidSets?) later this afternoon.</pre>
<!-- Author: Karen -->


<!-- Date: Fri Mar 21 12:22:33 2003 -->
<pre>Finished checking DB entries for 62 runs (HC=19).  Everything looks good.  21 runs w/o Si, & 16 runs w/o vxprim COT DB entry, but w/d-phi entry (11/16 have vxprim SVX DB entry.)  Next need to do HC=17...</pre>
<!-- Author: Karen -->


<!-- Date: Sun Mar 23 15:46:50 2003 -->
<pre>Submitted fitbeamjob for HC=17. Out of 62 runs fit w/HC=19, 22 had no HC=17 entry.  Not sure why this is the case...</pre>
<!-- Author: Karen -->

<!-- Date: Sun Mar 23 17:49:59 2003 -->
<pre>


	Matt says that the 4.9.1 refitter code did not scale the Cot errors
matrix correctly when using the KalFitter.  Was this known to you
and fixed?  Does this make sense with respect to observed scale factors?


---------- Forwarded message ----------
Date: Fri, 21 Mar 2003 17:18:22 -0600 (CST)
From: Matthew Herndon <herndon@ncdf61.fnal.gov>
To: cdf_code_librarians@fnal.gov
Subject: tracking tags 4.10.0int1

   Hi All,

  I tagged changes to the TrackRefitter and the silicon hit resolutions.
These tags fix the COT scaling problem in the refitter and update to the
latest measurements of the silicon hit resolution.


cvs rtag v4_10_0int1
TrackingUserHL/TrackingUserHL/TrackFitting/TrackRefitter.hh
cvs rtag v4_10_0int1 TrackingUserHL/src/TrackRefitter.cc

cvs rtag v4_10_0int1 TrackingObjects/src/SiHitResolutionSet.cc

  - matt

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



<!-- Date: Tue Mar 25 11:48:04 2003 -->
<pre>Submitted 15 new runs to CAF2: 
 
160305 
160306 
160312 
160314 
160346 
160349 
160350 
160351 
160359 
160403 
160404 
160405 
160406 
160407 
160408 
 
</pre>
<!-- Author: Karen -->
<!-- Comment: Tue Mar 25 11;50;40 comment by...Karen -->
<pre>JID 14929</pre>


<!-- Date: Mon Mar 31 21:26:53 2003 -->
<pre>Finished making HC 19 entries for 15 runs processed on CAF last week (jid 14929.)  The files for the last 2 runs in this series (160407-160408) were not accessible when the job was run, and the histograms are empty.   
 
HC 17 entries now exist for all but 6/81 of the runs from Production.  The runs still missing HC 17 are 
 
160351, 160359, 160403, 160404, 160407, 160408.   
 
The other 22 runs that had failed to be processed "magically" worked this time (w/no change to the scripts or any other measures taken.)   Not sure why this happened, but the situation clearly needs further investigation...</pre>
<!-- Author: Karen -->


<!-- Date: Tue Apr 1 16:55:56 2003 -->
<pre>I moved the scripts fitbeamjob and fitbeamjob_refit from 
Alignment to  Beamline. I added some more info output to the 
scripts. These changes are committed to Beamline CVS. 
 
In the current working directory of cdfopr I also removed 
the scripts from Alignment. From now on only the version in 
Beamline should be used. 
 
I'll ask Hartmut to remove the 2 scripts from the Alignment 
package.  
 
There are more scripts which could/should be moved to Beamline. 
On todays meeting we agreed that we will discuss this issue 
next week. For the two files I was working on today I wanted 
to finish that work to be in a clear state. </pre>
<!-- Author: Wolfgang -->


<!-- Date: Tue Apr 8 14:19:44 2003 -->
<pre>Submitted JID 17050 to CAF for refit; 6 runs 
 
160407 
160408 
160410 
160412 
160414 
160437 
</pre>
<!-- Author: Karen -->
<!-- Comment: Wed Apr  9 12;21;44 comment by...Karen -->
<pre>First 2 runs finished successfully after ~2 hours, but the last 4 have been languishing for nearly a day.  Killed JID 17050 and re-submitted the last four runs (JID: 17302.)</pre>


<!-- Date: Wed Apr 9 12:30:37 2003 -->
<pre>Fit 160407, 160408 and made DB entries for HC19.  Still no luck w/HC17 for these runs or the other 4 runs w/o HC17 entries: 
 
160351 
160359 
160403 
160404 
160407 
160408 
 
Checked the Production farm status and it looks like some of the streams are still processing some of these runs (e.g. 160404 on Stream_C), but it looks like some of the older runs are being (re?)processed on some of the streams (e.g. 160175 is being processed on Stream_H, although we have a HC17 entry for that run, which suggests that the run must have been processed through all the streams once.)</pre>
<!-- Author: Karen -->


<!-- Date: Wed Apr 16 11:48:42 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-1&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-1  width='300' align='top'></td><td>Beam wander, 156460</a></td></tr></table>
<!-- Author: Karen & Sal -->


<!-- Date: Wed Apr 16 11:52:33 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-2&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-2  width='300' align='top'></td><td>Beam wander, 155919</a></td></tr></table>
<!-- Author: Karen & Sal -->


<!-- Date: Fri Apr 18 18:04:27 2003 -->
<pre>On April 11th, we successfully copied HC 17 to HC 19 (COT beam) for runs 158644-159199.  Today we also copied 17 to 19 for 159202-160350. </pre>
<!-- Author: Karen & Joao -->


<!-- Date: Fri Apr 18 18:15:04 2003 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-3&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-3' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-5&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-5' width='300'></a></center>
<!-- Author: Karen & Joao -->
<!-- Comment: Fri Apr 18 18;17;22 comment by...Karen & Joao -->
<pre>HC 17 - HC 19 SVX & COT beam respectively.  Note that HC 17 COT beam has been successfully copied to HC 19 COT beam.</pre>
<!-- Date: Fri Apr 18 18:15:55 2003 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-6&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-6' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-7&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-7' width='300'></a></center>
<!-- Author: Karen & Joao -->
<!-- Comment: Fri Apr 18 18;20;34 comment by...Karen & Joao -->
<pre>COT - SVX beam for HC 19.  We see -20 um diff for x0 and -45 um for y0.</pre>


<!-- Date: Thu Apr 24 21:55:02 2003 -->
<pre>Made new release based on 4.9.1hpt3 for beamline operation. 
/cdf/opr/cdfopr/beamlines/4.9.1hpt3_beam 
 
This was made using: 
VertexAlg, VertexMods and TrackingUserMods tagged with v4_9_1_beam 
Alignment from history_19 plus: 
 test/FillMissingCOTEntry.cc -r 1.8 
 test/FillMissingSvxEntry.cc -r 1.9 
 test/GNUMakefile -r 1.21 
 test/RunStatus -r 1.2 
 
Alignment/scripts/updateBeamlinePass.sh -r 1.4 
                  MakeUsedValidSet -r 1.9 
                  fitbeamjob  -r 1.19 
                  mergefiles  -r 1.10 
 
Beamline package from the head 
Copied scripts used in Beamline package from the previous  
4.9.1hpt2_beam directory 
</pre>
<!-- Author: Joao -->
<!-- Comment: Fri Apr 25 16;59;34 comment by...Joao -->
<pre>Added the following to this release:
Alignment/test/SvxBeamFillDB.cc -r 1.7
               SvxBeamReadDB.cc -r 1.9
               UsedSetVersion.cc -r 1.4

Added line in GNUmakefile
override LOADLIBES += -lFramework
after 
include PackageList/link_all.mk

In the Alignment/scripts directory added:
checkForMissingEntries - r 1.2
copyBeamlinePass.sh -r 1.1
updateBeamlinePass.sh -r 1.5

</pre>
<!-- Comment: Fri Apr 25 17;01;01 comment by...Joao -->
<pre>These modifications were mostly from the head.
Not included from the head is FitBeam.cc which reduces the number of Silicon vertices from 1000 to 300 for a good fit.</pre>
<!-- Comment: Thu May  8 14;26;15 comment by...Joao -->
<pre>THESE RELEASE IS THE ONE TO BE USED WITH updateBeamlinePass.sh

The modifications added here relative to 4.91.hpt2_beam, include:

tbin executables
-----------------

1) Alignment/test/UsedSetVersion.cc -r 1.4
bug fix to pick the used set with the highest version number, was sorted as text before, e.g. so 9 was returned instead of 12; added algorithm parameter

2)Alignment/test/SvxBeamFillDB.cc -r 1.7
upgrade for time dependence

3) Alignment/test/SvxBeamReadDB.cc -r 1.9
upgrade for time dependence

4) Alignment/test/FillMissingCotEntry.cc -r 1.8
   Alignment/test/FillMissingSvxEntry.cc -r 1.9
remake old interpolated entries, fix for algorithm

5)  Alignment/test/RunStatus.cc -r 1.2
new executable to print information about a run that is useful to find missing beam line entries

6) Alignment/test/GNUmakefile -r 1.22


Scripts
-------

1) Alignment/scripts/MakeUsedValidSet -r 1.9
allow two versions of the script to run at the same time

2) Alignment/scripts/checkForMissingEntries -r 1.2
script to find missing beam line entries

3) Alignment/scripts/updateBeamlinePass.sh -r 1.5
always recreate the interpolated entries
added a nowrite option to simulate the valid_set making; give temporary files a unique name

4) Alignment/scripts/mergefiles -r 1.10
give temporary files a unique name to allow different users to run the scripts(in parallel)</pre>
<!-- Date: Thu Apr 24 22:00:36 2003 -->
<pre>Filling Missing Runs and Updating the Beamline Passes 
 
We have used the updateBeamlinePass.sh script to update the beamline passes for some of the runs. 
For SVX: 
updateBeamlinePass.sh 08 onotl_prd 19 156488 158975 nocot write 
 
For COT: 
updateBeamlinePass.sh 07 onotl_prd 19 156488 158975 nosvx write 
 
Log files are: 
SVX: 
updateBeamlinePass_08_svx_030424.log 
updateBeamlinePass_08_svx_030424-2.log 
 
COT: 
updateBeamlinePass_08_cot_030424-2.log</pre>
<!-- Author: Joao -->


<!-- Date: Thu Apr 24 22:16:45 2003 -->
<pre>Filling missing runs and making beamline pass for runs: 158977 - 160406 
 
updateBeamlinePass.sh 08 onotl_prd 19 158977 160406 nocot write &gt; & updateBeamlinePass_08_cot_030424-3.log 
 
SVX Runs done: 
156487 (January shutdown) to  160406 (2003.03.19) 
 
Runs Missing: 158976  
 
</pre>
<!-- Author: Joao -->


<!-- Date: Thu Apr 24 22:28:17 2003 -->
<pre>Know problems so far:  Run 158976 
 
This is the first run with trigger table PHYSICS_1_04[4,255,357] 
First run of Store 2236. 
 
Silicon was integrated into the run but there were no silicon tracks after production.  
</pre>
<!-- Author: Joao -->
<!-- Comment: Thu Apr 24 22;28;54 comment by...From Karen Gibson -->
<pre>i also looked in the e-log for run 158976 (taken while manfred was sci co)
and they had a lot of problems w/that run.  j.d.lewis said to take the new
trigger table out and run w/the old one b/c trigger rates from XMON were
too high.  they also had a lot of silicon L1 DONE TO's.  they ran 158977
w/the old trigger table, then switched back to the new one for 158978 and
everything went just swimmingly.  i checked the log file for 158976 and it
processed 11,774 events successfully; it just didn't find any SVX tracks.
there's clearly something else going on w/that one.  (technically it's not
in the "runs w/silicon good" list anyway.)</pre>


<!-- Date: Fri Apr 25 11:38:27 2003 -->
<pre>I made HC17 entries for the 6 runs missing HC17 beamlines: 160351, 160359, 160403, 160404, 160407, & 160408.  </pre>
<!-- Author: Karen -->
<!-- Comment: Fri Apr 25 12;06;09 comment by...Karen -->
<pre>Next need to copy HC17 COT beamline onto HC19 COT beamline for runs 160351-160408. </pre>




<!-- Date: Fri Apr 25 17:05:50 2003 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-8&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-8' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-9&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-9' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-10&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-10' width='300'></a></center>
<!-- Author: Karen -->
<!-- Comment: Fri Apr 25 17;14;00 comment by...Karen -->
<pre>Copied COT beam from HC17 onto HC19 for runs 160351-160408.  Checked results w/BeamDatabase exe and everything looks okay.  

COT x0 ~20um below SVX
    y0 ~50um   "    "

COT HC17-HC19 = 0 for all runs

SVX x0 HC17 ~14um above HC19  
    y0   "  ~20um below   "</pre>
<!-- Date: Fri Apr 25 17:10:05 2003 -->
<pre>Yesterday, I managed to screw up PAD_PHYSICS_COTBEAM by adding 
some runs with the wrong UsedSet. The problem was that we had not 
made the UsedSets after copying HC17 into HC19. We should have run 
MakeUsedValidSet after RepairBeamlines.cc. 
 
</pre>
<!-- Author: Joao -->
<!-- Comment: Fri Apr 25 17;11;26 comment by...Joao -->
<pre>EMAIL FROM HARTMUT:
-------------------

Hi Joao,
a recovering is not possible.
What needs to be done, is to create a new PAD_PHYSICS_COTBEAM pass 07 table using the 
PassTool. The next step is to copy the good entries from the retired table into the new 
one, see copyBeamlinePass.sh. Afterwards one can remake the entries that were bad.
 

On Fri, Apr 25, 2003 at 09:41:46AM -0500, Joao Guimaraes da Costa wrote:

&gt;&gt; Hi Hartmut,
&gt;&gt; 
&gt;&gt; How can I recover from a pass that was made with the wrong UsedSets?
&gt;&gt; 
&gt;&gt; Yesterday, when we used updateBeamlinePass.sh for the COT we realized 
&gt;&gt; that we possibly had made a mistake.
&gt;&gt; 
&gt;&gt; When we copied COT entries from HC17 to HC19 using Ray's script we did 
&gt;&gt; not made new UsedSets (we thought it was included). So, when running the 
&gt;&gt; updateBeamlinePass.sh we picked up the wrong UsedSets.

You should check to see if really the wrong used set were used.
When no HC19 used set exists for a run, the updateBeamlinePass.sh script will
create one. BeamDatabase -usedset -dbid onotl_prd &lt;runnumber&gt; should show the beam line of 
the latest used set. UsedSetVersion onotl_prd &lt;runnumber&gt; PAD_PHYSICS_COTBEAM 999 should list
all used sets for that run. 
 Sometimes I have modified the updateBeamlinePass.sh to force creating a new used set before doing anything,
but usually this is not necessary.
To force it, you have to add at line number 119 in the latest version of updateBeamlinePass.sh:
Alignment/scripts/MakeUsedValidSet ${RUNNUMBER} ${DBID} ${HISTORY} cot
to create a new used set for the COT beam line.
 </pre>


<!-- Comment: Fri Apr 25 17;14;34 comment by...Joao -->
<pre>Hartmut is correct. The used set was made for the runs missing a HC19 and therefore it picked up the correct HC17 entries. However,
the bad used set was picked up for runs which already had a HC19 used set.
We do need to remake the pass.</pre>


<!-- Date: Fri Apr 25 17:16:16 2003 -->
<pre>Made a passlist for pass 07 for PAD_PHYSICS_COTBEAM: 
 
~cdfsoft/dist/releases/development/CalibDB/bin/PassTool.pl -c /@cdfonprd -p PAD_PHYSICS_COTBEAM -n 07 -w 
 
48     	 
 
success:index=49 process_name=PAD_PHYSICS_COTBEAM stream=A passname=07 
</pre>
<!-- Author: Joao -->


<!-- Date: Fri Apr 25 18:58:26 2003 -->
<pre>The first run with PAD_PHYSICS seems to be: 133896 
 
Got that by running: 
 ${CDFSOFT2_DIR}/CalibDB/bin/PassCalibTool.pl -c cdf_reader/reader@cdfofprd -i 07 -d -f /tmp/pass_input$$.txt &gt; /dev/nul</pre>
<!-- Author: Joao -->
<!-- Comment: Fri Apr 25 21;19;23 comment by...Joao -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>This is WRONG.
The number to use with -i is the pass_index=49 not the pass_name = 07

The pass_index number can be obtain from:
PassTool.pl -c cdf_reader/reader@cdfofprd -l</pre></td></tr></td></table>


<!-- Date: Fri Apr 25 21:22:18 2003 -->
<pre>The correct first run number to use is: 122621. We got it using: 
 
PassCalibTool.pl -c cdf_reader/reader@cdfofprd -i 49 -d -f 
dbcontent.txt 
 
For last run we want the last run that has a beamline before the shutdown: 156487 
 
Now we are ready to run Hartmut's script.</pre>
<!-- Author: Joao -->
<!-- Comment: Wed May  7 14;54;51 comment by...Karen -->
<pre>Think this is a mistake; the correct command would be 

PassCalibTool.pl -c cdf_reader/reader@cdfofprd -i 41 -d -f 
dbcontent.txt</pre>
<!-- Date: Fri Apr 25 22:01:16 2003 -->
<pre>Copied the COT database entries from the previous PAD_PHYSICS_COTBEAM pass_index=41 to the new PAD_PHYSICS_COTBEAM pass_index=49 until run 157294. This is the run just before the 
first run with data after the shutdown which was  
 
copyBeamlinePass.sh 49 41 122621 157294 
copyPassList: copying entries for runs from 122621 to 157294 from pass_index 41 to the table with pass index 49. 
</pre>
<!-- Author: Joao -->
<!-- Comment: Fri Apr 25 22;03;34 comment by...Joao -->
<pre>This seems to have been successfull. Got message like these for all runs:

successfully executed: insert into passcalibs(pass_index,lorun,hirun,proc_calib_version) 
 values(49,157292,157292,1)
successfully executed: insert into passcalibs(pass_index,lorun,hirun,proc_calib_version) 
 values(49,157293,157293,1)
successfully executed: insert into passcalibs(pass_index,lorun,hirun,proc_calib_version) 
 values(49,157294,157294,1)
copyPassList: copying done.


List with input/output were left on disk for now:
pass_output26669.txt and pass_input26669.txt
In: /cdf/opr/cdfopr/beamlines/4.9.1hpt3_beam/Alignment/scripts</pre>


<!-- Date: Fri Apr 25 22:18:16 2003 -->
<pre>Filling the version map in the database for COT: 
 
Alignment/scripts/updateBeamlinePass.sh 07 onotl_prd 19 157295 160408 nosvx nowrite &gt; updateBeamlinePass_07_cot_030425.log 
 
Starting on the first run that was not copied from the previous pass and finishing in 160408, the last run for which we have HC17.</pre>
<!-- Author: Joao -->
<!-- Comment: Sat Apr 26 20;03;09 comment by...Joao -->
<pre>UsedSets were made within updateBeamlinePass for all HC17 runs 
that had been copied into HC19.

Runs without a HC17/HC19 beamline from algorithm 20 (vertices)
where interpolated if possible. Otherwise, null entries were made. 

We used the option "nowrite" so these runs were not added to the PAD_PHYSICS_COTBEAM pass 07 yet.</pre>


<!-- Date: Sat Apr 26 20:15:46 2003 -->
<pre>Modified updateBeamlinePass slightly to have it output to the log 
file the pass list and the run numbers with PROD_PHYSICS_CDF that 
will be used in the script. 
 
FOR NOW, I HAVE ALSO COMMENTED OUT THE LINES TO MAKE THE USED SETS, 
THESE ARE LINES 125 (FOR COT) AND 138 (FOR SVX). 
 
THESE LINES ARE USEFUL TO FORCE NEW USEDSETS TO BE MADE BUT NOT NECESSARY 
IF THEY ARE ALREADY THERE.  
 
THE MOST COMMON USE FOR THIS NOW IS TO MAKE USEDSETS FOR THE ENTRIES 
COPIED FROM HISTORY CODE 17.</pre>
<!-- Author: Joao -->


<!-- Date: Sat Apr 26 20:21:55 2003 -->
<pre>ADDING THE NEWLY CREATED USED SETS TO THE PASS -- PAD_PHYSICS_COTBEAM 07: 
 
Unfortunately, we have to re-run the updateBeamlinePass.sh but 
now using the the "write" option. This will again make used sets for the interpolated entries! 
 
Alignment/scripts/updateBeamlinePass.sh 07 onotl_prd 19 157295 160408 nosvx write &gt; updateBeamlinePass_07_cot_030426.log &</pre>
<!-- Author: Joao -->
<!-- Comment: Sat Apr 26 21;30;27 comment by...Joao -->
<pre>Check the log file and couldn't find any problems.
It seems that we succeed creating PAD_PHYSICS_COTBEAM pass 07 up
to run 160408.</pre>


<!-- Date: Sat Apr 26 21:31:40 2003 -->
<pre>ADDING TO PAD_PHYSICS_SVXBEAM pass 08 THE RUNS 160407 AND 160408. 
 
Alignment/scripts/updateBeamlinePass.sh 08 onotl_prd 19 160407 160408 nocot nowrite &gt; updateBeamlinePass_08_svx_030426.log &</pre>
<!-- Author: Joao -->
<!-- Comment: Sat Apr 26 21;33;36 comment by...Joao -->
<pre>Actually writing to the DB:

Alignment/scripts/updateBeamlinePass.sh 08 onotl_prd 19 160407 160408 nocot write &gt; updateBeamlinePass_08_svx_030426.log &</pre>


<!-- Date: Sun Apr 27 05:01:38 2003 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>I wrote a new script to check the beamline DB entries. 
The script compares the UsetSet version corresponding to a  
specific history code with the versions in the pass calib table for a specific pass name. 
It also checks that all runs within the defined range which have a PROD_PHYSICS_CDF entry  
have an associated used set and the corresponding PAD_PHYSICS_*BEAM 
 
Usage: 
For help run, 
Alignment/scripts/checkBeamlinePass.sh 
Normal use, 
Alignment/scripts/checkBeamlinePass.sh 156487 160408 19 cot 07 & 
The parameters are the run range (first and last run to be checked), history code, cot/svx and  
pass number of the specific detector (currently pass 07 for cot; pass 08 for svx). 
A log file name is generated automatically from the parameters. However, an alternative name  
can be given as the last parameter.  
</pre></td></tr></td></table>
<!-- Author: Joao -->


<!-- Date: Sun Apr 27 05:11:15 2003 -->
<pre>PAD_PHYSICS_COTBEAM pass 07 and PAD_PHYSICS_SVXBEAM pass 08 
have been completed up to run 160408 (March 19, 2003) with the 
 exception of run 158976 which is missing silicon tracks. 
 
The final check is being performed. If successful, we will request 
 PAD_PHYSICS_CDF to be made for this set of run.</pre>
<!-- Author: Joao -->


<!-- Date: Tue Apr 29 13:37:01 2003 -->
<pre>I made HC 17 entries for runs 160438-161044.  According to the list of physics runs compiled by Lester, 3 runs are missing entries (160797, 160798, &161032), though I looked thru all 7 streams in 4.8.4a_09 and I didn't find any sign of these runs in any of the streams.  Declare endeavor successful? 
 
Lester has made entries for HC 19 thru run 160796, so the next step is to copy HC 17 COT onto HC 19 COT.  I'll RepairBeamlines up to 160796, then we (Joao & I) can take a stab at adding these new runs to the pass.    </pre>
<!-- Author: Karen -->


<!-- Date: Tue Apr 29 13:58:38 2003 -->
<pre>Tried running RepairBeamlines (in 4.9.1hpt2_beam): 
 
RepairBeamlines 1 160410 160796 | & tee repairBeamlines_042903.log 
 
but when I checked runs w/BeamDatabase, it looks like they haven't been successfully copied over.  COT x0 differs by 60um, y0 by ~100um... 
</pre>
<!-- Author: Karen -->
<!-- Comment: Tue Apr 29 14;02;00 comment by...Karen -->
<pre>Also get messages from root macro like:

Found Cot 19 and not 17   160412
Found Cot 19 and not 17   160592
Found Cot 19 and not 17   160596
Found Cot 19 and not 17   160598
Found Cot 19 and not 17   160600
Found Cot 19 and not 17   160601
Found Cot 19 and not 17   160602

all of which supposedly have COT entries from the hc17_042803.log log file.  </pre>


<!-- Date: Tue Apr 29 16:48:07 2003 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-14&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-14' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-13&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-13' width='300'></a></center>
<!-- Author: Karen -->
<!-- Comment: Tue Apr 29 16;50;41 comment by...Karen -->
<pre>SVX & COT beamline entries HC17-HC19.  After waiting a bit, the COT entries look just fine (i.e. HC17 was successfully copied to HC19 for COT.)</pre>
<!-- Date: Tue Apr 29 16:49:04 2003 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-11&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-11' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-12&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-12' width='300'></a></center>
<!-- Author: Karen -->
<!-- Comment: Tue Apr 29 17;43;11 comment by...Karen -->
<pre>See one run w/large x0 & y0 diff bet. SVX + COT beamline.  Investigate further. </pre>


<!-- Comment: Wed Apr 30 14;59;31 comment by...Karen -->
<pre>Yesterday I looked at DB contents for contentious run, which is run 160541.  Interestingly, run 160540 (which didn't have SVX and henceforth doesn't appear on the COT-SVX plot) had a COT y0 that was 40 um off from the previous ave COT y0 for nearby runs. Pertinent(?) stats:

160541:
SVX:    x0 up ~6um from ave
        y0 up ~30um 

COT:    x0 up ~25um from ave
	y0 ~0um 

160540:
COT:    y0 up ~40um from ave

Seemed like something funny going on here, so I checked DB for HC19 & HC17 entries... nothing especially unusual or anything.    </pre>
<!-- Date: Wed Apr 30 14:44:09 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-15&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-15  width='300' align='top'></td><td>SVT beamline for run 160534-160541... 160541 ran on March 24 from 8:51-15:50.</a></td></tr></table>
<!-- Author: Karen -->
<!-- Comment: Wed Apr 30 14;48;03 comment by...Karen -->
<pre>SVT beam exhibited very strange behavior during run 160541 (and before, particularly in y0.)  This store also had a number of problems w/high losses and other assorted TeV issues.  Perhaps this is related to our strange deviation of Svx & Cot beam for this run?  Perhaps not.  Next look at FitBeamModule root files for these runs.   </pre>



<!-- Comment: Wed Apr 30 17;44;41 comment by...Karen -->
<pre>Joao & I checked the SVX time-dep. of 160541 in the DB and we do *not* see the ~90um change in SVT beam offline!?! </pre>
<!-- Date: Wed Apr 30 17:42:41 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-16&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=beamline&action=view&page=-16  width='300' align='top'></td><td>SVT beamline for run 148824,  which ran from 16:52 7/23/02- 07:20 7/24/02.  Lose info after 00:00 7/24, but see diff of ~70um in y,  which is also seen in offline time-dep.beamline  </a></td></tr></table>
<!-- Author: Karen -->