PSI update

r1464 | ffr | 2007-02-12 12:20:21 +1100 (Mon, 12 Feb 2007) | 2 lines

doc/user/optimise.htm

@@ -29,6 +29,18 @@ maximum number of cycles was reached. This routine requires that the
 instrument is currently placed somewhere on the peak and not miles away.
 </P>
 <p>
+The peak optimiser supports another optimisation algorithm which is faster but 
+may not be as accurate. This is hill climbing:
+<pre>
+while errors gt precision and cycles lt maxcycles
+  for all variables 
+	  find the direction into which the intensity rises
+	  step into this direction until the intensity drops
+   end for
+end while
+</pre>
+</p>
+<p>
 The Peak Optimiser is implemented as an object with the name opti. It
 understand the following commands:
 <DL>
@@ -43,7 +55,10 @@ and number of steps parameters should cover the whole peak. However, the
 Optimiser will extend the scan is the specified range is not sufficient.
 <DT>opti run
 <DD>Starts the optimiser. It will then optimise the peak. This may take some
-time. 
+time as it uses a time consuming scan based algorithm.
+<DT>opti climb
+<DD>Starts the optimiser in hill climbing mode. Hill climbing is faster but may 
+ not be as accurate as a scan based optimization.
 </DL> 
 The behaviour of the optimiser can be configured by modifying some
 parameters. The synatx is easy: <b>opti parameter</b> prints the value of the
@@ -72,5 +87,12 @@ status of the countmode  parameter this is either a preset time or a preset
 monitor.
 </DL>
 </p>
+<p>
+It is the users reponsability to provide meaningful step widths. Usually this is 
+dependent on the instrument resolution and thus fairly constant. Also these 
+optimisation algorithms will fail if the instrument is not positioned at the 
+flank of a peak. Probaly the best will be to do several cycles of hill 
+climbing first, followed by one cycle of scan optimisation for extra accuracy.   
+</p>
 </BODY>
 </HTML>