Privacy and Security Notice

SOS start time

Changes to and checks of the optics code 06/15/05

The major changes to the optics code were:
  1. The beam offsets were stored in a single file analyze/bpm.txt, which was read by pkumacs/set_sos_xs_ys_cuts.kumac and source_code/fit_init.f, and also analyze/ytar_raw.kumac (see later).
  2. The ytarg optimization stopped after reading 100 events rather than 100 events per hole.  This was changed by adding "scut" entries in db_files/sos_target_yopt.db (it is now identical to sos_target_angopt.db).
  3. Additions were made in source_code/chisq.f to write out the "model" variable directly after the svd fit.  This was useful to check the convergence of the fitting routine without problems associated with matching the optics code with the Analyzer.  The kumac analyze/ytar_raw.kumac was used to plot the results and apply the beam offsets.
  4. The results from ytar_raw showed improvement, but the results using the new matrix element file in the Analyzer were very poor.  I later determined this to be a bug I had inserted into s_targ_trans.f with all of the checking performed.  However, I wrote new code to write out the matrix element file directly after the fitting in source_code/chisq.f because this seemed less prone to mapping errors.  In addition source_code/fit.inc and source_code/func_fill.f were modified.  These changes may also have helped to fix the problems I was experiencing when performing optimizations in 2004.
  5. Mark was very helpful with the checks and modifications in #4, and he wrote a tcl script optkumacs/make_vary_kumac_file.tcl that will set only non-zero matrix elements to vary, which helped with the mapping issues.
  6. The fast raster was written out to the sievesos ntuple by modifying STRACKING/s_targ_trans.f.  This was not expected to change the results because delta was not being fit.

Many checks were performed:
  1. In particular, the mapping from the output of the optics code was checked with what the Analyzer reads in.  An entire matrix expansion for a singe event was checked, and there was no mismatch in position or units.
  2. ytar_raw.kumac was used to check the convergence of the svd fit (described above).

Optics code checks and correction 06/08/05
 There was another possible chance of a m->cm conversion problem in map_fp_ofp.f at the line:
 
	ofp1.x  = fp1.x/100. + fp1.xp * fp_ofp.z.value
It was also strange that fp_ofp.z.value was always zero.  However, fp1.xp comes straight from the sieve ntuple and is in cm, while ofp1.x is used in the optimization and needs to be in m.  So the conversion is correct.  Mark said that the "fp_ofp.z.value should be zero.  This was used at the very beginning of SOS optimization when they were not sure about where the focal plane was.  Now the tracks xfp and yfp are at z=0.  In the dbase position files the chambers position have been modified."

However, there was an error in the optics db file for ytar optimization.  Here is a copy of an email I sent to Mark.

The other problem occurred in ssytar optimization.  The db file sos_target_yopt.db does not contain the "scut" files.  Because there aren't any lines with "scut", the variable "found_cutsieve_file" is set to false in "target_assign.f".  Then in fit_init.f there are the lines:

nh_found = 1
if (found_cutsieve_file .and. inside) then
  pass_sieve = .false.
  xsieve=event(8)*zcol     ! event(8) =xptar
  ysieve=event(9)*zcol+event(7) ! event(9) =yptar
  do nh=1,nholes
   if (xsieve .lt. xshcut(k,nh) .and. xsieve .gt. xslcut(k,nh)
>  .and. ysieve .lt. yshcut(k,nh) .and. ysieve .gt. yslcut(k,nh)) then
      pass_sieve = .true.
      nh_found=nh
    endif
  enddo
endif
if (inside .and. ncount(k) .le. ntuple_evt(k)
> .and. pass_sieve .and. ntotal .lt. 100000
> .and. event(11) .gt. 0.5 .and. nh_count(k,nh_found) .lt. 100 ) then


You can see that nh_found is set to 1 (ie, the default hole that the particle passed though is hole number 1).  The "if" statement following is always false if there are no "scut" files.  The last "if" statement checks that there are no more than 100 events per sieve hole.  Because they all are labeled as coming from hole #1, only 100 events are used in the optimization.

I added the scut files at the end of sos_target_yopt.db, and now it is identical to sos_target_angopt.db.  I checked that found_cutsieve_file was not used anywhere else that would affect the ssytar optimization, and it looked ok.

Optics problems 05/03/05 (revised 05/04/05)

As can be seen in the optics optimization link, the optics optimization seems to fail.


I tried to find out how well the optics programs converged by plotting what the program thinks are the new ytar points directly after the fitting (ie using the new matrix elements).  This is shown in the plot with ytar before fitting in the top and ytar after in the second. 

There are a couple of things to notice:

(1) The data that is being fit does not look clean at low ytar.  This is because all of the foils are plotted together.

(2) The after (bottom) plot is an improvement on before (top).  Therefore, there must be an error in formatting the output of the matrix elements.



This is a link to chisq.f that produced the data for the plots.

After replaying the data with the 900 matrix and the new 1200 matrix, the reconstructed ytar looks like this (red indicates the foil position):
(old) 900 Matrix
 (new) 1200 matrix