Compiling And Running GAMESS-US (1 May 2013(R1)) On 64-bit Ubuntu 12.X/13.X In SMP Mode

Author’s Note 1: It is my standard policy to put too much info into guides so that those who are searching for specific problems they come across will find the offending text in their searches. With luck, your “build error” search sent you here.

Author’s Note 2: It’s not as bad as it looks (I’ve included lots of output and error messages for easy searching)!

Author’s Note 3: I won’t be much help for you in diagnosing your errors, but am happy to tweak the text below if something is unclear.

Conventions: I include both the commands you type in your Terminal and some of the output from these commands, the output being where most of the errors appear that I work on in the discussion.

Input is formatted as below:

username – your username (check your prompt)
machinename – your hostname (type hostname or check your prompt)

Text you put in at the (also shown, so you see the directory structure) prompt (copy + paste should be fine)

Text you get out (for checking results and reproducing errors)

Having just recently downloaded the newest version of GAMESS-US (R1 2013), my first few passes at using it under Linux (specifically, Ubuntu 12.04) ran into a few walls that required some straightforward modifications and a little bit of system prep planning. As my first few passes before successful execution are likely the same exact problems you might have run into in your attempts to get GAMESS-US to run (after a successful compilation and linking), I’m posting my problems and solutions here.

Qualifier 1 – My concern at the moment has been to get GAMESS-US to run under 64-bit Ubuntu 12.04 on a multi-core board (ye olde symmetric multiprocessing (which I always called single multi-processor, or SMP)). While some answers may follow in what’s below, this post doesn’t cover MPI-specific builds (nothing through a router, that is). SMP is the only concern (which is to say, I likely won’t have good answers if you send along an MPI-specific question). Also, although I’m VERY interested in trying it, I’ve not yet attempted to build a GPU-capable version (but plan to in the near future).

Qualifier 2 – It is my standard policy to install apps into /opt, and my steps below will reflect that (specifically because there’s a permission issue that needs to be addressed when you first try to build components). You can default to whatever you like, but keep in mind my tweaks when you try to build your local copy.

So, with the qualifiers in mind…

1. Prepping The System (apt-get)

There are few things better than being able to apt-get everything you need to prep your machine for an install, and I’m pleased to report that the (current) process for putting the important files onto Ubuntu 12.X/13.X is easy. Assuming you’re not going the Intel / PGI / MKL route, you can do everything by installing gfortran (compiler, presently installing 4.4) and the blas and atlas math libraries.

username@machinename:~$ sudo apt-get install gfortran libblas-dev libatlas-base-dev

Note: your atlas libraries will be installed in /usr/lib64/atlas/ – this will matter when you run config.

After these finish, run the following to determine your installed gfortran version (will be asked for by the new GAMESS config)

username@machinename:~$ gfortran -dumpversion

GNU Fortran (Ubuntu 4.4.3-4ubuntu5.1) 4.4.3
Copyright (C) 2010 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

4.4 And you’re ready for GAMESS.

2. Downloading GAMESS-US, Placing Into /opt, And Changing Permissions

First, obviously, get the GAMESS source (click on the red text).

After downloading, copy/move gamess-current.tar.gz into /opt

username@machinename:~$ cd ~/Downloads
username@machinename:~/Downloads$ sudo cp gamess-current.tar.gz /opt
username@machinename:~/Downloads$ cd /opt
username@machinename:/opt$ sudo gunzip gamess-cuerent.tar.gz
username@machinename:/opt$ sudo tar xvd gamess-current.tar



At this point, if you go through the config process and get to the point of building ddikick.x, you will get an error when you first try to run ./compddi

username@machinename:/opt/gamess/ddi$ sudo ./compddi >& compddi.log &

[1] 4622
-bash: compddi.log: Permission denied

The problem is with the permission of the entire gamess folder:

drwxr-xr-x  4 root        root              4096 2014-04-04 21:43 .
drwxr-xr-x 22 root        root              4096 2013-12-27 16:17 ..
drwxr-xr-x 14 1300 504              4096 2014-04-04 21:43 gamess
-rw-r–r– 1 root        root         198481920 2014-04-04 21:42 gamess-current.tar

Which you remedy before running into this error by changing the permissions:

username@machinename:/opt$ sudo chown -R username gamess

The next step is recommended when you run config, so I’m performing the step here to get it out of the way. With the atlas libraries installed, generate two symbolic links.

username@machinename:/opt$ cd /usr/lib64/atlas
username@machinename:/usr/lib64/atlas$ sudo ln -s
username@machinename:/usr/lib64/atlas$ sudo ln -s

And, at this point, you’re ready to run the new (well, new to me) config script that preps your system install.

3. Building GAMESS-US

Back to the GAMESS-US folder.

username@machinename:/usr/lib64/atlas$ cd /opt/gamess
username@machinename:/opt/gamess$ sudo ./config

This script asks a few questions, depending on your computer system,
to set up compiler names, libraries, message passing libraries,
and so forth.

You can quit at any time by pressing control-C, and then .

Please open a second window by logging into your target machine,
in case this script asks you to ‘type’ a command to learn something
about your system software situation. All such extra questions will
use the word ‘type’ to indicate it is a command for the other window.

After the new window is open, please hit to go on.

You can open that second window or blindly assume that what I include below is all you need.


GAMESS can compile on the following 32 bit or 64 bit machines:
axp64 – Alpha chip, native compiler, running Tru64 or Linux
cray-xt – Cray’s massively parallel system, running CNL
hpux32 – HP PA-RISC chips (old models only), running HP-UX
hpux64 – HP Intel or PA-RISC chips, running HP-UX
ibm32 – IBM (old models only), running AIX
ibm64 – IBM, Power3 chip or newer, running AIX or Linux
ibm64-sp – IBM SP parallel system, running AIX
ibm-bg – IBM Blue Gene (P or L model), these are 32 bit systems
linux32 – Linux (any 32 bit distribution), for x86 (old systems only)
linux64 – Linux (any 64 bit distribution), for x86_64 or ia64 chips
AMD/Intel chip Linux machines are sold by many companies
mac32 – Apple Mac, any chip, running OS X 10.4 or older
mac64 – Apple Mac, any chip, running OS X 10.5 or newer
sgi32 – Silicon Graphics Inc., MIPS chip only, running Irix
sgi64 – Silicon Graphics Inc., MIPS chip only, running Irix
sun32 – Sun ultraSPARC chips (old models only), running Solaris
sun64 – Sun ultraSPARC or Opteron chips, running Solaris
win32 – Windows 32-bit (Windows XP, Vista, 7, Compute Cluster, HPC Edition)
win64 – Windows 64-bit (Windows XP, Vista, 7, Compute Cluster, HPC Edition)
winazure – Windows Azure Cloud Platform running Windows 64-bit
type ‘uname -a’ to partially clarify your computer’s flavor.
please enter your target machine name:

We’re doing a linux64 build, so type the following at the prompt:


Where is the GAMESS software on your system?
A typical response might be /u1/mike/gamess,
most probably the correct answer is /opt/gamess

GAMESS directory? [/opt/gamess]

Who is this mike and where is my folder u1? We’ll get to that in rungms. For now, I’m installing in /opt, so the default directory is fine:


Setting up GAMESS compile and link for GMS_TARGET=linux64
GAMESS software is located at GMS_PATH=/opt/gamess

Please provide the name of the build locaation.
This may be the same location as the GAMESS directory.

GAMESS build directory? [/opt/gamess]

Fine as selected.


Please provide a version number for the GAMESS executable.
This will be used as the middle part of the binary’s name,
for example: gamess.00.x

Version? [00]

Is this important? Maybe, if you plan on building multiple versions of GAMESS-US (you might want a GPU-friendly version, one with a different compiler, one with MPI, etc.). Number as you wish and remember the number when it comes to rungms. That said, the actual linking step seems to really want to produce a 01 version (we’ll get to that). Meantime, default value is fine.


Linux offers many choices for FORTRAN compilers, including the GNU
compiler set (‘g77’ in old versions of Linux, or ‘gfortran’ in
current versions), which are included for free in Unix distributions.

There are also commercial compilers, namely Intel’s ‘ifort’,
Portland Group’s ‘pgfortran’, and Pathscale’s ‘pathf90’. The last
two are not common, and aren’t as well tested as the others.

type ‘rpm -aq | grep gcc’ to check on all GNU compilers, including gcc
type ‘which gfortran’ to look for GNU’s gfortran (a very good choice),
type ‘which g77’ to look for GNU’s g77,
type ‘which ifort’ to look for Intel’s compiler,
type ‘which pgfortran’ to look for Portland Group’s compiler,
type ‘which pathf90’ to look for Pathscale’s compiler.
Please enter your choice of FORTRAN:

We’re using gfortran (currently 4.4.3):


gfortran is very robust, so this is a wise choice.

Please type ‘gfortran -dumpversion’ or else ‘gfortran -v’ to
detect the version number of your gfortran.
This reply should be a string with at least two decimal points,
such as 4.1.2 or 4.6.1, or maybe even 4.4.2-12.
The reply may be labeled as a ‘gcc’ version,
but it is really your gfortran version.
Please enter only the first decimal place, such as 4.1 or 4.6:


Alas, your version of gfortran does not support REAL*16,
so relativistic integrals cannot use quadruple precision.
Other than this, everything will work properly.
hit to continue to the math library setup.

If this was my biggest concern I’d be a happy quantum chemist. Obviously you can try to install other flavors of gfortran and, possibly, by the time you need the procedure I’m following, a newer version of gfortran will be apt-gotten.


Linux distributions do not include a standard math library.

There are several reasonable add-on library choices,
MKL from Intel for 32 or 64 bit Linux (very fast)
ACML from AMD for 32 or 64 bit Linux (free)
ATLAS from for 32 or 64 bit Linux (free)
and one very unreasonable option, namely ‘none’, which will use
some slow FORTRAN routines supplied with GAMESS. Choosing ‘none’
will run MP2 jobs 2x slower, or CCSD(T) jobs 5x slower.

Some typical places (but not the only ones) to find math libraries are
Type ‘ls /opt/intel/mkl’ to look for MKL
Type ‘ls /opt/intel/Compiler/mkl’ to look for MKL
Type ‘ls /opt/intel/composerxe/mkl’ to look for MKL
Type ‘ls -d /opt/acml*’ to look for ACML
Type ‘ls -d /usr/local/acml*’ to look for ACML
Type ‘ls /usr/lib64/atlas’ to look for Atlas

Enter your choice of ‘mkl’ or ‘atlas’ or ‘acml’ or ‘none’:


Where is your Atlas math library installed? A likely place is
Please enter the Atlas subdirectory on your system:

Our location is, in fact, /usr/lib64/atlas, so we type it in accordingly.

NOTE: If you don’t type anything but [enter] below, the script closes (/usr/lib64/atlas is listed as the expected location, but it is not defaulted by the script. You need to type it in.


The linking step in GAMESS assumes that a softlink exists
within the system’s /usr/lib64/atlas
from to a specific file like
from to a specific file like
config can carry on for the moment, but the ‘root’ user should
chdir /usr/lib64/atlas
ln -s
ln -s
prior to the linking of GAMESS to a binary executable.

Math library ‘atlas’ will be taken from /usr/lib64/atlas

please hit to compile the GAMESS source code activator

The symbolic linking was performed before the GAMESS steps.


gfortran -o /home/username/gamess/tools/actvte.x actvte.f
unset echo
Source code activator was successfully compiled.

please hit to set up your network for Linux clusters.


If you have a slow network, like Gigabit Ethernet (GE), or
if you have so few nodes you won’t run extensively in parallel, or
if you have no MPI library installed, or
if you want a fail-safe compile/link and easy execution,
choose ‘sockets’
to use good old reliable standard TCP/IP networking.

If you have an expensive but fast network like Infiniband (IB), and
if you have an MPI library correctly installed,
choose ‘mpi’.

communication library (‘sockets’ or ‘mpi’)?

Again, I’m not building an mpi-friendly version, so am using sockets.


64 bit Linux builds can attach a special LIBCCHEM code for fast
MP2 and CCSD(T) runs. The LIBCCHEM code can utilize nVIDIA GPUs,
through the CUDA libraries, if GPUs are available.
Usage of LIBCCHEM requires installation of HDF5 I/O software as well.
GAMESS+LIBCCHEM binaries are unable to run most of GAMESS computations,
and are a bit harder to create due to the additional CUDA/HDF5 software.
Therefore, the first time you run ‘config’, the best answer is ‘no’!
If you decide to try LIBCCHEM later, just run this ‘config’ again.

Do you want to try LIBCCHEM? (yes/no):


Your configuration for GAMESS compilation is now in
Now, please follow the directions in

At this stage, you’re ready to build ddikick.x and continue with the compiling.

4. Build ddikick.x

username@machinename:/opt/gamess$ cd ddi
username@machinename:/opt/gamess/ddi$ sudo ./compddi >& compddi.log &

Will dump output into compddi.log (which will now work with the correct permissions).

username@machinename:/opt/gamess/ddi$ sudo mv ddikick.x ..
username@machinename:/opt/gamess/ddi$ cd ..
username@machinename:/opt/gamess$ sudo ./compall >& compall.log &

Feel free to follow along as compall.log dumps results. You’re also welcome to follow the readme.unix advice:

This takes a while, so go for coffee, or check the SF Giants web page.

Upon completion, the last step is to link the executable.

Now, it used to be the case that you specified the version number in the lked step. So, if you wanted to stick with the 00 version from the config file, you’d type

username@machinename:/opt/gamess$ sudo ./lked gamess 00 >& lked.log &

When you do that at present, you get

[1] 7626

[1]+ Stopped sudo ./lked gamess 00 &>lked.log

This then leads you to use the lked call from the readme.unix file.

username@machinename:/opt/gamess$ sudo ./lked gamess 01 >& lked.log &

Which then produces lked.log and gamess.01.x.

Now, if you run with 00 again, you get a successful linking of gamess.00.x . Not sure why this happens, but the version number isn’t important so long as you specify the right one when you use rungms (so I’ve not diagnosed it further).

At this point, you have a gamess.00.x and/or gamess.01.x executable in your /opt/gamess folder:

30828747 2014-04-04 22:41 gamess.01.x

I’m going to ignore the 00 issue out of the config file and use the gamess.01.x executable.

We’re ready to run calculations and work through the next set of errors you’ll receive if you don’t properly modify files.

5. PATH Setting

First, we copy rungms to our home folder, then add /opt/gamess to the PATH:

username@machinename:/opt/gamess$ cp rungms ~/
username@machinename:/opt/gamess$ cd ~/
username@machinename:~$ nano .bashrc

Add the following to the bottom of .bashrc (or extend your PATH)


Quit nano and source.

username@machinename:~$ source .bashrc
[OPTIONAL] username@machinename:~$ echo $PATH


6. rungms (Probably Why You’re Here)

If you just go blindly into a run, you’ll get the following error:

username@machinename:~$ ./rungms test.inp

—– GAMESS execution script ‘rungms’ —–
This job is running on host machinename
under operating system Linux at Fri Apr 4 22:47:55 EDT 2014
Available scratch disk space (Kbyte units) at beginning of the job is
df: `/scr/username’: No such file or directory
df: no file systems processed
GAMESS temporary binary files will be written to /scr/username
GAMESS supplementary output files will be written to /home/username/scr
Copying input file test.inp to your run’s scratch directory…
cp test.inp /scr/username/test.F05
cp: cannot create regular file `/scr/username/test.F05′: No such file or directory
unset echo
/u1/mike/gamess/gms-files.csh: No such file or directory.

As is obvious, rungms needs some modifying.

username@machinename:~$ nano rungms

Scroll down until you see the following:

set TARGET=sockets
set SCR=/scr/$USER
set USERSCR=~$USER/scr
set GMSPATH=/u1/mike/gamess

Given that it’s just me on the machine, I tend to simplify this by making SCR and USERSCR the same directory, and I make them both /tmp. If you intend on keeping all of the files, you’ll need to make rungms specific for each run case. My only concerns are .dat and .log, so /tmp dumping is fine. Furthermore, we must change GMSPATH from how the ever-helpful Mike Schmidt (he got me through some early issues when I started my GAMESS-US adventure 15ish years ago. Won’t complain about his continued default-ed presence in the scripts) has it set up at Iowa to how we want it on our own machines (in my case, /opt/gamess)

set TARGET=sockets
set SCR=/tmp
set USERSCR=/tmp
set GMSPATH=/opt/gamess

With these modifications, your next run will be a bit more successful:

username@machinename:~$ ./rungms test.inp

—– GAMESS execution script ‘rungms’ —–
This job is running on host machinename
under operating system Linux at Fri Apr 4 22:51:35 EDT 2014
Available scratch disk space (Kbyte units) at beginning of the job is
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 1905222596 249225412 1559217460 14% /
GAMESS temporary binary files will be written to /tmp
GAMESS supplementary output files will be written to /tmp
Copying input file test.inp to your run’s scratch directory…
cp test.inp /tmp/test.F05
unset echo
/opt/gamess/ddikick.x /opt/gamess/gamess.00.x test -ddi 1 1 machinename -scr /tmp

Distributed Data Interface kickoff program.
Initiating 1 compute processes on 1 nodes to run the following command:
/opt/gamess/gamess.00.x test

* GAMESS VERSION = 1 MAY 2013 (R1) *
* J.COMPUT.CHEM. 14, 1347-1363(1993) *
**************** 64 BIT LINUX VERSION ****************

DDI Process 0: shmget returned an error.
Error EINVAL: Attempting to create 160525768 bytes of shared memory.
Check system limits on the size of SysV shared memory segments.

The file ~/gamess/ddi/readme.ddi contains information on how to display
the current SystemV memory settings, and how to increase their sizes.
Increasing the setting requires the root password, and usually a sytem reboot.

DDI Process 0: error code 911
ddikick.x: application process 0 quit unexpectedly.
ddikick.x: Fatal error detected.
The error is most likely to be in the application, so check for
input errors, disk space, memory needs, application bugs, etc.
ddikick.x will now clean up all processes, and exit…
ddikick.x: Sending kill signal to DDI processes.
ddikick.x: Execution terminated due to error(s).
unset echo
—– accounting info —–
Files used on the master node machinename were:
-rw-r–r– 1 username username 0 2014-04-04 22:51 /tmp/test.dat
-rw-r–r– 1 username username 1341 2014-04-04 22:51 /tmp/test.F05
ls: No match.
ls: No match.
ls: No match.
Fri Apr 4 22:51:36 EDT 2014
0.0u 0.0s 0:01.08 9.2% 0+0k 0+8io 0pf+0w

Things worked, but with a memory error. This issue is discussed at the Baldridge Group wiki:

From the wiki:

If you are sure you are not asking for too much memory in the input file, check that your kernel parameters are not allowing enough memory to be requested. You might have to increase the SHMALL & SHMAX kernel memory values to allow GAMESS to run. (See for a better explanation.)
For example, on a machine with 4GB of memory, you might add these to /etc/sysctl.conf:
# cat /etc/sysctl.conf | grep shm
kernel.shmmax = 3064372224
kernel.shmall = 748137
Then set the new settings like so:
# sysctl -p
Since they are in /etc/sysctl.conf, they will automatically be set each time the system is booted.

In our case, we modify sysctl.conf with the recommendations from the wiki:

username@machinename:~$ sudo nano /etc/sysctl.conf

Add the following to the bottom of the file:

kernel.shmmax = 3064372224
kernel.shmall = 748137

Save and exit.

username@machinename:~$ sudo sysctl -p

net.ipv4.ip_forward = 1
kernel.shmmax = 3064372224
kernel.shmall = 748137

These memory values will change depending on your system.

Now we empty the /tmp and rerun.

username@machinename:~$ rm /tmp/*
username@machinename:~$ ./rungms test.inp

If your input file is worth it’s salt, you’ll have successfully run your file on a single processor (single core, that is). If you run into additional memory errors, increase kernel.shmmax and kernel.shmall.

Now, onto the SMP part. My first attempt to run games in parallel (on 4 cores using version 00) produced the following error:

username@machinename:~$ rm /tmp/*
username@machinename:~$ ./rungms test.inp 00 4

—– GAMESS execution script ‘rungms’ —–
This job is running on host machinename
under operating system Linux at Fri Apr 4 22:52:52 EDT 2014
Available scratch disk space (Kbyte units) at beginning of the job is
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 1905222596 249225416 1559217456 14% /
GAMESS temporary binary files will be written to /tmp
GAMESS supplementary output files will be written to /tmp
Copying input file test.inp to your run’s scratch directory…
cp test.inp /tmp/test.F05
unset echo
I do not know how to run this node in parallel.

I tried a number of stupid things to get the run to work, finally settling on modifying the rungms file properly. To make gamess know how to run the node in parallel, we need only make the following changes to our rungms file.

username@machinename:~$ nano rungms

Scroll down until you find the section below:

# 2. This is an example of how to run on a multi-core SMP enclosure,
# where all CPUs (aka COREs) are inside a -single- NODE.
# At other locations, you may wish to consider some of the examples
# that follow below, after commenting out this ISU specific part.
if ($NCPUS > 1) then
switch (`hostname`)
if ($NCPUS > 2) set NCPUS=4
set NNODES=1

The change is simple. We remove the cases for $NCPUS > 1 in the file and add the hostname of our linux box (and if you don’t know this or it’s not in your prompt, simply type hostname at the prompt first). We’ll disable the two cases listed and add our hostname to the case list.

# 2. This is an example of how to run on a multi-core SMP enclosure,
# where all CPUs (aka COREs) are inside a -single- NODE.
# At other locations, you may wish to consider some of the examples
# that follow below, after commenting out this ISU specific part.
if ($NCPUS > 1) then
switch (`hostname`)
case machinename:
# case
# case
if ($NCPUS > 2) set NCPUS=4
set NNODES=1

This gives you parallel functionality, but it’s still not using the machine resources (cores) correctly when I ask for anything more than 2 cores (always using only 2 cores).

[minor complaint]
Admittedly, I don’t immediately get the logic of this section as currently coded, as one cannot get more than 2 cores to work in this case given how the if statements are written (so far as I can see now. I will assume I am the one missing something but have not decided to ask about it, instead changing the rungms text to the following). You can check this yourself by running top in another window. This is the most simple modification, and assumes you want to run N number of cores each time. Clearly, you can make this more elegant than it is (my modification, that is). Meantime, I want to run 4 cores on this machine, so I change the section to reflect a 4-core board (and commented out much of this section).

# 2. This is an example of how to run on a multi-core SMP enclosure,
# where all CPUs (aka COREs) are inside a -single- NODE.
# At other locations, you may wish to consider some of the examples
# that follow below, after commenting out this ISU specific part.
if ($NCPUS > 1) then
switch (`hostname`)
case machinename
# case
# case
# if ($NCPUS > 2) set NCPUS=2
# set NNODES=1
# set HOSTLIST=(`hostname`:cpus=$NCPUS)
# breaksw
# case machinename
# case
if ($NCPUS >= 4) set NCPUS=4
set NNODES=1
set HOSTLIST=(`hostname`:cpus=$NCPUS)
case machinename
# case
# case
# case
# case
# case
# case
# case
# case
# case
# if ($NCPUS > 4) set NCPUS=4
# set NNODES=1
# set HOSTLIST=(`hostname`:cpus=$NCPUS)
# breaksw
# case
# case
# case
# if ($NCPUS > 6) set NCPUS=6
# set NNODES=1
# set HOSTLIST=(`hostname`:cpus=$NCPUS)
# breaksw
echo I do not know how to run this node in parallel.
exit 20

And, with this set of changes, I’m using all 4 cores on the board (but have some significant memory issues when running MP2 calks. But that’s for another post).

The typical user will never be able to do what the GAMESS group has done in making an excellent program that also happens to be free. That said, the need to make changes to the rungms file is something that would be greatly simplified by having N number of rungms scripts for each case instead of a monolithic file that is mostly useless text to users not using one of the system types. This, for instance, would make rungms modification much easier. If I streamline rungms for my specific system, I may post a new file accordingly.

Some Light Science Reading. The Constellations: Taurus

As first appeared in the November 2009 edition of the Syracuse Astronomical Society newsletter The Astronomical Chronicle (PDF).

Constellation Map generated with Starry Night Pro 6.

This month’s constellation is one of the best in the Night Sky for combining ancient tradition, mythology, modern astronomy, world history, stellar eye candy, and even modern engineering into one reasonably small bordered pen of celestial real estate. The early evening sight of the constellation Taurus the Bull in the November southeast sky at Darling Hill might appear to CNY viewers as a snow divining rod pointing to the western Great Lakes in anticipation of winter and the upcoming lake-effect snow. Taurus is a distinctive constellation and very easy to identify once its central asterism is identified. The brightest star in the constellation is almost equidistant from the easily identified Pleiades and the shoulder of the constellation Orion, the celestial hunter Taurus is running from as the sky appears to move (or, from the most commonly drawn orientation, right towards him!). While Taurus is mildly sparse in quantity when it comes to dark sky objects, it more than makes up for it in quality, hosting two of the most significant stellar sights in the Night Sky.

Like its neighbor Orion, Taurus the Bull is a very, very old constellation and has been recognized as a bull for the duration of its existence in Middle Eastern and European traditions. Earliest records of any kind place the birth of Taurus in the Copper (Chalcolithic) Age (4500 – 3500 B.C.E.), although some records support its existence even earlier. The presence of a bull and what appears to be a Pleiades-like star formation exists on a wall in the Lascaux Caves of France (see right). Although the interpretation of the Constellation set is controversial, this arrangement may date back as far as 16,500 years. Personally, I find even the thought of that kind of continuity between what we might see in the winter skies and what our ancestors also saw at night both comforting and humbling. Many of the same stand-out patterns we know today no doubt stood out immediately to them as the brightest objects in the sky marked out regular places as the Sun set, and the great distance we’ve traveled in history might be barely perceptible to an ancient astronomer going simply by the positions of stars.

Lascaux Cave bull and star pattern. From the Institute for Interdisciplinary Studies and

We begin the tour by aiming our sights at the bright eye of the bull, the star Aldebaran. This orange giant is 44 times the diameter of our own Sun and has already used its hydrogen fuel, leaving this fusion engine to now graze on a steady diet of helium. Its name is derived from the Arabic for “the follower,” often reported as in reference to its position below the Pleiades (so “following” this open cluster as we progress into winter). The other stars in Taurus are easy to see in darker skies but not otherwise noteworthy for their brightness at either naked-eye or binocular viewing magnification. Several of the bright stars closest to Aldebaran make up an asterism that a new observer might confuse with the complete constellation. The V-shaped Hyades (center of the image below and shown at right with white border) are composed of five stars, with Aldebaran the brightest tip. I’ll admit that the first time I marked out the space for Taurus, I confused this asterism (and lambda-Tau to the west) with the entire object before double-checking the size. No bull. The Hyades star closest to Aldebaran, theta-Tau, is actually a pair of pairs, although they only appear as a single bright pair in binoculars and telescopes.

The Hyades (white) and Pleiades (red). From Lynn Laux,

Caught within the bull pen is the Pleiades (M45, shown labeled below from a Hubble image). This Tiny Dipper is visible year-round during the daytime in parking lots and slow-moving traffic everywhere (as the object embedded within the emblem on every Subaru, the Japanese name for this asterism) and is one of the treats of winter viewing in CNY (unless VERY early morning viewing is your game or you’ve been trying to see Mars in the late Summer skies, in which case you’ve been enjoying the pre-dawn sight of M45 since August). The amount of information available on the Pleiades online and as part of space research could easily (and very likely has) fill an entire book. While the seven bright stars are identified from Greek mythology as the Seven Sisters (Sterope, Merope, Electra, Maia, Taygete, Celaeno, and Alcyone), the counting aid that comes from a pair of binoculars easily reveals nine stars. The two stars that make up the handle of this tiny dipper are the proud parents Atlas and Pleione, placed to the east of the dipper to protect their daughters from either Taurus (for being a bull) or Orion (for being a male). Given the long history of this asterism, it is perhaps not surprising that the parents decided not to stop at seven. In fact, there are over 1,000 distinct stars in the Pleiades that have been revealed as part of multiple high-resolution studies. This density of stars makes the Pleiades a unique open cluster, as there is a wealth of stars and patterns visible at virtually any magnification, from small binoculars to the largest ground-based telescopes. For my first proper viewing session, I spent one full hour simply looking at this cluster through my Nikon 12×50’s, amazed at just how little we really see of the Night Sky using the 1×7 binoculars built into our heads (and, perhaps, corrected by horn-rimmed glasses).

The Pleiades in detail. Image from and

On the opposite side of Taurus and caught between the horns is the first of the categorized Messier objects, the Crab Nebula. M1 to its friends, this nebula is a supernova remnant with a remarkable history. As documented in both Arab and Chinese texts (Europe was just coming out its, er, Dark Ages at the time), this supernova was so bright on July 4, 1054 that it was visible during daylight hours (and, as you can guess by the date, visible without any magnification). The supernova remnant we know today as the Crab Nebula was discovered (and correlated to the original supernova) first by John Bevis in 1731, then by Charles Messier in 1758 while, as it happens, observing a comet (that Messier is known best for his catalogue of objects that were NOT comets instead of the comets he worked so diligently to discover is one of the great fun ironies of astronomy). The NASA images of the Crab Nebula reveal a dense sponge-like structure full of filaments of all sizes. The image above shows a remarkable sight – the full cycle of the pulsar at the heart of the crab that continues to magnetically drive the expansion of the nebula (in the series of frames, the pulsar lies below and to the right of a constant-brightness star).

The Crab Nebula pulsar. Image from

Stepping forward several hundred years, Taurus also marks the present locations of Pioneer 10 and COSMOS 1844. Pioneer 10 is currently speeding in the direction of Aldebaran, having been successfully steered through the asteroid belt to make a series of images of Jupiter. At its current velocity, this trip to Aldebaran’s current location would take 2 million years, about the same amount of time it might take most of the world to decipher the meaning of the emblematic plaque attached to its exterior (below). Perhaps someday we’ll have to explain to the aliens how a civilization that could launch a complicated probe into space couldn’t see the multitude of planets in their own Solar System, then perhaps have to explain what happened to Pluto hat it no longer appears in our Solar System images. COSMOS 1844 is one of over 2440 satellites launched by the Soviet Union (and now Russia) since the first of the COSMOS series in 1962. At mag. 5, this satellite makes for a fun artificial viewing target (with a good map in hand).

The Pioneer 10 plaque. From

The final sights for telescope viewers include four NGC objects. NGC 1746, 1647, and 1807 are open clusters with magnitudes between 6 and 7. NGC 1514 (below) is a mag 10 planetary nebula just at the far edge of the Taurus border that should be increasingly good viewing as Taurus works its way towards our zenith (1514 will be the closest it will get to our zenith by midnight, a perfect last-good-look before Darling Hill completely freezes over).

NGC 1514. From Martin Germano,

Phenomenal viewing at a reasonably safe distance. Just be mindful not to wave your red flashlights at Aldebaran!