Running Amber 9 on Macintosh OS 10.x

Amber 9 should function "out of the box" on Macintosh, both with G4/G5 and Intel chips. Please report problems to the Amber mail reflector.

Running Amber 8 on Macintosh OS 10.x

Amber 8 is not officially supported on this platform, although we believe that it can be made to work. You will need to get the xfl90 fortran compiler (we used version 8.1), and the xlc "C" compiler (gcc may also work, but we have not tested this.) The configuration as given uses the IBM version of cpp; this should be in the same place as your xlf90, except the last part of tree is "exe" rather than "bin", such as /opt/ibmcmp/xlf/8.1/exe. (Go figure.) You will also need the X11 development libraries if you want to use the xleap program.

Then, use the following configuration patch to update your $AMBERHOME/src/configure file. Execute "configure macosx", and "make serial". You should be in good shape, but please remember that this has not yet been extensively tested. Below are some comments on our experiences with both G4 and G5 Macs.

  • Update, 7/30/04: Parallel jobs using lam-7.0.6 seem to run fine, at least on a G5 cluster; some timings have been posted here. These were run on a small cluster of dual-cpu G5 nodes; scaling beyond about 4 cpus is not (yet?) very good.

  • Update, 8/2/04: The above configuration file also works for tleap and xleap, provided that you have the X11 development libraries installed on your machine. X11 tests were carried out on a pretty stock e-mac loaner machine.

  • Update, 8/2/04: The sander.QMMM program is not yet functioning correctly with this configuration; this means that the antechamber tests also fail, since they also depend on the semiempirical features of divcon. We are still working on pmemd, and patches should be coming out soon. But all other features of Amber appear to be working and pass the test suite. But users should bear in mind that this is a very new port, and hidden problems may emerge in the future.

  • Update, 8/3/04: It appears that it is illegal with the xlf compiler (at least in version 8.1) to have a common block named "fopen" (!?!). Or, at least, having such a name exposes some other bug in the compiler or in our code. Go to $AMBERHOME/src/divcon and edit divcon.h to change the "fopen" block to some other name (I used "fileinfo"), and recompile. This allows the sander.QMMM and antechamber divcon tests to pass.

  • Update, 9/1/04: The pmemd program also works, if you put the following config.h file into $AMBERHOME/src/pmemd. Futher speedups are possible with code modifications, which we will be posting after further testing.