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.

As it turned out, however, one of the MPI solutions still was getting installed in the /usr directory. On a mac, this can be a big problem because the macos goes for dynamic libraries in the usual places before loading anything in /opt. Hence, I was compiling for OpenMPI, but the OS was loading either mpich, OpenMPI without fortran support, or 32 bit instead of 64. The results of which are not pleasant.

The upshot to solving this problem is that I might be able to get the GCC/g95 solution to run the model instead of the Portland compilers. I'm happy with the portland compilers, but they're expensive to keep current. So, it's time to give it another go!

My first iPhone app: rejected by the app store! Annoying, but...

I spent part of my morning fuming because my iPhone app was rejected. What made it worse was that it was rejected for false reasons. What made me a little more crazy was that there was no clear way to email whomever rejected the app a nastygram!

After I calmed down, I realized my reaction was in part because of all the other questionable rejections from the App Store. Moreover, I pondered how on earth they made the assumptions they made...

They rejected the app because when the app attempts to get data from the network, and the network is not active, there is no warning about the lack of connect. The annoying thing about this is that the application DOESN'T GET DATA OVER THE NETWORK! It doesn't use the network internally at all. All of the data is stored within the app.

Of course, after I calmed down, the obvious question arose, "why did they think that the data came over the network?" Looking at the screen shots they sent me suggested that what really happened is that they set some sort of search criteria (it's a database app) that resulted in no records being selected. Looking at what the screen showed when no records are selected was a little vague and could be interpreted that the data came over the network - it should have been clear that there were no records selected. Okay, my bad. I also decided to add alerts where a user should know there were no selected data, and when flipping a switch might cause such a selection problem.

Grr, now I have to wait another week to see if they let me in.

Cocoa in CBS' Numbers

In the final episode of Numbers on CBS, Apple's Cocoa language appears on screen. Amita is kidnapped and forced to hack into a bank. On occassion, her code appears on screen and it's clearly Objective-C! Aside from the standard Objective-C notation, [object method], there are clear Apple Cocoa classes and methods, such as NSArray and addSubview. Not only that, but the code is available online!

See Safari Books Online!

So, it's not only Cocoa, but it's iPhone code!

I'm used to Apple hardware spotting on TV, but this is my first Cocoa spotting.

Update: As it turns out, the link above will get you to the right section, but does not display the source code. If you do a search on "// recover switchview" you'll then find the source code.

Doh! My first hard drive failure in my Drobo!

It had to happen sooner or later. One of my hard drives in my Drobo failed yesterday.






As a rule, failures like these happen when there's a deadline looming. The deadline in this case is a talk my wife is giving tomorrow. Much of the imagery and data she needs are on the Drobo. The promise of the Drobo is that it should still be accessable even though a drive is out or during the rebuilding process. However, in this case, something about the rebuilding and the OS screwed up. Not only did the drobo become unavailable, the Finder on the OS locked up. As you can see from the screenshot above, the Drobo Dashboard is still working so I'm not messing with a reboot or anything until that completes. The OS itself seems quite functional under the Finder - it's just the Finder is locked up and cannot be forced quit. This is probably something related to how I set up my system rather than a failure of the Drobo or its software, but we'll see. Anyway, if there's anything else wrong with the rebuild, I'll post it here.

One thing I didn't see anywhere is how to figure out how the drive has failed. I need to look into this.

This all brings me back to the issue of adding drives in a cost-effective manner. Now that I have a dead drive, I have a choice to make. 1) Leave the bay empty, 2) Replace the drive with the smaller drive I removed earlier, or 3) buy a new drive.

Option 1 is a tolerable solution. Even with the loss of the drive, I would have a fully protected system with almost a half-terabyte free. The only issue is that there's not enough space for a rebuild should another drive fail; the data would be protected until such an event, but no rebuilding would be possible until a new drive is added.

Option 2 is tolerable as well. I can reinsert the 320 gig drive into the drobo and it would bump me back up to about 2 tb of useable space. However, at this point, the 320 might be better use as a backup drive that I store elsewhere. It's not large, but it would be good as a backup drive.

Option 3 is my preferred option, but will probably have to wait. At this point, if I'm going to add a new drive, I'd prefer the largest drive that I can afford, at least 1.5 TB. Although only 1 TB would be usable, rather than the full 1.5, it will allow some room to grow when the drobo fills up without having to buy at least 2 drives at a time. Maybe a WD green 1.5 TB drive....