we now (in theory, not tested yet) support

the CactusEinstein/StaticConformal conformal metric

also add more discussion of C++ code portability
(stil needs updating for Peters experiences compiling on various machines)


git-svn-id: http://svn.einsteintoolkit.org/cactus/EinsteinAnalysis/AHFinderDirect/trunk@788 f88db872-0e4f-0410-b76b-b9085cfa78c5

2 files changed, 32 insertions, 13 deletions

diff --git a/doc/TODO b/doc/TODO
index 08ab187..16b8704 100644
--- a/doc/TODO
+++ b/doc/TODO
@@ -1,9 +1,9 @@
 small things
   set centroid variables for drift correction
   ??larger max_Newton_iterations for initial data than for time evolution??
+  do we work properly with fisheye?
 
 medium things
-  support CactusEinstein conformal_state et al
   HDF5 data files
   move origin point
   export a "compute h(theta,phi)" function
diff --git a/doc/documentation.tex b/doc/documentation.tex
index f87906e..0774358 100644
--- a/doc/documentation.tex
+++ b/doc/documentation.tex
@@ -165,10 +165,9 @@ solving~\eqref{AEIDevelopment_AHFinderDirect_eqn-horizon}.  It requires
 as input the usual Cactus 3-metric $g_\ij$ and extrinsic curvature
 $K_\ij$,%%%
 \footnote{%%%
-	 At present \thorn{AHFinderDirect} doesn't
-	 support the \arrangement{CactusEinstein}
-	 {\tt conformal\_state} system, but this
-	 should change soon.
+	 And the conformal factor $\psi$ if the
+	 \thorn{StaticConformal} metric semantics
+	 are used.
 	 }%%%
 {} and produces as output the Cactus $(x,y,z)$ coordinates of a large
 number of points on the apparent horizon, together with some auxiliary
@@ -255,17 +254,37 @@ arrangement.
 
 This thorn is written primarily in \Cplusplus{}, calling C and
 Fortran~77 numerical libraries.  The code should be fairly portable to
-modern \Cplusplus{} compilers.  Templates are used, but only rather
-simple ones for containers or other low-level stuff templated on
-the floating-point or integer datatype, and these templates are always
-instantiated explicitly.  \code{bool}, \code{mutable}, and \code{typename}
-are used, but (at the cost of a slight obfuscation) the code has been
-written to be agnostic with regard to modern versus archaic
-\code{for}-loop declaration scope rules.
+modern \Cplusplus{} compilers.  As to specific \Cplusplus{} features\dots
+\begin{itemize}
+\item	Templates are used, but only rather simple ones for containers
+	or other low-level stuff templated on the floating-point or
+	integer datatype, and these templates are always instantiated
+	explicitly.
+\item	\code{bool}, \code{mutable}, and \code{typename}]
+	are used.
+\item	The code will work ok under either the archaic or the modern
+	\code{for}-loop declaration scope rules.
+\item	C header files are used in the pre-namespaces form
+	\begin{verbatim}
+	#include <stdio.h>
+	int main()
+	{
+	printf("hello, world\n");
+	return 0;
+	}
+	\end{verbatim}
+	This is deprecated in standard \Cplusplus{}, but alas
+	none of the more modern forms using the \code{std::} namespace
+	seem to be supported on as wide a range of systems as the
+	pre-namespaces forms.
+\item	\code{vector} is the only part of the C++ standard template library
+	(STL) used, and for the same reasons as above, it's used in the
+	pre-namespaces \verb|<vector.h>| form.
+\end{itemize}
 
 The code has been compiled and run successfully using
 \begin{itemize}
-\item	various {\bf gcc} versions (2.95.2 and later) versions
+\item	various {\bf gcc} versions (2.95.2, 2.95.3, and 3.2) versions
 	on x86 GNU/Linux and *BSD
 \item	Intel C++ compiler for GNU/Linux, version 5.0
 \end{itemize}