This HTML automatically generated with rman for NEMO
Table of Contents

Name

nemo, astronemo - outline the NEMO package

Description

nemo is a computer package, there is no program with that name. On linux there is the nemo file manager, which is a fork of nautilus.

astronemo is the name you may find in some package managers. If you google the name nemo, you will find a lot of computer related tools with that name. We also adopted this name in https://astronemo.readthedocs.io.

NEMO is a Stellar Dynamics Toolbox for users and programmers. It has various programs to create, integrate and analyze N-body systems. In addition there are various tools to operate on images, tables and orbits, including FITS files to export/import to/from other astronomical data reduction packages.

A good start is the manual page programs(8NEMO) , which lists programs thematically, and index(1NEMO) , which lists them alphabetically (CAVEAT: these pages are not well maintained).

NEMO vs. UNIX

NEMO is very much modeled after the Unix(tm) operating system, so users are expected to use standard Unix commands as glue between the various tasks (cat, ls, rm, cp, awk, sm, etc.). Understanding of shell scripting (sh, csh, python, perl, etc.) can be very useful. for NEMO as well. Several example shell scripts exist in the source tree to demonstrate how experiments can be orchestrated. We use mostly csh, bash and python. Yes, csh too, even though csh is considered harmful now.

Here are some useful reminders of using NEMO when you are familiar with the unix style of command line tools, piping etc.:


- programs use a set of key=value command line arguments,
  minimum match works, but you cannot repeat keywords
    * the --help or help=h are ways to get inline help from a program
      and remind you of the keyword names
    * keyword values can be math expressions (see nemoinp(1NEMO))
    * the UNIX man(1) command will get offline help
- NEMO can use pipes efficiently:
    * The UNIX stdin and stdout are represented with a dash (-),
      so using pipes can become a little awkward
    * The UNIX /dev/null is represented with a dot (.),
      like a black hole sucking up everything

Man Pages

You are reading a man page, and since NEMO is using standard unix man pages, the man command has a lot of powerful ways to find the information (short of using grep on the 800+ $NEMO/man/manX/*.* files):

apropos keyword
man -M $NEMO/man -k .
man -f keyword also: program help=u
man --regex <pattern> man --regex ".*network$"
man -S <section_ID> <keyword>
man -wK <keyword>

Synopsis


program --help
program --man
program help=h
program [key1=]val1 [key2=]val2 .!.!.
runprogram [key1=]val1 [key2=]val2 .!.!.
run program ...

Getting Started

What you need to do to set yourself up for NEMO:

The easiest way is to add the appropriate line to your .cshrc or .bashrc file, but you need to know the root directory where NEMO is installed. For example

source /opt/nemo/nemo_start.sh

or for (t)csh users we still have

source /opt/nemo/nemo_start.csh

If you need more control over your NEMO environment, there are other methods described elsewhere (The NEMO Users/Programmers Guide, Appendix A), or consult one of your local friendly NEMO users.

For systems where this is supported, the module(1) command may be able to load nemo, e.g.

module load nemo
module load nemo/4.2.1

How to Run Nemo Programs

NEMO programs can be run just as any other command in Unix, in that sense NEMO is nothing more than an extension of Unix. NEMO programs usually read and/or write files, though these files can in most circumstances be replaced with a dash to designate a unix pipe, e.g.

mkplummer - 10 | snapprint -

this would be identical to the two liner

mkplummer out=p10.snap nbody=10
snapprint in=p10.snap

NEMO programs all work by using a series of keyword=value pairs on the commandline. If the order of the supplied keywords is the same as the program expects them, the keyword= part can be omitted, simply to save some keystrokes. There is a consistent ordering of keywords in most programs that allows experienced users to use such (and other) shortcuts. Python uses the same principle with the un-named arguments. (e.g. in= the first one, out= the second one etc.). Keywords can be used in minimum match, but this is not recommended for shell scripts. To make shell scripts robust, it is recommended you add the keyword= part for all but the first one or two.

NEMO programs make a distinction between program keywords (keywords unique to a program) and system keywords (a fixed set of keywords that each NEMO program understands). The system keywords that you are likely to use are help= and yapp=, and to a lesser degree debug= and error=. The help= gives various types of inline aid from a program. There is also online help on a program, for which unix man(1) command (or any of it’s derived friends) is normally used. The yapp= sets the graphics device used by programs who use a graphics device. Your nemo_start environment may have given you a default. YAPP=/xs is a common default if the yapp_pgplot interface is used.

Each system keyword can be defaulted by setting it’s equivalent environment variable (in upper case!). Program keywords can be abbreviated to uniqueness.

Examples: Consider the program mkplummer, a program which creates an N-body realization of a Plummer sphere. To get online help, one types (we included three legacy program options, --man, --help, --version):

man mkplummer
mkplummer --man
   
and to get various types of inline help:

mkplummer --help
mkplummer -h
mkplummer help=
mkplummer help=h
mkplummer help=’?’
   
and to get the version:

mkplummer help=V
mkplummer --version
   
Note the literal quotes around the question-mark needed if you use a regular Unix shell as interface. The first help= reminds you of the order of the program keywords and their default values. The second form, help=h prints out a small one-line reminder what each keyword means. The last form help=’?’ lists various options the user interface understands, this one is not program dependant.

If you chain NEMO programs, pipes can be a very efficient way to stream data and/or prevent large amounts of disk access. Most keywords that operate on files (notably in=, out=, as long as stropen(3NEMO) is used) can use standard piped I/O by using the dash (-) to name the keyword, e.g.

mkplummer - 10 | snapprint -

would create a snapshot of 10 bodies on the fly, and print positions and velocities to the user using snapprint. The alternative would have been

mkplummer out=tmp nbody=10
snapprint in=tmp
rm tmp

HOW TO RUN non-NEMO PROGRAMS

Over the times NEMO has incoorporated a number of non-NEMO programs, with varying degrees of input parameter schemes. Some via parameter files, some interactive input, some a command line interface alien to NEMO. For a number of them a unified NEMO frontend was developed, usually those programs start with the prefix run. For example, bulgerot comes with runbulgerot. Since often such programs have a hardcoded name for input and/or output files, one simple way to be able to run them in parallel without stepping on filenames, is the use of a clean run directory. Example of this can be found in runbulgerot(1NEMO) , runbody1(1NEMO) , rungalaxy(1NEMO) , runscfm(1NEMO) , runqumond(1NEMO) , and some others.

You will find a few common user keywords for this: outdir= is always a required keyword, and needs to be a non-existing directory in which the data is written. For some programs there is an exe= keyword, in order to change the name of the non-NEMO program to be run. This is always assumed to be in the standard Unix search path ($PATH).

Although these run* programs use a fairly common method to run the non-NEMO programs, they have not all been unified as is proposed in run(3NEMO) .

HELP on GIPSY and MIRIAD

Some NEMO programs refer to non-NEMO programs in the "man" style. For example ccdpot(1NEMO) refers to potential(GIPSY) and potfft(MIRIAD). If those packages are in your shell environment, the following commands should give their version of the online help:

man -l $MIRDOC/man/man1/potfft.1
more $gip_root/tsk/potential.dc1

Programming

You may need to do some sherlocking here. You have probably seen the $NEMO/configure.ac and $NEMO/makedefs file, though the $NEMOLIB/makedefs is the active file. This is where you can hack to fix compilation errors. The mknemo(8NEMO) script will help you (re)compile programs, though sometimes bake(8NEMO) can do a better job in a local directory.

See Also

index(1NEMO) , programs(8NEMO) , tricks(8NEMO) , mkplummer(1NEMO) , files(8NEMO) , nemoinp(1NEMO) , stropen(3NEMO) , getparam(3NEMO) , run(1NEMO) , run(3NEMO) , mknemo(8NEMO) , mkman(8NEMO) , template(8NEMO) , history(8NEMO) , pipestatus(l)


https://www.unix.com/man-page-repository.php - Man Page Repository
https://man7.org/linux/man-pages/man1/man.1.html - The Linux man-pages project

Author

Peter Teuben

Further Information

The NEMO Users/Programmers Guide contains most of the information you need to get down to the guts of the system.

Various man(1NEMO) pages explain programs(1) , subroutine libraries(3) file formats(5) and system management(8) .

NEMO homepage http://www.astro.umd.edu/nemo and github page https://github.com/teuben/nemo.

readthedocs page: https://astronemo.readthedocs.io/en/latest/ (this replaced the old latex manual)

Other introductions

Workshop on N-body simulations:  \
http://paginapessoal.utfpr.edu.br/rubensmachado/outros-1/simulacoes-de-n-corpos/NbodyTutorial.pdf

Caveats

Since programs are being modified, and extended fairly regularly, manual pages for related programs do not always know about these changes if they should. Keeping good cross references in the manual pages might help. However, the help= description should always be up to date, since it is derived from the code itself. See also checkpars(8NEMO) . And there

is always https://github.com/teuben/nemo/issues

History


1986    V1 Initial Development    Barnes/Hut/Teuben
1994    V2 UMD release    Teuben
2001    V3 UMD release using CVS    Teuben
2017    V4 UMD release using git    Teuben


Table of Contents