From 1a9473f2e6ffeff838b340e8790bcb75ee58d0a3 Mon Sep 17 00:00:00 2001
From: koennecke <koennecke>
Date: Wed, 16 Aug 2006 14:13:38 +0000
Subject: [PATCH] - Updatex optimise documentation

---
 doc/user/optimise.htm | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/doc/user/optimise.htm b/doc/user/optimise.htm
index c8a2e881..4e97d439 100644
--- a/doc/user/optimise.htm
+++ b/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>
@@ -75,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>