Macintosh
Climate Model on a Mac: Snow Leopard
Snow Leopard, the latest OS offering from Apple, promised to be both 64-bit and faster. The question is whether Apple delivered those promises and whether those improvements impact modeling.
First, I got Snow Leopard booting to the 64-bit Snow Leopard kernal. There are instructions how to do this out there on the web (note that you don't have to bother if your machine is 64-Bit and you're running the server version).
More info below the fold..
Climate Model on a Mac #15: Watch those dynamic libraries!
I recently upgraded my PGI compiler to version 8, and I had tons of trouble getting the climate model to compile and run. In this case, I decided to switch from mpich 1.2.7 to OpenMPI, on the hopes it would be better for the system and easier to set up.
However, nothing linked properly. If the software compiled, then it would have tons of MPI related errors. As a rule, I install all the libraries needed to run the model in the /opt directory, since it's easier to have more than one version of various libraries (different versions, different compilers, 32 vs 64 bit, etc), so I didn't think there could be a conflict in the libraries.
My Drobo: A few months in...
Well, I've had my drobo for a while now. I really have no complaints on the hardware; it works as expected and works well. I do have issues, however.
My first issue is my own behavior. I sometimes fail to RTFM. In this case, it was the part of the manual on formatting. I simply formatted the drobo from Disk Utilities. If I had RTFM, I would have learned that the standard format was for 2 TB volumes - if you stick more available space in the system, you'd get multiple volumes. The drobo can be formatted to anticipate a volume of 16 TB, which would have made more sense to me. The drawback to this format is slower boot times, but I'm okay with that. In any case, it's simply a matter of reformatting the drobo and start over. Unfortunately, I have the older USB 2.0 drobo and offloading the data took at least a day (and some struggling to find the disk space). Now, the drobo is reformatted and I've started the process of moving all the data back! ugh! take my advice, if you get a drobo, RTFM.
Revamping my data protection plan
Revamping might not be the right word, since I don't have a written plan, but I'm at least re-evaluating what I do to protect my data.
In the last week, I've been more seriously considering "cloud-based" data storage; that is, storing data on someone else's server out there on the "internets". The advantage of this is that if my computer is stolen, house burns down, or a tornado hits (there have been 2 near misses over the last few years), data in the cloud would be preserved. Thus, it can be effective off-site storage solution.
Refactoring your code!
My current programming project is Objective-C application for MacOSX to generate climate model results in the form of a web site and a PDF. It's actually a complete write of an existing application.
Why rewrite? The original code was built over many months, is stringy, and very hard to maintain. To get an idea of how hard, I've tried to rewrite this application five (yes, 5) times. The original application was designed to generate NCAR Command Lanaguage (NCL) scripts that generate hundreds of images based on climate model results. From there, the application generated makefiles that would continue the processing by running NCL for each script, convert the resulting postscript images into jpegs, and finally using FOP and Docbook to generate HTML and PDF documents with all the images and some related text.
The Drobo so far
With the Drobo up and running, I'm feeling a little safer. Right now, I have about 2 TB of disk space, which gives me just under 1 TB of available disk space. Of that space, I've used about half.
Overall, I'm very happy with the system. The largest drawback in this version of the Drobo is the USB 2. USB 2 is painfully slow compared to Firewire and SATA. However, in the way I'm using the system, the slow speed is tolerable.
Another test of my backup strategy
It happened again! I had a hard drive crash. This time, the drive was a Seagate 1 TB drive about 60% full.
So what was my backup strategy and did it work?
I have three basic methods of backing up:
1. Time Machine - I use time machine to manage the backups of my laptop.
2. Backup to DVD - This method I was hoping to end. It's time consuming and hard to use with large groups of files. However, this has been relatively reliable.
3. Drive "mirroring" - Using tools such as rsync to maintain a second copy of a hard drive.
Whither MacOS 9 Classic: Time to update my data
The following was a post I started a while ago and I'm not sure if I finished it. So, here's a quick re-write...
In practical terms, MacOS 9 is dead, again. Now that Leopard doesn't support "classic" mode, the Mac universe is going OSX... finally. On the other hand, Classic made me lazy. I have tons of stuff still floating about that is not OSX compatible. Now, I'm forced to do the unhappy task of data migration.
Climate model on a mac project: #14 Knowing when you quit...
When not using a scheduler like Torque/PBS, it can be complicated to find out whether the model has quit. If the run was successful, you can have a reasonable idea when it SHOULD quit, but it might crash long before that time. As a result, you've lost hours, if not days, of computing time.
Climate model on a mac project: #12 In Production!
At last, the new machine is now doing production work and I've run almost 24 hours so far. First, it's running a bit slower than anticipated, about 13.5 model years per day. I'm not sure what's causing the slower speeds, but it's still an acceptable speed considering my original estimate was only 7 model years per day.
Temperature remains a worry for me. The CPU temps seemed reasonable, but the RAM temps seemed rather high for long-term processing. So, I ordered some fans to cool the RAM boards.
