Urania

One of the neat internal websites you are seeing more and more of at observatories is the use of all-sky cameras to monitor cloud cover. You spend your time in a windowless control room (so as not to let light out) so sometimes you completely miss changes in weather. I downloaded the last roughly 10 hours of video from the all-sky camera here at CTIO and am posting a Flash movie version of it. It starts off with the crescent moon setting (which is bright enough to overwhelm the camera). Then you see the center of the Milky Way galaxy rising in the East, eventually getting very high in the sky.

Since each exposure is 10 seconds, in some frames you see ‘lines’ appear, these are typically airplanes or possibly satellites.

The bright “star” to the East (left) of the Galactic Center in the last few frames is the planet Jupiter. Also in the last few frames you start seeing a glow in the eastern sky, almost pointing toward Jupiter. This is the Zodiacal light, sunlight reflecting off dust particles in the plane of the solar system. You need quite dark skies to see that.

My last observing run at Cerro Tololo, we were observing in “grey” time, when the moon was between 3rd quarter and full. So the dark sky only lasted a few hours. Now we are here during dark time, the days around new moon. Cerro Tololo is a nice, very dark site… perfect for astronomy. There is a bit of light pollution from La Serena and Coquimbo in the east and Vicuña in the north, but the sky is very dark, especially without the moon up. A large part of what makes this site so important to optical astronomy is this darkness, which is a rare commodity in the modern electric light-filled world.

I realize how dark the skies are here every time I go outside now. The Center of the Milky Way is passing overhead and it just screams out at you to be noticed. You can see it clearly on the right side of this picture, shot by Roger Smith of NOAO/AURA/NSF. It shows the 4-meter at Cerro Tololo shot at night. This is what the skies look like here. Admittedly this picture goes a bit deeper than human vision, but I would swear it isn’t much deeper. At home, we can’t see the Milky Way easily, even 15 miles from town, because of the light pollution and the fact that the Galactic Center is very far south. Here, you can’t avoid it! The Large and Small Magellanic Clouds, two irregular galaxies orbiting the Milky Way, are clearly visible to the human eye (they are on the right side of this picture).

And just a few minutes ago I saw something I have never seen before, Zodiacal Light. I am seeing sunlight reflecting off dust grains in the plane of the Solar System. Something only possible because of these extremely dark skies. Cool!

Last night was quite a misadventure for us. First, we lost the autoguiding computer that keeps the telescope pointed at its target. The able engineers here tackled it for over 2 hours, we finally decided to guide by hand… tedious, but possible. Then the fiber controller on our multifiber spectrograph flaked out. Another 3 hours lost in attempts to remedy that. In a 10 hour night, we only had about 4 hours on sources. Oh, and in the last hour or so, something I hadn’t seen at CTIO during my last run happen, high cirrus clouds came in. Blech.

Tonight is starting off better. The clouds dispersed (mostly). The autoguider is working. And while we lost about 45 minutes to fiber issues, it looks like those may be vanquished as well. Hopefully the telescope gremlins that were working against us last night will be gone tonight. We are on our first 50 minute exposure, so I am going to bang out this post quickly.

Here’s some more pictures I have taken around here during the few hours of daytime I have been awake.

This is the telescope we are using, the 4-meter Blanco telescope on Cerro Tololo. This is a stitched image composed of 6 single frames. Because I was relatively close to the telescope, there is a distortion here similar to a fisheye lens image. To get a sense of scale, notice the double doors to the lower right hand side of the telescope itself.

This is an image of the other telescopes on the peak of Cerro Tololo shot from the catwalk around the 4-meter. From left to right the larger domes contain the 60-inch (1.5 meter), 36-inch (0.9 meter), the Yale 1-meter (which I used in April 2006), and the Michigan Schmidt Telescope. There are a few smaller telescopes in the background. About 50 miles behind the telescopes is the La Silla observatory (not visible in this picture).

There were some clouds here earlier today. This is the view from the peak of Cerro Tololo towards Cerro Pachon, which the rightmost mountain in this image. On its peak you can see (as small dots in the thumbnail) the SOAR telescope on the left and the large Gemini South 8-meter telescope on the right. I love the clouds in the background rolling over clouds, towards Argentina.

This is another 180 degree panorama shot from a bit up the hill from the dormitories. It shows Cerro Tololo on the right and on the left, appearing more distant than it really is, Cerro Pachon. If you squint, you might see the Gemini South 8-meter in this image.

Finally, another 180 degree panorama of the western horizon as seen from my dorm room right around sunset tonight. Those pink clouds, illuminated by the setting sun, are over Argentina. They form over those mountains to the west of us, Cerro Tololo rarely sees puffy clouds like those, it rarely sees clouds (except in the winter), and when it does see clouds, they are high cirrus as shown in the picture above.

Another “panorama” of CTIO, this time a set of 6 photos covering about 75-90 degrees of my field of view of the dome-covered peak of Cerro Tololo as seen from the parking lot near the dormitories. I am using the Blanco 4-meter which is in the far left (largest) dome.

It was beautiful outside when I arrived yesterday, so using my cruddy little Casio Exilim camera, I shot 16 pictures of the view from outside to dormitories near the peak of CTIO. Here’s the panoramic image I stitched together from those 16 images. It’s not nearly as impressive as the real view. It covers about 180 degrees of the horizon. Click on the images for the largee versions.

Here’s a version of the image with some of the features/telescopes labeled (yes, I misspelled dormitories in the image, its not worth fixing it right now).

As noted in my last blog post, SciSoft OSX Intel 2008.3.1 was released a few days ago. While I am Cerro Tololo, last night was our “training night” on the instrument, so I did get a decent night of sleep, so I decided to take some time and see what is in this new SciSoft OSX Intel 2008.3.1 package in detail. Because I didn’t want to lose my functional version of SciSoft OSX, especially during an observing run, I first moved the directory containing my functional SciSoft OSX install temporarily out of the way via the command line: sudo mv /scisoft /scisoft_old Having done that I double-clicked on the installer package and let it do its thing, installing everything in the /scisoft directory. According the CONTENTS file at the top level of the /scisoft directory, the main changes were

• If you have SuperMongo (SM), you can request the new version. It has jumped from version SM 2.4.16 to SM 2.4.26. I don’t have a license for SuperMongo, so I can’t report much beyond this. This version of SM has Aquaterm support.
• FV, the FITS file viewer, was updated to version 5.1 from version 4.4 (they changed numbering conventions, I think). The CONTENTS file accidentally lists it as version 1.1.
• Numpy (which is used in PyRAF extensively) was updated from version 1.0.3 to the current version 1.0.4.
• stsci_python (which is also used in PyRAF extensively) went from version 2.5 to the current version 2.6.
• The mkiraf command line program that creates user’s IRAF directories appears to have been fixed for c-shell users. The bug (along with a fix) had been noted by Nor Pirzkal on his blog, so I am not surprised it was rolled into this release.
• The IRAF external packages STSDAS and TABLES when from version 3.7 to current version 3.8. The change in STSDAS includes a new package for processing WFC3 data (since I don’t use HST, I’m not that excited at the moment by this change, but I am sure someone is).
• The ESO-MIDAS version is listed as unchanged from the last release of SciSoft OSX, although the release notes just noted that “[t]his version includes a recompiled version of MIDAS (which was not tested under 10.4)”. The installed version is listed as 07FEBpl1.1 whereas the current version is 08FEBpl1.1.
• The version of DS9 included with this install of SciSoft is the current version 5.1 Aqua. This replaces the X11-based version previously included. I haven’t checked to see if it works in previous MacOS X installs, but it works fine in MacOS 10.5.2 (aka Leopard). If you do need to install a version of ds9 more appropriate to your MacOS X or if you are like me and prefer the X11 version of ds9, you can easily change the installed version.
  • If you are using an earlier MacOS X than Leopard and find the Aqua version of DS9 isn’t working, you can download an appropriate DS9 for you at http://hea-www.harvard.edu/RD/ds9/ and install it within SciSoft by noting that SciSoft OSX places the DS9 application at /scisoft/i386/Applications/SAOImage DS9.app. You could rename the installed DS9 application via the Finder or from the command line,

    mv /scisoft/i386/Applications/SAOImage DS9.app /scisoft/i386/Applications/SAOImage DS9 (Disabled).app

    then if you want the Tiger (Aqua) version there, just place it in the /scisoft/i386/Applications/ directory.
  • I happen to prefer the X11 version of DS9 usually because I use pipe files to connect my IRAF session to my DS9 session and I have found that the Aqua version of ds9 doesn’t seem to play nicely in this regard. Its for that reason I installed the X11 version over the command line ds9. To do this, I noticed the command line ds9 is at /scisoft/i386/bin/ds9 and is just a symbolic link to the ds9 binary within the Application. You can just rename this symbolic link at /scisoft/i386/bin/ds9 from the command line:

    mv /scisoft/i386/bin/ds9 /scisoft/i386/bin/ds9.old

    and place the executable ds9 file that is in the X11-version tarball of ds9 there instead.

    mv ds9 /scisoft/i386/bin/ds9

    This has the added advantage of leaving the Aqua version of DS9 completely intact.
• I noticed this version of SciSoft OSX does install with me as the owner (instead of user 502). I don’t know if that is because it is defaulting to user 501 or because a change occurred in the SciSoft OSX installer, but its a welcome change.

That’s it for what I have noticed for now. This update addressed all of the issues I has noted with the previous version. Thanks guys! One very mild issue I have with this version of SciSoft OSX. I noticed the RVSAO external package for IRAF included with this version of SciSoft OSX is Version 2.5.7. That’s several versions older than the current version. Its easy enough to install the current version in another directory (I use /usr/local/iraf) and then edit the /scisoft/all/packages/iraf/iraf/unix/hlib/extern.pkg file to point to the newer install, but I thought I would note that.

I am Cerro Tololo preparing for our observing run starting tomorrow night with the Blanco 4-meter, so I don’t have much time right now to analyze the new version of Scisoft OSX that was released today, but it looks like they addressed quite a few of my comments from before about some of the Aqua applications being out of date. Here’s the release notes:

Scisoft Intel 2008.3.1 is available. This version includes a recompiled version of MIDAS (which was not tested under 10.4), updates to STSDAS/TABLES and a few other packages such as FV, STScI_Python, and DS9 Aqua.

I’ve placed a copy Scisoft OSX Intel 2008.3.1 on the online mirror, but I will also keep last few versions around for a while until I can evaluate this one. I suspect users may this version of SciSoft OSX may have issues running under 10.4, given the comment above in the release notes. I believe if you install DS9 yourself, you have to install the version specific to your MacOS version.

I am having an interesting problem. In my last post, I noted that on some Macs with Leopard installed, deactivating the lines calling /usr/libexec/path_helper in the /etc/profile file fixed LaTeXit hanging at launch. A bit more investigation by Antonio Molins (posted in the comments to that post) revealed it was possible to add an ASCII file in the /etc/paths.d directory. We could create a file called /etc/paths.d/macports containing the only the line

/opt/local/bin

and it should automatically add everything in macports to most user’s PATH variables. However, when I tried this, all my calls to /usr/libexec/path_helper -s always locked up the command.

Some further investigation revealed new user accounts on my Macs didn’t have this problem. I surmised that since I was setting up the PATH and MANPATH variables in my environment at login, that this could apparently lock up path_helper. Since I use tcsh by default (instead of Apple’s default bash shell), I issued the following two commands from the command line

unsetenv PATH
unsetenv MANPATH 

and sure enough path_helper worked without an issue. So something is buggy in path_helper, or at least hypersensitive to pre-existing PATH environmental variables. I’ll have to investigate this more later. One thing I did discover is that

/usr/libexec/path_helper -c 

will produce the commands to set up tcsh’s environment.

/usr/libexec/path_helper -s 

returns those for the default bash shell.

[A better fix to this problem is to upgrade to LaTeXit 1.15, which was released on April 16, 2008.  It fixes the problems with Leopard and allows you to keep the default /etc/profile file for Leopard.]

Apparently, LaTeXIt, which I use to generate equations with Latex which can then be copied into Apple’s Keynote and Pages documents, locks up on launch a vanilla install of Leopard. This post on MacOSXHints.com provides a hack, but it wasn’t that nice, since it involves re-installing a particular version of latex. It turns out the solution was really much simpler and shows up in the comments on that page. In the comments, user Paolo Bosetti notes that

There is actually a much easier workaround: simply change your /etc/profile commenting the following lines (add the “#” at the begining):

# if [ -x /usr/libexec/path_helper ]; then
# eval `/usr/libexec/path_helper -s`
# fi

and adding the following two:

PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/local/bin:/usr/X11/bin"
export PATH

Why so? Apple changed the Leopard way to set the PATH variable, and now it uses the /usr/libexec/path_helper command, which seems having troubles with LaTeXiT spawned bash scripts. If you make this modification to your /etc/profile, you are simply dropping the new path_helper in favour of the plain old way to set the PATH variable.

This also explains why I wasn’t seeing this on my laptop, since it kept the old /etc/profile file during the upgrade.

Another user comments that the fix could also be done without hacking the /etc/profile but instead just changing ~/.profile such that /opt/local/bin appears in the path last, since /usr/libexec/path_helper is supposed to read ~/.profile. However, I was unable to get this approach to work.

Since switching to Leopard on my server earlier this week, I have noticed that file transfers over the Ethernet LAN at work are insanely slow. I frequently synchronize files (over AFS File Sharing) over an Ethernet LAN between my server and my MacBook Pro. My MacBook Pro has been running Leopard for several months while my server was running MacOS 10.4.11 until this week. Having been happy with Leopard on my MBP, I decided to upgrade my server. Since then, file transfers between the two computers have been a royal disaster. When I initially connected I was getting speeds of up to 1.5 MB/s, but it quickly drops to 30KB/s or less. This was much less than the 10MB/s speeds I was typically seeing before upgrading my server to Leopard. I couldn’t quite figure out the pattern. It did seem the speed uploading files to my server was not as affected as downloading from my server.

Given the fact I didn’t see any file transfer issues between the two computers before upgrading the server to Leopard (MacOS 10.5.2), I suspected the issue was solely with the server (or possibly due to the communication between two computers running Leopard). On a hunch that the “self-tuning” networking heralded (quietly) on Apple’s Leopard Features page might be the problem, I tried to turn it off by tinkering with the “Advanced” settings in the Network Preference Pane. Specifically I changed the settings to look like this:

Notably, I forced the configuration to be manual (instead of “Automatic”), I set the “Speed” to “100BaseT” which is my LAN’s speed (instead of “autoselect”), and I set the “Duplex” to “full-duplex” without “flow control”. I left the “MTU” at “Standard (1500)”.

Making these changes seems to have done the trick. For the last hour my network has maintained speeds of about 10 MB/s on download, something it hasn’t been able to do for the last few days. I suspect Apple has some work to do on their “self-tuning” Network code.

[Followup Post: Yes,this pretty much fixes my network slowdowns. I just did some Bandwidth tests online, I'm back up to my pre-Leopard speeds.]

There is a great article online at Scientific American’s website investigating the claim that Arthur Eddington and Frank Dyson might have “cooked” the data from their solar eclipse observations in 1919 in a way that supported Einstein’s (then new) General Theory of Relativity:

On May 29, 1919, two British expeditions, positioned on opposite sides of the planet, aimed telescopes at the sun during a total eclipse. Their mission: to test a radical theory of gravity dreamed up by a former patent clerk, who predicted that passing starlight should bend toward the sun. Their results, announced that November, vaulted Albert Einstein into the public consciousness and confirmed one of the most spectacular experimental successes in the history of science.

In recent decades, however, some science historians have argued that astronomer Sir Arthur Eddington, the junior member of the 1919 expedition, believed so strongly in Einstein’s theory of general relativity that he discounted data that clashed with it. [From Fact or Fiction: Did Researchers Cook Data from the First Test of General Relativity?]

The nice thing is this article illustrates one of the less well-appreciated challenges facing the functional scientist: distinguishing between bad data and data that conflicts with your theoretical expectations. Bad data, like other things in life, just happens. And when it happens, it can be a pain to deal with. How do you know when the data is “bad” (that is, the result of a problem at the telescope or a glitch in your software) versus when the data simply conflicts with your theory? In one case, getting rid of the data makes sense. However, being over-eager to reject conflicting data may make you reject a completely compatible alternative interpretation to your observation. Furthermore, if your data seem to support a controversial theory, you should be fairly confident your results are not the result of “bad” data. As Carl Sagan said in Cosmos , “Extraordinary claims require extraordinary evidence.” You have to be pretty confident you haven’t made a mistake if your data strays far from what you expect. Knowing the difference between “bad” data and data that supports a different theory the human part of the science I try to teach my students about. It is also the reason peer-review is such an incredibly important part of the scientific process.

By the way, the verdict of the article’s author is that Eddington and Dyson did the right thing. It turns out it was actually Dyson, who was initially inclined against Einstein’s theory, who made the decision to toss the bad data out. The final results when published^[1] supported Einstein’s General Theory of Relativity, which still stands as the most well-supported model for gravitation to this day.

The nice thing about MacOS X 10.5 Leopard is that it comes with PHP 5.2.4 pre-installed. Unfortunately one of the features Apple choose not to compile in was support for the GD graphics library, which I use extensively. Furthermore compiling in new features has proven to be somewhat troublesome. When I tried to configure PHP 5.2.5 on my Leopard box which the following commands (a variant of the configure command I would issue under Tiger with no complaints):

./configure --prefix=/usr --mandir=/usr/share/man 
   --infodir=/usr/share/info --disable-dependency-tracking 
   --with-apxs2=/usr/sbin/apxs  
  --with-ldap=/usr --with-kerberos=/usr 
   --enable-cli 
   --with-zlib-dir=/usr 
   --enable-trans-sid 
   --with-xml 
   --with-dom 
   --enable-exif 
   --enable-ftp 
   --enable-mbstring 
   --enable-mbregex 
   --enable-dbx 
   --enable-sockets  
  --with-iodbc=/usr 
   --with-curl=/usr 
   --with-iconv=shared,/opt/local
   --with-openssl=shared,/opt/local
   --with-xmlrpc 
   --with-xsl=/usr 
   --with-config-file-path=/etc 
   --sysconfdir=/private/etc 
   --with-gd=/opt/local --enable-gd-native-ttf 
   --with-jpeg-dir=/opt/local 
   --with-tiff-dir=/opt/local 
   --with-png-dir=/opt/local 
   --with-freetype-dir=/usr/X11 
   --with-xpm-dir=/usr/X11 
   --with-pdflib=/opt/local 
   --with-gettext=/opt/local
   --with-mysql=/usr/local/mysql 
   --with-mysqli=/usr/local/mysql/bin/mysql_config 
   --with-pdo-mysql=/usr/local/mysql 
   --without-pear

The result was a failed configure due to an error in mysql configuration. I pinned this down to a request for a library at /usr/local/mysql/lib/mysql/libmysqlclient.15.dylib which is actually located one directory up. This can be fixed via the command line using:

cd /usr/local/mysql/lib
mkdir mysql
cp libmysqlclient.15.dylib mysql/libmysqlclient.15.dylib

Then the ./configure worked just fine. Unfortunately, when I did a

make
make test

to compile the PHP and test it, there was no happiness. There were over 50 errors, some of them major. Crud. This is just the setup. See, all I needed was GD graphics library support in PHP for my website. Well, after googling for some time for some master hacker’s notes on getting PHP 5.2.5 to compile on Leopard, I discovered a fellow named Hill Pei had hacked GD support into the Leopard PHP without too much effort. His method simply requires some comfort with the command line and editing text files. In five minutes, I had GD support with Leopard’s built-in PHP. Excellent! [Despite a report in the comments to the contrary. This still appears to be necessary if you apply Security Update 2008-002, which installs PHP version 5.2.5. In which case, you should grab the php 5.2.5 code and work from there. I can confirm Hill Pei's instructions do work after Security Update 20008-002 if you grab the PHP-5.2.5 code instead of 5.2.4 as he suggests.]