<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!--Converted with LaTeX2HTML 2002-2-1 (1.71)
original version by: Nikos Drakos, CBLU, University of Leeds
* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
* with significant contributions from:
Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
<HTML>
<HEAD>
<TITLE>UserManual</TITLE>
<META NAME="description" CONTENT="UserManual">
<META NAME="keywords" CONTENT="UserManual">
<META NAME="resource-type" CONTENT="document">
<META NAME="distribution" CONTENT="global">
<META NAME="Generator" CONTENT="LaTeX2HTML v2002-2-1">
<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
<LINK REL="STYLESHEET" HREF="UserManual.css">
</HEAD>
<BODY <BODY text="#000000" bgcolor="#ffffff">>
<P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<P>
<DIV ALIGN="CENTER">
</DIV>
<P>
<DIV ALIGN="CENTER"><BIG CLASS="HUGE"><B>Nightfall User Manual</B>
</BIG></DIV>
<P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<P>
<DIV ALIGN="CENTER">
<BIG CLASS="LARGE"><B> by R. Wichmann
<BR> (rwichman@lsw.uni-heidelberg.de)
</B>
</BIG></DIV>
<P>
<P>
<BR>
<H2><A NAME="SECTION00010000000000000000">
Contents</A>
</H2>
<!--Table of Contents-->
<UL CLASS="TofC">
<LI><A NAME="tex2html68"
HREF="UserManual.html#SECTION00020000000000000000">1 Introduction</A>
<UL>
<LI><A NAME="tex2html69"
HREF="UserManual.html#SECTION00021000000000000000">1.1 Remarks</A>
<LI><A NAME="tex2html70"
HREF="UserManual.html#SECTION00022000000000000000">1.2 Bugs</A>
<LI><A NAME="tex2html71"
HREF="UserManual.html#SECTION00023000000000000000">1.3 Copyright</A>
</UL><BR>
<LI><A NAME="tex2html72"
HREF="UserManual.html#SECTION00030000000000000000">2 Requirements and Installation</A>
<UL>
<LI><A NAME="tex2html73"
HREF="UserManual.html#SECTION00031000000000000000">2.1 Requirements</A>
<LI><A NAME="tex2html74"
HREF="UserManual.html#SECTION00032000000000000000">2.2 Installation</A>
<LI><A NAME="tex2html75"
HREF="UserManual.html#SECTION00033000000000000000">2.3 Compile/configure problems</A>
<LI><A NAME="tex2html76"
HREF="UserManual.html#SECTION00034000000000000000">2.4 Compile-time configuration</A>
</UL><BR>
<LI><A NAME="tex2html77"
HREF="UserManual.html#SECTION00040000000000000000">3 Usage</A>
<UL>
<LI><A NAME="tex2html78"
HREF="UserManual.html#SECTION00041000000000000000">3.1 General</A>
<LI><A NAME="tex2html79"
HREF="UserManual.html#SECTION00042000000000000000">3.2 Plotting, Graphics</A>
<LI><A NAME="tex2html80"
HREF="UserManual.html#SECTION00043000000000000000">3.3 Interactive usage - the graphical user interface (GUI)</A>
<LI><A NAME="tex2html81"
HREF="UserManual.html#SECTION00044000000000000000">3.4 OpenGL</A>
<LI><A NAME="tex2html82"
HREF="UserManual.html#SECTION00045000000000000000">3.5 MPI</A>
<LI><A NAME="tex2html83"
HREF="UserManual.html#SECTION00046000000000000000">3.6 Problems</A>
<LI><A NAME="tex2html84"
HREF="UserManual.html#SECTION00047000000000000000">3.7 Configuration File</A>
<LI><A NAME="tex2html85"
HREF="UserManual.html#SECTION00048000000000000000">3.8 Data files</A>
<LI><A NAME="tex2html86"
HREF="UserManual.html#SECTION00049000000000000000">3.9 Environment variables</A>
</UL><BR>
<LI><A NAME="tex2html87"
HREF="UserManual.html#SECTION00050000000000000000">4 Introduction to Binary Stars</A>
<UL>
<LI><A NAME="tex2html88"
HREF="UserManual.html#SECTION00051000000000000000">4.1 The Roche Geometry</A>
<LI><A NAME="tex2html89"
HREF="UserManual.html#SECTION00052000000000000000">4.2 Shape of the lightcurve</A>
<LI><A NAME="tex2html90"
HREF="UserManual.html#SECTION00053000000000000000">4.3 Suggested experiments</A>
</UL><BR>
<LI><A NAME="tex2html91"
HREF="UserManual.html#SECTION00060000000000000000">5 More details</A>
<UL>
<LI><A NAME="tex2html92"
HREF="UserManual.html#SECTION00061000000000000000">5.1 Which star is which ?</A>
<LI><A NAME="tex2html93"
HREF="UserManual.html#SECTION00062000000000000000">5.2 How is eclipse testing done ?</A>
<LI><A NAME="tex2html94"
HREF="UserManual.html#SECTION00063000000000000000">5.3 Temperature and Brightness</A>
<LI><A NAME="tex2html95"
HREF="UserManual.html#SECTION00064000000000000000">5.4 Output Lightcurves</A>
<LI><A NAME="tex2html96"
HREF="UserManual.html#SECTION00065000000000000000">5.5 Gravity Brightening</A>
</UL><BR>
<LI><A NAME="tex2html97"
HREF="UserManual.html#SECTION00070000000000000000">6 Disk</A>
<UL>
<LI><A NAME="tex2html98"
HREF="UserManual.html#SECTION00071000000000000000">6.1 Disk model</A>
<LI><A NAME="tex2html99"
HREF="UserManual.html#SECTION00072000000000000000">6.2 Disk parameters</A>
<LI><A NAME="tex2html100"
HREF="UserManual.html#SECTION00073000000000000000">6.3 Hot spot parameters</A>
</UL><BR>
<LI><A NAME="tex2html101"
HREF="UserManual.html#SECTION00080000000000000000">7 Advanced Options</A>
<UL>
<LI><A NAME="tex2html102"
HREF="UserManual.html#SECTION00081000000000000000">7.1 Fractional Visibility</A>
<LI><A NAME="tex2html103"
HREF="UserManual.html#SECTION00082000000000000000">7.2 Reflection</A>
<LI><A NAME="tex2html104"
HREF="UserManual.html#SECTION00083000000000000000">7.3 Overcontact systems</A>
<LI><A NAME="tex2html105"
HREF="UserManual.html#SECTION00084000000000000000">7.4 Asynchroneous Rotation</A>
<LI><A NAME="tex2html106"
HREF="UserManual.html#SECTION00085000000000000000">7.5 Eccentric Orbit</A>
<LI><A NAME="tex2html107"
HREF="UserManual.html#SECTION00086000000000000000">7.6 Limb Darkening</A>
<LI><A NAME="tex2html108"
HREF="UserManual.html#SECTION00087000000000000000">7.7 Surface Spots</A>
<LI><A NAME="tex2html109"
HREF="UserManual.html#SECTION00088000000000000000">7.8 Radial Velocities</A>
<LI><A NAME="tex2html110"
HREF="UserManual.html#SECTION00089000000000000000">7.9 Line profiles</A>
<LI><A NAME="tex2html111"
HREF="UserManual.html#SECTION000810000000000000000">7.10 Third Light</A>
</UL><BR>
<LI><A NAME="tex2html112"
HREF="UserManual.html#SECTION00090000000000000000">8 Fitting observed data</A>
<UL>
<LI><A NAME="tex2html113"
HREF="UserManual.html#SECTION00091000000000000000">8.1 Reading in the data</A>
<LI><A NAME="tex2html114"
HREF="UserManual.html#SECTION00092000000000000000">8.2 Finding a local optimum</A>
<LI><A NAME="tex2html115"
HREF="UserManual.html#SECTION00093000000000000000">8.3 Goodness-of-fit</A>
<LI><A NAME="tex2html116"
HREF="UserManual.html#SECTION00094000000000000000">8.4 Finding a global optimum</A>
<LI><A NAME="tex2html117"
HREF="UserManual.html#SECTION00095000000000000000">8.5 Mapping the Chi-Square function</A>
</UL><BR>
<LI><A NAME="tex2html118"
HREF="UserManual.html#SECTION000100000000000000000">9 Miscellaneous</A>
<UL>
<LI><A NAME="tex2html119"
HREF="UserManual.html#SECTION000101000000000000000">9.1 Debug options</A>
<LI><A NAME="tex2html120"
HREF="UserManual.html#SECTION000102000000000000000">9.2 Output of the surface map</A>
<LI><A NAME="tex2html121"
HREF="UserManual.html#SECTION000103000000000000000">9.3 User-defined wavelenghts</A>
</UL><BR>
<LI><A NAME="tex2html122"
HREF="UserManual.html#SECTION000110000000000000000">10 Technical details</A>
<UL>
<LI><A NAME="tex2html123"
HREF="UserManual.html#SECTION000111000000000000000">10.1 Geometry</A>
<LI><A NAME="tex2html124"
HREF="UserManual.html#SECTION000112000000000000000">10.2 Reflection and gravity darkening/brightening</A>
<LI><A NAME="tex2html125"
HREF="UserManual.html#SECTION000113000000000000000">10.3 Spots</A>
<LI><A NAME="tex2html126"
HREF="UserManual.html#SECTION000114000000000000000">10.4 Output flux</A>
<LI><A NAME="tex2html127"
HREF="UserManual.html#SECTION000115000000000000000">10.5 Eclipse testing</A>
<LI><A NAME="tex2html128"
HREF="UserManual.html#SECTION000116000000000000000">10.6 Fractional visibility</A>
<LI><A NAME="tex2html129"
HREF="UserManual.html#SECTION000117000000000000000">10.7 Eccentric orbits</A>
<LI><A NAME="tex2html130"
HREF="UserManual.html#SECTION000118000000000000000">10.8 Optimization</A>
</UL><BR>
<LI><A NAME="tex2html131"
HREF="UserManual.html#SECTION000120000000000000000">Bibliography</A>
<LI><A NAME="tex2html132"
HREF="UserManual.html#SECTION000130000000000000000">11 Command line Options</A>
</UL>
<!--End of Table of Contents-->
<P>
<HR>
<P>
<H1><A NAME="SECTION00020000000000000000">
<SPAN CLASS="arabic">1</SPAN> Introduction</A>
</H1>
<P>
<SMALL>NIGHTFALL</SMALL> is an interactive application that introduces into
the fascinating realm of eclipsing binary stars. Apart from their light
variations that make them interesting objects for observations,
eclipsing binaries are of fundamental importance for astrophysics, e.g.
for measuring the mass of stars.
<SMALL>NIGHTFALL</SMALL> is capable of producing:
<P>
<UL>
<LI>animated views of eclipsing binary
stars,
</LI>
<LI>lightcurves and radial
velocity curves,
</LI>
<LI>best-fit binary star parameters for a given set of observational data.
</LI>
</UL>
It is, however, not able to fry your breakfast
egg on your harddisk.
<BR>
<P>
Eclipsing binary stars are most often very close systems. In such systems,
owing to tidal forces, the shapes of both stars can be highly nonspherical,
up to the possible formation of an 'overcontact' system, where both stars
form a single, dumbbell-shaped object.
<BR>
<P>
<SMALL>NIGHTFALL</SMALL> is a mildly ultramundane program of baroque complexity
(I like Verdi and Händel on lazy sunday mornings - friday evenings are
better with Iron Maiden and a good whisky).
<SMALL>NIGHTFALL</SMALL> is based on a physical model that
takes into account the nonspherical
shape of stars in close binary systems, as well as mutual irradiance
of both stars, and a number of additional physical effects.
<BR>
<P>
<SMALL>NIGHTFALL</SMALL> can handle a large range of configurations, including
overcontact systems,
eccentric (non-circular) orbits,
surface spots and asynchroneous rotations (stars rotating
slower or faster than the orbital period), and the possible presence of a
third star in the system.
<BR>
<P>
<SMALL>NIGHTFALL</SMALL> supports OpenGL (or MesaGL) for an animated display of
binary systems. Individual frames of the animation can be saved as JPEGs
to create am MPEG movie.
<BR>
<P>
<SMALL>NIGHTFALL</SMALL> can be build in a parallelized version, if you have
an implementation of MPI (i.e. an MPI library) installed.
<BR>
<P>
<SMALL>NIGHTFALL</SMALL> supports the GNOME desktop (if installed), but does
<I>not</I> require it.
<BR>Also, <SMALL>NIGHTFALL</SMALL> supports <I>internationalization</I>. Currently,
besides the default language (english), only german is supported. The
language is selected by the environment variable LANG (must be set
before starting the program,
in sh, bash: <TT>LANG=de; export LANG</TT>
<BR>in csh, tcsh: <TT>setenv LANG de</TT>).
<P>
<H2><A NAME="SECTION00021000000000000000">
<SPAN CLASS="arabic">1</SPAN>.<SPAN CLASS="arabic">1</SPAN> Remarks</A>
</H2>
<P>
<SMALL>NIGHTFALL</SMALL> is not part of my
research work - rather it is the result of a recreational activity aimed
at distracting myself
from daily research work.
<BR>
<P>
I have tested <SMALL>NIGHTFALL</SMALL> with published data on several binary stars.
Data for these systems are included in the source code
distribution. As no two light curve programs use exactly the same
algorithms, results are never identical; however, results from
<SMALL>NIGHTFALL</SMALL> appear to be within the range of similar
light curve programs used in the literature. I hope
that I have found most flaws in the logic of the code, at least in the
'scientific' part. If you want to use
<SMALL>NIGHTFALL</SMALL> for a publication, you may want to evaluate its
performance by yourself.
<SMALL>NIGHTFALL</SMALL> comes WITHOUT ANY WARRANTY
(see also
<A HREF="#copyright">the copyright statement</A>
for more information).
<P>
<H2><A NAME="SECTION00022000000000000000">
<SPAN CLASS="arabic">1</SPAN>.<SPAN CLASS="arabic">2</SPAN> Bugs</A>
</H2>
<P>
Several, probably.
If you find a bug and can eliminate it, send me a diff. If you find a bug
and can't cope with it, send me a report, and wait for the next version.
If you would like a feature, tell me.
<P>
<H2><A NAME="SECTION00023000000000000000">
<SPAN CLASS="arabic">1</SPAN>.<SPAN CLASS="arabic">3</SPAN> Copyright</A>
</H2>
<P>
<SMALL>NIGHTFALL</SMALL> is copyright (c) 1998-2002 Rainer Wichmann, (c) 2001-2002
Markus Kuster, (c) 2001-2002 Patrick Risse
<A NAME="copyright"></A>
<BR>
<P>
<SMALL>NIGHTFALL</SMALL> is free software; you can redistribute it
and/or modify
it under the terms of the GNU General Public License as
published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
<BR>
<P>
<SMALL>NIGHTFALL</SMALL> is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
<BR>
<P>
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
<P>
This document is considered part of the <SMALL>NIGHTFALL</SMALL> program.
<P>
<HR>
<P>
<H1><A NAME="SECTION00030000000000000000">
<SPAN CLASS="arabic">2</SPAN> Requirements and Installation</A>
</H1>
<P>
<H2><A NAME="SECTION00031000000000000000">
<SPAN CLASS="arabic">2</SPAN>.<SPAN CLASS="arabic">1</SPAN> Requirements</A>
</H2>
<P>
<SMALL>NIGHTFALL</SMALL> has been developed with the aim of being able
to compile and run the program on a typical Linux system without
any need of downloading/installing additional libraries or programs.
Although I have not tested this, <SMALL>NIGHTFALL</SMALL> should compile
on other Unix systems as well.
<BR>
<P>
For command line use/file output, all you need is a C compiler (e.g. gcc).
For interactive use and plotting, <SMALL>NIGHTFALL</SMALL> requires additional
libraries/programs, which, however, should already be included in
your Linux distribution (most probably). All required libraries/programs
are available for a wide variety of Unix systems.
<BR>
<P>
<UL>
<LI><B>For interactive use</B> of <SMALL>NIGHTFALL</SMALL>, a GUI is provided,
which is based
on the GTK library (available at http://www.gtk.org, GNU Library General
Public License). GTK should compile on most Unix systems.
If you have a recent Linux distribution, GTK should
already be included (Debian: libgtk1.2, libgtk1.2-dev).
To see whether GTK is installed, try to run
<P>
$ gtk-config -libs
<P>
which should yield something like: '-L/usr/lib -L/usr/X11R6/lib -lgtk
-lgdk -lglib -lXext -lX11 -lm' (might be different for your system).
If you get a message like 'sh: gtk-config: not found', you might
need to install GTK. (On SuSE Linux - and maybe other distributions -,
GTK is split in two packages.
For running GTK applications, you need only the 'gtk' package. For compiling
applications (like <SMALL>NIGHTFALL</SMALL>), you also need the 'gtkdev' package.
Debian package names: libgtk1.2, libgtk1.2-dev)
<P>
</LI>
<LI><B>For plots and graphs</B>, <SMALL>NIGHTFALL</SMALL> requires either
<P>
<UL>
<LI>GNUPLOT, version 3.5 (pre 3.6) patchlevel beta 347, or higher
(Debian: gnuplot).
Earlier versions may or may not work. You need a version with 'multiplot'
support. To verify this, try:
<P>
$ gnuplot
<BR> gnuplot$ set multiplot
<P>
If you get an error message, you have to update your GNUPLOT.
<BR> You also need write permission to the directory '/tmp' on your system.
To test this, try:
<P>
$ touch /tmp/foo
<P>
</LI>
<LI>or the PGPLOT Fortran graphics subroutine library
(Debian: pgplot5, also available at:
<P>
http://astro.caltech.edu/ tjp/pgplot
<P>
free for non-commercial use). You need a Fortran compiler
(g77 is fine) to compile it. You have to compile it with
the Xserver and postscript drivers, and also have to compile
the C wrapper library that comes with PGPLOT.
<P>
</LI>
</UL>
<P>
</LI>
<LI><B>For OpenGL support</B>, <SMALL>NIGHTFALL</SMALL> requires
<P>
<UL>
<LI>O<SMALL>PEN</SMALL>GL or M<SMALL>ESA</SMALL>GL (Debian: xlibmesa3, xlibmesa3-dev),
<P>
</LI>
<LI>GLUT, the OpenGL Utility Toolkit
(Debian: glutg3, glutg3-dev),
<P>
</LI>
<LI><SMALL>GTKGLAREA</SMALL> (Debian: gtkglarea5, gtkglarea5-dev), and
<P>
</LI>
<LI><SMALL>LIBJPEG</SMALL> (Debian: libjpeg62, libjpeg62-dev).
<P>
</LI>
</UL>
<P>
</LI>
<LI>For building a <B>parallelized version</B>, <SMALL>NIGHTFALL</SMALL> requires
a MPI (Message Passing Interface) library. If your vendor does
not supply one, you may consider the MPICH library, which is freely
available from http://www-unix.mcs.anl.gov/mpi/mpich/. With
MPICH, you can easily run a parallelized version of <SMALL>NIGHTFALL</SMALL>
e.g. on a cluster of networked PCs (Debian: mpich).
<BR>
<P>
MPI parallelization has been tested with the MPICH library on a
Linux PC cluster. The MPICH library has been compiled using the
flags <I>./configure -with-device=ch_p4 -rsh=ssh</I>.
<P>
</LI>
<LI>If you have installed the Gnome Desktop on your system, <SMALL>NIGHTFALL</SMALL>
will build with support for it. However, Gnome is <I>not</I> required
for <SMALL>NIGHTFALL</SMALL> - it compiles just as well without Gnome.
<P>
</LI>
</UL>
<P>
<B>Note</B>: With GNUPLOT, plots are not that nice sometimes, but
animated mode runs much smoother with GNUPLOT than with PGPLOT.
GNUPLOT does not support
incremental plotting and display of images, thus a few options are
only available with PGPLOT.
<P>
<P>
<H2><A NAME="SECTION00032000000000000000">
<SPAN CLASS="arabic">2</SPAN>.<SPAN CLASS="arabic">2</SPAN> Installation</A>
</H2>
<P>
After downloading the source code, do:
<BR>
<P>
$ gunzip -c nightfall-<I>(version number)</I>.tar.gz <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img1.png"
ALT="$\vert$"></SPAN> tar -xvf -
<BR>$ cd nightfall-<I>(version number)</I>
<BR>$ ./DoInstall.sh
<BR>
<P>
The 'DoInstall.sh' script will query you for some information (e.g. where
to install the program),
and then (optionally) build, test, and install the application.
If you want to do it by hand, instead of './DoInstall.sh' run the following
sequence of commands:
<BR>
<P>
$ ./configure
<BR>$ make
<BR>$ make install
<BR>
<P>
If you want to use PGPLOT, 'configure' might find it by itself;
otherwise
you might need the 'configure' option
<BR>'-with-pgplot-include=PFX' (where PFX should be the directory where
the PGPLOT header file cpgplot.h is installed), and
'-with-pgplot-lib=PFX' (where PFX should be the directory where the
PGPLOT library files libpgplot.a, libcpgplot.a are installed).
<BR>
<P>
If you want to build a <B>parallelized version</B>, you need
the 'configure' option '-enable-mpi', <B>and</B> you need to
set the compiler flags to
indicate the location of include and library files, if these are not
in the default search path. There are two ways to do this:
<BR>
<P>
(a) The MPICH library provides a C compiler
wrapper 'mpicc' that will automatically set the correct flags, so
if mpicc is in your PATH, you may just say (for compiling with
PGPLOT, you need also the Fortran77 compiler wrapper 'mpif77'):
<BR>$ ./configure -enable-mpi CC=mpicc F77=mpif77
<BR>or
<BR>$ ./configure -with-gnuplot -enable-mpi CC=mpicc
<BR>
<P>
(b) If this fails (e.g. because ./configure may not find the correct
preprocessor), you have to specify the correct flags:
<BR>$ mpicc -show
<BR>cc -DUSE_STDARG -L/usr/local/lib -lmpich
<BR>$ ./configure -enable-mpi CC=cc CFLAGS='' -DUSE_STDARG'' LIBS=''-L/usr/local/lib -lmpich''
<BR>
<P>
<H3><A NAME="SECTION00032100000000000000">
<SPAN CLASS="arabic">2</SPAN>.<SPAN CLASS="arabic">2</SPAN>.<SPAN CLASS="arabic">1</SPAN> Install locations</A>
</H3>
<P>
By default, the binary is installed to /usr/local/bin, the
data/help/configuration files to
<BR>/usr/local/share/nightfall. If you don't
like this, use the 'configure' option
'-prefix=/where/to/install', where '/where/to/install' will
replace '/usr/local'.
<P>
<H2><A NAME="SECTION00033000000000000000">
<SPAN CLASS="arabic">2</SPAN>.<SPAN CLASS="arabic">3</SPAN> Compile/configure problems</A>
</H2>
<P>
If you want to use a different compiler, you can supply the
option CC=myCCompiler to <TT>configure</TT> (and also F77=myFortranCompiler,
if you compile with PGPLOT).
<P>
<UL>
<LI>Have gnuplot, but configure does not find it
<P>
<UL>
<LI>is gnuplot in your path ?
if no, update your PATH environment variable
<P>
</LI>
<LI>does it support 'set multiplot' ?
( start interactively by typing 'gnuplot',
then type 'set multiplot' to test)
if no, update your gnuplot
<P>
</LI>
<LI>does 'gnuplot_x11 -persist' work, or does it
give an error message like:
gnuplot: bad option: -persist ?
if error, update your gnuplot
<P>
</LI>
<LI>There was at least one gnuplot version that
supports the required 'multiplot' option, but does not
list it as supported.
In this case, enforce gnuplot support with:
<BR> <TT>./configure -with-gnuplot</TT>
</LI>
</UL>
<P>
</LI>
<LI>Have gnuplot and pgplot, want gnuplot support
<P>
<UL>
<LI>use:
<BR> <TT>./configure -with-gnuplot</TT>
</LI>
</UL>
<P>
</LI>
<LI>Have pgplot, but configure does not find it
<P>
<UL>
<LI>do you have a fortran compiler (required) ?
<P>
</LI>
<LI>the following files are required:
cpgplot.h, libcpgplot.a, libpgplot.a
<BR> Use <TT>./configure -with-pgplot-include=/my/pgplot/include/dir
-with-pgplot-lib=/my/pgplot/lib/dir</TT>,
<BR> where '/my/pgplot/include/dir' is the directory where
cpgplot.h is located, and '/my/pgplot/lib/dir' is the directory
where libcpgplot.a, libpgplot.a are located.
</LI>
</UL>
<P>
</LI>
<LI>Have pgplot, get compile error
<P>
<UL>
<LI>maybe your fortran compiler does not understand the
link options required by Gtk.
upgrade to a recent version of g77.
<P>
</LI>
<LI>maybe pgplot was compiled with a different fortran compiler.
Recompile it with the fortran compiler found by configure, or
convince configure to use a different compiler (use the
configure option F77=myFortranCompiler and/or CC=myCCompiler).
</LI>
</UL>
<P>
</LI>
<LI>Other compile errors
<P>
<UL>
<LI>There might be problems related to internationalization,
that may be caused by a broken installation of a respective
utility on your system.
For solving this, you should choose one of the
following switches for the 'configure' script:
<BR> <TT>-disable-nls</TT>
<BR> <TT>-with-included-gettext</TT>
<BR> like, e.g.: <TT>./configure -with-included-gettext</TT>
<BR> The first switch will completely disable internationalization,
i.e. only the english version will be available.
The second switch will use the internationalization
program that is included in this source code distribution,
thus bypassing any preinstalled, maybe broken, utility on
your system.
</LI>
</UL>
<P>
</LI>
</UL>
<P>
<H2><A NAME="SECTION00034000000000000000">
<SPAN CLASS="arabic">2</SPAN>.<SPAN CLASS="arabic">4</SPAN> Compile-time configuration</A>
</H2>
<P>
Several aspects/limits of <SMALL>NIGHTFALL</SMALL> can be configured at
compile time. Mostly, these are related to fixed array sizes.
For most users, the defaults should be sufficient.
<P>
To configure, edit the file 'Light.h' and change the default value(s) of
the '#define ITEM' statement(s) in the first section of this file
(where 'ITEM' stands for any of the bold words on the list below).
Configuration options include (but are not limited to):
<UL>
<LI>NIGHTFALL_PLOTFILE - the name of the output plot file
(default is 'Nightfall.ps').
<P>
</LI>
<LI>STEPS_PER_PI, MAXELEMENTS - the number of surface elements
for stars. This number cannot be set
exactly, as the algorithm determines it at run time, trying to
achieve a more or less constant area per surface element (for the
lightcurve computation, of course the exact surface area is taken
into account). You can, however, set the number of steps per
one Pi (= 180 degree) on the equator, which is
STEPS_PER_PI.
You also have to adjust
the size of the array holding the surface, which is
MAXELEMENTS.
<P>
</LI>
<LI>MAXOBS - the maximum number of observational data per filter
<P>
</LI>
<LI>PHASESTEPS - the maximum number of steps for a full orbit
<P>
</LI>
<LI>N_SPOT - the maximum number of spots per star
<P>
</LI>
<LI>GNU_GEOMETRY - the plot window geometry, if you use GNUPLOT
as plotting program
<BR> Please note: it is not possible to fully
specify the PGPLOT plot window
geometry from within the program.
It can be defined (in pixels) by:
<BR> X resource: pgxwin.Win.geometry: WIDTHxHEIGHT+X+Y
<BR> or environment variable: PGPLOT_XW_WIDTH
[fractional display width].
<BR> PGPLOTS's default is width=867, height=669 and aspect=8.5/11.
<BR> If PGPLOT_XW_WIDTH is undefined, <SMALL>NIGHTFALL</SMALL> will set
it to scale down the window width to the GNU_GEOMETRY width.
<BR> Set PGPLOT_XW_WIDTH to 1.0, if you don't like this
<BR> (bash, ksh: 'PGPLOT_XW_WIDTH=1.0; export PGPLOT_XW_WIDTH'
<BR> csh, tcsh: 'setenv PGPLOT_XW_WIDTH 1.0').
<P>
</LI>
<LI>OUT_FILE, OUT_SIMPLEX - the names of output files for the
lightcurve (OUT_FILE)
and eventual fit results (OUT_SIMPLEX).
<P>
</LI>
<LI>PROFILE_ARRAY, PROFILE_RES - the size of the array for
line profile computation
(PROFILE_ARRAY) and the default resolution
(PROFILE_RES).
<P>
</LI>
</UL>
<P>
<HR>
<P>
<H1><A NAME="SECTION00040000000000000000">
<SPAN CLASS="arabic">3</SPAN> Usage</A>
</H1>
<P>
<H2><A NAME="SECTION00041000000000000000">
<SPAN CLASS="arabic">3</SPAN>.<SPAN CLASS="arabic">1</SPAN> General</A>
</H2>
<P>
If used in non-interactive mode, unless a configuration file is
read in at startup
(see
<A HREF="#config">info on configuration files</A>),
<SMALL>NIGHTFALL</SMALL> requires at least the following six numerical arguments on the
command line (in that order):
<P>
<UL>
<LI>(1) the mass ratio of both stars
(mass(Secondary)/mass(Primary), allowed range 0.0001 - 10000.0.
For Roche lobe fill
factors (see below) above one, the mass ratio is restricted to
0.003 - 50.
<P>
</LI>
<LI>(2) orbital inclination ( = viewing angle of orbital plane,
range 0 - 90 degree), where 0 deg corresponds to face-on view (no eclipse
possible), and 90 deg to edge-on view (eclipse guaranteed). For
angles in between, the occurence of an eclipse depends on the mass
ratio and the Roche fill factors (see below).
<P>
</LI>
<LI>(3,4) Roche lobe fill factors. The <I>Roche lobe</I> is the maximum
volume a star can fill in a binary system. Its size is, in general,
different for the two stars, and depends on the mass ratio (see
<A HREF="#roche">details on 'Roche lobe'</A>
for an explanation). The Roche lobe fill factor
is in units of the polar radius of the <I>Roche lobe</I>.
The allowed range is 0.001 - 1.3. For values above 1.0, both stars
merge into a <I>common envelope/overcontact</I> system.
<P>
</LI>
<LI>(5,6) surface temperatures of both stars
(in Kelvin, range 350 - 350000; Kelvin = degree Celsius + 273.15).
Just for comparison, the surface temperature of the sun is 5780 K.
If you use the 'model atmosphere' option, the minimum temperature is
2000K, the maximum temperature is 31000K
(for surface gravity <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img2.png"
ALT="$\log{g} = 3.5$"></SPAN>), 39000K (<SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img3.png"
ALT="$\log{g} = 4.0$"></SPAN>), and
49000K (<!-- MATH
$\log{g} = 4.5, 5.0$
-->
<SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img4.png"
ALT="$\log{g} = 4.5, 5.0$"></SPAN>)
<P>
</LI>
</UL>
<P>
<B>These six numerical arguments are always required, if
<SMALL>NIGHTFALL</SMALL> is used in command-line (i.e. non-interactive) mode
without reading in a configuration file</B> (see below)
<BR>
<P>
$ nightfall -U -C ty_boo.cfg
<BR>
<P>
will read parameters from a configuration file and start <SMALL>NIGHTFALL</SMALL>
in interactive mode. The configuration file is a simple text file
that can be edited by hand. In interactive mode, you can also
write out the current parameters to a configuration file.
<BR>
<P>
$ nightfall (without arguments) will produce a full list of options (many).
<BR>
<P>
<B>By default, <SMALL>NIGHTFALL</SMALL> will do nothing more than
run in non-interactive mode, compute
the lightcurve, write it to an output file 'NightfallCurve.dat',
and exit silently. If you want more (nifty plots, etc.), read on.</B>
<P>
<H2><A NAME="SECTION00042000000000000000">
<SPAN CLASS="arabic">3</SPAN>.<SPAN CLASS="arabic">2</SPAN> Plotting, Graphics</A>
</H2>
<P>
requires that <SMALL>NIGHTFALL</SMALL> has been
compiled with support for PGPLOT or Gnuplot.
<P>
In interactive mode, there are several menu options available to produce plots.
In non-interactive (command-line) mode, you can choose from the following:
<P>
<UL>
<LI>For a real-time animation of the two stars orbiting each other, use
<B>-A</B>
<P>
</LI>
<LI>To select plotting of the output light curve, use <B>-G</B>
<P>
</LI>
<LI>To select the filter for the plottted lightcurve, use <B>-Bfilter</B>
where 'filter'is one of UBVRIJHKuvby (see
<A HREF="#filter">details on filters</A>)
<P>
</LI>
<LI>To visualize the geometry, use <B>-V</B>.
<BR> There are four sub-options (-Va, -Vi, -Vc, -Vv):
<UL>
<LI>-Vc for a contour plot of the potential,
</LI>
<LI>-Vi for an image of the potential,
</LI>
<LI>-Vv for viewing the stars,
</LI>
<LI>-Va for all in one plot.
</LI>
</UL>
The default is 'c'. Only
'c' and 'v' are supported by GNUPLOT
(GNUPLOT cannot display images).
<P>
</LI>
<LI>To obtain a hardcopy, use <B>-H</B>.
</LI>
</UL>
<P>
<I>Detailed output is always written to a file 'NightfallCurve.dat'.</I>
<P>
<H2><A NAME="SECTION00043000000000000000">
<SPAN CLASS="arabic">3</SPAN>.<SPAN CLASS="arabic">3</SPAN> Interactive usage - the graphical user interface (GUI)</A>
</H2>
<P>
Use command line option <B>-U</B> to choose this option.
A GUI will (hopefully) come up.
<BR>
<P>
In the menu bar, there is a <B>File</B> menu for
reading data/configuration files.
Please note that you need to reset the data memory <B>[Reset Memory]</B>
before reading in data for another binary, otherwise you will end up
in a mess ...
<BR>The <B>Output</B> menu allows to choose between several facilities for
viewing the output of a computation and visualizing the binary system.
Some of them allow interactive change of parameters like viewing angle etc.
Please read the online help for more details.
<BR>
<P>
In the toolbar below,
there are buttons for computing a lightcurve <B>[Compute]</B>,
toggling animated view of the binary <B>[Animate]</B> while computing,
writing out the current binary configuration <B>[Write]</B>,
and getting help on the currently active notebook page <B>[Context]</B>.
<BR>
<P>
The rest of the GUI is layed out as a 'notebook' with several
different pages for setting options:
<P>
<UL>
<LI><B>Basic</B> Here you can define the basic configuration of the
binary - mass ratio, inclination, fill-out ratios and temperatures.
I know, reading manuals is not much fun, but you should read at least
<A HREF="#basic">the basic introduction</A>
to know what's going on. Use animated mode
for 'learning by doing'.
<P>
</LI>
<LI><B>Disk</B> For defining the parameters of an optional accretion disk. See
See
<A HREF="#disk">'Disk'.</A>
<P>
</LI>
<LI><B>Advanced</B> For advanced options like asyncroneous rotation,
non-circular orbit, etc. See
<A HREF="#advanced">'Advanced Options'.</A>
<P>
</LI>
<LI><B>Plot Options</B> for the selection of output filter
(see
<A HREF="#filter">details on filters</A>),
and plot window for lightcurve, as well
as options for geometry visualization.
<BR> If compiled with OpenGL support, you can also switch on/off
OpenGL viewing mode here.
<P>
</LI>
<LI><B>Data Fiting</B> Computation of best-fit parameters.
Also: definition of absolute system parameters (for radial velocity).
See
<A HREF="#fitting">details on data fitting.</A>
<P>
</LI>
<LI><B>Spots</B> Here you can interactively define up to two spots per star
(additional spots can be defined on the command line or in a
configuration file). Both spots can be switched on/off independently.
See
<A HREF="#spotted">details on surface spots.</A>
<P>
</LI>
<LI><B>Third Light</B> For definition of the brightness of an (eventual)
third star in the system. Third Light is just added to
the total brightness,
never eclipsed, i.e. it only has an effect on the relative depth
of the eclipses. See
<A HREF="#third">the section on third light.</A>
<P>
</LI>
</UL>
<P>
On the bottom of the GUI, there is a status/progress bar.
<P>
<H2><A NAME="SECTION00044000000000000000">
<SPAN CLASS="arabic">3</SPAN>.<SPAN CLASS="arabic">4</SPAN> OpenGL</A>
</H2>
<P>
<B>Note</B> that OpenGL can lead to program crashes with some graphic cards.
<P>
If compiled with OpenGL support, the animated display will by default
run in OpenGL mode. You can switch to GNUPLOT/PGPLOT mode
in the PlotOptions page in the GUI. In OpenGL
mode, you have the following options:
<P>
<UL>
<LI><B>Zoom</B> by clicking into the display area and drag with the
middle mouse button.
<P>
</LI>
<LI><B>Change viewpoint</B> by clicking into the display area
and drag with the
left mouse button.
<P>
</LI>
<LI><B>Reset</B> with the space bar.
<P>
</LI>
<LI><B>Save animation</B> as JPEG images with File->Save animation
<P>
</LI>
<LI><B>Edit preferences</B> with Edit->Preferences.
<UL>
<LI>You can switch
between wireframe, solid, and points display.
</LI>
<LI>For solid mode, you
can switch on textures, and choose different texture types.
</LI>
<LI>You can switch on/off the display of labels and axes.
</LI>
</UL>
<P>
</LI>
<LI>The following keybindings are available in the OpenGL window:
<BR> <PRE><TT>
right arrow zoom out
<BR>left arrow zoom in
<BR>space reset to real observer viewpoint
<BR>f switch to 'points' display mode
<BR>l switch to 'wireframe' display mode
<BR>o switch to 'opaque' display mode
<BR>t toggle textures on/off
<BR>w cycle through texture type
<BR>(image/temperature/gravity/flux/velocity)
<BR>p toggle primary texture on/off
<BR>s toggle secondary texture on/off
<BR>a toggle axes on/off
<BR>m toggle movie mode on/off
<BR>
</TT></PRE>
<P>
</LI>
</UL>
<P>
With textures enabled, the default is to use a pixmap as texture. All
other textures display the variation of physical quantities
(caused by the non-spherical shape and/or limb darkening)
across the stellar surface. Available choices are: surface temperature,
surface gravity, flux <I>towards the observer</I>, and the velocity of surface
elements <I>towards the observer</I> relative to the star's centre of mass.
<P>
<H2><A NAME="SECTION00045000000000000000">
<SPAN CLASS="arabic">3</SPAN>.<SPAN CLASS="arabic">5</SPAN> MPI</A>
</H2>
<P>
Please read the documentation of your MPI library for details about
how to start a parallel application. The MPICH library (and some
other MPI implementations) provides a command <B>mpirun</B> that
handles everything:
<BR>
<P>
$ mpirun -np <I>number_of_processes</I> nightfall <I>nightfall-options</I>
<BR>
<P>
(Note that for MPICH, you need to enter the machines where the different
processes should run into a <I>machines file</I>. See the MPICH documentation.)
<P>
<H2><A NAME="SECTION00046000000000000000">
<SPAN CLASS="arabic">3</SPAN>.<SPAN CLASS="arabic">6</SPAN> Problems</A>
</H2>
<P>
<UL>
<LI>OpenGL can lead to program crashes with some graphic cards.
<P>
</LI>
<LI>Overcontact systems are not displayed correctly with OpenGL.
<P>
</LI>
<LI>The G<SMALL>NUPLOT</SMALL> PS-driver apparently does not support
the 'multiplot' option.
<P>
</LI>
<LI>For eccentric (non-circular) orbits, very small fill factors
produce strong numerical artifacts in the light curve.
<P>
</LI>
<LI>There seem to be some numerical artifacts also in the line
profiles sometimes, preferentially at quadrature.
<P>
</LI>
</UL>
<P>
<HR>
<P>
<H2><A NAME="SECTION00047000000000000000">
<SPAN CLASS="arabic">3</SPAN>.<SPAN CLASS="arabic">7</SPAN> Configuration File</A>
</H2>
<P>
<SMALL>NIGHTFALL</SMALL> comes with a set of configuration files, each of which
will set the system parameters for a particular (real) binary system,
and automatically load some data files with observed data for
this particular binary star (see next section).<A NAME="config"></A>
<BR>
<P>
For the file format, see the commented example file 'ty_boo.cfg'
in the source code distribution. To read in such a file, on the
command line use:
<BR>
<P>
<B>-C path/to/config/file</B>
<BR>
<P>
If you don't give the full path,
N<SMALL>IGHTFALL</SMALL> will search (in this order of priority) the present working
directory, an eventual subdirectory './cfg', and the default
data directory set at compile time. If the configuration file is in one
of these, only the name, not the full path is required.
<BR>
<P>
<H2><A NAME="SECTION00048000000000000000">
<SPAN CLASS="arabic">3</SPAN>.<SPAN CLASS="arabic">8</SPAN> Data files</A>
</H2>
<P>
<SMALL>NIGHTFALL</SMALL> comes with a set of sample observational data for several
different eclipsing binaries. For each included binary system, the data
comprise lightcurves in several filters, as well as radial velocity curves.
Also, for each of these systems there is a configuration file
(see
<A HREF="#config">details on configuration files</A>).
Loading this configuration file will set the
appropriate parameters for that particular system, and also read in the data.
You can then compute the lightcurve and visualize the binary, with the
observed data overlayed on the lightcurve.
<BR>
<P>
E.g. you might call <SMALL>NIGHTFALL</SMALL>
as 'nightfall -U -C data/ty_boo.cfg', then press 'ANIMATE' to switch
on the real-time animation, and press 'COMPUTE' to compute the
lightcurve. With 'PlotCurve' you can then get a plot of the final lightcurve,
with the data overlayed.
<BR>
<P>
Of course, you can also experiment by yourself and try to fit the
lightcurve by varying the system parameters, or use the automatic
fitting option.
<BR>
<P>
To read in a single data file, use
<BR>
<P>
<B>-I path/to/data/file</B>.
<BR>
<P>
If you don't give the full path,
N<SMALL>IGHTFALL</SMALL> will search (in this order) the present working
directory, an eventual subdirectory './data', and the default
data directory set at compile time. If the data file is in one
of these, only the name, not the full path is required.
For details on the format of the files, see
<A HREF="#dataread">here.</A>
<P>
Data are available for the following systems:
<P>
<UL>
<LI><B>TY Boo:</B> a 'common-envelope' ('overcontact') system with two
cool stars. This is a so-called 'shallow' overcontact system, as
the stars are only slightly overfilling their Roche lobes (for the
explanation of the term 'Roche lobe' see
<A HREF="#roche">here.</A>
The two
stars have slightly different temperatures.
<P>
</LI>
<LI><B>MR Cyg:</B> a semi-detached system (the cooler fills its Roche lobe)
with two stars of very different temperature (but both much hotter
than the Sun). Lightcurve should be
computed with some advanved options: model atmosphere fluxes,
detailed reflection (2-3 iterations), quadratic limb darkening.
<P>
</LI>
<LI><B>DD Mon:</B> another semi-detached system (the cooler star fills its
Roche lobe). The cooler star is slightly cooler than the Sun, the other one
slightly hotter than the Sun. The total mass is very low - both stars
together have only about 0.6 solar masses. It seems difficult to
fit the lightcurve without spots (did not try as yet).
<P>
</LI>
<LI><B>BH Vir:</B> a detached system with two stars, one slightly hotter,
the other slightly cooler than the Sun. At least one of the stars
has surface spots, which cause a slight, but noticeable distotion
of the lightcurve. The config file includes two spots on the cooler star.
The BV lightcurves and the uvby lightcurves are
from different years. As the stars exhibit some variability, you might want
to use either the BV or the uvby lightcurves,
but not all six simultaneously.
<P>
</LI>
<LI><B>LZ Cen:</B> a detached, but near-contact system with two rather
similar stars, both very hot. The stars are rotating very slightly faster
than synchroneously. Lightcurve should be
computed with some advanved options: model atmosphere fluxes,
detailed reflection (2-3 iterations), quadratic limb darkening.
<P>
</LI>
<LI><B>ER Vul:</B> a detached system of two stars that are both slightly
hotter than the sun, and also have masses only slightly higher than
the sun. The stars show strong and variable activity, i.e.
large starspots that are varying with time. Thus the derived parameters
of the spots can vary a lot from one observation to the next.
<P>
</LI>
<LI><B>V541 Cyg:</B> a well-detached (i.e. wide) binary system with an
eccentric (i.e. non-circular) orbit. As the binary is very wide, the
eclipses are narrow, and it is <B>important</B> to set the number of
steps for the lightcurve to a high value (say, 600, instead of the
default of 80) in order to resolve the eclipses.
<P>
</LI>
<LI><B>51 Peg:</B> an extrasolar planetary system. Only the radial velocity
curve of the primary is known, thus for the planet only the product
<!-- MATH
$m \times \sin(i)$
-->
<SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img5.png"
ALT="$m \times \sin(i)$"></SPAN> is known (0.45 Jupiter masses). Depending on the
unknown inclination angle, the mass may be as high as 15 Jupiter masses,
while higher masses are probably ruled out, because a higher-mass
companion would have synchronized the primary, which is not the case
(the rotation period of 51 Peg is 29-37 days, while the
orbital period of the planet is 4.23 days). The model assumes an inclination
angle of 25 deg, and a density similar to Jupiter's for the planet. The
parameters of the star (mass, radius, temperature) are well known; the
temperature of the planet can be calculated from its distance to the star.
No eclipses (by the planet) have been observed, but the amplitude would be
at the limit of even the most sensitive measurements.
<P>
</LI>
</UL>
<P>
<H2><A NAME="SECTION00049000000000000000">
<SPAN CLASS="arabic">3</SPAN>.<SPAN CLASS="arabic">9</SPAN> Environment variables</A>
</H2>
<P>
The run-time behaviour of the program can be modified by the value of
some <I>environment variables</I>. To set an <I>environment variable</I>
to some value, depending on your shell the following command is required:
<BR>
<P>
in csh, tcsh: <TT>setenv VARIABLE=value</TT>
<BR>
<P>
in sh, bash: <TT>VARIABLE=value; export VARIABLE</TT>
<BR>
<P>
<UL>
<LI><B>HOME</B> your home directory, usually automatically set by your shell
<P>
</LI>
<LI><B>TEMPDIR or TMPDIR</B> location for temporary files
(should not be on NFS mounted filesystem). If these variables are not set,
<SMALL>NIGHTFALL</SMALL> will use /tmp as default.
<P>
</LI>
<LI><B>LANGUAGE or LC_ALL or LC_MESSAGES or LANG</B> (in this order of priority)
will be used to determine your language. The default is English. At the
time of this writing, the only other supported language is German
(LANG=de).
<P>
</LI>
<LI><B>NIGHTFALL_DATAROOT</B> the root directory to search for the data/, cfg/,
and doc/ subdirectories (containing data, config, and help files,
respectively). Only needed if this directory has been moved after
installation.
<P>
</LI>
<LI><B>NIGHTFALL_DATA_DIR</B> the directory where data are located. Only needed
if these have been moved after installation, and <B>NIGHTFALL_DATAROOT</B>
is not set or data are not in <B>$NIGHTFALL_DATAROOT</B>/data.
<P>
</LI>
<LI><B>NIGHTFALL_CFG_DIR</B> for location of config files.
See <B>NIGHTFALL_DATA_DIR</B>.
<P>
</LI>
<LI><B>NIGHTFALL_DOC_DIR</B> for location of help files.
See <B>NIGHTFALL_DATA_DIR</B>.
<P>
</LI>
<LI><B>NIGHTFALL_LOCALE_DIR</B> for location of data for
localization. Only important if you use internationalization to
support your language. See <B>NIGHTFALL_DATA_DIR</B>.
<P>
</LI>
<LI><B>NIGHTFALL_PLOTFILE</B> the name of the output file for plots. Default
is nightfall.ps.
<P>
</LI>
<LI><B>GNUPLOT_GEOMETRY</B> the window size for gnuplot. Default is
550x424+300+20.
<P>
</LI>
<LI><B>PGPLOT_XW_WIDTH</B> fractional display width for PGPLOT X window.
<P>
</LI>
<LI><B>NIGHTFALL_RADIATIVE</B> limiting upper temperature for stars with
convective envelope (default is 7700; unit is Kelvin). Above
that temperature the envelope will be considered radiative. The only
effect this has to to switch the albedo from 0.5 (below) to 1.0 (above).
<P>
</LI>
<LI><B>NIGHTFALL_SMAP_PATH</B> base path to the surface map. To this,
the index for the bandpass and the
current phase will be appended. No surface map
will be output if this environment variable is not set.
<P>
</LI>
<LI><B>NIGHTFALL_SMAP_BAND</B> bandpass (0..11 for UBVRIJHKuvby) for
which surface map is output.
<P>
</LI>
<LI><B>NIGHTFALL_MONO_WAVE</B> a comma-delimited list of up to twelve
monochromatic wavelengths (unit: micrometer)
to replace the effective wavelengths for the
blackbody approximation.
<P>
</LI>
</UL>
<P>
<HR>
<P>
<H1><A NAME="SECTION00050000000000000000">
<SPAN CLASS="arabic">4</SPAN> Introduction to Binary Stars</A>
</H1>
<P>
This section (and the next) provide(s) an introduction
to the problem (at a popular science <A NAME="basic"></A>level, hopefully), the options, and the algorithm(s) used. More technical
aspects are in italics. If you find the less technical part too arcane,
feel free to supply (constructive) suggestions.
<P>
<H2><A NAME="SECTION00051000000000000000">
<SPAN CLASS="arabic">4</SPAN>.<SPAN CLASS="arabic">1</SPAN> The Roche Geometry</A>
</H2>
<P>
Imagine two lakes, seperated by a ridge. There are about three possible
configurations: <A NAME="roche"></A>
<P>
<UL>
<LI>In both lakes, the water level is well below the level of the ridge.
This is a <B>detached system</B>.
<P>
</LI>
<LI>One of the lakes reaches up to the lowest point of the ridge, and water
may spill over to the other lake.
This is a <B>semi-detached system</B>.
<P>
</LI>
<LI>Both lakes overflow the ridge and form one single lake.
This is a <B>contact/overcontact system</B>.
<P>
</LI>
</UL>
<P>
Replace 'water' by 'gas', 'lake' by 'star', and you have the possible
configurations of a close binary star system.
<BR>
<P>
The stellar shapes in such a system are given by the sum of the
gravitational forces, and the centrifugal force due to the orbital motion.
Instead of using the forces, it is easier to use a <B>potential</B> (forces
can then be expressed as the derivative of the potential, if needed).
In the case of binary stars, this potential is called
the <B>Roche potential</B>, named after the French mathematician
Edouard Albert Roche (1820-1883).
The stellar surface is then given by an <B>equipotential surface</B>
(a surface, on which the potential is constant).
Thus, the introduction of the potential makes
the computation of any forces superfluous in this particular application.
<BR>
<P>
The largest size a single star can have in a binary system is given by the
<B>Roche lobe</B> - a teardrop-shaped equipotential surface,
whose cusp touches the cusp of the
Roche lobe of the other star at a point called <B>Lagrange 1 (L1)</B>
(there are four more Lagrange points, which are of less interest here).
L1 is located between both stars, on the line connecting their centres.
At L1, the sum the forces is zero, thus, if a star fills its Roche lobe, at L1
matter can flow into the Roche lobe of the other star (provided it is not
filled as well).
<BR>
<P>
Thus, L1 would correspond to 'lowest point of the ridge' in the two-lake
example above, and the Roche lobes would correspond to the two valleys below
that point, that potentially can be filled by the two lakes. But just as
the two lakes in the example above may be smaller than their
maximum size (before flowing together), also the stars in a binary system
may be smaller than their respective Roche lobes.
A star that completely fills its Roche lobe will assume
its teardrop-like shape. A star filling only a small fraction of its Roche lobe
will be more spherical - distortion increases with the <B>Roche lobe filling
factor</B>.
<BR>
<P>
Note that the <I>relative</I> size of the Roche lobe of the two stars
in the system depends on their mass ratio. The <I>absolute</I> size of the
Roche lobe also scales with the separation of the two stars.
Thus, with a fixed mass ratio and fixed absolute sizes of the stars (e.g.
in kilometers), a star may fill its Roche lobe (and have a highly distorted
figure), if the stars are rather close,
but the same star might fill just a tiny fraction of its Roche lobe
(and thus would be nearly spherical) if the binary separation
would be rather large.
<BR>
<P>
To define the sizes of stars in <SMALL>NIGHTFALL</SMALL>, you have to
give the 'Roche lobe filling factor', which is defined in units of the
Roche lobe (actually, its polar radius).
<SMALL>NIGHTFALL</SMALL> uses a dimensionless potential, i.e. the distance between
both stars is arbitrarily set to unity.
Thus, for a fixed absolute size of the stars, decreasing the
'Roche lobe filling factor' would be equivalent to increasing the
distance.
<P>
<H2><A NAME="SECTION00052000000000000000">
<SPAN CLASS="arabic">4</SPAN>.<SPAN CLASS="arabic">2</SPAN> Shape of the lightcurve</A>
</H2>
<P>
The shape of the lightcurve depends mainly on three factors:
<UL>
<LI>temperatures - as the eclipsed areas are equal for the eclipse of
the Primary and the eclipse of the Secondary, the depths of the
eclipses are only different if the temperatures of both stars
differ. See
<A HREF="#norm">here</A>
for details on temperature and
brightness.
<P>
</LI>
<LI>relative sizes and shapes of the stars, which are determined
by the mass ratio (that determines the relative sizes of both
Roche lobes) and the Roche lobe filling factors
(see
<A HREF="#roche">the info on 'Roche lobe'</A>).
<P>
</LI>
<LI>temperature distribution on the stellar surface. If the Roche lobe
filling factor is large, the star is very nonspherical, and its
temperature can vary significantly over its surface. This effect
is known as gravity brightening (see
<A HREF="#gravbright">details on gravity brightening</A>).
The result is that the lightcurve varies strongly, even if there
is no eclipse.
<P>
</LI>
<LI>mutual irradiation of both stars (see
<A HREF="#reflect">details on reflection treatment</A>).
<P>
</LI>
<LI>cool/hot surface spots (like sunspots, but can be much larger
in some stars, see
<A HREF="#spotted">details on surface spots</A>
<P>
</LI>
</UL>
<P>
<H2><A NAME="SECTION00053000000000000000">
<SPAN CLASS="arabic">4</SPAN>.<SPAN CLASS="arabic">3</SPAN> Suggested experiments</A>
</H2>
<P>
<UL>
<LI>to begin, set the mass ratio to 1.0,
both stars to equal fill factor and
both temperatures to equal values. You will find that
both eclipses have the same depth, as the eclipsed areas
are equal (and have the same limb darkening).
<P>
</LI>
<LI>as soon as one star is hotter than the other, the depth of
the eclipses will become different.
<P>
</LI>
<LI>the width of the eclipses depends on the sizes of the stars
<P>
</LI>
<LI>the 'textbook' case of a flat lightcurve between eclipses
is very rare. The reason is that due to the aspherical shape of
stars in close binary systems, the visible surface area
of the star varies during the orbit. Also, this aspherical shape
causes strong temperature
(= brightness) variations over the surface of the star
an effect called 'gravity brightening' (or 'gravity darkening').
For more details, see
<A HREF="#gravbright">here</A>
You will see that the lightcurve only becomes flat between
eclipses if the Roche lobe fill factors (and thus the
aspherical distortions) of the stars are very small. Which
means that the distance of the two stars is large compared
to their sizes, and
an eclipse con only be observed if the orbital inclination
is very close to 90 degrees - a rather rare case.
<P>
</LI>
<LI>on the other hand, the aspherical shape of the stars
can cause deep throughs in the lightcurve
even if there is no eclipse at all ! To see this,
set the mass ratio to 0.9, the Primary fill factor to 1.0,
the Secondary fill factor to 0.1, and the inclination to
40 degree (just as an example).
In animated mode, you can verify that there is
no eclipse at all, but still you see
deep throughs in the light curve.
<P>
</LI>
<LI>the 'bottom' of an eclipse only becomes (more or less) flat
if the star is eclipsed for a prolonged time, i.e. if it is
significantly smaller than the other, eclipsing star.
<P>
</LI>
<LI>in an eccentric (non-circular) orbit, the velocity of the stars
is not constant. Thus, also the width of both eclipses may be
different, and the times between them as well
(see
<A HREF="#eccentric">details on eccentric orbits</A>
There is a config file
'v541_cyg.cfg' for the binary system V541 Cygni, which
shows both effects.
<P>
</LI>
<LI>the shape of the stars can vary a lot in an eccentric orbit,
because the varying distance is equivalent to a varying Roche
lobe filling factor. To demonstrate this, set the mass ratio
to 1.0, and both Roche lobe filling factors to 1.0. Set
the eccentricity to a large value (say, 0.6), and the orbital
inclination to 0.0, to see what's going on (don't forget to
switch on 'eccentric orbit', if you are in interactive mode).
Use animated mode and enjoy.
<P>
</LI>
</UL>
<P>
<HR>
<P>
<H1><A NAME="SECTION00060000000000000000">
<SPAN CLASS="arabic">5</SPAN> More details</A>
</H1>
<P>
<H2><A NAME="SECTION00061000000000000000">
<SPAN CLASS="arabic">5</SPAN>.<SPAN CLASS="arabic">1</SPAN> Which star is which ?</A>
</H2>
<P>
Stars in binary systems are labelled 'Primary' and 'Secondary'.
In <SMALL>NIGHTFALL</SMALL>, the star called 'Primary' is the star which
is <I>eclipsing</I> first, i.e.
the star that passes <I>in front</I> of the other one at
orbital phase zero (orbital phase indicates the position of the stars
in the orbit on a scale from zero to one). The secondary is the star that
is <I>eclipsed</I> first. In animated view, at start the Primary is left,
the Secondary right. Note that this labelling of 'Primary' and 'Secondary'
is inverse to the usual
convention ... mea culpa. Maybe I fix it sometime.
<BR>
<P>
To exchange the stars (if needed), you can either (i) swap the eclipses
in your data, or (ii) swap the stars themselves.
<BR>For (i), add half an orbital period to the phase zeropoint in your datafile
(for a circular orbit), or the time lag of the second eclipse (for an eccentric
orbit).
<BR>For (ii), swap temperatures and Roche lobe fill factors, and replace the
mass ratio q by 1/q. Don't forget to swap spots, if you have. For an
eccentric orbit, add or subtract 180 deg to/from the Periastron length.
<BR>
<P>
For a circular orbit, <SMALL>NIGHTFALL</SMALL>
starts at orbital phase -0.25 - which is identical to +0.75 -,
and calculates up to +0.75.
In a circular orbit, eclipses are at orbital phase 0.0 and 0.5.).
<BR>
<P>
<SMALL>NIGHTFALL</SMALL> uses a dimensionless potential, i.e. the distance between
both stars is arbitrarily set to unity.
The relative size of both Roche lobes then depends
only on the mass ratio of both stars. The size of both stars has to be
given as a fraction of the Roche lobe (actually, its polar radius).
This fraction might be larger than one, if you want to specify an overcontact
system. To specify a semi-detached system, set the Roche lobe filling fraction
to 1.0 for one star, less for the other.
<BR>
<P>
<H2><A NAME="SECTION00062000000000000000">
<SPAN CLASS="arabic">5</SPAN>.<SPAN CLASS="arabic">2</SPAN> How is eclipse testing done ?</A>
</H2>
<P>
<SMALL>NIGHTFALL</SMALL> divides each stellar surface into a grid of a few thousand
elements. Eclipse testing is done by checking - for each surface element
individually- whether the line of sight towards that surface element
intersects the other star. For overcontact systems, a star might eclipse
its own throat region
(the region connecting both stars). This condition is tested as well.
<P>
Although simple tests based on orbital phase or intersection of sperical
regions suffice in most cases, still sometimes a rigorous and expensive
test is needed.
<BR>
<P>
<H2><A NAME="SECTION00063000000000000000">
<SPAN CLASS="arabic">5</SPAN>.<SPAN CLASS="arabic">3</SPAN> Temperature and Brightness</A>
</H2>
<P>
Stellar <A NAME="norm"></A> surface temperatures can range from a
few 1000 Kelvin to several
10000 Kelvin. The respective brightness can be calculated
from the so-called blackbody law (a blackbody is an idealized thermal
radiation source). The blackbody law is applicable to thermal radiation,
such as infrared radiation of your own body, or radiation by stars; it is
not applicable to non-thermal radiation sources like lasers.
<BR>
<P>
By default, <SMALL>NIGHTFALL</SMALL> uses the blackbody law, which is neither terribly
good nor terribly bad. It is possible to use, instead, light fluxes
from detailed numerical computations of stellar atmospheres. Contrary
to blackbody fluxes, these model atmosphere fluxes (like real stellar fluxes)
depend not only on temperature, but also (mildly)
on surface gravity, and on the chemical composition of the stellar atmosphere.
As actual atmosphere calculations
would be prohibitively expensive, model atmosphere fluxes are taken from
tables that cover only a limited range in temperature (3000 K to 35000 K).
Tables are hardcoded, and only available for one surface gravity value
(a compromise value that should be ok for most cases), and solar
chemical composition.
<BR>
<P>
To switch on model atmosphere fluxes, use
<BR>
<P>
<B>-M</B>
<P>
<H2><A NAME="SECTION00064000000000000000">
<SPAN CLASS="arabic">5</SPAN>.<SPAN CLASS="arabic">4</SPAN> Output Lightcurves</A>
</H2>
<P>
Lightcurves are <A NAME="filter"></A> output in eight commonly
used broad-band filters (UBVRIJHK from
near-UV to near-infrared),
and four narrow-band filters (Stroemgren uvby). The shape of the lightcurve
depends on the filter passband.
<BR>
<P>
The human eye itself also is not equally sensitive to all wavelengths
of light - it also is a kind of 'filter' for light. To create a lightcurve
that looks like the human eye would see it, you have to choose an output
filter that matches as close as possible the sensitivity of the human
eye. For broadband filters, the V filter gives the best match to the human
eye. In the Stroemgren filter system, you might want to choose Stroemgren v.
<BR>
<P>
Lightcurves are output in <B>magnitudes</B>.
This is a relative unit commonly used in astronomy,
and defined as <BR><P></P>
<DIV ALIGN="CENTER" CLASS="mathdisplay">
<!-- MATH
\begin{displaymath}
m_1 - m_2 = -2.5 \times \log{\frac{flux_1}{flux_2}}.
\end{displaymath}
-->
<IMG
BORDER="0" SRC="img6.png"
ALT="\begin{displaymath}m_1 - m_2 = -2.5 \times \log{\frac{flux_1}{flux_2}}. \end{displaymath}">
</DIV><BR CLEAR="ALL">
<P></P>
(For magnitude differences smaller than about 0.4, the difference
in magnitude times 100 is nearly equal to the percentage difference in flux,
i.e. 0.1 mag is about 10 per cent difference.)
The brighter an object, the smaller its magnitude (Sun is -26.7 in the
V filter, while the faintest stars visible by naked eye are about +6).
<SMALL>NIGHTFALL</SMALL> uses the brightness at quadrature (phase -0.25 in a circular
orbit, both stars fully visible) as
normalization (i.e. as <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img7.png"
ALT="$flux_2$"></SPAN> in the equation above).
<BR>
<P>
<B>Output</B> goes to a file 'NightfallCurve.dat'.
To select plotting of output light curve, use
<BR>
<P>
<B>-G</B>
<BR>
<P>
To select the filter for the plotted lightcurve, use
<BR>
<P>
<B>-Bfilter</B>,
<BR>
<P>
where <B>filter</B> should be one of UBVRIJHKuvby. The default for plotting
is the V filter, which is the best match to the human eye. If you read in
data files with observed lightcurves (see
<A HREF="#dataread">here for more info</A>
), the default
will be the filter of the first lightcurve read in.
<P>
To obtain a hardcopy (i.e. PS file), use
<BR>
<P>
<B>-H</B>
<BR>
<P>
<H2><A NAME="SECTION00065000000000000000">
<SPAN CLASS="arabic">5</SPAN>.<SPAN CLASS="arabic">5</SPAN> Gravity Brightening</A>
</H2>
<P>
The nonspherical shape <A NAME="gravbright"></A>
of both stars causes a non-constant surface gravity.
This, in term, causes brightness variations, with regions of higher
surface gravity having higher brightness. This effect is called gravity
brightening or gravity darkening (depending on which article you read).
Gravity brightening can produce deep minima in the lightcurve,
even if there is no eclipse at all !!
<SMALL>NIGHTFALL</SMALL> always takes care of this effect - there is no option to
switch it off.
<BR>
<P>
<HR>
<P>
<H1><A NAME="SECTION00070000000000000000"></A>
<A NAME="disk"></A><BR>
<SPAN CLASS="arabic">6</SPAN> Disk
</H1>
<P>
In a binary system where one star fills its Roche lobe, there may be mass transfer via
Roche lobe overflow. I.e. at the L1 point between the two stars, matter from the
Roche-lobe filling star can flow into the Roche lobe of the other star. For physical
reasons (conservation of angular momentum), this matter will not just fall onto the
other star, but rather form a so-called <B>accretion disk</B>.
<BR>
<P>
Within this disk, the
gas orbits the star and loses angular momentum by friction, thus slowly moving towards
the stellar surface. If the star has a strong magnetic field, this field may disrupt
the disk close to the star. I.e. the disk will not reach all the way to the stellar surface,
but rather there will be a gap between the inner edge and the star, and the gas will take
the last part of its journey along the magnetic field lines.
<BR>
<P>
The disk is characterized by inner and outer radius, temperature, height, and the <B>disk model</B>.
Furthermore, optionally a <B>hot spot</B> may be included in the model.
<BR>
<P>
The outer and inner edge of the disk are modelled as vertical ``walls''.
<P>
<H2><A NAME="SECTION00071000000000000000">
<SPAN CLASS="arabic">6</SPAN>.<SPAN CLASS="arabic">1</SPAN> Disk model</A>
</H2>
<P>
For all models, the height of the disk at radius <B>r</B> is computed as
<BR><P></P>
<DIV ALIGN="CENTER" CLASS="mathdisplay">
<!-- MATH
\begin{displaymath}
a + b * r^c.
\end{displaymath}
-->
<IMG
BORDER="0" SRC="img8.png"
ALT="\begin{displaymath}a + b * r^c. \end{displaymath}">
</DIV><BR CLEAR="ALL">
<P></P>
<P>
<H3><A NAME="SECTION00071100000000000000">
<SPAN CLASS="arabic">6</SPAN>.<SPAN CLASS="arabic">1</SPAN>.<SPAN CLASS="arabic">1</SPAN> Simple disk</A>
</H3>
<P>
For a <B>simple disk</B>, <SPAN CLASS="MATH"><IMG
ALIGN="BOTTOM" BORDER="0" SRC="img9.png"
ALT="$c = 1$"></SPAN>, <SPAN CLASS="MATH"><IMG
ALIGN="BOTTOM" BORDER="0" SRC="img10.png"
ALT="$a$"></SPAN> is set equal to half of the <B>thickness</B> parameter, and
<SPAN CLASS="MATH"><IMG
ALIGN="BOTTOM" BORDER="0" SRC="img11.png"
ALT="$b$"></SPAN> is set equal to the <B>H/R</B> parameter. Setting H/R to zero results in a flat disk.
The <B>temperature</B> is constant and equal to the respective input parameter.
<P>
<H3><A NAME="SECTION00071200000000000000">
<SPAN CLASS="arabic">6</SPAN>.<SPAN CLASS="arabic">1</SPAN>.<SPAN CLASS="arabic">2</SPAN> Isothermal disk</A>
</H3>
<P>
While the <B>simple</B> disk model is isothermal, it's run of the height with radius is not
physically correct for an isothermal disk. In the <B>isothermal disk</B>, the exponent <SPAN CLASS="MATH"><IMG
ALIGN="BOTTOM" BORDER="0" SRC="img12.png"
ALT="$c$"></SPAN>
is set to <SPAN CLASS="MATH"><IMG
ALIGN="BOTTOM" BORDER="0" SRC="img13.png"
ALT="$c = 1.5$"></SPAN>, which is the correct value for an isothermal disk. Furthermore,
the <B>H/R</B> parameter is ignored, the constant <SPAN CLASS="MATH"><IMG
ALIGN="BOTTOM" BORDER="0" SRC="img10.png"
ALT="$a$"></SPAN> is set to <SPAN CLASS="MATH"><IMG
ALIGN="BOTTOM" BORDER="0" SRC="img14.png"
ALT="$a = 0.0$"></SPAN>, and the factor
<SPAN CLASS="MATH"><IMG
ALIGN="BOTTOM" BORDER="0" SRC="img11.png"
ALT="$b$"></SPAN> is chosen such that at the inner disk radius, the disk thickness equals the
<B>thickness</B> input parameter.
<P>
<H3><A NAME="SECTION00071300000000000000">
<SPAN CLASS="arabic">6</SPAN>.<SPAN CLASS="arabic">1</SPAN>.<SPAN CLASS="arabic">3</SPAN> Reprocessing disk</A>
</H3>
<P>
The <B>reprocessing disk</B> is the model for a disk that is reprocessing (absobing/re-radiating) the
radiation from the central star. The exponent <SPAN CLASS="MATH"><IMG
ALIGN="BOTTOM" BORDER="0" SRC="img12.png"
ALT="$c$"></SPAN>
is set to <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img15.png"
ALT="$c = 9/8$"></SPAN>, which is the correct value for a reprocessing disk. Furthermore,
the <B>H/R</B> parameter is ignored, the constant <SPAN CLASS="MATH"><IMG
ALIGN="BOTTOM" BORDER="0" SRC="img10.png"
ALT="$a$"></SPAN> is set to <SPAN CLASS="MATH"><IMG
ALIGN="BOTTOM" BORDER="0" SRC="img14.png"
ALT="$a = 0.0$"></SPAN>, and the factor
<SPAN CLASS="MATH"><IMG
ALIGN="BOTTOM" BORDER="0" SRC="img11.png"
ALT="$b$"></SPAN> is chosen such that at the inner disk radius, the disk thickness equals the
<B>thickness</B> input parameter. Lastly, the <B>temperature</B> falls off with radius
as <!-- MATH
$r^{-frac{3}{4}}$
-->
<SPAN CLASS="MATH"><IMG
ALIGN="BOTTOM" BORDER="0" SRC="img16.png"
ALT="$r^{-frac{3}{4}}$"></SPAN>.
<P>
<H2><A NAME="SECTION00072000000000000000">
<SPAN CLASS="arabic">6</SPAN>.<SPAN CLASS="arabic">2</SPAN> Disk parameters</A>
</H2>
<P>
<UL>
<LI>(1, 2) inner and outer radius,
<P>
</LI>
<LI>(3) thickness at inner edge,
<P>
</LI>
<LI>(4) H/R (height/radius), only used in <B>simple disk</B> model,
<P>
</LI>
<LI>(5) temperature at inner edge, constant throughout the disk for
<B>simple disk</B> model and <B>isothermal disk</B> model.
<P>
</LI>
</UL>
<P>
<H2><A NAME="SECTION00073000000000000000">
<SPAN CLASS="arabic">6</SPAN>.<SPAN CLASS="arabic">3</SPAN> Hot spot parameters</A>
</H2>
<P>
The disk may have a hot spot (where the accretion stream from the donor star
hits the outer edge of the disk). The hot spot is assumed to have constant
temperature and constant depth (as measured from the outer edge of the disk).
<P>
To <B>switch off</B> the hot spot, set the extent in longitude to zero.
<P>
<UL>
<LI>(1) T(hot spot) the temperature of the hot spot (assumed constant),
<P>
</LI>
<LI>(2) Longitude(hot spot) the longitude where the hot spot centre is located
on the disk rim.
<P>
</LI>
<LI>(3) Extent(hot spot) the extent in longitude, and
<P>
</LI>
<LI>(4) Depth(hot spot) the depth, as measured from the outer disk edge, to
which the hot spot extends into the disk.
<P>
</LI>
</UL>
<P>
<H1><A NAME="SECTION00080000000000000000"></A>
<A NAME="advanced"></A><BR>
<SPAN CLASS="arabic">7</SPAN> Advanced Options
</H1>
<P>
<H2><A NAME="SECTION00081000000000000000">
<SPAN CLASS="arabic">7</SPAN>.<SPAN CLASS="arabic">1</SPAN> Fractional Visibility</A>
</H2>
<P>
As eclipse testing is only done for the centres of surface elements,
the coarse surface grid introduces numerical artifacts that are readily
visible sometimes. To fix this problem, it is possible to compute
<B>fractional visibilities</B> for the surface elements (i.e. compute what
fraction of a surface element is eclipsed). To switch on, use
<BR>
<P>
<B>-F</B>
<BR>
<P>
<H2><A NAME="SECTION00082000000000000000">
<SPAN CLASS="arabic">7</SPAN>.<SPAN CLASS="arabic">2</SPAN> Reflection</A>
</H2>
<P>
Due to the mutual <A NAME="reflect"></A>
irradiance of both stars, in addition to its own light,
each star will also reflect light of its companion. This can be a very
important effect, especially if the two stars are close (large Roche fill
factor) or the temperature difference is large.
<SMALL>NIGHTFALL</SMALL> offers two options:
<BR> (1) by default, the irradiating
star is treated as a point source. This is ok for low Roche lobe
filling factors, but not very accurate for stars filling a large fraction of
the Roche lobe. It is rather fast, however.
<BR> (2) it is possible to compute the mutual irradiance of all pairs of surface
elements, with up to nine iterations (usually, two to three are sufficient).
This is an <SPAN CLASS="MATH"><IMG
ALIGN="BOTTOM" BORDER="0" SRC="img17.png"
ALT="$N^2$"></SPAN> algorithm (N the number of surface elements), and thus
computationally very expensive. To switch on, use
<BR>
<P>
<B>-Rn</B>
<BR>
<P>
where 'n' is the number of iterations.
<P>
<H2><A NAME="SECTION00083000000000000000">
<SPAN CLASS="arabic">7</SPAN>.<SPAN CLASS="arabic">3</SPAN> Overcontact systems</A>
</H2>
<P>
For overcontact systems, the second Lagrange point (L2) comes into play.
It is located behind the less massive star (as seen from the more massive),
and has the same property as L1, i.e. the force vanishes there, and matter
might flow out of the common envelope of an overcontact system (I suppose,
by now you know where L3 is. L4 and L5 are in the orbital plane, left and
right of the line connecting the centres of both stars. L3-5 are not
terribly important for binary stars.)
<BR>
<P>
Thus, the surface of the common envelope of an overcontact system has to be
between the two equipotential surfaces given by the potentials of L1 and L2
(remember, the force is the derivative of the potential, thus if the net force
is zero, the potential can still have a non-zero value - it just has to be
'flat' locally).
<BR>
<P>
To have an overcontact system, set the Roche lobe filling factor of one star
larger than 1.0 (as there is only one surface now, the smaller Roche lobe
filling factor will be ignored).
If you choose a too large value, <SMALL>NIGHTFALL</SMALL> will adjust it. (The largest
possible value depends on the mass ratio. Anything
larger than about 1.3 is rather unreasonable for any mass ratio.)
<BR>
<P>
The combination of overcontact and non-circular orbit or
asynchroneous rotation (see below)
is not supported. It would be rather unphysical anyway,
as the strong interaction (tidal forces and friction) would
circularize and synchronize the system
extremely rapidly.
<P>
<H2><A NAME="SECTION00084000000000000000">
<SPAN CLASS="arabic">7</SPAN>.<SPAN CLASS="arabic">4</SPAN> Asynchroneous Rotation</A>
</H2>
<P>
Tidal forces in close binaries will tend to enforce synchroneous rotation
(both stars rotating with the orbital period, thus showing each other
always the same side) on a timescale usually shorter than stellar lifetimes.
<BR>
<P>
There are, however, occasions when stars might rotate asynchroneously, e.g.
young stars that are not yet rotating synchroneously,
or massive stars that have short livetimes anyway, too short for
synchronization to occur during their lifetime. Also, tidal forces
fall off very rapidly with increasing distance, thus wide binaries
are likely candidates for asynchroneous rotation
(the tidal force is inverse proportional to
the cube of the distance - unlike e.g. gravity, which is inverse proportional
to the square of the distance and thus falls off much less rapidly).
<BR>
<P>
A (nonstellar) example for synchronization is the Earth-Moon system,
where Moon's rotation has been synchronized already, while Earth's rotation
is known to slow down gradually. This would eventually lead to Earth's
synchronization as well, but I suspect it might take longer than the lifetime
of our solar system ...
<BR>
<P>
To switch on asynchroneous rotation,
use
<BR>
<P>
<B>-fP fratio</B> or <B>-fS fratio</B>
<BR>
<P>
[-fP for Primary, -fS for Secondary). 'fratio' is the ratio between
stellar rotation period and orbital
period.
<BR>
<P>
Asynchroneous rotation modifies the Roche potential (see
<A HREF="#roche">the info on 'Roche lobe'</A>),
and hence
the equipotential surface which defines the stellar shape. One effect
is a 'flattening' of the star for faster rotation.
Another effect is that the 'critical lobe',
i.e. the largest possible surface, is modified. For faster rotation, it
becomes smaller than the Roche lobe (which is the 'critical lobe' for
a synchroneously rotating star, as discussed
<A HREF="#roche">here</A>).
In this situation, you might have two binary component, both filling
their 'critical lobes', but well separated from each other.
<BR>
<P>
For slower rotation, the 'critical lobe' can become larger than the Roche
lobe... <SMALL>NIGHTFALL</SMALL> will check (and complain), if both stars intersect.
(While an overcontact system with synchroneous rotation is no problem,
asynchroneous rotation, with contact, will cause heavy friction, I would
think, presumably leading to rapid synchronization. Thus a contact
system with asynchroneous rotation probably is unrealistic.)
<BR>
<P>
Surface spots (if there are any)
will move with the stellar rotation rate (just as they should).
<P>
<H2><A NAME="SECTION00085000000000000000">
<SPAN CLASS="arabic">7</SPAN>.<SPAN CLASS="arabic">5</SPAN> Eccentric Orbit</A>
</H2>
<P>
According to Keplers <A NAME="eccentric"></A> laws, the shape of the orbit is
an ellipse. Often, it is close to a special case of an ellipse - a circle.
However, sometimes binary orbits are markedly eccentric, i.e. non-circular.
In an eccentric orbit,
the distance and the orbital velocity is not constant. The stars will
gain velocity, as they fall toward each other, and
move fastest at Periastron (closest approach). They will lose
velocity again as they move away from each other, and move slowest at Apastron
(largest distance). Thus the time between first and second
eclipse in general is different from the time between second and first.
Also, the width of the eclipses may be different, as in general
the stars will move with different velocities during the two eclipses.
<SMALL>NIGHTFALL</SMALL> comes with sample data for the star 'V541 Cygni', an eccentric
binary system where you can observe both effects.
<BR>
<P>
Similar to asynchroneous rotation, the comment applies that tidal forces
will act towards circularization of the orbit. Eccentric orbits are more
likely in wide binaries than in close ones.
<BR>
<P>
The problem is, that in an eccentric orbit the changing distance
is equivalent to a changing Roche lobe filling factor,
and thus a changing shape of the star
(remember, the larger the Roche lobe filling factor, the
larger also is the nonspherical distortion of a star's shape).
While in a circular orbit the stellar surface is calculated only once,
and then just rotated in space, in an eccentric orbit the stellar surface
must be re-calculated at each step in orbital phase, thus causing substantial
computational overhead.
<BR>
<P>
To switch on this option, use
<BR>
<P>
<B>-e eccentricity periastron_length</B>
<BR>
<P>
where 'eccentricity' (range 0-1, 0 is circular orbit) is defined as
<BR><P></P>
<DIV ALIGN="CENTER" CLASS="mathdisplay">
<!-- MATH
\begin{displaymath}
e = \frac{r_2 - r_1}{r_2 + r_1},
\end{displaymath}
-->
<IMG
BORDER="0" SRC="img18.png"
ALT="\begin{displaymath}e = \frac{r_2 - r_1}{r_2 + r_1}, \end{displaymath}">
</DIV><BR CLEAR="ALL">
<P></P>
with <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img19.png"
ALT="$r_2$"></SPAN> is the largest and
<SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img20.png"
ALT="$r_1$"></SPAN> the smallest distance. Clearly, <SPAN CLASS="MATH"><IMG
ALIGN="BOTTOM" BORDER="0" SRC="img21.png"
ALT="$e = 0.0$"></SPAN> if <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img22.png"
ALT="$r_2 = r_1$"></SPAN>,
which is the case for a circular orbit. <SPAN CLASS="MATH"><IMG
ALIGN="BOTTOM" BORDER="0" SRC="img23.png"
ALT="$e = 1.0$"></SPAN> is a
degenerate case (a parabola), which cannot be handled by the program.
'periastron_length' is the length (in degree) of the periastron,
i.e. the point of closest approach in the orbit. To find out how it is
counted, you may set the Roche lobe filling factor to 1.0, and e to a high
value, like 0.5, Then, using the animation option (-A), you can identify
the periastron easily, as the star will fill the Roche lobe at closest
approach.
<P>
The input Roche lobe filling factor is assumed at Periastron.
Due to the variable orbital velocity, 'synchroneous' rotation is not really
synchroneous - rotation will lag behind the orbital motion for part of the
orbit, and advance for the other part of the orbit.
Surface spots (if there are any) will move accordingly.
<BR>
<P>
<H2><A NAME="SECTION00086000000000000000">
<SPAN CLASS="arabic">7</SPAN>.<SPAN CLASS="arabic">6</SPAN> Limb Darkening</A>
</H2>
<P>
The depth to which you can see into a star's atmosphere (where the visible
light comes from) varies with
the viewing angle. As the temperature (which determines the light flux)
increases with depth, you can see hotter (= brighter) layers
of the atmosphere towards the centre of the star's disk, where you
can look deeper. Towards the limb, you see shallower, cooler, and thus
less bright layers of the atmosphere.
This results in the limb of a star being darker than the
centre of its visible disk, an effect that can be seen readily on good (!)
photographies of the Sun.
<BR>
<P>
Limb darkening, as a function of the cosine of the viewing angle
towards the stellar surface,
is well aproximated by simple expressions. <SMALL>NIGHTFALL</SMALL> offers three
different options, with expressions that are linear or include
additional square or square root terms. The square root law
is probably most accurate, but you will
find that there is not much difference.
<BR>
<P>
The default is the linear law. To change this, use
<BR>
<P>
<B>-Ln</B>
<BR>
<P>
with 'n' a number in the range 0-2 (0 = default).
<BR>
<P>
<H2><A NAME="SECTION00087000000000000000">
<SPAN CLASS="arabic">7</SPAN>.<SPAN CLASS="arabic">7</SPAN> Surface Spots</A>
</H2>
<P>
Cool stars like the sun (i.e. stars with surface temperatures of a
few thousand Kelvin only) <A NAME="spotted"></A>often have surface spots, which are regions of somewhat lower temperature
on the surface. Among such stars, some are
known to have surface spots ('starspots') much larger than those
shown by the Sun. In extreme
cases, spots may cover a few tenths of the stellar surface. Usually, these
are cool spots (i.e. a few 100 K cooler than the surrounding area), caused
by magnetic activity (like on the Sun).
<BR>
<P>
To include spots, use
<BR>
<P>
<B>-sP longitude latitude radius dimfactor</B> or
<BR>
<P>
<B>-sS longitude latitude radius dimfactor</B>
<BR>
<P>
(-sP for a spot on the Primary, -sS for a spot on the secondary).
Spots are circular. The arguments are longitude and latitude of the spot's
centre, the radius (all in degree) and the factor, by which the surface
temperature is changed in the spot area. You can have multiple spots on each
star. For overlapping spot areas, 'dimfactor' is averaged.
<BR>
<P>
It is possible, but physically very unrealistic, to set 'dimfactor' to rather
low or high values (0.5 - 2.0). Temperature deviations of more than about
1000 K may be not realistic. Hot spots are seen only in
exceptional cases.
<P>
<H2><A NAME="SECTION00088000000000000000">
<SPAN CLASS="arabic">7</SPAN>.<SPAN CLASS="arabic">8</SPAN> Radial Velocities</A>
</H2>
<P>
Unlike lightcurves, which can be expressed in a relative unit, radial
velocity curves only make sense in absolute units (km/s in <SMALL>NIGHTFALL</SMALL>).
Thus, they require absolute dimensions as input for the system.
(<SMALL>NIGHTFALL</SMALL> supplies default values, however, if you don't want to
bother about this.) Use
<BR>
<P>
<B>-tP period</B> or
<BR>
<P>
<B>-tM mass</B> or
<BR>
<P>
<B>-tD distance</B>
<BR>
<P>
('period' in days, 'mass' ( = total mass of both stars) in solar masses,
'distance' in solar radii.) You need to give two of these; the third
can (and will) be calculated from Kepler's third law.
<BR>
<P>
Radial velocities are computed as the sum of the orbital velocity of a point
mass plus corrctions (flux-weighted contributions from each surface element).
In animated view, you can see the resulting sum as well as the correction term
(the latter multiplied by 2).
<P>
<H2><A NAME="SECTION00089000000000000000">
<SPAN CLASS="arabic">7</SPAN>.<SPAN CLASS="arabic">9</SPAN> Line profiles</A>
</H2>
<P>
<SMALL>NIGHTFALL</SMALL> can calculate spectral line profiles at each phase
step, which are output to files (one for each phase step). You can
specify the rest wavelength 'lambda_zero' for the line.
The luminosities (of individual surface elements)
used to compute the profile are those for the passband with the closest
effective wavelength. To switch on, use
<BR>
<P>
<B>-Plamda_zero</B>
<BR>
<P>
In interactive mode, you have the option to view the line profiles, and
change the phase interactively.
<BR>
<P>
<I>Some numerical artifacts present, probably due to finite surface grid.</I>
<P>
<H2><A NAME="SECTION000810000000000000000">
<SPAN CLASS="arabic">7</SPAN>.<SPAN CLASS="arabic">10</SPAN> Third Light</A>
</H2>
<P>
The presence <A NAME="third"></A>
of an additional light source in the system (e.g. a third star)
will decrease the contrast between eclipsed and non-eclipsed parts of the
lightcurve. To include this effect, use
<BR>
<P>
<B>-3filter fraction</B>
<BR>
<P>
where 'filter' is one of the supported filters (UBVRIJHKuvby) and
'fraction' is the relative contribution of third light
to the total system luminosity. I.e.: <BR><P></P>
<DIV ALIGN="CENTER" CLASS="mathdisplay">
<!-- MATH
\begin{displaymath}
L1 + L2 + L3 = 1.0,
\end{displaymath}
-->
<IMG
BORDER="0" SRC="img24.png"
ALT="\begin{displaymath}L1 + L2 + L3 = 1.0,\end{displaymath}">
</DIV><BR CLEAR="ALL">
<P></P>
where <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img25.png"
ALT="$L1 + L2$"></SPAN> is the combined light flux from Primary and Secondary,
and <SPAN CLASS="MATH"><IMG
ALIGN="BOTTOM" BORDER="0" SRC="img26.png"
ALT="$L3$"></SPAN> is 'third light'.
<BR>
<P>
<!-- MATH
$\underline{\smash{\hbox{This option is not tested yet.}}}$
-->
<SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img27.png"
ALT="$\underline{\smash{\hbox{This option is not tested yet.}}}$"></SPAN>
<P>
<HR>
<P>
<H1><A NAME="SECTION00090000000000000000">
<SPAN CLASS="arabic">8</SPAN> Fitting observed data</A>
</H1>
<P>
<SMALL>NIGHTFALL</SMALL> offers <A NAME="fitting"></A>
the possibility of determining a best-fit model
for observed data. Several datasets can be fit simultaneously.
Both a local and a global optimization algorithm are available.
<B>Fit results</B> are written to a file 'NightfallFitted.dat'.
<P>
<H2><A NAME="SECTION00091000000000000000">
<SPAN CLASS="arabic">8</SPAN>.<SPAN CLASS="arabic">1</SPAN> Reading in the data</A>
</H2>
<P>
In order <A NAME="dataread"></A>
to determine a best-fit model to observed data, you first
have to read them into memory. Use
<BR>
<P>
<B>-I path/to/data/file</B>.
<BR>
<P>
Only one file is read. To read more files, prepend each of them with a
<B>-I</B>. You can read in (only) one datafile for each filter.
<BR>
<P>
Each row in the file should consist of two or three numbers. The first
is the date of the observation (as decimal number, in any unit you like),
the second the measurement value (in magnitudes
for brightness, in km/s for radial velocity), and the third (optional)
the estimated error of the measurement.
<BR>
<P>
Lines starting with a '#' are ignored, with the following exceptions
(no blank after '#' !!):
<BR>
<P>
<B>#P period</B>
gives the orbital period of the system (same unit as dates).
The program will use this value
to fold the data into orbital phase. The default is 1.0 (thus assuming
that your data are already folded in phase).
<BR>
<P>
<B>#Z zeropoint</B>
gives the zeropoint for orbital phase, i.e. the time of Primary eclipse
(same unit as dates).
The default is 0.0 (again assuming
that your data are already folded in phase).
<BR>
<P>
<B>#B filter</B>
gives the filter (UBVRIubvyJHK) in which your data have been observed.
Default is V. For radial velocities, use '1' for Primary, '2' for Secondary.
<BR>
<P>
<B>#W error</B>
gives the average estimated error of measurements (if you do not have
individual ones). Default is 0.01 (brightness) or 1.0 (radial velocities).
You can mix individual and average error estimates (e.g. if you have
individual error estimates only for some of your data).
<BR>
<P>
<B>#V system_velocity</B>
For radial velocity curves, use this parameter to set the system velocity.
Radial velocities will be set to <!-- MATH
$data - system\_velocity$
-->
<SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img28.png"
ALT="$data - system\_velocity$"></SPAN>.
<BR>
<P>
<B>#N normalisation_phase</B>
Use this parameter to set the phase at which to normalize the light curve.
The default is the starting point of the lightcurve.
<BR>
<P>
<B>#S shift</B>
This is a particular important parameter that requires some care. As noted
in
<A HREF="#norm">the info on brightness,</A>
<SMALL>NIGHTFALL</SMALL> will normalize its lightcurves to light at
the normalisation_phase (see above),
which by default is the starting point
of the lightcurve (the leftmost in the plotted lightcurve).
Thus, at this point, the brightness is zero magnitudes.
For a meaningful fit, your observed lightcurve must be shifted up/down
to have the value zero at this point as well (within the measurement
errors). <SMALL>NIGHTFALL</SMALL> will
try to do it automatically, but some correction may be required. Plot the
lightcurve (data will be overplotted, if there are any), and check.
Note: incorrect use of this parameter may make a fit look better, but
the fitted parameters might be meaningless. Do not shift to anywhere else
than the starting point of the lightcurve.
<BR>
<P>
The source code distribution includes example files for the binaries
TY Boo (an overcontact system) and some more. If in doubt, look into them.
<P>
<H2><A NAME="SECTION00092000000000000000">
<SPAN CLASS="arabic">8</SPAN>.<SPAN CLASS="arabic">2</SPAN> Finding a local optimum</A>
</H2>
<P>
Determining a best-fit model means to optimize the parameters (like
inclination, temperature, mass ratio, etc.) in such a way that the mismatch
between model and observation is minimized. This mismatch is measured
by a suitable <B>merit function</B>
(sometimes also called <B>cost function</B>). <SMALL>NIGHTFALL</SMALL> uses the
chi-square function as merit function.
<BR>
<P>
General problems of determining best-fit parameters are:
<BR>
<P>
(1) uniqueness: there may be several/many (nearly) equally good solutions.
Do a few trials. <B>Restart</B> fitting with last best-fit as starting point.
<BR>
<P>
(2) overfitting: the information content of a lightcurve is limited. Fitting
too many parameters might produce good-looking, but meaningless results.
Use as few free parameters as are sufficient for a good fit.
<BR>
<P>
(3) local vs. global optimum: just that you find a valley, doesn't mean this is
the deepest valley on Earth. The same applies to optimization problems.
Any local optimization algorithm will only find a local optimum. If
the problem is well-behaved, this will be the one and only, global, optimum.
If the problem is badly-behaved, you might need a few trials with different
starting points to find (hopefully) the global optimum. If the problem
is even worse, you might need an awful lot of computing time to find
the global optimum. Most examples in textbooks are nice. Most real-world
optimization problems turn out to be bad or even ugly.
<BR>
<P>
<SMALL>NIGHTFALL</SMALL> uses the so-called Simplex algorithm for local
optimization. This is a direct search algorithm that is not terribly fast
(and not terribly slow either),
but very robust. To switch on optimization, use
<BR>
<P>
<B>-Xparameters tolerance</B>
<BR>
<P>
where 'parameters' is a string of characters indicating the parameters
you want to fit (all others kept fixed), and 'tolerance' is the stopping
criterion (something like 0.1 or less would be appropriate - 0.001 has
a special meaning, see
<A HREF="#global">the section on global fitting</A>).
Use
'nightfall' without options to get the character codes for fit parameters.
<BR>
<P>
If more than one data file is input (e.g. lightcurves in different filters),
<SMALL>NIGHTFALL</SMALL> will fit all data simultaneously. This will probably work
well only if different datasets are properly weighted - i.e. if the
error estimates (or at least their ratios) are ok.
<BR>
<P>
Have a cup of coffee ready. Use the <B>-Db</B> option (switch on 'Busy' in
interactive mode) to see what is going on meanwhile.
<BR>
<P>
<B>IMPORTANT:</B> Restart fit with last best-fit as starting point.
Continue this until you are sure that the solution has converged and does not
improve anymore, i.e. the value of 'SDV (Chi square)' does not significantly
change anymore. Otherwise, your results may be <B>completely meaningless</B>.
(swich on the -Db option to see 'SDV (Chi square)' for each iteration -
see
<A HREF="#debug">the info on debug options.</A>
<BR>
<P>
<I>Output is always written to a file 'NightfallFitted.dat'.</I>
<P>
<H2><A NAME="SECTION00093000000000000000">
<SPAN CLASS="arabic">8</SPAN>.<SPAN CLASS="arabic">3</SPAN> Goodness-of-fit</A>
</H2>
<P>
To evaluate how good a fit is, <SMALL>NIGHTFALL</SMALL> offers the following
options:
<BR>
<P>
(1) if you plot the lightcurve, residuals will be plotted as well. Look
at them to check whether there are systematic trends ( = bad fit).
<BR>
<P>
(2) for a good fit, the residuals should scatter randomly around the
model, with no systematic trends. This can be quantified by computing the
'runs statistic' (the number of runs = occurences of two or more
<B>consecutive</B> residuals above or below the model curve). Obviously,
a large number of runs would occur for a strictly alternating sequence,
which is very unlikely for a random sequence. Likewise, only two runs
would occur for the first half of the data below, the second above the
model curve - also suspiciously non-random. The expected number of runs can
be calculated analytically. <SMALL>NIGHTFALL</SMALL> will print out the actual number
of runs, and the lower and upper limits for a 90 percent confidence interval.
<BR>
<P>
(3) in theory, the goodness-of-fit can be evaluated from the <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img29.png"
ALT="$\chi^2$"></SPAN>
(Chi Square) value of the fit (the function actually minimized in
parameter fitting), which should be close to unity for a good fit.
However, this only works
if the error estimates for the measurements
are realistic - neither to high nor to low. This is
very rarely the case in astronomy ...
<P>
<H2><A NAME="SECTION00094000000000000000">
<SPAN CLASS="arabic">8</SPAN>.<SPAN CLASS="arabic">4</SPAN> Finding a global optimum</A>
</H2>
<P>
To find a <A NAME="global"></A> global optimum,
basically a stochastic search strategy is required
(or an exhaustive seach of the complete parameter space ...).
There are different possibilities, ranging from complete random search to
some 'intelligent' variation of random search. <SMALL>NIGHTFALL</SMALL> offers
'Simulated Annealing', which is a kind of mathematical implementation of
the cooling of matter (leading to crystallization, i.e. an energy optimum,
if cooling is slow enough). Switch on by setting the fit tolerance to 0.001
(in command-line mode).
<BR>
<P>
Be prepared for a computing time on the order of a day or more (if you have
no other CPU-expensive job running).
<BR>
<P>
I am not sure whether the algorithm is correctly implemented. In the
present implementation, cooling
might be too fast, or might stop at a too high 'temperature'. However,
my own experiments were rather satisfactory most of the time.
<BR>
<P>
Apparently, 'Simulated Annealing' does not mathematically
guarantee that the global optimum is indeed
found, unless 'cooling' proceeds infinetely slow ...
<P>
<H2><A NAME="SECTION00095000000000000000">
<SPAN CLASS="arabic">8</SPAN>.<SPAN CLASS="arabic">5</SPAN> Mapping the Chi-Square function</A>
</H2>
<P>
This option will create a two-dimensional map of the
merit function (i.e. in the case of N<SMALL>IGHTFALL</SMALL> the
Chi-Square function that measures the
goodness of a fit) with respect to two parameters.
Start values are the current values, step values
can be entered. The gridsize is fixed at compile time
(default 16 x 16, i.e. 256 lightcurves will be evaluated).
To switch on this option, use
<BR>
<P>
<B>-Xparameters step1 step2</B>
<BR>
<P>
Parameters are coded like in the fitting option (see above),
but only two parameters should be chosen.
<P>
<HR>
<P>
<H1><A NAME="SECTION000100000000000000000">
<SPAN CLASS="arabic">9</SPAN> Miscellaneous</A>
</H1>
<P>
<H2><A NAME="SECTION000101000000000000000">
<SPAN CLASS="arabic">9</SPAN>.<SPAN CLASS="arabic">1</SPAN> Debug options</A>
</H2>
<P>
<B>-Dcharacterstring</B>
<BR>
<P>
Most debug <A NAME="debug"></A> options (selected by 'characterstring')
are of little use
unless you know the code rather well. Some will produce excessive
(and excessively messy) output.
<BR>
<P>
Exceptions are:
<P>
<UL>
<LI><B>b</B> ('busy'), which keeps your screen somewhat busy
in case you do something computationally expensive
(data fitting, elliptical orbit).
<P>
</LI>
<LI><B>w</B> ('warning'), which will print out warnings. Usually,
these refer to problems that the program can deal with, and
thus you can ignore them. If you do not get the output you expect,
you might want to turn them on to see what the program complains
about.
<P>
</LI>
<LI><B>v</B> ('verbose'), which will print out a moderate amount of
information (will grow excessive during data fitting ... use 'b'
instead if you just want to see what's going on).
<P>
</LI>
</UL>
<P>
<H2><A NAME="SECTION000102000000000000000">
<SPAN CLASS="arabic">9</SPAN>.<SPAN CLASS="arabic">2</SPAN> Output of the surface map</A>
</H2>
<P>
It is possible to obtain the 2D surface map of the stars, as seen by an
observer, i.e. the map displayed in animated mode.
You have to set the environment variable
NIGHTFALL_SMAP_PATH to the path of the map file (the program will
append the index of the phase to this, i.e. you will get a seperate file for
each step in orbital phase). If NIGHTFALL_SMAP_PATH is undefined,
no map will be printed.
<P>
By default, the map will be output for the V band; you can change that
with the environment variable NIGHTFALL_SMAP_BAND (0..11 for UBVRIJHKuvby).
<P>
The map includes for each <I>visible</I> surface element:
<BR> (1) the index of the star,
<BR> (2) the index of the surface element,
<BR> (3, 4) x, y coordinates in the viewing plane of the observer,
with the star at (0, 0),
<BR> (5, 6) x, y coordinates as above, but with the centre of mass
at (0, 0),
<BR> (7) <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img30.png"
ALT="$\cos{\gamma}$"></SPAN>, the line-of-sight angle,
<BR> (8) temperature,
<BR> (9) dimensionless gravity,
<BR> (10) area,
<BR> (11) flux.
<BR>The flux is not normalized to the area; it is the flux that this surface
element contributes to the total flux.
<P>
<H2><A NAME="SECTION000103000000000000000">
<SPAN CLASS="arabic">9</SPAN>.<SPAN CLASS="arabic">3</SPAN> User-defined wavelenghts</A>
</H2>
<P>
It is possible to compute monocromatic fluxes at up to twelve different,
user-defined wavelengths. These wavelengths (unit: micrometer) must be
provided as a comma-seperated list in the environment
variable NIGHTFALL_MONO_WAVE. They will replace the wavelenghts used in the
blackbody approximation.
<P>
<UL>
<LI>If less than twelve wavelengths are given, the remaining ones will be filled
in with the wavelengths of the corresponding passbands.
<P>
</LI>
<LI>For each wavelength,
<SMALL>NIGHTFALL</SMALL> will use the limb darkening
coefficients of the passband whose wavelength matches
best the monochromatic one.
<P>
</LI>
<LI>Blackbody approximation must be selected (i.e. the 'model atmosphere' option
must be switched off), otherwise these user-defined
wavelengths do not take effect.
<P>
</LI>
</UL>
<P>
<HR>
<P>
<H1><A NAME="SECTION000110000000000000000">
<SPAN CLASS="arabic">10</SPAN> Technical details</A>
</H1>
<P>
<I>This section is intended as a technical reference for experts who want to
familiarize themself with the nasty details and the algorithms used.
</I>
<P>
<P>
<H2><A NAME="SECTION000111000000000000000">
<SPAN CLASS="arabic">10</SPAN>.<SPAN CLASS="arabic">1</SPAN> Geometry</A>
</H2>
<P>
The geometric setup is based on a paper [<A
HREF="UserManual.html#djura92a">11</A>]
by Djuraševic (1992a).
In a cartesian coordinate system <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img31.png"
ALT="$(x, y, z)$"></SPAN>, the stars are located at
<SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img32.png"
ALT="$(0, 0, 0)$"></SPAN> and <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img33.png"
ALT="$(1, 0, 0)$"></SPAN>, and the <SPAN CLASS="MATH"><IMG
ALIGN="BOTTOM" BORDER="0" SRC="img34.png"
ALT="$z$"></SPAN>-axis is perpendicular to the orbital
plane.
A normalized, dimensionless Roche potential is used, which at a point
<SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img35.png"
ALT="$P(x,y,z)$"></SPAN> is given by the value <SPAN CLASS="MATH"><IMG
ALIGN="BOTTOM" BORDER="0" SRC="img36.png"
ALT="$C$"></SPAN> as
<BR><P></P>
<DIV ALIGN="CENTER" CLASS="mathdisplay">
<!-- MATH
\begin{displaymath}
C = \frac{1}{r_1} + q (\frac{1}{r_2} - x)
+ \frac{q + 1}{2} ( x^2 + y^2 )f^2,
\end{displaymath}
-->
<IMG
BORDER="0" SRC="img37.png"
ALT="\begin{displaymath}C = \frac{1}{r_1} + q (\frac{1}{r_2} - x)
+ \frac{q + 1}{2} ( x^2 + y^2 )f^2, \end{displaymath}">
</DIV><BR CLEAR="ALL">
<P></P>
with <!-- MATH
$r_1 = x^2+y^2+z^2$
-->
<SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img38.png"
ALT="$r_1 = x^2+y^2+z^2$"></SPAN>, <!-- MATH
$r_2 = (x-1)^2+y^2+z^2$
-->
<SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img39.png"
ALT="$r_2 = (x-1)^2+y^2+z^2$"></SPAN>,
mass ratio <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img40.png"
ALT="$q = m_2/m_1$"></SPAN>, and nonsynchronism parameter <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img41.png"
ALT="$f = w/w_k$"></SPAN>
(i.e. the ratio of the angular velocity to the Keplarian angular
velocity).
<BR>For practical purposes, a spherical coordinate system <!-- MATH
$(r, \eta, \phi)$
-->
<SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img42.png"
ALT="$(r, \eta, \phi)$"></SPAN>
is used, which is defined by
<P></P><DIV ALIGN="CENTER" CLASS="mathdisplay">
<!-- MATH
\begin{eqnarray*}
x & = & r\ \cos{\eta},\\
y & = & r\ \sin{\eta}\ \cos{\phi},\\
z & = & r\ \sin{\eta}\ \sin{\phi}.\\
\end{eqnarray*}
-->
<IMG
BORDER="0" SRC="img43.png"
ALT="\begin{eqnarray*}
x & = & r\ \cos{\eta},\\
y & = & r\ \sin{\eta}\ \cos{\phi},\\
z & = & r\ \sin{\eta}\ \sin{\phi}.\\
\end{eqnarray*}"></DIV><BR CLEAR="ALL"><P></P>
<BR CLEAR="ALL"><P></P>
The surface of the star is then divided into elementary areas by a grid
in <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img44.png"
ALT="$(\eta, \phi)$"></SPAN>, and for each surface element the gravity
acceleration <!-- MATH
$g(r, \eta, \phi)$
-->
<SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img45.png"
ALT="$g(r, \eta, \phi)$"></SPAN>, the area <!-- MATH
$dS(r, \eta, \phi)$
-->
<SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img46.png"
ALT="$dS(r, \eta, \phi)$"></SPAN>, and the normal
vector <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img47.png"
ALT="$(l, m, n)$"></SPAN> is computed as outlined in [<A
HREF="UserManual.html#djura92a">11</A>].
<BR>
<P>
<I>Notes</I>:
<B>(i)</B> Equation (1-16) in [<A
HREF="UserManual.html#djura92a">11</A>] has a minor typo
(wrong sign for <SPAN CLASS="MATH"><IMG
ALIGN="BOTTOM" BORDER="0" SRC="img48.png"
ALT="$l$"></SPAN>).
<BR><B>(ii)</B> Djuraševic [<A
HREF="UserManual.html#djura92a">11</A>] apparently uses
equidistant steps in <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img49.png"
ALT="$\phi$"></SPAN>, thus leading
to very unhomogeneous elementary areas. <SMALL>NIGHTFALL</SMALL> avoids this
by adjusting the number of steps <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img50.png"
ALT="$N_{\phi}$"></SPAN> as
<BR><P></P>
<DIV ALIGN="CENTER" CLASS="mathdisplay">
<!-- MATH
\begin{displaymath}
N_{\phi} = 10 + N_{\eta} sin{\eta},
\end{displaymath}
-->
<IMG
BORDER="0" SRC="img51.png"
ALT="\begin{displaymath}N_{\phi} = 10 + N_{\eta} sin{\eta},\end{displaymath}">
</DIV><BR CLEAR="ALL">
<P></P>
with <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img52.png"
ALT="$N_{\eta}$"></SPAN> a (compile-time) constant.
<P>
<H3><A NAME="SECTION000111100000000000000">
<SPAN CLASS="arabic">10</SPAN>.<SPAN CLASS="arabic">1</SPAN>.<SPAN CLASS="arabic">1</SPAN> Accretion disk</A>
</H3>
Eclipse testing for the accretion disk is based on the method described in [<A
HREF="UserManual.html#djura92a">11</A>]
by Djuraševic (1992b).
<P>
<H2><A NAME="SECTION000112000000000000000">
<SPAN CLASS="arabic">10</SPAN>.<SPAN CLASS="arabic">2</SPAN> Reflection and gravity darkening/brightening</A>
</H2>
<P>
There are two options available for the treatment of reflection.
Both are <I>bolometric</I> corrections, in the sense that the bolometric
flux of the irradiating component is used to modify the temperature
distribution on the irradiated component. See [<A
HREF="UserManual.html#wilso90">24</A>] for a discussion
of this issue.
<BR>
<P>
The 'simple' option for the treatment of reflection is described
in [<A
HREF="UserManual.html#djura92a">11</A>]. The correction should be
exact for spherical stars.
<BR>
<P>
The 'detailed' reflection treatment loops over all pairs of surface
elements <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img53.png"
ALT="$(dS_1,dS_2)$"></SPAN> and sums up, for each surface element <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img54.png"
ALT="$dS_1$"></SPAN>,
the irradiation by all visible surface elements <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img55.png"
ALT="$dS_2$"></SPAN> of the other star.
Again, <I>bolometric</I> irradiation is computed. Of course, the true
temperature of the irradiating surface elements (including reflection)
is not known, thus it is necessary to iterate the algorithm. Convergence
is typically reached after 2-3 iterations.
The algorithm is described in [<A
HREF="UserManual.html#hendr92">13</A>].
<BR>
<P>
For both treatments, by default for convective stars
(below 7700 K) an albedo of 0.5, and for
radiative stars an albedo of 1.0 is used. It is possible to
choose different albedo values at program start using
the command line option(s) <TT>-aP</TT> <I>value</I> for the primary and
<TT>-aS</TT> <I>value</I> for the secondary.
<BR>
<P>
Gravity darkening is computed by
<BR><P></P>
<DIV ALIGN="CENTER" CLASS="mathdisplay">
<!-- MATH
\begin{displaymath}
T(r, \eta, \phi) = T_{eff}(\frac{g(r, \eta, \phi)}{g_{eff}})^{\beta}.
\end{displaymath}
-->
<IMG
BORDER="0" SRC="img56.png"
ALT="\begin{displaymath}T(r, \eta, \phi) = T_{eff}(\frac{g(r, \eta, \phi)}{g_{eff}})^{\beta}. \end{displaymath}">
</DIV><BR CLEAR="ALL">
<P></P>
For the gravity brightening exponent, the results from [<A
HREF="UserManual.html#claret00a">6</A>]
(Fig. 1 in the paper) are used, which provide a smooth transition to the
Von Zeipel (1924) exponent of 0.25 for radiative stars.
<BR>
<P>
<I>Notes</I>:
<B>(i)</B> The 'simple' reflection treatment in [<A
HREF="UserManual.html#djura92a">11</A>]
has been supplemented by a penumbral correction for
the partial visibily of the other star, if it is at the horizon.
This penumbral correction assumes that the horizon is flat
and that the other star
is spherical, i.e. that the visible part is a segment of a circle.
<BR><B>(ii)</B> For the 'detailed' reflection treatment, instead of
the quadratic limb darkening law used by
[<A
HREF="UserManual.html#hendr92">13</A>], a square root law ([<A
HREF="UserManual.html#diaz92">10</A>])
<BR><P></P>
<DIV ALIGN="CENTER" CLASS="mathdisplay">
<!-- MATH
\begin{displaymath}
I(\mu) = I(1)[1 - c(1-\mu) - d(1 - \sqrt{\mu})]
\end{displaymath}
-->
<IMG
BORDER="0" SRC="img57.png"
ALT="\begin{displaymath}I(\mu) = I(1)[1 - c(1-\mu) - d(1 - \sqrt{\mu})] \end{displaymath}">
</DIV><BR CLEAR="ALL">
<P></P>
is used (where <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img58.png"
ALT="$\mu$"></SPAN> is the cosine of the angle subtended by the emergent
radiation and the direction perpendicular to the stellar surface),
and bolometric
limb darkening coefficients are taken from [<A
HREF="UserManual.html#claret00">7</A>].
The normalization factor for the square root
law was calculated as
<BR><P></P>
<DIV ALIGN="CENTER" CLASS="mathdisplay">
<!-- MATH
\begin{displaymath}
\frac{1}{\pi\ (1 - c/3 - d/5)}.
\end{displaymath}
-->
<IMG
BORDER="0" SRC="img59.png"
ALT="\begin{displaymath}\frac{1}{\pi\ (1 - c/3 - d/5)}.\end{displaymath}">
</DIV><BR CLEAR="ALL">
<P></P>
<B>(iii)</B> The temperature limit of 7700K dividing stars with
convective/radiative envelopes can be changed by the environment
variable NIGHTFALL_RADIATIVE (within the range 4000 - 12000K).
This changes the albedo only (0.5 below, 1.0 above).
<P>
<H2><A NAME="SECTION000113000000000000000">
<SPAN CLASS="arabic">10</SPAN>.<SPAN CLASS="arabic">3</SPAN> Spots</A>
</H2>
<P>
Spots are always circular, and
characterized by four parameters: longitude <SPAN CLASS="MATH"><IMG
ALIGN="BOTTOM" BORDER="0" SRC="img60.png"
ALT="$\lambda$"></SPAN>,
latitude <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img61.png"
ALT="$\beta$"></SPAN>, radius <SPAN CLASS="MATH"><IMG
ALIGN="BOTTOM" BORDER="0" SRC="img62.png"
ALT="$r$"></SPAN>, and a 'dimming' factor <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img63.png"
ALT="$A_p = T_p/T$"></SPAN>,
i.e. the ratio of the (local) temperature <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img64.png"
ALT="$T_p$"></SPAN> with spot to the temperature
<SPAN CLASS="MATH"><IMG
ALIGN="BOTTOM" BORDER="0" SRC="img65.png"
ALT="$T$"></SPAN> without spot. A detailed discussion of the trigonometric
expressions used to identify surface elements within the spot area
can be found in [<A
HREF="UserManual.html#djura92a">11</A>], section I-3.
In the 'detailed' reflection treatment,
reflection is calculated with spots, i.e. the spots are applied first,
then the reflection is calculated. For overlapping spots, in the overlap area
the mean value of their <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img66.png"
ALT="$A_p$"></SPAN> is used.
<P>
<H2><A NAME="SECTION000114000000000000000">
<SPAN CLASS="arabic">10</SPAN>.<SPAN CLASS="arabic">4</SPAN> Output flux</A>
</H2>
<P>
In the blackbody approximation, for each stellar component and
each filter a (temperature-dependent)
effective wavelength is computed, following Equation 3.30 in
[<A
HREF="UserManual.html#buddi93">4</A>]:
<BR><P></P>
<DIV ALIGN="CENTER" CLASS="mathdisplay">
<!-- MATH
\begin{displaymath}
{\lambda}_{eff} = {\lambda}_{0}
+ \frac{ 5 {\mu}_2 ({\lambda}_{p}-{\lambda}_{0}) }{\sqrt{{\lambda}_{0}}},
\end{displaymath}
-->
<IMG
BORDER="0" SRC="img67.png"
ALT="\begin{displaymath}{\lambda}_{eff} = {\lambda}_{0}
+ \frac{ 5 {\mu}_2 ({\lambda}_{p}-{\lambda}_{0}) }{\sqrt{{\lambda}_{0}}},
\end{displaymath}">
</DIV><BR CLEAR="ALL">
<P></P>
where <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img68.png"
ALT="${\lambda}_{0}$"></SPAN> is the filter wavelength, and <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img69.png"
ALT="${\lambda}_{p}$"></SPAN>
the wavelength of the blackbody peak for the effective temperature of the
respective component.
The required second moments <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img70.png"
ALT="${\mu}_2$"></SPAN> of the filter passbands
are computed following the prescription by [<A
HREF="UserManual.html#young92">25</A>], Equation 12:
<BR><P></P>
<DIV ALIGN="CENTER" CLASS="mathdisplay">
<!-- MATH
\begin{displaymath}
{\mu}_2 \simeq \frac{FW(0.05)}{4.4},
\end{displaymath}
-->
<IMG
BORDER="0" SRC="img71.png"
ALT="\begin{displaymath}{\mu}_2 \simeq \frac{FW(0.05)}{4.4}, \end{displaymath}">
</DIV><BR CLEAR="ALL">
<P></P>
where <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img72.png"
ALT="$FW(0.05)$"></SPAN> is
the full width at the 0.05 level.
<BR>
<P>
For the 'model atmosphere' option, fluxes for temperatures below 9800K are
from Hauschildt et al. (private comm., 2006) PHOENIX models,
otherwise flux tables from Kuruzc models ([<A
HREF="UserManual.html#kuru98">19</A>]).
are used. All models are for solar abundances. PHOENIX models below
2000K incorporate dust formation, with dust remaining in situ (no settling).
The (originally monochromatic) fluxes have been integrated over
the filter passbands (as given in [<A
HREF="UserManual.html#lando82">20</A>]).
Surface gravities <!-- MATH
$\log{g} = 3.5 - 5.0$
-->
<SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img73.png"
ALT="$\log{g} = 3.5 - 5.0$"></SPAN> (in steps of 0.5) are available.
<BR>
<P>
Three different limb darkening approximations are available, a <I>linear</I>,
a <I>quadratic</I>, and a
<I>square root</I> one,
which are given by the following expressions, respectively:
<P></P><DIV ALIGN="CENTER" CLASS="mathdisplay">
<!-- MATH
\begin{eqnarray*}
I(\mu) & = & I(1)[1 - u(1-\mu)],\\
I(\mu) & = & I(1)[1 - a(1-\mu) - b(1-\mu)^2],\quad {\rm and}\\
I(\mu) & = & I(1)[1 - c(1-\mu) - d(1 - \sqrt{\mu})],\\
\end{eqnarray*}
-->
<IMG
BORDER="0" SRC="img74.png"
ALT="\begin{eqnarray*}
I(\mu) & = & I(1)[1 - u(1-\mu)],\\
I(\mu) & = & I(1)[1 - a(1-...
... and}\\
I(\mu) & = & I(1)[1 - c(1-\mu) - d(1 - \sqrt{\mu})],\\
\end{eqnarray*}"></DIV><BR CLEAR="ALL"><P></P>
<BR CLEAR="ALL"><P></P>
where <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img58.png"
ALT="$\mu$"></SPAN> is the cosine of the angle subtended by the emergent
radiation and the direction perpendicular to the stellar surface.
Limb darkening coefficients are from [<A
HREF="UserManual.html#claret00">7</A>].
A discussion of the relative
merits of these three approximations can be found in [<A
HREF="UserManual.html#diaz92">10</A>].
<P>
<I>Notes</I>:
<B>(i)</B> When tabulated values are used, for temperatures out of
range (below 2000K and above 31000K for <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img2.png"
ALT="$\log{g} = 3.5$"></SPAN>,
39000K for <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img3.png"
ALT="$\log{g} = 4.0$"></SPAN>, 49000K for <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img75.png"
ALT="$\log{g} = 4.5$"></SPAN>,
50000K for <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img76.png"
ALT="$\log{g} = 5.0$"></SPAN>) the
lowest/highest value is used (i.e. no extrapolation is attempted).
<P>
<H2><A NAME="SECTION000115000000000000000">
<SPAN CLASS="arabic">10</SPAN>.<SPAN CLASS="arabic">5</SPAN> Eclipse testing</A>
</H2>
<P>
Eclipse testing follows the method proposed in [<A
HREF="UserManual.html#djura92a">11</A>]. First,
the contact angle of the Roche lobes is used to exclude eclipses, if
possible.
<BR>If an eclipse is possible,
for each surface element <SPAN CLASS="MATH"><IMG
ALIGN="BOTTOM" BORDER="0" SRC="img77.png"
ALT="$dS$"></SPAN> the line of sight (LOS) towards <SPAN CLASS="MATH"><IMG
ALIGN="BOTTOM" BORDER="0" SRC="img77.png"
ALT="$dS$"></SPAN>
is tested for intersection with the smallest sphere enclosing the
eclipsing star (no intersection = not eclipsed). Then the LOS is
tested for intersection with the largest sphere within the
eclipsing star (intersection = eclipsed). This procedure takes advantage
of the simplicity of testing the intersection of a line with a sphere.
<BR>If the LOS intersects the outer, but not the inner sphere, as a last
(and computationally expensive) resort, the minimum of the Roche potential
along the LOS is searched, and compared against the surface potential
of the eclipsing star.
<BR>
<P>
<I>Notes</I>:
<B>(i)</B> In [<A
HREF="UserManual.html#djura92a">11</A>], the osculating cone (i.e. the tangent cone
to the Roche surface at the inner Lagrangian point <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img78.png"
ALT="$L_1$"></SPAN>) is used as the first
eclipse criterion. According to [<A
HREF="UserManual.html#chana72">5</A>], this can lead to serious
errors for mass ratios very different from unity, as the larger Roche lobe
is concave at the <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img78.png"
ALT="$L_1$"></SPAN>. <SMALL>NIGHTFALL</SMALL> uses tabulated values from
[<A
HREF="UserManual.html#chana72">5</A>] (the cone angle <!-- MATH
$\phi_{\rm max}$
-->
<SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img79.png"
ALT="$\phi_{\rm max}$"></SPAN> as given in their Table 2).
<B>(ii)</B> In [<A
HREF="UserManual.html#djura92a">11</A>], the coordinate frame of the
eclipsed star is used, for eclipse testing,
which seems not to work for asynchroneous rotation.
<SMALL>NIGHTFALL</SMALL> therefore uses the coordinate frame of the eclipsing star,
following [<A
HREF="UserManual.html#antok96">2</A>].
<B>(iii)</B> In [<A
HREF="UserManual.html#djura92a">11</A>], it is proposed to evaluate the potential
along the LOS at six steps only. <SMALL>NIGHTFALL</SMALL> uses a more rigorous
approach with a minimum finding routine (Brent's algorithm [<A
HREF="UserManual.html#brent73">3</A>]).
<P>
<H2><A NAME="SECTION000116000000000000000">
<SPAN CLASS="arabic">10</SPAN>.<SPAN CLASS="arabic">6</SPAN> Fractional visibility</A>
</H2>
<P>
The eclipse testing routine assigns to each surface element a visibility
of 0 (eclipsed) or 1 (visible). However, the visibility is only
evaluated for the centre of the element. This can lead to 'spikes' in the
light curve, if large numbers of surface element centres become visible
at once. Therefore, an option is provided to compute a <I>fractional</I>
visibility for surface elements on the shadow limb.
<BR>
<P>
The algorithm first searches all pairs of elements on the shadow limb
(i.e. pairs with
one element eclipsed, the adjacent element uneclipsed), and
determines the potential minimum along the LOS towards them (which is typically
already available from the eclipse test).
Then, a linear approximation is made:
for each pair, the
distances <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img80.png"
ALT="$d_i$"></SPAN> to the shadow limb are taken as proportional
to the differences
between the minimum Roche potential <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img81.png"
ALT="$p_{i}^{LOS}$"></SPAN> along the LOS
and the surface potential <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img82.png"
ALT="$p_{*}$"></SPAN>
of the eclipsing star:
<BR><P></P>
<DIV ALIGN="CENTER" CLASS="mathdisplay">
<!-- MATH
\begin{displaymath}
f = \frac{d_1}{d_2} = \frac{p_{1}^{LOS} - p_{*}}{p_{2}^{LOS} - p_{*}}.
\end{displaymath}
-->
<IMG
BORDER="0" SRC="img83.png"
ALT="\begin{displaymath}f = \frac{d_1}{d_2} = \frac{p_{1}^{LOS} - p_{*}}{p_{2}^{LOS} - p_{*}}.\end{displaymath}">
</DIV><BR CLEAR="ALL">
<P></P>
The surface element with the larger distance is assumed to be
completely eclipsed or visible, and the other one of the pair is assigned
a fractional visibility <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img84.png"
ALT="$(1/2 + \vert f\vert)$"></SPAN> based on the above approximation.
This is not exact for individual surface elements,
as the dividing line between them may not be parallel to the shadow limb.
However, averaged over all surface elements on the limb, the error
should be negligeable.
<P>
<H2><A NAME="SECTION000117000000000000000">
<SPAN CLASS="arabic">10</SPAN>.<SPAN CLASS="arabic">7</SPAN> Eccentric orbits</A>
</H2>
<P>
In an eccentric orbit, the complete geometry and temperature distribution
is re-calculated at each step ( = step in mean anomaly). As the Roche
potential is used in a dimensionless form, the change in distance
is equivalent to a change in the Roche volume filling factor
( = surface potential) with an unchanged unit distance.
<BR>
<P>
This implies that the correct new surface potential must be found as
a function of the stellar volume, which is scaled up/down with the
distance. To avoid an iterative numerical integration of the stellar volume
(i.e. varying the surface potential until the correct volume is found),
which would be prohibitively expensive, the algorithm uses analytical
approximations from [<A
HREF="UserManual.html#kopal">18</A>] to derive the new surface potential.
<BR>
<P>
The following procedure is used:
<OL>
<LI>Solve the Kepler equation to determine the distance of the stars
(and their position in the orbit).
</LI>
<LI>Re-scale the distance to unity.
</LI>
<LI>Scale the stellar volume by the the cube of the distance scale factor.
</LI>
<LI>Find the 'mean radius' as the root of an analytical
expression for the stellar volume (of 11th order in this 'mean radius').
</LI>
<LI>Compute the new surface potential as a function of the 'mean radius'.
</LI>
</OL>
<P>
Numerical details, including the definition of the 'mean radius', can
be found in [<A
HREF="UserManual.html#kopal">18</A>].
<P>
<H2><A NAME="SECTION000118000000000000000">
<SPAN CLASS="arabic">10</SPAN>.<SPAN CLASS="arabic">8</SPAN> Optimization</A>
</H2>
<P>
For local optimization, the Simplex algorithm is used. This is a
direct search algorithm that does not require derivatives.
For <SPAN CLASS="MATH"><IMG
ALIGN="BOTTOM" BORDER="0" SRC="img85.png"
ALT="$N$"></SPAN> free parameters,
the simplex is a polyhedron with <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img86.png"
ALT="$(N + 1)$"></SPAN> vertices (or points) in the
<SPAN CLASS="MATH"><IMG
ALIGN="BOTTOM" BORDER="0" SRC="img85.png"
ALT="$N$"></SPAN>-dimensional parameter space. At each step, the simplex moves
through this parameter space according to some rules, basically
moving away from its worst point.
Details of the algorithm can be found in [<A
HREF="UserManual.html#kallr87">17</A>,<A
HREF="UserManual.html#nelder65">22</A>].
<BR>
<P>
For global optimization, an implementation of the 'simulated annealing'
method is provided.
Basically, 'simulated annealing' does a stochastic search of
the parameter space. Replacing the current best point with a better
point (i.e. a downhill step) is always allowed,
replacing it with a worse point (an uphill step) is allowed with some
probability depending on the (steadily decreasing) 'temperature' of the
system.
<BR>The implementation is based on the 'Very Fast Simulated Re-Annealing'
algorithm
[<A
HREF="UserManual.html#ingber">16</A>], however, the 're-annealing' part is not included.
For random number generation, the
'Mersenne Twister' random number generator (period length <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img87.png"
ALT="$2^{19937} - 1$"></SPAN>)
by Makoto Matsumoto and Takuji Nishimura [<A
HREF="UserManual.html#mersenne">21</A>] is used.
It has a Mersenne prime period of <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img87.png"
ALT="$2^{19937} - 1$"></SPAN> (about <SPAN CLASS="MATH"><IMG
ALIGN="BOTTOM" BORDER="0" SRC="img88.png"
ALT="$10^{6000}$"></SPAN>)
and is equi-distributed in 623
dimensions.
Mainly for debugging purposes, the seed is fixed, thus the
generated sequence is always the same, and the results are reproducible.
<P>
<HR>
<P>
<P>
<H2><A NAME="SECTION000120000000000000000">
Bibliography</A>
</H2><DL COMPACT><DD>
<P>
<P></P><DT><A NAME="alenc97">1</A>
<DD>
Alencar S.H.P., Vaz L.P.R. (1997), A&A 326, 257
<P>
<P></P><DT><A NAME="antok96">2</A>
<DD>
Antokhina E.A. (1996), ARep 40, 483
<P>
<P></P><DT><A NAME="brent73">3</A>
<DD>
Brent R. (1973), Algorithms for minimization without derivatives,
Prentice-Hall
<P>
<P></P><DT><A NAME="buddi93">4</A>
<DD>
Budding E. (1993),
An Introduction to Astronomic Photometry,
Cambridge University Press
<P>
<P></P><DT><A NAME="chana72">5</A>
<DD>
Chanan G. A., Middleditch J., Nelson J.E. (1972), ApJ 208, 512
<P>
<P></P><DT><A NAME="claret00a">6</A>
<DD>
Claret A. (2000), A&A 359, 289
<P>
<P></P><DT><A NAME="claret00">7</A>
<DD>
Claret A. (2000), A&A 363, 1081
<P>
<P></P><DT><A NAME="diaz95a">8</A>
<DD>
Diaz-Cordovés J., Claret A., Giménez A. (1995), A&ASS 110, 329
<P>
<P></P><DT><A NAME="diaz95b">9</A>
<DD>
Claret A., Diaz-Cordovés J., Giménez A. (1995), A&ASS 114, 247
<P>
<P></P><DT><A NAME="diaz92">10</A>
<DD>
Diaz-Cordovés J., Giménez A. (1992), A&A 259, 227
<P>
<P></P><DT><A NAME="djura92a">11</A>
<DD>
Djuraševic G. (1992a), Ap&SS 196, 241
<P>
<P></P><DT><A NAME="djura92b">12</A>
<DD>
Djuraševic G. (1992b), Ap&SS 196, 267
<P>
<P></P><DT><A NAME="hendr92">13</A>
<DD>
Hendry, P. D., Mochnacki, S. W. (1992), ApJ 388, 603
<P>
<P></P><DT><A NAME="peter99a">14</A>
<DD>
Hauschildt P.H., Allard F., Baron E. (1999), ApJ 512, 377
<P>
<P></P><DT><A NAME="peter99b">15</A>
<DD>
Hauschildt P.H., Allard F., Ferguson J., Baron E., Alexander D.R. (1999),
ApJ 525, 871
<P>
<P></P><DT><A NAME="ingber">16</A>
<DD>
Ingber L. (1989), J.Math.Comput.Modelling 12, 967
<P>
<P></P><DT><A NAME="kallr87">17</A>
<DD>
Kallrath J., Linnel A.P. (1987), ApJ 313, 346
<P>
<P></P><DT><A NAME="kopal">18</A>
<DD>
Kopal Z. (1989), The Roche Problem,
Kluwer Academic Publishers
<P>
<P></P><DT><A NAME="kuru98">19</A>
<DD>
Kurucz R. L. 1998, http://kurucz.harvard.edu/grids/gridp00/ip00k2.pck19,
accessed 2006-04-12
<P>
<P></P><DT><A NAME="lando82">20</A>
<DD>
Landolt-Boernstein (1982),
Numerical Data and functional Relationships in Science and Technology.
New Series, Berlin: Springer
<P>
<P></P><DT><A NAME="mersenne">21</A>
<DD>
Matsumoto M. & Nishimura T.,
ACM Transactions on Modeling and Computer Simulation, Vol. 8, No. 1, p. 3
<P>
<P></P><DT><A NAME="nelder65">22</A>
<DD>
Nelder J.A., Mead R. (1965), Comput. J. 7, 308
<P>
<P></P><DT><A NAME="vanha93">23</A>
<DD>
Van Hamme W. (1993), AJ 106, 2096
<P>
<P></P><DT><A NAME="wilso90">24</A>
<DD>
Wilson R.E. (1990), ApJ 356, 613
<P>
<P></P><DT><A NAME="young92">25</A>
<DD>
Young A.T. 1992, A&A 257, 366
<P>
</DL>
<P>
<HR>
<P>
<P>
<H1><A NAME="SECTION000130000000000000000">
<SPAN CLASS="arabic">11</SPAN> Command line Options</A>
</H1>
<P>
<TABLE CELLPADDING=3 BORDER="1">
<TR><TD ALIGN="LEFT"> </TD>
<TD ALIGN="LEFT"> </TD>
</TR>
<TR><TD ALIGN="LEFT"><B>Mandatory:</B></TD>
<TD ALIGN="LEFT"> </TD>
</TR>
<TR><TD ALIGN="LEFT">(q)</TD>
<TD ALIGN="LEFT">mass(Secondary)/mass(Primary)</TD>
</TR>
<TR><TD ALIGN="LEFT">(i)</TD>
<TD ALIGN="LEFT">inclination angle (degree)</TD>
</TR>
<TR><TD ALIGN="LEFT">(rf1)</TD>
<TD ALIGN="LEFT">Primary Roche fill factor</TD>
</TR>
<TR><TD ALIGN="LEFT">(rf2)</TD>
<TD ALIGN="LEFT">Secondary Roche fill factor</TD>
</TR>
<TR><TD ALIGN="LEFT">(t1)</TD>
<TD ALIGN="LEFT">Primary temperature</TD>
</TR>
<TR><TD ALIGN="LEFT">(t2)</TD>
<TD ALIGN="LEFT">Secondary temperature</TD>
</TR>
<TR><TD ALIGN="LEFT"> </TD>
<TD ALIGN="LEFT"> </TD>
</TR>
<TR><TD ALIGN="LEFT"><B>Interactive:</B></TD>
<TD ALIGN="LEFT"> </TD>
</TR>
<TR><TD ALIGN="LEFT">-U</TD>
<TD ALIGN="LEFT">Interactive mode</TD>
</TR>
<TR><TD ALIGN="LEFT"> </TD>
<TD ALIGN="LEFT"> </TD>
</TR>
<TR><TD ALIGN="LEFT"><B>Graphic Output:</B></TD>
<TD ALIGN="LEFT"> </TD>
</TR>
<TR><TD ALIGN="LEFT">-A</TD>
<TD ALIGN="LEFT">Animated view</TD>
</TR>
<TR><TD ALIGN="LEFT">-V[v,i,c,a]</TD>
<TD ALIGN="LEFT">Visualize geometry (default: v)</TD>
</TR>
<TR><TD ALIGN="LEFT"> </TD>
<TD ALIGN="LEFT">v: view of stars</TD>
</TR>
<TR><TD ALIGN="LEFT"> </TD>
<TD ALIGN="LEFT">i: image of potential</TD>
</TR>
<TR><TD ALIGN="LEFT"> </TD>
<TD ALIGN="LEFT">c: contourmap of potential</TD>
</TR>
<TR><TD ALIGN="LEFT"> </TD>
<TD ALIGN="LEFT">a: all of the above</TD>
</TR>
<TR><TD ALIGN="LEFT">-G[P,S,1,2]</TD>
<TD ALIGN="LEFT">Graph of lightcurve (default: 1)</TD>
</TR>
<TR><TD ALIGN="LEFT"> </TD>
<TD ALIGN="LEFT">P,S: close-up of Primary/Secondary eclipse</TD>
</TR>
<TR><TD ALIGN="LEFT"> </TD>
<TD ALIGN="LEFT">1,2: display 1/2 orbital cycles</TD>
</TR>
<TR><TD ALIGN="LEFT">-B[U/B/V...]</TD>
<TD ALIGN="LEFT">Bandpass to display in graph (default: V)</TD>
</TR>
<TR><TD ALIGN="LEFT">-H</TD>
<TD ALIGN="LEFT">Hardcopy (postscript plot)</TD>
</TR>
<TR><TD ALIGN="LEFT"> </TD>
<TD ALIGN="LEFT"> </TD>
</TR>
<TR><TD ALIGN="LEFT"><B>Files:</B></TD>
<TD ALIGN="LEFT"> </TD>
</TR>
<TR><TD ALIGN="LEFT">-I datafile</TD>
<TD ALIGN="LEFT">Read in a data file containing observed data</TD>
</TR>
<TR><TD ALIGN="LEFT">-C cfgfile</TD>
<TD ALIGN="LEFT">Read in a configuration file</TD>
</TR>
<TR><TD ALIGN="LEFT"> </TD>
<TD ALIGN="LEFT"> </TD>
</TR>
<TR><TD ALIGN="LEFT"><B>Advanced System Parameters:</B></TD>
<TD ALIGN="LEFT"> </TD>
</TR>
<TR><TD ALIGN="LEFT">-f[P/S] F</TD>
<TD ALIGN="LEFT">asynchroneous rotation ratio (Period/Period_Orbit)</TD>
</TR>
<TR><TD ALIGN="LEFT">-s[P/S] longitude latitude radius dimfactor</TD>
<TD ALIGN="LEFT">Spot on Primary/Secondary</TD>
</TR>
<TR><TD ALIGN="LEFT">-e e w</TD>
<TD ALIGN="LEFT">eccentric orbit, e = eccentricity, w = periastron length</TD>
</TR>
<TR><TD ALIGN="LEFT">-t[P/M/D] value</TD>
<TD ALIGN="LEFT">period/total mass/separation
in days/solar masses/solar radii</TD>
</TR>
<TR><TD ALIGN="LEFT"> </TD>
<TD ALIGN="LEFT"> </TD>
</TR>
<TR><TD ALIGN="LEFT"><B>Debugging Options:</B></TD>
<TD ALIGN="LEFT"> </TD>
</TR>
<TR><TD ALIGN="LEFT">-D[vwb]</TD>
<TD ALIGN="LEFT">Debug [verbose,warn,busy]</TD>
</TR>
<TR><TD ALIGN="LEFT"> </TD>
<TD ALIGN="LEFT"> </TD>
</TR>
<TR><TD ALIGN="LEFT"><B>Computation Options:</B></TD>
<TD ALIGN="LEFT"> </TD>
</TR>
<TR><TD ALIGN="LEFT">-Plamda_zero</TD>
<TD ALIGN="LEFT">Profile of absorption line at
rest wavelength lamda_zero (nm)</TD>
</TR>
<TR><TD ALIGN="LEFT">-Nnn</TD>
<TD ALIGN="LEFT">nn steps for lightcurve (default 80)</TD>
</TR>
<TR><TD ALIGN="LEFT">-M</TD>
<TD ALIGN="LEFT">use Model atmosphere</TD>
</TR>
<TR><TD ALIGN="LEFT">-O[P/S] value</TD>
<TD ALIGN="LEFT"><SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img89.png"
ALT="$\log{g}$"></SPAN> (surface gravity) Primary/Secondary</TD>
</TR>
<TR><TD ALIGN="LEFT">-F</TD>
<TD ALIGN="LEFT">compute Fractional visibility</TD>
</TR>
<TR><TD ALIGN="LEFT">-L[0-2]</TD>
<TD ALIGN="LEFT">Limb darkening method (default: linear = 0)</TD>
</TR>
<TR><TD ALIGN="LEFT"> </TD>
<TD ALIGN="LEFT">0: linear</TD>
</TR>
<TR><TD ALIGN="LEFT"> </TD>
<TD ALIGN="LEFT">1: quadratic</TD>
</TR>
<TR><TD ALIGN="LEFT"> </TD>
<TD ALIGN="LEFT">2: square root</TD>
</TR>
<TR><TD ALIGN="LEFT">-R[1-9]</TD>
<TD ALIGN="LEFT">Reflection treatment</TD>
</TR>
<TR><TD ALIGN="LEFT"> </TD>
<TD ALIGN="LEFT">0: Point source</TD>
</TR>
<TR><TD ALIGN="LEFT"> </TD>
<TD ALIGN="LEFT">1-9: iterations for mutual reflection</TD>
</TR>
<TR><TD ALIGN="LEFT">-a[P/S] value</TD>
<TD ALIGN="LEFT">Albedo of Primary/Secondary</TD>
</TR>
<TR><TD ALIGN="LEFT"> </TD>
<TD ALIGN="LEFT">(default: 0.5 for T <SPAN CLASS="MATH"><IMG
ALIGN="MIDDLE" BORDER="0" SRC="img90.png"
ALT="$<=$"></SPAN> 7700, 1.0 otherwise)</TD>
</TR>
<TR><TD ALIGN="LEFT">-3CM</TD>
<TD ALIGN="LEFT">Third light, C: colour code, M: magnitude</TD>
</TR>
</TABLE>
<TABLE CELLPADDING=3 BORDER="1">
<TR><TD ALIGN="LEFT"> </TD>
<TD ALIGN="LEFT"> </TD>
</TR>
<TR><TD ALIGN="LEFT"><B>Data Fitting:</B></TD>
<TD ALIGN="LEFT"> </TD>
</TR>
<TR><TD ALIGN="LEFT">-X[..] Tolerance</TD>
<TD ALIGN="LEFT">Fit the parameters coded in string [..]</TD>
</TR>
<TR><TD ALIGN="LEFT"> </TD>
<TD ALIGN="LEFT">012345: q, i, rf1, rf2, t1, t2</TD>
</TR>
<TR><TD ALIGN="LEFT"> </TD>
<TD ALIGN="LEFT">67: e, w (eccentric orbit)</TD>
</TR>
<TR><TD ALIGN="LEFT"> </TD>
<TD ALIGN="LEFT">89: F(Primary),F(Secondary) (asynchroneous rotation)</TD>
</TR>
<TR><TD ALIGN="LEFT"> </TD>
<TD ALIGN="LEFT">A-H: 2 Spots (Primary)</TD>
</TR>
<TR><TD ALIGN="LEFT"> </TD>
<TD ALIGN="LEFT">I-P: 2 Spots (Secondary)</TD>
</TR>
<TR><TD ALIGN="LEFT"> </TD>
<TD ALIGN="LEFT">QR: Mass, Separation</TD>
</TR>
<TR><TD ALIGN="LEFT"> </TD>
<TD ALIGN="LEFT">a-l: Third Light (UBVRIJHKuvby)</TD>
</TR>
<TR><TD ALIGN="LEFT"> </TD>
<TD ALIGN="LEFT">(Tolerance = 0.001 to use Simulated Annealing)</TD>
</TR>
<TR><TD ALIGN="LEFT">-Y[as above] Step1 Step2</TD>
<TD ALIGN="LEFT">Chi Square Map (2 Parameters)</TD>
</TR>
</TABLE>
<P>
<P>
<H1><A NAME="SECTION000140000000000000000">
About this document ...</A>
</H1>
<P>
This document was generated using the
<A HREF="http://www.latex2html.org/"><STRONG>LaTeX</STRONG>2<tt>HTML</tt></A> translator Version 2002-2-1 (1.71)
<P>
Copyright © 1993, 1994, 1995, 1996,
<A HREF="http://cbl.leeds.ac.uk/nikos/personal.html">Nikos Drakos</A>,
Computer Based Learning Unit, University of Leeds.
<BR>Copyright © 1997, 1998, 1999,
<A HREF="http://www.maths.mq.edu.au/~ross/">Ross Moore</A>,
Mathematics Department, Macquarie University, Sydney.
<P>
The command line arguments were: <BR>
<STRONG>latex2html</STRONG> <TT>-no_images -split 0 -show_section_numbers -no_navigation -link 2 UserManual.tex</TT>
<P>
The translation was initiated by on 2007-04-11<BR><HR>
<ADDRESS>
2007-04-11
</ADDRESS>
</BODY>
</HTML>
