Urania

A blog named for the muse of Astronomy containing musings by an astronomer

PGPLOT on Mountain Lion 0

Posted on October 20, 2012 by Juan

One of the most popular posts I made on this site was back in 2009 when I wrote about how I got  the increasingly dated PGPLOT package put together by Tim Pearson running under Snow Leopard.  I decided to update that entry to how I approach things today, using homebrew as a package manager under Mountain Lion.  Honestly, these days I do most of my programming and plotting with Python and matplotlib, but I still have old code that needs to be run sometimes, so getting PGPLOT running under Mountain Lion allows me to keep that old software running.

  1. Install X11: You will need to install XQuartz in order to have XWindows support for PGPLOT.  Grab the package installer and install it.
  2. Install Homebrew:   Intall the homebrew package manager.
  3. Install GFORTRAN: The first thing you need to do after installing homebrew isinstall Gnu Fortran (aka gfortran).  This is fairly simple.  All you need to do is say:
    brew install gfortran
    There is a glitch here.  For some reason, the home-brew version of gfortran doesn’t bother to link the gfortran libraries from /usr/local/lib.  To workaround this,  symbolically linked them using:

    ln -s /usr/local/Cellar/gfortran/4.2.4-5666.3/lib/gcc/i686-apple-darwin11/4.2.1/x86_64/libgfortran.a /usr/local/lib/libgfortran.a
    ln -s /usr/local/Cellar/gfortran/4.2.4-5666.3/lib/gcc/i686-apple-darwin11/4.2.1/x86_64/libgfortranbegin.a /usr/local/lib//libgfortranbegin.a
    ln -s /usr/local/Cellar/gfortran/4.2.4-5666.3/lib/gcc/i686-apple-darwin11/4.2.1/x86_64/libgfortranbegin.la /usr/local/lib//libgfortranbegin.la

    The exact path to the original gfortran libraries may change if you install a newer version of gfortran! 
     
  4. Once they are installed, you simply have to make sure /usr/local/bin is in your $PATH.
     
  5. Install PGPLOT: I grabbed the PGPLOT source code from Tim Pearson’s website (here) and untarred the tarball into /usr/local/src/pgplot, the default location the code expects to be in (based on the instructions in the install-unix.txtfile included in the source code tarball).
    sudo tar -C /usr/local/src/ -xzvf pgplot pgplot5.2.tar.gz
  6. Install sys_macosx configuration: The PGPLOT source code has various compiler configurations stored in “configuration directories” but it doesn’t come with one for Mac OS X.  I ended up hacking the sys_macosx/ configuration directory to include a gfortran configuration. I have made a tarball of that configuration directory available in the pgplot5.2_macosx_addition.tgz that you can download and unpack into the PGPLOT source directory using:
    sudo tar -C -xzvf /usr/local/src/pgplot5.2_macosx_addition.tgz
  7. Compile the PGPLOT binaries: At this point, if you follow the instructions in the install-unix.txtfile in the PGPLOT directory you will be fine, baring in mind the configuration you want to use is the “maxosx gfortran_gcc” configuration. However, I will outline the steps I used below.
     
  8. Create a PGPLOT library/binary directory:Create a directory to contain the PGPLOT libraries. I created /usr/local/pgplot using the command:
    sudo mkdir /usr/local/pgplot
  9. Choose the graphics drivers you want:Copy the drivers.list file from the source directory to this new pgplot directory and edit it to match your needs:
    cd /usr/local/pgplot
    sudo cp /usr/local/src/pgplot/drivers.list .
    sudo vi drivers.list

    (You can replace this last step with emacs or whatever text editor you prefer). You make a graphics driver part of the compilation by removing the leading exclamation point from the line. I choose to activate the X-Window drivers, the GIF drivers (to create GIF images), and the PostScript printer drivers (which you can use to create PostScript versions of plots for publication). Be aware PNG support requires libpng be installed.
     
  10. Create the makefile: We now need to create the makefile using PGPLOT’s makemake script. Within the /usr/local/pgplotdirectory execute:
    sudo /usr/local/src/pgplot/makemake /usr/local/src/pgplot  macosx gfortran_gcc

    which should result in the following output
    Reading configuration file: /usr/local/src/pgplot/sys_macosx/gfortran_gcc.conf
    Selecting uncommented drivers from ./drivers.list
    Found drivers GIDRIV NUDRIV PSDRIV XWDRIV
    Creating make file: makefile
    Determining object file dependencies.
  11. Create all the binaries: Now you just have to create all the binaries, which is a simple makecommand:
    sudo make

    Assuming everything proceeds without error, you should then see at the end of the output
    *** Finished compilation of PGPLOT ***
    
    Note that if you plan to install PGPLOT in a different
    directory than the current one, the following files will be
    needed.
    
           libpgplot.a
           libpgplot.dylib
           grfont.dat
           rgb.txt
           pgxwin_server
    
    Also note that subsequent usage of PGPLOT programs requires that
    the full path of the chosen installation directory be named in
    an environment variable named PGPLOT_DIR.

    At this point, you should (if you are going to use PGPLOT within perl or C compile the C library as well using
    sudo make cpg

    Finally, clean out all the temporary object files, you don’t need them. Do this using the makefile by typing
    sudo make clean

    If you want to test if things are working you can run one of the PGPLOT demo programs created in this directory. However, the pgdemo* executables seem hard coded to expect the pgplot libraries in the /usr/local/lib directory, to it might be a good idea to do the following step before trying the demos. 
     
  12. Link library and header files: This step is optional, but since most programs (including the pgdemo* executables) don’t look in /usr/local/pgplot for library and header files, I symbolically linked the versions in the /usr/local/pgplot directory to /usr/local/lib and /usr/local/include respectively using
    sudo ln -s /usr/local/pgplot/libcpgplot.a /usr/local/lib/libcpgplot.a
    sudo ln -s /usr/local/pgplot/libpgplot.a /usr/local/lib/libpgplot.a
    sudo ln -s /usr/local/pgplot/libpgplot.dylib /usr/local/lib/libpgplot.dylib
    sudo ln -s /usr/local/pgplot/cpgplot.h /usr/local/include/cpgplot.h
  13. Making sure I use these PGPLOT binaries: Since I am using SciSoft OSX, I modified my ~/.tcshrcfile to change the PGPLOT related environmental variables after loading SciSoft’s environment
    setenv PGPLOT_DIR /usr/local/pgplot/
    . If you are not using Scisoft, you can place these lines anywhere in your ~/.tcshrc file. If you stick to using bash, then the corresponding lines in the ~/.bashrcfile that you need to create (after setting up Scisoft, if you are using that) are:
    export PGPLOT_DIR=/usr/local/pgplot/
    At this point you have a working PGPLOT set of libraries installed. 
     
  14. Installing PGPLOT support in Perl: You can stop here if you just want to use PGPLOT from C or FORTRAN source code. If you want to use PGPLOT from within Perl, you need to go further.
    1. Install the ExtUtils:: F77 perl module: In order to install PGPLOT support, you need to install ExtUtils:F77 first. You can download ExtUtils::F77 here and once you untar the tarball,
      tar xzvf ExtUtils-F77-1.17.tar.gz

      It can be easily compiled using the following standard perl module compilation steps:
      cd ExtUtils-F77-1.17
      perl Makefile.PL
      make
      sudo make install
    2. Install the PGPLOT perl module: You can download PGPLOT here. Untar the tarball.
      tar xzvf PGPLOT-2.21.tar.gz

      We start as we usually do for Perl modules, creating the makefile using the Makefile.PL script:
      cd PGPLOT-2.21

      Unfortunately, the Makefile.PL script will create a makefile this creates doesn’t work because it doesn’t call gfortran so we have to change the Makefile.PL script to know about gfortran. So load Makefile.PL and edit the line that reads
      use ExtUtils::F77;

      to read
      use ExtUtils::F77 qw{Darwin GFortran};

      Once you have done that, create the makefile using
      perl Makefile.PL

      Once you have done that, you can finish installing the perl module using:
      make

      you will see some warnings related to missing type specifiers and non-void functions.  Ignore them and continue
      make test
      sudo make install

      I was able to get the make test to work once I had the proper environmental variable settings for PGPLOT_DIR (see step 13).

So that is it, I now have working PGPLOT installations with perl support on my Mountain Lion Macs.

SciSoft OSX 2012.7.1 Available 0

Posted on August 01, 2012 by Juan

I haven’t been doing much image processing in recent months (something that will be changing as I take charge of the MSUM observatory for the next year).  I just noticed that Nor Pirzkal placed a new version of the 64-bit SciSoft OSX online here.  If you are still transitioning from 32-bit Scisoft, this version of SciSoft OSX doesn’t install over the old 32-bit version, so a simple edit of your start up files can allow you to switch between the two versions.

This version makes a variety of updates to IRAF and pyraf and the underpinnings of those systems.  Specific changes I noticed versus the 2012.3.1 beta I was using

  • IRAF updated to version 2.16 64bit (from version 2.15 EXPORT) which was released on April 13, 2012.
  • STSDAS and TABLES updated to version 3.15 from version 3.13
  • pyraf updated to 1.11 (from 1.10)
  • Python package changes include
  • The ipython interactive interpreter updated to 0.13 (from 0.10)
  • The matplotlib plotting package has been updated to version 1.1.0 (from 1.0.0)
  • The scientific computing packages NumPy and SciPy have been updated.  Numpy from version 1.5.1 to 1.6.1 and SciPy from 0.8.0 to 0.10.0.
  • stsci_python updated to 2.12 (from 2.11)
  • The astronomical ephemeris calculator package pyephem was updated to 3.7.5.1 (from 3.7.3.4)
  • ScientificPython updated to 2.9.1 (from 2.8)
  • The python Monte Carlo stats package pymc was updated to version 2.1a (from 2.0).
  • The python database interface package egenix-mx updated to version 3.2.2 (from 3.1.3)
  • Cython updated to 0.15.1 (from 0.13)
  • New Python packages Quantities (version 0.7), uncertainties (version 1.8), and pymzq (version 2) added.
  • Nor also noted in his release notes that “This version fixed a missing link for SuperMongo and updated the STScI Synphot tables.”

Before installing this version, I backed up the old version of SciSoft OSX using the command line

sudo mv /usr/local/scisoft /usr/local/scisoft_old

(you may not need to ‘sudo’ if you have write permission for /usr/local).  Once the backup was done,  I installed this version of SciSoft OSX by double clicking the installer package.  

Minor Tweaks I Made to My SciSoft Installation After the Installation

  1. Fixing Owenership Issues: To fix ownership issues with some of the files, I performed a

    sudo chown -R root:admin /usr/local/scisoft
     

  2. Updating SAOImage DS9: I noticed that SAOImage DS9 installed by this Scisoft OSX is still at version 6.1 whereas version 7.0 is the current version, so I manually installed the updated version by downloading the MaxOSX 10.7 (Lion) version  DS9 from here.  Once unpacked, there were two files there, ds9 and ds9.zip.  I replaced the symbolic links to the SciSoft OSX ds9 binaries in /usr/local/scisoft/bin with these binaries using the commands when I had the terminal in the ds9 download directory:

    sudo rm /usr/local/scisoft/bin/ds9*
    sudo mv ds9 /usr/local/scisoft/bin/ds9
    sudo mv ds9.zip /usr/local/scisoft/bin/ds9.zip

  3. Living with Enthought Python Distribution: I have been using the Enthought Python Distribution for the last few month, quite happily I might add.  However, SciSoft OSX prefers to use the system’s python distribution and so I have taken to only loading the SciSoft OSX packages into my path when I need them by defining the following command in my ~/.tcshrc (and I use C shell, the native shell for IRAF out of habit):

    alias load_scisoft "test -r /usr/local/scisoft/bin/Setup.csh && source /usr/local/scisoft/bin/Setup.csh"
     

Rebuilding a server for little fun or profit… 0

Posted on May 31, 2012 by Juan

Well, that sucked.  I had my computer start locking up when severing web pages.  Not a hard lock up, but all the httpd processes would become ‘uninterruptible’ and hang.  Eventually this prevented the server for feeding out webpages and required me to hard reboot (aka, push the power button) on the server to reboot it.

As such, I decided to do some spring cleaning and built up the server from scratch, luckily I had backups of everything.  Steps thus far:

  1. Break up a mirrored and stripped RAID array of four 2TB drives.  Given the mirroring didn’t seem to be getting me much more than having a simple second striped RAID of two 2TB drives as backup, I switched to two 4TB partitions.  Had to copy the data back onto the new RAID setup from the backup drive. Total time: 7 hours for first copy, then 7 more hours to make backup that used to be mirrored.  Net gain: I now have 2GB of additional drive space available, even with the backups.
  2. Backup the old boot drive to a backup partition.  Total time: 5 hours.
  3. Wipe a drive and install OSX Lion Server on it. Total time: 1 hour
  4. Copy user files and Applications from old drive to new boot drive.  Total time: 4 hours (but ran simultaneous to the second copy of the RAID mentioned above).
  5. Set up new server to clone itself to backup every day and let those backups run.  Total time: 3 hours.
  6. Setup new web server, including figuring out how Apple sets up server security certificates.  Total time: 3 hours.

It may seem like a lot of time invested, but really, most of the time has been spent copying data from backups… so I multitask and work on other things on my laptop while that is going on.  The big lesson I take away from this.  Having automatic nightly backups is ABSOLUTELY ESSENTIAL to making this kind of changes relatively quickly.  My resistance to making this kind of change would have been much larger if I thought I might lose data and didn’t think I could just switch boot drives and go back to my old set up in case I had screwed things up.

So at this point, I have checked, all my old applications seem to be running and the website is back up.  The only problem I have is that PHP doesn’t seem to be properly loading the SSH2 extension.

Another Update to Clear Sky Clock (Now Supporting Accented Characters) 0

Posted on October 03, 2011 by Juan

A Quebec-er informed me that certain sites in Quebec were not showing up in my Clear Sky Clock widget.  An investigation revealed that JavaScript doesn’t understand Unicode characters in its regular expressions.  A bit of thinking revealed a much simply regular expression that would match the site names from Attilla Danko’s Clear Sky Chart website.  So I have fixed the widget to support all accented characters, and for that matter, any name that the Clear Sky Chart presents.  The accented characters may appear as ‘diamonds’ in the menu, but selecting the sites will work now.

You can download this MacOS X widget from here.

If you have the old version installed, you can simply quit the widget, then replace the installed widget with this one.  You may have to log out and log back in for the new version of the Clear Sky Clock to be loaded after installing the new version.

Update to Clear Sky Clock Widget for OSX Dashboard 0

Posted on August 12, 2011 by Juan

In mid 2008 I spent some time learning JavaScript well enough to update and fix the Clear Sky Clock widget for the OSX Dashboard. This widget, developed by Joshua Lynch, pulled Attilla Danko’s Clear Sky Chart images (example shown above) and displayed them on the Mac Dashboard. However, it was not parsing the locations properly. I fixed the location parsing and added a built-in legend and the ability to resize the widget and released it under a GPL license.

This morning I was alerted by Bruce Krobusek to the fact that the widget was no longer allowing users to select a location, at least with the current Snow Leopard and Lion releases. I had not seen this problem because once you had the widget configured (as I did under Leopard), the settings were saved. However, new users could not change the location from the default of Minneapolis, Minnesota without a bit of hacking on the preferences files. After a bit of digging around, I found the glitch in the location parsing. I am not certain, but I believe this failure was occurring due to a change in JavaScript. There were no changes to Attilla’s website where the widget gets its list of locations. In any case, I have fixed the bug and everything seems to be working again.

The new widget, version 1.4, is available at my Clear Sky Clock widget website. If you have the old version installed, you can simply quit the widget, then replace the installed widget with this one. You may have to log out and log back in for the new version of the Clear Sky Clock to be loaded after installing the new version.

Scisoft OSX 2011.4.1beta available and IRAF as a package install from STScI! 0

Posted on May 24, 2011 by Juan

New version of Scisoft OSX 64-bit beta available

I just noticed today that, over a month ago, Nor Pirzkal placed a new beta of the 64-bit SciSoft OSX online here.  I have not had as much joy with the 64-bit version of IRAF as with the older ones.  That said, this version of SciSoft OSX doesn’t install over the old 32-bit version, so a simple edit of your start up files can allow you to switch between the two versions.

I backed up the old version of scisoft using the command line

sudo mv /usr/local/scisoft /usr/local/scisoft_old

and then I installed this version

sudo tar -C / -xzvf scisoft.current.tar.gz

(you may not need to ‘sudo’ if you have write permission for /usr/local).  I’ll report back if anything interesting changes.  The CONTENTS file only noted that ncftp 3.2.5 had been added.  Not sure why an FTP client was added unless it was needed by some other package.

One note is that I have been experimenting with Enthought’s Python Distribution and have it over-riding the python packages installed by the Scisoft OSX installation, so I may have to play around a bit to get PyRAF working again.  Or I may drop SciSoft OSX altogether (since its Python interferes with Enthought).

STScI makes MacOS X Package Installer version of IRAF available

In the process of looking at PyRAF, I was pleasantly surprised to find that STScI now has a package installer available for installing IRAF+STSDAS/TABLES and all the corresponding files needed for STSCI Python in a single click.  It is only for 64-bit Macs.  I will have to look this over in the future, but it apparently installs everything in /usr/scisoft so it will not collide with anything. However, it also requires a new installation of gfortran which I already know can break my PGPLOT installation.

Securing your Snow Leopard Web Server 0

Posted on April 05, 2011 by Juan

I run several blogs as well as some WebDAV servers on my MacOS X web server, all of which use passwords to authorize access.  I recently decided it would a good idea to support HTTPS (secured, encrypted HTTP) on my web server so that my passwords for accessing my blogs and webDAV server were not sent plaintext and unsecured over the internet.

Initially I had balked at this because the typical SSL Certificate, needed to encrypt and decrypt the traffic from the web server, cost on the order of $100 per year if signed by a Certificate Authority (one of the companies that all the web browsers come set up to ‘trust’ as signers of SSL certificates).  Such a digital signature is necessary if you want your https connections to be recognized as trusted by all web browsers.

However, I recently learned that it is possible to simply ‘self-sign’ your SSL certificates and so long as you only need the encryption for yourself (for example, when using a password to log in as an admin on a blog), this is a free solution that works.  The certificate will not be marked as ‘trusted’ by any authority, but if you can trust it, it will allow you to encrypt the traffic to and from your web server.

The solution I outline below is partly based on a hint provided at MacOSXHints for getting a full Certificate Authority signed certificate installed (here) and a hint from the CentOS wiki (here) for self-signing your certificates.

I’ll outline the procedure I used below, but as a warning, you need to have a familiarity with the command line and the use of sudo.  I am also assuming you are using Snow Leopard (MacOS 10.6.x).

  1. Create Directory to store certificate: Start by creating a directory you want to place the certificates in and then “cd” into that directory on the command line.  I used /etc/apache2/local_certs/ as my directory.
  2. Generate the Private Key file: Next, from the command line, generate a private key:
    openssl genrsa -out ca.key 1024
    during the command the output should look like this:
    Generating RSA private key, 1024 bit long modulus
    ........++++++
    .......................++++++
    e is 65537 (0x10001)
  3. Generate a Certificate Signing Request file: Next you need to generate a certificate signing request. You won’t ask anyone else to sign this, but you need it in order to create the public key file. So from the command line type:
    openssl req -new -key ca.key -out ca.csr
    and you will be asked a series of questions. Your answers should be as follows:
    1. For Country Name (2 letter code) answer with the two letter code for your country, for the United States it was “US”.
    2. For State or Province Name (full name) I answered “Minnesota”.
    3. For Locality Name I entered my city.
    4. For Organization Name I entered my name (Juan Cabanela) since this is a server run by my school, but not managed by my school.
    5. For Organizational Unit Name I just hit “enter” and left it blank, your answers may vary.
    6. For Common Name I entered by server’s URL iparrizar.mnstate.edu.
    7. For Email Address I used my email address. It appears in the certificate so I suppose it could lead to spam, but I figured it was better to give people stumbling across the certificate an email address they could contact for questions.
    8. For A challenge password and An optional company name, I hit enter. I don’t expect to need to get the certificate signed.
  4. Generate a Public Key file: The last step in certificate creation is you need to generate the self-signed public key which will actually be what users get when they access your server. The user uses this public key which decrypts the traffic the web server will encrypt with the private key (only accessible to the web server).  To generate the public key file, use the command line to run:
    openssl x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.crt
    This will only make your public key valid for 365 days, you might want to change this if you don’t want to have to generate a new public key every year.
  5. Set up the web server: Now you have to edit your MacOS web server configuration to support encrypted HTTPS traffic.  This comes down to editing two files. ou will need ‘admin permission’ to edit both of these files, so you will either need to use sudo with a command line text editor (like vi or emacs) or you will need to use a text editor that supports editing files with ‘admin’ permission. The changes you need to make are the following:
    1. Open the main web server configuration file, /private/etc/apache2/httpd.conf, in a text editor and uncomment (remove the leading ‘#’ from) the following line (it’s line 473 in my installation):
      Include /private/etc/apache2/extra/httpd-ssl.conf
    2. Edit /private/etc/apache2/extra/httpd-ssl.conf and make sure the following lines are set as follows:
      • SSLCertificateFile points to /private/etc/apache2/iparrizar_ssl_new/ca.crt or where ever you have your ca.crt file you created in step 4. SSLCertificateKeyFile points to /private/etc/apache2/iparrizar_ssl_new/ca.key or where ever you have your key file you created in step 2.
      • Make sure the lines containing SSLCACertificateFile and SSLCARevocationPath (these are two seperate lines) are commented out (add a leading ‘#’ to each line). Since these certificates will not be signed by a certificate authority, you have no need to point people to CA certificate files or revocation paths.
  6. Restarting the web server: Now all you should have to do is restart you apache web server and see if everything works. From the command line type:
    sudo apachectl restart
    This should restart the web server.  Assuming no error messages appear, you can next test the connection.
  7. Testing the web server: See if you can go to your web server using https://your.domain.name.here/ as the URL in your web browser. You will be presented with the ‘untrusted’ certificate and asked if you want to accept it.  In Safari on the Mac, accepting the certificate adds it to the Keychain.  I am not sure about where Firefox or Chrome store the certificate, but they should hold on to it for future use, ensuring your future connections to the web server are secure (if done via “https”).
  8. Bonus Step for iOS device users: If you want to add these self-signed certificates to your iOS device, you can do this by simply ‘exporting’ the certificate as a ‘crt’ file from the Keychain (or finding the original “crt” public key file you created earlier).  Email that public key .crt file to yourself and open that email on the iOS device.  If you click on the attached certificate in that email you will be presented with the option of adding that certificate to your iOS profile.  Doing so will allow Safari and other programs on the iOS device to connect securely to your web server.

Ripley’s Believe it or Not Understatement 0

Posted on March 30, 2011 by Juan

Astronomically Offensive Panel from March 30, 2011 Ripley's Believe It or Not comicToday’s Ripley’s Believe It or Not comic contained an understatement of extraordinary proportions.  I include a copy of the panel of particular interest to me.  It states the “unbelievable” fact that

By driving at 100 miles per hour in a car, if it were possible, it would take more than 28 years to reach the nearest star – Proxima Centauri.

This implies that you would get there in a little more than 28 years.  Unfortunately, this is horrifically off the mark!

Let’s see, at 100 miles per hour, you go 876,600 miles per year (assuming 365.25 days per year and 24 hours per day).  In 28 years you have gone about 24.5 million miles.  That doesn’t even get you to Venus, the closest planet, which at closest approach is about 25.5 million miles away!

This is a problem a lot of my incoming students have, they don’t realize just how “astronomical” astronomical distances tend to be.  Let’s use a few examples with this 100 mile per hour space car.

  • Driving to the Moon: The closest heavenly body is the moon, at an average distance of about 240,000 miles.  At 100 miles per hour, it will take this space car 2400 hours or approximately 100 days to reach the Moon. The Apollo astronauts took just over 3 days to get there!   I guess the Saturn V rocket moved them a bit faster than 100 miles per hour!
  • Driving to the Sun: The distance to the nearest star, the Sun, (yeah, Ripley’s got this one wrong too!) is approximately 93 million miles.  This distance is so huge, astronomers often replace miles with “astronomical units” where one “AU” is the average distance to the Sun.  It would take this space car 930,000 hours or just over 106 years to travel 1 AU to reach the Sun. So remember that, about 106 years to drive 1 AU (NOTE: Actually, that is the time to reach the center of the Sun, shave off half a year if you just want to reach the surface of the Sun.  Yes, the Sun is that big! It’s a star baby!)
  • Driving to the Neptune: The minimum distance to Neptune, the furthest planet out is approximately 28.8 AU.  So you are looking at a travel time in this space car of about 3050 years.
  • Driving to the Edge of the Solar System: The farthest large object in the solar system that I am aware of is Eris, the dwarf planet.  It’s average distance from us is about 67.7 AU or a drive time of about 7175 years.
  • Driving to Proxima Centauri: But all these distances pale in comparison to the distance to nearest star other than the Sun, Proxima Centauri.  Proxima Centrauri is 4.2 light years away.  1 Light year is the distance light travels in one year and light is the fastest thing in the universe.  Light travels about 186, 282 miles per second or 5,878,625,372,000 miles per year.  This works out to about  63240 AU per light year, so the distance to Proxima Centauri is about 265,600 AU!  This is enormous!  It would take Ripley’s space car traveling 100 miles per hour over 28 million years to get to Proxima Centauri.  “More than 28 years” indeed!

In all honestly, I suspect a typo on behalf of Ripley’s Believe It or Not (after all, that word “millions” is hard to fit in the space provided, might as well drop it), but this is illuminating to say the least!!!

I’ll close with an analogy I use in my intro astronomy classes.  If we shrunk the Sun to be the size of a tennis ball, the Earth would be a small dot (roughly the size of a printed ‘period’ at the end of a sentence) about 38 feet away.  The entire solar system lies within 2000 feet of the tennis ball.  Proxima Centauri would be 1185 miles away.  Its a long distance between star systems compared to the distances between planets.

[Edit: Fixed a stupid error because I used kilometers like a good scientist, but normal Americans use miles.]

Asymmetric Thick Disk Project Bears Fruit 0

Posted on March 15, 2011 by Juan

Today the collaboration I am in published the last two papers (here and here) in our series of papers on the Asymmetric Thick Disk Project, a project which consumed the last four years of my research life.  I have posted a web page including links to the papers and data products from this project on my website here, but here is a copy of the writeup, which I thought turned out quite nice.

History of the Asymmetric Thick Disk

In 1996, Jeff Larsen (then at U Minnesota) and Roberta Humphreys (U Minnesota) discovered “a large and significant asymmetry in the number of stars in the first quadrant I of the galaxy compared to complementary longitudes on the other side of the center-anticenter line.” This work, focusing on probable thick disk stars 30 degrees above the plane of the galaxy showed a 30% excess in stars in the first quadrant versus the corresponding field in the fourth quadrant covering 90 degrees of galactic longitude! (Larsen and Humphreys 1996)

Followup work by Jennifer Parker (then at U Minnesota), Roberta Humphreys, and Jeff Larsen showed that the asymmetry in star counts extended over an even larger part of the sky and “While the region of the asymmetric distribution is somewhat irregular in shape, it is also fairly uniform, stretching over several hundred square degrees on the sky. It is therefore a major substructure in the Galaxy due to more than small-scale clumpiness in the thick disk or inner halo” (Parker, Humphreys, and Larsen 2003). Furthermore, they obtained spectra for 741 stars scattered across these fields. Using the spectral analysis pipeline developed by their collaborator, Tim Beers, they were able to use the metallicity estimates from the spectra to show most of the stars in the sample were Thick Disk stars. Isolating the thick disk stars, they demonstrated that the ” VLSR velocities reveals a significant lag of approximately 80 to 90 km/s in the direction of Galactic rotation for the thick-disk stars in quadrant I, while in quadrant IV, the same population has only a approximately 20 km/s lag confirming the kinematic asymmetry between the two directions” (Parker, Humphreys, and Beers 2004).

So by 2004 it was clear there was a significant feature in the Thick Disk of the Milky Way that was causing an asymmetry in both the star counts and kinematics of the thick disk. At the end of Parker, Humphreys, and Beers (2004), three possibie explanations were proposed for the asymmetry:

  1. The asymmetry is due to a fossil remnant of a merger passng through Quadrant I.
  2. The thick disk and/or halo is triaxial with the major axis in Quadrant I, thus they asymmetry just reflects that the long axis of the triaxial distribution is nearer to us in Quadrant I than Quadrant IV.
  3. The asymmetry is due to a “gravitational wake” caused by the interaction of the thick-disk/inner halo stars with the bar in the disk, which is in Quadrant I, but lies a few kpc beyond the thick disk stars in the asymmetry.

The “Mapping the Asymmetric Thick Disk” Project

Figure 11
Figure 1 [Click Image for Full Size Version]:
The location of excess for faint “Blue” stars with (top) 500 pc < Z < 1500 pc, (middle) 1500 pc < Z < 2500 pc, and (bottom) 2500 pc < Z < 4000 pc shown overlaid on the density contours of the bar in the Disk as traced by IRAS AGB stars from Weinberg (1992). All figures are in galactocentric Cartesian coordinates. (Figure 11 from Larsen, Cabanela, and Humphreys 2011)

In 2006, Roberta Humphreys (U Minnesota), Jeff Larsen (US Naval Academy), and Juan Cabanela (then at St. Cloud State University, currently at Minnesota State University Moorhead) proposed to NSF for a collaborative project to determine the spatial extent of the asymmetry both in star counts and kinematics and to better constrain the origin of the spatial and kinematic asymmetry. This project focused on obtaining (1) multibandpass CCD observations of 63 roughly 1 degree square fields to extend the star counts to deeper magnitudes and (2) obtaining high resolution spectra of several thousands stars in these fields to allow a more extensive investigation of the kinematics of this feature.

By 2008, it was clear the stellar asymmetry had been confirmed by Juric et al (2008) using the Sloan Digital Sky Survey (SDSS). However, their interpretation of the excess in the star counts as a ringlike structure is not supported by critical complementary data in the fourth quadrant, which is not covered by the SDSS. Therefore, we published a short letter (Larsen, Humphreys, and Cabanela 2008) to present stellar density maps from the Minnesota Automated Plate Scanner Catalog of the POSS I showing that the over density does not extend into the fourth quadrant and therefore the over density is most probably not a ring. The asymmetry feature was named the Hercules Thick-Disk Cloud.

Our initial analysis of the star count data focused on searching for a clear signature of triaxiality, an asymmetry in the star counts that extended to higher and higher Galactic longitude. However we found no evidence for an excess of faint blue stars at l≥55° including the faintest magnitude interval. This demonstrated the asymmetry’s spatial limits and ruled out a triaxial thick disk as a likely explanation of the excess of Thick Disk stars in Quadrant I (Larsen et al. 2010).

By 2010, we had obtained multi-color UBVR photometry for 1.2 million stars in 63 fields approximately 1 square degree each. This extensive star count dataset allowed us to determine the spatial extent of the over density across and along the line of sight, and estimate the size and mass of the Hercules Thick Disk Cloud. Using photometric parallaxes we determined the stars responsible for the excess are between 1 and 6 kiloparsecs from the Sun, 0.5 – 4 kpc above the Galactic plane, and extend approximately 3-4 kiloparsecs across our line of sight (See Figure 1). This is a major substructure in the Galaxy. The distribution of the excess along our sight lines corresponds with the density contours of the bar in the Disk, and its most distant stars are directly over the bar. We also see through the Cloud to its far side. Over the entire 500 square degrees of sky containing the Cloud, we estimate more than 5.6 million stars and 1.9 million solar masses of material. If the over density is associated with the bar, it would exceed 1.4 billion stars and more than than 50 million solar masses. (Larsen, Cabanela, and Humphreys 2011)

Figure 10
Figure 2 [Click Image for Full Size Version]: Mean VLSR velocity as a function of distance from the Sun for the thick disk stars in the first quadrant. Note the turnover or shift to less negative velocities at distances greater than 4 kpc. (Figure 10 from Humphreys, Beers, Cabanela, Grammer, Davidson, Lee, and Larsen 2011)

By the end of this project we had also obtained radial velocities and derived metallicity parameters for over 4000 Thick Disk-candidate stars in Quadrant I (hereafter Q1), above and below the plane and in Quadrant IV (hereafter Q4) above the plane. Using these spectroscopic observations, we have confirmed the corresponding kinematic asymmetry first reported by Parker et al. (2004), extended to greater distances and with more spatial coverage. The metallicity parameters allowed us to separate the stars by population type: Halo, Thick Disk, Metal-Weak Thick Disk, and (Thin) Disk stars. The Thick Disk stars in Q1 have a rotational lag of 60 – 70 km/s relative to circular rotation, and the Metal-Weak Thick Disk stars have an even greater lag of 100 km/s. Both lag their corresponding populations in Q4 by about 30 km/s. Interestingly, the Disk stars in Q1 also appear to participate in the rotational lag by about 30 km/s. The enhanced rotational lag for the Thick Disk in Q1 extends to 4 kpc or more from the Sun. At 3 to 4 kpc, our sight lines extend above the density contours on the near side of the bar, and as our lines of sight pass directly over the bar the rotational lag appears to decrease (See Figure 2).This is consistent with a “gravitational wake” induced by the rotating bar in the Disk which would trap and pile up stars behind it. (Humphreys, Beers, Cabanela, Grammer, Davidson, Lee, and Larsen 2011)

Summary of Our Conclusions:

When we started this project in 2004, there were three proposed explanations for the asymmetry in the star counts and kinematics of the Thick Disk stars: (1) a fossil remnant, (2) a triaxial Thick Disk or Halo, or (3) a dynamical interaction of the Thick Disk stars with the stellar bar. Our new deeper star counts across 63 fields extending to higher Galactic latitude and longitude than previous plate based work, eliminated a Triaxial Thick Disk as an explanation of the observed star count asymmetry. Our spectroscopic observations of over 4000 Thick Disk-candidate stars showed the kinematics of these stars in the asymmetry were strongly tied to their position relative to the stellar bar of the Galaxy in a way that is consistent with a “gravitational wake” induced by the stellar bar in the Disk. Based on our observational evidence, we conclude the best explanation of the Hercules Thick Disk Cloud is that it is the result of the dynamical interaction of the Thick Disk with the stellar bar.

Papers2: Not ready for prime time 0

Posted on March 08, 2011 by Juan

papers2 really still a betaOne of the programs I use almost daily now that I am on sabbatical is Papers by Mekentosj B.V. Papers really helps you organize your reading, allowing you basically an iTunes-like interface for organizing PDFs.  While it originally seemed to be aimed at medical researchers, it has supported ADS abstract searches for quite some time.  Its ability to store metadeta outside the PDFs in a searchable database made it a powerful tool for me.

For the last few weeks, Mekentosj B.V. has been promoting the release of Papers2 and it has some really interesting new features.  The ones that stood out for me were:

  • Ability to attach other sorts of files (such as ASCII data tables) to a paper in the database.
  • The ability to search multiple online search engines (ADS abstracts and Google Scholar, for example) simultaneously.
  • “Magic Manuscripts” which basically seemed like a citation manager to integrate Papers into almost any writing environment.

This morning, I downloaded and purchased the update to Papers2.  It is clear the developers had some idea of how important Papers is to people in that they made the update create a whole new database instead of wiping out your old one.  You don’t even have to shell out any money, as Papers2 has a fully functional 30-day trial mode.  This means if you are a Papers user, trying out Papers2 is a safe thing to do.  And while I paid for the update (since I trust the developer to improve the product over time), I would suggest you NOT do so until you have throughly tested it, especially if you are a Papers user already.

Papers2 is a complete re-write, so problems were bound to exist.  This is after all a .0 release.  However, in a few hours of experimentation with Papers, I have found it to be much buggier than Papers.  Papers2 is also missing some features I had come to rely on.  The developers are clearly aware of this as one of the web pages they link to within Help menu of the app is a link to their “Future Roadmap,” a lot of which seems geared toward bringing features back that were in Papers.

Among the problems I have experienced this morning:

  1. Activation problems: The license I purchased is supposed to allow registration and activation of Papers2 on two computers.  The activation failed on the second computer and I have not heard back from their (probably overwhelmed) tech support about this yet.  I am sure this will be resolved as they have very good tech support, but it is annoying. [Tech support didn’t respond to my email but a re-attempt a bit later did activate my second copy of Papers2.  I suspect an overloaded activation server. – March 10 3:45 pm CST]
  2. No synching available, yet: I use Papers on my iPad to carry my collection of papers with me on the road.  Apparently, syncing, even though advertised in the app as a feature.  When I reported it, the response was that synching is not available until the next update of the iOS app (which has already been submitted to the Apple for review).  I understand that Mekentosj B.V. can’t control Apple’s App Store acceptance timetable, but then make it clear the feature is not yet available or is pending the release of the new version of the iOS app.  It does say this in small print, but it is not clear enough in my mind.
  3. Missing AAS citation template: Its a small thing, but of the 1400 citation styles built-in in the Manuscripts Preferences, only one is astronomical and it is not one I use.  The American Astronomical Society format (used for the Astronomical Journal, Astrophysical Journal, and Publications of the Astronomical Society of the Pacific as well as many conference proceedings) is documented, I’d like to see it added.  I suspect I can add my own, but it would have been nice for it to have been built in.
  4. Refreshing Smart Collections: I have a smart collection set up to identify all papers not already in a collection.  When I file a paper in a collection, this smart collection doesn’t reflect that until I either restart Papers2 or control click on the smart collection and say “Edit Collection” to re-setup the collection.
  5. GUI bugs: There are various GUI errors I have run across.
    1. Occasional Lockups in “Match to Repository”: Attempts to “Match to Repository” an article usually brings up a one line interface for attempting to match an article’s metadata, but occasionally the program doesn’t seem to respond properly.
    2. Metadata column disappearance bug: I have a reproducible bug [as shown in the video below] where if I use the “View Mode” button more than 3x on a given paper, it locks up with the “View Mode” button grayed out and disabled, no longer allowing you to view the meta data.  Furthermore, it is clear that this bug is stored in a preference file, because relauching the app leaves you with the same disabled View Mode button.  I have reported the bug to the support forums and have at least one other person seeing the bug there.  [WORK AROUND DISCOVERED: I have confirmed that if you move your mouse to the right edge of the window after the right metadata column has disappeared, you have the ability to drag the panel back open as suggested by “Good and Bad”in their comments in the support forum. – March 10 4:00 pm CST]
    3. Failure to reimport article: An attempt to connect a arXiv preprint to the final peer-reviewed paper produced an interesting bug.  The new paper was found, and when I try to add the PDF, it reports it can add it as supplemental material, but all choices I make produce a “error” beep and the program doesn’t offer a way out of this.  Makes importing articles dangerous.
  6. Searching for metadata is crippled: Searching for articles on the ADS abstract server appears to only allow searches by paper author and maybe title (this problem was also noted by Bryan Gaensler).  It is no where near as robust as searching in Papers, which allowed your to indicate the title, author, year, and other pieces of metadata for your search.  That said, this crippled search is on their list of “Missing Features” in their “Future Roadmap” so it is clear they are working on fixing this.  

    [I will note that my critique below, while valid for how poor the search capability is compared to Papers, may also be a bit unfair, since Papers2 has a very different approach to metadata matching.  In the days since the release of Papers2, the folks at Mekentosj have been releasing videos to better explain the new search approach.  There are two videos of note regarding this: (1) a tutorial video here that explains Papers2’s approach to metadata and  (2) a video illustrating how to use specific tags in searches.  I don’t know yet if BIBCODEs can be used with ADS searches, but it is clear that it doesn’t default to this and so it is still not as easy as Papers was in its searching, at least for astronomers. – Added March 13 12:15 pm CDT]

    But this problem also affects the ability to match papers to their metadata.  When the “Match to Repository” dialog is used, its ability to search is so crippled [as shown in the video below] that I have not managed to get and article matched to its metadata yet (since I can’t pull up the correct article to match it with.  This reduced search capability is also giving some people pause on the support forums.  “Jonathan” on that forum page stated something I agree with:

    It appears as though the developers tried to simplify and automate the matching process, but in doing so, oversimplified and compromised a critical function. Although I have been looking forward to the new version, I have had no choice but to revert to Papers1 until this is addressed (hopefully a.s.a.p.).

    “Matias” from Mekentosj B.V. does respond that

    We’re looking into this — degrading the matching user experience certainly isn’t the plan and we will either re-introduce the matching view from Papers1 or improve the automated matching behaviour in an upcoming update (most likely both). Please also keep Papers1 still around and only migrate once you’re happy with the experience that Papers2 gives you.

Because of the GUI interface glitches and the compromised matching ability compared to Papers (version 1.9.7), for now I will be sticking with Papers for my work.  Am I concerned about the future of Papers2?  Not at all! Mekentosj B.V. has had a very good record, at least as I have seen with Papers, of addressing bugs and adding features as time goes on.  I am sure, in a few month, Papers2 will be part of my arsenal for organizing my research reading and writing… but it is not there yet.

Playing with Scisoft OSX 2011.1.1 beta 0

Posted on March 03, 2011 by Juan

Since I am on sabbatical, I have been working on updating some of my software.  One of my projects is to update External SPECROAD to be functional on 64-bit IRAF installations which are becoming more common.  To do this, I needed to get a 64-bit IRAF installation.  Lucky for me, Nor Pirzkal has been working on updating Scisoft OSX for 64-bit and the most recent beta version is very usable.

Dr. Pirzkal started work on this version in early 2010.  The first alpha release was in March 2010 and contained the following note:

The latest version Scisoft OSX is being prepared. We are switching the distribution to be 10.6 compatible only. Its location is also being moved (again) from /Applications/Scisoft/ to /usr/local/scisoft/.
The main changes to this version are:

1) Requires OSX 10.6
2) 64 bit only
3) Now uses the OSX Python system
4) Pyraf no longer uses X11 and all windowing calls are made using the OSX Aqua TCL/TK libraries

These all sounded good to me, especially the move away from using a custom python installation.  The only problem is that the alpha was missing a lot for me, so after an initial try, I dropped it and went back to the 32-bit Scisoft OSX 2009.10.1.

This version installed easily enough with a couple of clicks to uncompress the ZIP file and then another click on the resulting package file to trigger the Mac installer.  The instructions were straight forward for how to edit your environment.  Once done, I had Scisoft OSX installed in /usr/local/scisoft/. I’ll note that this doesn’t clobber any previous installations of Scisoft OSX, so it is easy to switch back by editing your startup files. I am presenting a slightly modified version of his checklist for upgrading here.

  1. Install Scisoft OSX 2011.1.1b by downloading it here or from my mirror (NOTE: The file is misnamed Scisoft_OSX_macintel_2011.11.1b.pkg.zip, don’t worry, you don’t need to time travel to use this version before November 2011).
  2. Download the patch to IRAF 2.15.1a at
    ftp://iraf.noao.edu/iraf/v215/PCIX/patch1.macx.x86_64.gz(for 64 bit systems).
  3. In a terminal, type: cd /usr/local/scisoft/packages/iraf/iraf
  4. Assuming the downloaded file ended up in ~/Download, type
    sudo tar xvfz ~/Downloads/patch1.macx.x86_64.gz
  5. Now IRAF should show that you are using v2.15.1 (not 2.15) when you start it. However, that is not all: also the external packages need to be updated. I found the instructions on the IRAF web page not applicable for the Scisoft OSX installation. Instead, 
    1. start a superuser shell:
      sudo tcsh
    2. source /usr/local/scisoft/bin/Setup.csh
    3. cd to a directory containing your login.cl (might also work without this step) and type ecl
    4. within IRAF:
      cd /usr/local/scisoft/packages/iraf/iraf
    5. And then type:
      make update
      (and have a coffee or three because this is taking a while)
  6. logout (of IRAF) and then exit (to make sure you’re not continuing with superuser privileges

That process worked fine for me and I now have a current IRAF installation.  There are a few things in this beta that are not noted in the CONTENT file that came with it.  It certainly contains sextractor 2.5.0 (the current version is 2.8.6) which isn’t listed in the CONTENT file and in addition to STSDAS and TABLES 3.13, which are noted in the CONTENT file, the following IRAF packages are preinstalled:

  • color 2.0
  • fitsutil
  • gemini 1.9
  • gmisc
  • guiapps 1.2
  • mscred 4.8
  • rvsao 2.7.8  (this is the current version as far as I can tell)
  • nlocal
  • nmisc
  • vol 2.8

 

Cool Physics demos site 0

Posted on March 02, 2011 by Juan

I am always on the look out for inspiration for physics demos for my classes.

One my my students, Ben, just walked into my office to tell me to check out Fizik.si.  This is the English version of a Slovakian website which has a bunch of information on Physics demos.  The cool part is the science videos page which presents a few videos of physics demos (no audio in the videos).  Don’t forget to check out the links on the right hand side of the page for demos in other areas.

Ben specifically pointed me to this video:
/>

This video demonstrates total internal reflection of a laser beam being bent by a column of water leaking out of a pop bottle, just like a fiber optic cable.  Cool ideas abound on this website.

  • Translate

  • Astro Pic o' the Day

  • Archives

  • Admin



↑ Top