Urania

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.

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.

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.

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.

Today’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.]

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 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 2 [Click Image for Full Size Version]: Mean V_LSR 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.

One 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.

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

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.

Well, today it finally happened.  I got sick and tired of MacPorts behavior of replacing every binary already included in the Mac OS with its own version.  I don’t need two versions of perl or python installed on my Macs and I am getting tired that every time I try to install a port, it insists on installing a complete perl/python installation or its own set of libraries the MacOS already has built in,  in order to install a small utility.  I know that MacPorts has some justification for this, but it seems messy to me.

As such, I started looking for alternatives and came back to homebrew, which I had discovered a few months ago.  It is a package management system in which everything relies on already installed Mac binaries/libraries as much as possible.  By default, homebrew packages are installed into their own isolated directory (/usr/local/Library/Cellar/) and then symlinked into /usr/local/bin, /usr/local/sbin, or /usr/local/lib directories as needed. But it is flexible enough that you can install it where ever you want and it will still run.  Another nice feature, it doesn’t require you install it as root, it can run completely as the user permission level!

The negatives of homebrew:

1. There are no where near as many packages (they call them “Formula”) are available for Homebrew as for MacPorts or Fink.
2. For an astronomer, another big problem, there is no TeX under Homebrew.

It turned out the first negative was a bit of annoyance, but I was willing to live with it because the installation was so much cleaner and most of the important packages I needed MacPorts for were already there.  The second negative turned into a postive because I discovered here is a very easy to install MacTeX package available now that installs a complete TeXlive installation, including AASTeX, by default!  It even has some nice GUI controls included for keeping it up to date.

What follows is a description of what I did to transition from MacPorts to HomeBrew+MacTeX.

1. Backing up MacPorts: No need to not have a way to change my mind if this blows up in my face.  I backed up my entire MacPorts installation by using the command

   tar czvf /opt_backup.tgz /opt

   and then when that was done, I had a 1.6 Gig tarball at the root level of my drive called opt_backup.tgz.

2. Disable MacPorts: At this point, I deleted the /opt directory and commented out the commands in my ~/.tcshrc that added those directories to the PATH environmental variable.   If you use the default bash shell, you will need to edit ~/.bashrc to disable MacPorts.
3. Install Homebrew: Following the directions on the Homebrew site. I originally wanted to place homebrew in its own custom install directory (/usr/local/homebrew).But after reviewing the Homebrew installation documentation, I came to realize that using the default /usr/local location for the install makes the most sense.

   I did this in the recommended manner, using the install script, which does some nice permission checking to make sure things will run nicely before installing. Since my default shell isn’t bash, I had to switch to it, then just run the install script from the command line:

   bash
   ruby -e "$(curl -fsSLk https://gist.github.com/raw/323731/install_homebrew.rb)"

   The first time I ran it, it failed because my permissions for /usr/local had been tweaked. So I had to run the command

   sudo chown -R root:staff /usr/local

   to get the permissions so the script could run.

4. Activate Homebrew: Since I am not using a custom directory for the installation, there is not configuration needed in terms of setting up the environment. /usr/local/bin/ is in the default PATH, so as soon as I start up a new terminal window, homebrew is available! Otherwise, I would have to edit my default ~/.tcshrc or ~/.bashrc to add the homebrew binaries directories (bin and sbin) to the PATH environmental variable.
5. Install my favorite packages using homebrew: Installing packages in homebrew is just a matter of making sure the Formula for the package exists (all the publicaly available Formula are here) and then typing

   brew install (formula name)

   So for example, installing CFITSIO was just a matter of typing:

   brew install cfitsio

   Actually, this was for the most part simple for my attempts to install git.  It kept crashing with an error that said:

   The current directory must be set to the ITT directory.

   Well, ITT is the vendor of IDL (a package commonly used by astronomers for data reduction) and I discovered that I had accidentally set the IDL binary directory to be in the PATH ahead of the default system directories.  This meant the IDL version of a binary called install was replacing the system default version of this.  Just the kind of problem I was trying to get away from in MacPorts.  I  changed to my ~/.tcshrc to make sure the IDL binaries directory was later in the PATH than the system directories fixed things.  The only package this affected the install of was git, all the other packages installed without a hitch thus far.  The other brew formulae I installed were installed with the following commands:

   brew install subversion  imagemagick ghostscript macvim lynx coreutils findutils plotutils

   I can get a list of all the packages I have installed using the command:

   brew list

6. Installing MacTeX: This was extremely easy, I downloaded the MacTeX 2010 package (The version I got was dated 10 Sept 2010 and was 1.6 Gig) and then uncompressed it and double clicked it. It installs using the Mac Installer. I did make sure to customize the install to remove some of the stuff I didn’t feel I needed, but I kept the GUI tools. Turns out there is a nice TeX Live Utility installed in /Applications/TeX that lets you customize which TeX packages are installed and can automatically update things. Review of this tool also showed a very astronomer friendly decision to include AASTeX by default! The TeX installation is in the /usr/local/texlive/ directory and it installs a symlink at /usr/texbin/ to all the LaTeX binaries. I added the following lines to my ~/.tcshrc file to get the tex binaries in my PATH:

   # Set up MacTeX 2010 by including path to that installation of LaTeX
   setenv PATH ${PATH}:/usr/texbin

So there you have it, how I went from using MacPorts and the literally hundreds of packages to support the few I wanted to trimming things down to a few packages in homebrew and one double-clickable TeX installer.

[Edited on Mar. 2, 2011 11:04 am to update the instructions to the default homebrew instructions, which are cleaned and easier to implement.]

[Added 4:45 pm on December 7, 2010: In the giving credit where credit is due category, Jonathan Monroe of Actual Technologies responded to my complaint (in the comments to this blog post) and has done a very nice thing, crediting me my upgrade fee.  I fully understand this is no small action for what I suspect is a smallish developer with reasonably small margins.  While I didn't like how I felt extorted, Mr. Monroe does seem to be interested in fixing the problem.  So as you read this, be aware there was in fact a happy ending...]

One of the pieces of software I use a lot is database software, specifically MySQL.  Much of my research involves manipulating large amounts of data and using a free product like MySQL just made a lot of sense to me.

To get that data to easily move into Microsoft Excel, I have used Actual Technologies ODBC Driver for Open Source.  This awesome product worked beautifully for allowing me to move data from MySQL to Excel.  Until today…

Recently my university upgraded my Microsoft Office to version 2011.  I am not sure if the problem lies in Office 2011 or in Actual’s drivers, but Excel couldn’t see the driver.  I could open the ODBC Manager software and see the Actual drivers were installed and I had a valid license:

I could even see the serial number and confirm it was OK:

However Excel insisted it wasn’t installed.  Faced with this problem, I went ahead and downloaded the software again, figuring I might just need to reinstall it to get Excel to see it.  So I downloaded the new version of the driver and installed it.  Notice the installer claimed it was upgrading my drivers:

I then launched Excel and it did see my MySQL database success!!!!  Oh wait, why am I only getting 3 lines of data back for my query….  Opening the ODBC manager my worst fears are confirmed, my old license key is no longer valid!

I am able to confirm my old license number is in there…  the driver just claims it is “not valid for the current version of the driver”.  I try to erase the number thinking that maybe the driver just got confused and I got this error:

This acknowledgement that I had a previously valid license key that they are now rejecting strongly suggests they didn’t do this by accident. Actual technologies simply declared my old license number invalid.  Now I am rather upset.

An installer program should NEVER simply upgrade a user if the new software is going to declare their old serial number invalid.  That is just rude and frankly smacks of extortion.

After waiting a few hours for a response, I got one. I had a license key for the old version, NOT the new version. They did send me instructions for downgrading. In that sense, they are doing a good job, and in fact, the upgrade price is reasonable and I will probably pay for the upgrade, but I replied with the following message to Jonathan Monroe of Actual Technologies:

Mr. Monroe,

First of all, thank you for your response. I appreciate it. I especially appreciate that you provided instructions for downgrading the driver. I will in fact probably purchase the upgrade, the price is reasonable.

That said, I do need to chastise Actual Technology a bit. I am currently working on a blog post about this, but in a nutshell, it is rude in the extreme to upgrade a user without warning them that such an upgrade requires a new license key. This action left me without a functional installation of ODBC drivers for hours, right when I needed them. Please consider placing a warning message in large print telling users how this will happen or changing your software to recognize formerly valid licenses as ‘temporary licenses’ so a user can contact you to get things resolved.

Sincerely,

Juan

As I noted above, Mr. Monroe in fact has done a gracious thing and refunded me my upgrade fee as well as made the suggestion they will be looking into remedying this problem.  Fixing the problem always makes the customer happy… thanks Mr. Monroe and Actual Technologies.

When I first started teaching at Saint Cloud State over a decade ago, I worked with a fellow named Ted Bunn. He is a theorist, which of course means as a observational astronomer that I have to joke about how all he had to do to get a Ph.D. was “invent a particle.” The truth is however that theorists sometimes amaze me. It has taken me a decade a teaching to feel like I really understand undergraduate physics. These guys get there quicker.

Anyway, Ted now keeps a blog which often has what I find to be insightful little posts one what it is like to be a scientist. Today (June 12, 2010) Ted posted a short post about an Abstruse Goose comic about how scientists view the world:

Ted then quotes Richard Feynman on something that I think is very true about scientists:

I have a friend who’s an artist, and he sometimes takes a view which I don’t agree with. He’ll hold up a flower and say, ‘Look how beautiful it is,’ and I’ll agree. But then he’ll say, ‘I, as an artist, can see how beautiful a flower is. But you, as a scientist, take it all apart and it becomes dull.’ I think he’s kind of nutty …. There are all kinds of interesting questions that come from a knowledge of science, which only adds to the excitement and mystery and awe of a flower. It only adds. I don’t understand how it subtracts. (From What Do You Care What Other People Think?)

I’ll admit, I don’t quite see the world as equations as implied by the figure, but I am constantly fascinated by trying to understand “how things work.”  Earlier this week, I was mowing the grass and I started wondering “what are the minimal conditions necessary for a planet to form on which grass could grow?”  I started thinking about the need for the planet to be composed of the right materials, that is rock.  For a planet to be rocky, there needs to be  heavier elements like silicon and iron in the early solar nebula.  The universe started with no silicon or iron, these elements are forged at the centers of high mass starts and then expelled into the interstellar medium when these high-mass stars explode in supernova.  This means grass can only grow in a universe that has been around long enough for a few generations of high-mass stars to have lived there lives so that the fraction of heavier elements is high enough for rocky worlds to form…  This thought process  happened in a span of maybe 15 seconds… and I didn’t even get started on considering all the other factors which actually affect the ability for a rocky world to harbor life.  Scientists really do get to awe at the universe around them in a way other people don’t.