Merge branch 'master' of https://github.com/teuben/nemo

VERSION

@@ -1 +1 @@
-4.5.0
+4.5.1

docs/source/bench.rst

@@ -5,9 +5,10 @@ Benchmarking
 
 How fast does the N-body treecode run?
 To what degree does optimization/vectorizing help? When do
-programs become I/O dominated? Some of the numbers quoted below should
+programs become I/O dominated? Benchmarking is a black art, and
+some of the numbers quoted below should
 be taken with great care, since a lot of other factors can go into
-the timing result. 
+their timing.
 
 A number of programs in NEMO have a command line parameter such as
 ``nmodel=N``, ``nbench=N`` or ``iter=N`` (N normally set to 1)
@@ -19,6 +20,10 @@ some programas their respective man pages discuss a particular benchmark.
 On the top level we have ``make bench5`` and ``make bench``, the latter
 dynamically controlled with the scattered ``Benchfile``'s
 
+See also
+`bench(5NEMO) <https://teuben.github.io/nemo/man_html/bench.5.html>`_
+for more benchmarks.
+
 
 N-body integration
 ------------------
@@ -110,55 +115,55 @@ part of this no doubt (probably smaller) factor is due to improved compiler tech
      - (linux) software floating point
 
 
-The rubbish below are from the old latex table, TBD which ones make it into the new table
+The rubbish below is from the old latex table::
      
-i7-3630QM @ 3.4 GHz          & 0.000177 & hackcode1 & 2014 laptop \\
-i70-870 @ 2.93 GHz	     & 0.00030 & hackcode1 & 2010 desktop \\
-
-Dec-alpha		     & 0.0042 & hackcode1 & -O4 -fast \\
-Dec-alpha		     & 0.0048 & hackcode1 & default \\
-CRAY X/YMP48                 & 0.0060 & TREECODE V3 & estimate (1989) \\
-Onyx-2			     & 0.0088 & hackcode1 & default (1996) \\
-ETA-10                       & 0.010 & TREECODE V2 & estimate (1987)  \\
-
-Sun 20/62                    & 0.013 & hackcode1 & default (1994) \\
-Cyber 205                    & 0.018 & TREECODE V2 & estimate (1986) \\
-Sun 20/61                    & 0.020 & hackcode1 & \\
-HP/UX 700                    & 0.020 & hackcode1 &  \\
-Sun Ultra-140		     & 0.024 & hackcode1 & default \\
-Sun 20/??		     & 0.024 & hackcode1 & -xO4 -xcg92 -dalign -xlibmil \\
-
-Sun 10/51                    & 0.029 & hackcode1 & -O -fast -fsingle \\
-Cray-2                       & 0.029 & TREECODE2   & REAL - Pitt, oct 91\\
-% SGI ???                      & 0.030 & hackcode1   & John Wangs machine
-DEC DS3000/400 alpha         & 0.036 & hackcode1   & default compilation \\
-Pentium-100                  & 0.038 & hackcode1   & default \\
-SGI Indigo		     & 0.045 & hackcode1   & default compilation \\
-CRAY YMP                     & 0.059 & hackcode1   & default compilation \\
-% bootes:
-Sparc-10                     & 0.063 & hackcode1   & using {\tt acc -cg92} \\
-
-486DX2-66 (linux)            & 0.093 & hackcode1   & -DSINGLEPREC \\
-Sparc-2	                     & 0.099 & gravsim V1  & \\
-IBM R/6000                   & 0.109 & hackcode1   & default cc compiler \\
-Dec 5000/200		     & 0.116 & hackcode1   & \\
-Sparc-2                      & 0.130 & hackcode1   & -DSINGLEPREC -fsingle \\
-Sparc-2                      & 0.180 & hackcode1   & \\
-Multiflow 14/300             & 0.190 & hackcode1   & \\
-Convex C220                  & 0.290 & & \\
-NeXT                         & 0.240 &             & [ganymede 68040, nov 91]\\
-Sparcstation1+               & 0.340 & & \\
-
-Alliant FX??                 & 0.430 & gravsim V1 & \\
-Alliant FX4/w 3 proc's       & 0.590 & & \\
-VAX workstation 3500         & 0.970 & & \\
-Sun-4/60 Sparcstation 1      & 1.040 & treecode2   & cf. C-code @ 0.420 \\
-Sun-3/110                    & 1.660 & hackcode1 & fpa.il \\
-
-
-
-
-Nbody0
+   i7-3630QM @ 3.4 GHz          & 0.000177 & hackcode1 & 2014 laptop \\
+   i70-870 @ 2.93 GHz	        & 0.00030 & hackcode1 & 2010 desktop \\
+
+   Dec-alpha		        & 0.0042 & hackcode1 & -O4 -fast \\
+   Dec-alpha		        & 0.0048 & hackcode1 & default \\
+   CRAY X/YMP48                 & 0.0060 & TREECODE V3 & estimate (1989) \\
+   Onyx-2			& 0.0088 & hackcode1 & default (1996) \\
+   ETA-10                       & 0.010 & TREECODE V2 & estimate (1987)  \\
+
+   Sun 20/62                    & 0.013 & hackcode1 & default (1994) \\
+   Cyber 205                    & 0.018 & TREECODE V2 & estimate (1986) \\
+   Sun 20/61                    & 0.020 & hackcode1 & \\
+   HP/UX 700                    & 0.020 & hackcode1 &  \\
+   Sun Ultra-140		& 0.024 & hackcode1 & default \\
+   Sun 20/??		        & 0.024 & hackcode1 & -xO4 -xcg92 -dalign -xlibmil \\
+
+   Sun 10/51                    & 0.029 & hackcode1 & -O -fast -fsingle \\
+   Cray-2                       & 0.029 & TREECODE2   & REAL - Pitt, oct 91\\
+   % SGI ???                    & 0.030 & hackcode1   & John Wangs machine
+   DEC DS3000/400 alpha         & 0.036 & hackcode1   & default compilation \\
+   Pentium-100                  & 0.038 & hackcode1   & default \\
+   SGI Indigo		        & 0.045 & hackcode1   & default compilation \\
+   CRAY YMP                     & 0.059 & hackcode1   & default compilation \\
+   % bootes:
+   Sparc-10                     & 0.063 & hackcode1   & using {\tt acc -cg92} \\
+
+   486DX2-66 (linux)            & 0.093 & hackcode1   & -DSINGLEPREC \\
+   Sparc-2	                & 0.099 & gravsim V1  & \\
+   IBM R/6000                   & 0.109 & hackcode1   & default cc compiler \\
+   Dec 5000/200		        & 0.116 & hackcode1   & \\
+   Sparc-2                      & 0.130 & hackcode1   & -DSINGLEPREC -fsingle \\
+   Sparc-2                      & 0.180 & hackcode1   & \\
+   Multiflow 14/300             & 0.190 & hackcode1   & \\
+   Convex C220                  & 0.290 & & \\
+   NeXT                         & 0.240 &             & [ganymede 68040, nov 91]\\
+   Sparcstation1+               & 0.340 & & \\
+
+   Alliant FX??                 & 0.430 & gravsim V1 & \\
+   Alliant FX4/w 3 proc's       & 0.590 & & \\
+   VAX workstation 3500         & 0.970 & & \\
+   Sun-4/60 Sparcstation 1      & 1.040 & treecode2   & cf. C-code @ 0.420 \\
+   Sun-3/110                    & 1.660 & hackcode1 & fpa.il \\
+
+
+
+
+nbody0
 ~~~~~~
 
 The program is Aarseth's simplest
@@ -187,26 +192,56 @@ It seems the input data have been lost.
      -
      - 1302
      - 0.65
+   * - Sparc 1
+     -
+     - 1023
+     - 0.83
+   * - Sparc IPC(Courage - 16 Mb)
+     - 9,015
+     - 850
+     - 1.000
+   * - Sparc 2
+     - 4,483
+     -
+     - 2.01
+   * - Sparc 2'	
+     -
+     - 417
+     - 2.04
 
-Sparc 1			&		& 1023	&	0.83 \\
-
-Sparc IPC(Courage - 16 Mb) &	9,015	&	  850	&	1.000 \\
-
-Sparc 2 	&	4,483	&		&	2.01 \\
-
-Sparc 2'	&		&	  417	&	2.04 \\
-
-Dec 5000/200 	&		&	  318	&	2.67 \\
+   * - Dec 5000/200
+     -
+     - 318
+     - 2.67
 
-Stardent(ism)	&		&	  211 	&	4.03 \\
+   * - Stardent(ism)
+     -
+     - 211
+     - 4.03
 
-IBM Risc (Juno)	&	2,117	&	  198	&	4.27 \\
+   * - IBM Risc (Juno)
+     - 2,117
+     - 198
+     - 4.27
 
-IBM Risc (wibm01)&	2,115	&		&	4.26 \\
-Convex		&		&	  172 	&	4.94 \\
-HP/UX 700     &                  &     26.2   &     \\
+   * - IBM Risc (wibm01)
+     - 2,115
+     -
+     - 4.26
+   * - Convex
+     -
+     - 172 
+     - 4.94
+   * - HP/UX 700
+     -
+     - 26.2 
+     -
+
+   * - Cray YMP	
+     -
+     - 19.1
+     - 44.5
 
-Cray YMP	&		&	  19.1	&	44.5
 
 
 Orbit integration

docs/source/glossary.rst

@@ -6,10 +6,10 @@ Glossary
 .. glossary::
 
 
-  accelleration
+  acceleration
       Dataformat used in the :term:`falcon` package. Related to the
       :term:`potential` in NEMO, except one can use multiple
-      accelleration descriptors, normally separated by a semi-colon.
+      acceleration descriptors, normally separated by a semi-colon.
 
   bodytrans
       Dataformat (normally a C function) that is used to
@@ -87,7 +87,7 @@ Glossary
       Dataformat in NEMO used to represent a
       potential; most programs in NEMO which handle potentials start
       or end with *pot*, for example ``potlist``.
-      Related to the :term:`accelleration`
+      Related to the :term:`acceleration`
 
   program keyword
       Keywords that are defined by the

docs/source/graphics.rst

@@ -11,32 +11,34 @@ NEMO programs also need to display their data of course.
 Here we will make a distinction between *graphics* and *image* data.
 A simple but flexible *graphics* interface has been defined in NEMO and is used
 extensively in programs that need such output.  These are controlled by
-the user via the ``yapp=`` (system) keyword.
+the user via the ``yapp=`` :ref:`system_keywords`.
 
-To display *image* data we rely mostly (but see *ccdplot(1NEMO)* for an exception)
+To display *image* data we rely mostly (but see
+`ccdplot(1NEMO) <https://teuben.github.io/nemo/man_html/ccdplot.1.html>`_
+for an exception)
 on external software.
 Often images would need to be copied to a FITS file for this
-(but see ``nds9`` for an example that can use NEMO's image format).
-
+(but see ``nds9`` for an example that can use NEMO's image format), and
+use 3rd party programs such as *ds9*.
 
 The YAPP graphics interface
 ---------------------------
 
 The programs in NEMO which use *graphics* are rather simple and generally allow no
-interactive processing, except perhaps for a simple 'hit-the-return-key'
-or 'push-a-mouse-button' between successive plots or actions.  A very
+interactive processing, except perhaps for a simple 'hit-the-Enter-key'
+or 'click-a-mouse-button' between successive plots or actions.  A very
 simple interface (API) was defined (**yapp**, Yet Another Plotting Package)
 with basic plot functions.  
 There are currently a few yapp implementations
-available, such as a postscript-only device, and pgplot.  
+available, with a postscript-only device, and pgplot the most common ones.
 If your output device is not supported by the ones available
 in the current yapp directory
 (``$NEMO/src/kernel/yapp``), you may have to write a new one!
 A reasonably experienced programmer writes a functional yapp-interface in
 an hour or so.
 
 Although this method results in a flexible graphics interface, a
-program can currently only be linked with one yapp-interface, which
+program can currently only be linked with one yapp-interface at a time, which
 is selected at NEMO's installation time via the **configure** script.
 This might
 result in the existence of more than one version of the same
@@ -48,23 +50,30 @@ screen,
 Hence we may see program names such as {\tt snapplot} (the default),
 ``snapplot_ps`` (postscript), or
 ``snapplot_cg`` (color Sun screen when this was popular) .
-Again: actual names may differ on your system.
+Again: actual names may differ on your system, and it may never be used.
 
 If programs are linked with the multiplexing libraries
 *yapp_pgplot* interface, several device drivers are transparently present through
 pgplot, and the system keyword ``yapp=`` is then used to select
 a device (a default can be set by using the **YAPP** environment
 variable). 
-See also the :ref:`iface` chapter
-or the
-`yapp <https://teuben.github.io/nemo/man_html/yapp.5.html>`_
+See also the
+:ref:`iface`
+chapter or the
+`yapp(5NEMO) <https://teuben.github.io/nemo/man_html/yapp.5.html>`_
 manual page.
 
 However, despite these grim sounding words, we currently
 almost exclusively use the PGPLOT implementation of yapp, which is very flexible.
 You will need to have pgplot installed on your system, which is another story
 in itself.
 
+.. note::
+   The command ``mknemo pgplot`` may work if you cannot find a system package installer.
+   This will install PGPLOT system files in ``$NEMOLIB``.  
+
+
+
 pyplot=: python matplotlib
 --------------------------
 
@@ -81,20 +90,28 @@ General Graphics Display
 Another convenient way to present data in graphical form is by using
 the table format. We have already encountered the *tables* created by
 many NEMO programs. These tables can be used by NEMO programs
-such as *tabplot(1NEMO)*, *tabhist(1NEMO)*, and other packages
+such as
+`tabplot(1NEMO) <https://teuben.github.io/nemo/man_html/tabplot.1.html>`_
+and 
+`tabhist(1NEMO) <https://teuben.github.io/nemo/man_html/tabhist.1.html>`_, 
+and other packages
 such as
 *gnuplot*,
 *xgobi*,
 *xmgrace*, 
-*xgraphic*, and
-*glueviz*.
+*xgraphic*, 
+*glueviz*, and
+*topcat*.
 
 
 Image Display Interface
 -----------------------
 
-Data in *image(5NEMO)* format can be transferred in
-*fits(5NEMO)* format and subsequently displayed and analyzed within
+Data in 
+`image(5NEMO) <https://teuben.github.io/nemo/man_html/image.5.html>`_
+format can be transferred in
+`fits(5NEMO) <https://teuben.github.io/nemo/man_html/fits.5.html>`_
+format and subsequently displayed and analyzed within
 almost any astronomical image processing system.  They are generally much
 better equipped to display and manipulate data of this kind of format. 
 A number of standalone display programs can also understand FITS

docs/source/iface.rst

@@ -243,6 +243,8 @@ are both equivalent.
 .. A third interesting shortcut is something new and introduced in version 3.2,
    which allows keyword references using the \% symbol to cut accross programs.
 
+.. _system_keywords:
+
 System Keywords
 ~~~~~~~~~~~~~~~
 

docs/source/potname.rst

@@ -1,5 +1,5 @@
-Potentials and Accellerations
-=============================
+Potentials and Accelerations
+============================
 
 Here we lists a number of potentials, taken from
 from CTEX comments in the
@@ -31,8 +31,8 @@ Mostly **G=1**, unless otherwise mentioned.
 
 .. include:: potctex.rst
 
-Accellerations
---------------
+Accelerations
+-------------
 
 This is a falcON addition. They are defined in ``$FALCON/src/public/acc``,
 where their list (for installation) is defined in ``$FALCON/makepub``.