Shelxtl XP on a Mac

Update 22/01/29: This works properly on MacOS 12.2 'Monterey', but it appears that the X11 files have all been moved. As such, XP complains about a missing file (/usr/X11/lib/libX11.6.dylib). To workaround this problem, place a copy of libX11.6.dylib in /usr/local/lib.
Update 21/11/01: On an M1 Mac Mini, XP runs fine using XQuartz 2.8.1 (but apparently not versions later than that) without any need for the stuff below. Rotation in PROJ is smooth and fast enough for normal usage, except for rotation of anaglyph stereo (which I never use anyway).
Update 2021/06/24: 'Big Sur' appears to bollocks it up, so be warned. I went back to 10.14.6, so much for progress. The problem was the missing lib file, which is fixable (see above update 22/01/29).
Update 2019/06/07: The fix here works well on a 15" MacBook Pro (2016) running MacOS Mojave (version 10.14.6). Sometimes, it seems to run better if the xp-proj-enabler is set to 'iconic' in the xp-launcher script. I put a commented out line for this in the script, so it should be easy to set. Try it with and without and pick which works better.

Shelxtl XP, written by George Sheldrick, used to work very well on OSX 10.4. With the X11 that comes with OSX 10.5 and later, however, performance is poor. PROJ rotation of small structures is painfully slow, but for larger structures or extended atom lists, such as what you get after GROW or MGEN, rotation can be fine. The official explanation is that the slow down is due to "many layers of inefficient code". However, large atom lists rotate quite well with PROJ, so something else is going on. If that were the reason, then why did it work so well on OSX 10.4 and why would performance be worse for small atom lists? Maybe a fresh compile would help, but the source code is not available. I had a fix for this problem on OSX 10.5 and 10.6, but that solution does not work on OSX 10.9 (or later) so I had to find a different workaround.

This document describes a simple fix for the lousy PROJ rotation in XP on OSX 10.9.x and later. It probably also works for OSX 10.7 and 10.8, but I haven't tried. Also described here is how to use an unmodified XP executable without having to hand edit any of the newer SHELXL commands (e.g. RIGU) that the now deprecated XP does not understand. How it does this is explained below. In addition, a way of setting some run-time preferences that can't be set using the sxtl.ini file is described. Lastly, a script to automatically convert XP-created *.plt files into PostScript (and PDF) files is included. This might sound like a lot of work, but really it's not too complicated. Once the scripts are in place it is almost totally transparent, so you can work pretty much the way that you are used to working. Note that in addition to the scripts given here, you will also need to install the expect scripting language if it is not already installed on your system.

Aside: I did an experiment in which I disabled three of the four cores on my MacBook. With only one core, PROJ rotation (without my fix) was smooth, but too slow. I also tried it with all four cores enabled but hyperthreading disabled, but that was still choppy. It therefore seems likely that there are two problems. One could well be "many layers of inefficient code". The other seems more like a 'race condition', in which cores get stuck waiting for each other to catch up. Whatever the cause, the following fix is still good. Also worth mentioning is that it is quite possible to make xp-launcher more sophisticated. For example, on my MacBook it queries the OS to get the screen resolution, and sets a larger WSIZ in XP if an external monitor attached. This also works on the 'Retina' MacBook screens to allow well-sized XP windows for the higher resolution settings. If you're interested in how to do this, please send me an e-mail.
Anyhow, here's what to do:

1) Get the following files from the UK X-Ray Facility website:

These scripts, as well as other programs and workarounds are kept here. The scripts are just text files that contain either bash or expect code.

2) Copy these files to /usr/local/bin and make them all executable. Depending on your Mac's settings, you might need 'sudo' to do this. Something like the following should work. Type (or copy/paste) these lines on a terminal or xterm command line and hit return after each line:

3) Rename your copy of the executable file for XP to 'xpx'. If you are squeamish, you may want to make a backup copy beforehand. It might be easier if you change directory to /usr/local/bin, i.e. like this:

4) Rename your copy of xp-launcher to 'xp':

5) I use a custom xterm for XP. To automatically start a custom xterm, use a .xinitrc file in your home directory. Click here for an example. This file is read whenever X11 starts. My .xinitrc opens a yellow on near-black xterm on the far right of the screen with the title "xterm for XP", and changes directory to my in-progress structure files. You might want to modify it to suit your own aesthetics and workflow. I think the syntax is straightforward enough, but feel free to ask me if you need help.

If you have followed the above instructions properly, everything should be in place to trick XP into civilised behaviour on newer Macs. There are, however, a few things you might want to tweak. Before going into more detail, here's a brief explanation of what happens when you launch XP from an xterm command line using the method described here.

If you have used a variant of my .xinitrc file, when you start up X11 you will automatically get a near-black xterm with yellow text. The window position and size are optimized for my flaptop, so you may want to experiment with the "-geometry 82x67+1168+0" numbers in the last line. For me, an 82 column x 67 row xterm positioned snug against the top-right side of the screen works well. This size is not just pulled out of thin air; it is set that way on purpose (see below).

Once the xterm window has launched you need to change directory to the place where your structure is located. My .xinitrc file automatically changes the directory to ~/Structures, but you can set it to go where you like. Once in the directory of choice, you start XP exactly as you would expect, i.e. by typing "XP filename" at the xterm prompt:

Now, rather than starting XP directly, the xp-launcher script that you downloaded, installed and renamed (to xp) will run. There are some details within the file to explain what it does, but a brief explanation is in order.

The first thing to happen is that xp-proj-enabler opens a small xterm in the top-left corner with an innocuous print loop running in it. Strange as it may seem, it is this seemingly useless print-to-the-screen loop that cures the choppy rotation problem in PROJ. The xp-proj-enabler window will be hidden from view by the XP graphics window. As an alternative you can minimize it to the dock if you like (there's a commented out line in xp-launcher that does this via the -iconic flag). You might also try experimenting with the "sleep 0.05" line in xp-proj-enabler. A smaller number makes the rotation smoother, but slower. You could also replace the "sleep" instruction with one or more "wait" instructions. This can make it even smoother, but the speed will depend on your system. On my new flaptop (2016 MBP, 15") this gives comparable results to the sleep instruction.

The next thing to happen is that xp-launcher creates a backup of the *.res file. It then edits the working copy of the *.res by inserting "REM" in front of all the SHELXL instructions that XP doesn't understand. A more detailed description is included within the xp-launcher script, which explains the handling of *.res vs *.ins files. I tried to make it behave as similarly as possible to running XP in the usual way, but there are, of necessity, a few minor differences. Nevertheless, it does a good job for the most part. One major advantage of starting XP this way, as opposed to hacking the binary executable (ask me for details), is that as new instructions are added to SHELXL, it is trivial to simply REM them out in xp-launcher.

Once the working copy of the file has been edited, the expect script xprun is invoked to actually start the XP executable [which was renamed to 'xpx' in step (4) above]. The advantage of doing it via an expect script, rather than simply calling the XP executable directly, is that expect allows you to set a few preferred defaults that cannot be set with Bruker's sxtl.ini file. You can modify xprun to do different things from mine - the syntax should be pretty obvious. My copy is set to specify an XP graphics window size that depends on which screen (laptop or external monitor) is in use. That's an extra complication that you might not need. If it is unclear, please ask me. On my flaptop, such a window size fits perfectly side-by-side with, and is the same height as the 82x67 "xterm-for-XP" text window. Note that I also have a commented out "WSIZ 800" entry that works well with some lecture theatre projectors (so is useful for teaching). As with the other scripts, the xprun text file includes additional detailed notes.

The last two scripts mentioned above are used to automate generation of *.PS and *.PDF files of ellipsoid and packing plots etc. These scripts are not necessary for smooth running of XP on the Mac, but I find them to be extremely useful. In short, they automatically convert any XP *.plt file in the working directory into *.ps and *.pdf files. To use them, you have to create your XP plot files in the usual way (e.g. with TELP). Then, instead of using the XP command "DRAW" to write PostScript files, you use the bash script xpdraw (which calls plt2ps, an expect script). This can be done from within XP like this:

Or after quitting XP, like this on the command line:

The rationale behind these scripts is to minimize repetitive typing. If you do a lot of structures, it is a tedious time sink to have to explicitly DRAW each and every *.plt file individually. A burden that is automated by xpdraw and plt2ps.

Aside from xp-proj-enabler, the rest of these scripts can be used on gnu-linux installations too, but you might have to manually install expect (e.g. using yum or whatever installation tool you use). If you try these things and they don't behave the way you expect, please ask me. It all works seamlessly for me, so it should also work for you. I have this all (and more) running on my flaptop and on a MacMini and several linux computers (sans xp-proj-enabler) in the UK X-Ray lab. It all works flawlessly.