Kudos to the NSF for standing up to Rep. Lamar Smith

Kudos to the NSF for standing up to Rep. Lamar Smith

Rep. Lamar Smith (R-TX) demanded that the NSF turn over peer reviews of funded proposals that he doesn’t like.  The NSF told him, flatly, no.  Right on.


Nature Turning Point’s interview with Carl Boettiger

CSGF alumnus Carl Boettiger is featured in a recent edition of Nature: Turning Point.  Much of the interview focuses on Carl’s open research notebook, a bold experiment in sharing research as it is being done, before it’s actually “research product.”  Kudos.

“Were you afraid of getting scooped?

That concern is there, but I haven’t experienced any scoops. I think it is an overrated fear, especially when compared with the risk of being unknown in your field. My notebook has helped me to extend my reach in ecology and computing. People were aware of me before I had published — which led, for example, to invitations to review papers. If anything, I was reluctant to put things up in case they contained mistakes. Every mistake that I made during my PhD is in there. But if I am trying to resolve an error, I can easily show others all the work I have done and the steps I have taken, and ask them for advice.”

Hot off the presses: my new review article on electrostatic models for proteins

My second article in the open-access journal Computational Science and Discovery has been published.

The article, a rather sizable review of implicit-solvent models for proteins and other molecules, is here; the odd title is a punning nod to one of my favorite bands, Rancid (see here for the reference).

I had always wanted to write a different kind of review article, one which provides more philosophy and an integrated view of progress; the process of writing this one revealed just how hard that is.  For one thing, many reviews are written to meet deadlines.  Academics tend to be fairly busy types (“If it weren’t for the last minute,” quipped one mentor, “I wouldn’t have any minutes at all.”) so that many reviews end up being annotated bibliographies: “The group of X has been looking at Y [1, 2], which is new.”

My thanks to the numerous individuals who slogged their way through early drafts to provide really helpful comments and suggestions (among others: Geoff Oxberry, Matt Knepley, Ahmed Ismail, Christopher Rinderspacher, and Matt Reuter).  I am especially indebted to Nathan Baker and Dirk Gillespie for encouraging me to get my thoughts together for a review article.  Your comments and criticisms are welcome as well!


Talk about your two cultures!

Georgia Tech’s Prof. Lipton has posted an amazing story that you’ll enjoy.

It’s about Frank Ryan, the NFL quarterback with a PhD in math, who was a professor at Case Western Reserve University while he was still a star in the NFL.

Prof. Lipton notes that today no NFL team would sign a player with such a significant outside commitment, and of course he’s right.  On the flip side: how do faculty hiring committees and promotion committees view outside activity?

Also, beyond the epic awesomeness, Prof. Lipton makes an interesting point about his former teacher’s approach to teaching mathematics.

Thanks to Matt Knepley for the link.

P.S. Yes, I know these aren’t the two cultures C. P. Snow discussed.  That’s the joke.

Lanczos and Einstein’s correspondence

Lanczos once wrote to Einstein about his work on iterative methods,

“The reason I am interested very much in dealing with methods of approximation is not the practical applicability of the solution but rather the fact that a very ‘economical’ solution is possible only if it is very ‘adequate’ too.  To get a solution in a few steps means nearly always that one has found a method which is consistent with the intrinsic nature of the problem.”

Einstein replied,

“Your remark concerning the significance of the adapted approximation methods is very enlightening, and I am convinced that it represents not merely a practical method but also is a promising mathematical viewpoint.”

[Via C. Brezinski , L. Wuytack, “Numerical Analysis in the 20th Century,” the Introduction to the volume “Numerical Analysis: Historical Developments in the 20th century” (eds. Brezinski and Wuytack, North-Holland, 2001)]

Installing VMD with Python options on a Mac

Backstory: To simplify my workflow, I’ve been learning Python so that I’m not constantly switching between Matlab, C, Perl, and Tcl.  I use a Mac, and due to the rather baroque set of options in Mac software development the VMD developers have sensibly chosen to not provide Python functionality in their binary distributions for Mac.  This week, I spent some time figuring out how to build it.

The biggest help by far was Reid Van Lehn’s (RVL’s) detailed post on the VMD mailing list.


My system:

  • MacBook Air running OS X 10.7.5
  • MacPorts gcc 4.2.1 with SciencePorts ( https://bitbucket.org/seanfarley/scienceports )… I would like to give a shout out to my friend and colleague Sean Farley, who is my go-to expert on all things Mac and especially MacPorts.
  • For Python, I used the 64-bit Enthought Python Distribution for access to SciPy and many other packages.

It is likely that this installation process could be simplified further.  I don’t quite have time at the moment.

Happy to post more system details if people ask for them; off the top of my head, I don’t know what else might be relevant.

1. My build directory is

and it holds


2. cd ~/tmp/vmdsrc/ ; mkdir fltk ; mkdir tcltk

3. tar -xzvf *.gz

4. Build and install FLTK to the place you want it (dummy directory here)
cd ~/tmp/vmdsrc/fltk-1.3.2
./configure –prefix=/Users/jbardhan/tmp/vmdsrc/fltk
make install

5. Build and install Tcl to the place you want (perhaps not in a system directory…)
cd ~/tmp/vmdsrc/tcl8.5.13/unix
./configure –prefix=/Users/jbardhan/tmp/vmdsrc/tcltk –disable-64bit –disable-corefoundation
make test
make install

Note 5.0: Notes on compiling Tcl/Tk are at http://www.tcl.tk/doc/howto/compile.html

Note 5.1: I disabled 64 bit following the earlier instructions from RVL, but I’m
not sure what this does since everything else was built 64 bit, and
nothing died.

Note 5.2: I built with corefoundation disabled because I was hoping to use this
Tcl/Tk installation to build PyMOL from scratch. That turned out to be impossible,
so this is probably unnecessary.

Note 5.3: A number of Tcl tests fail: httpold-4.12, exec-9.7, platform. Googling
wasn’t so helpful, except to see that other people have the same problems.

6. Build and install Tk
cd ~/tmp/vmdsrc/tk8.5.13/unix

./configure –prefix=/Users/jbardhan/tmp/vmdsrc/tcltk –with-tcl=/Users/jbardhan/tmp/vmdsrcd/tcl8.5.13/unix/ –disable-xft –disable-64bit –disable-corefoundation
make test
make install

Note 6.1: I disabled xft because it was giving me problems. The fonts
in the resulting VMD are definitely a step down, so this would be a
good problem to fix.

Note 6.2: A bunch of things fail during the test. clipboard-6.2,
focus-5.1, font-21.15 crashes the test suite.

7. Now on to the actual VMD side of things. Plugins are compiled first.

cd ~/tmp/vmdsrc/vmd-1.9.1/plugins
export TCLINC=”-I/Users/jbardhan/tmp/vmdsrc/tcltk/include”
export TCLLIB=”-L/Users/jbardhan/tmp/vmdsrc/tcltk/lib”
export PLUGINDIR=/Users/jbardhan/tmp/vmdsrc/vmd-1.9.1/plugins
make distrib

Note 7.1: Big difference from RVL’s instructions: I actually used
MACOSXX86_64 architecture, whereas he said to use MACOSXX86.

Note 7.2: The last two lines copy all the needed compiled plugins into
the VMD source directory. I didn’t understand RVL’s Steps 8 and 9 a
at first, but do now; the above instructions do what he said.

8. Time to start the pain.

cd ~/tmp/vmdsrc/vmd-1.9.1

edit configure.options to read

edit configure for the final destination of your VMD scripts and files:
$install_name = “vmdpy”;


cd src

edit the Makefile so that
a) I commented out VMD_OTHER_EXE and VMD_OTHER_NAMES because I don’t use those

b) INCDIRS = -F/System/Library/Frameworks -I../lib/tcl/include -I../lib/tk/lib_MACOSXX86_64/Tk.framework/Versions/8.5/Headers -I../plugins/include -I../plugins/MACOSXX86_64/molfile -I../lib/fltk/fltk -I. -I/Users/jbardhan/tmp/vmdsrc/fltk/include -I/Users/jbardhan/tmp/vmdsrc/tcltk/include -I/Library/Frameworks/EPD64.framework/Versions/7.3/include/python2.7 -I/Library/Frameworks/EPD64.framework/Versions/7.3/include/python2.7

c) LIBS = -lfltk_gl -lfltk -framework ApplicationServices -framework Cocoa -framework OpenGL -frameemacwork AGL -L/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/config -ldl -framework CoreFoundation /Library/Frameworks/EPD64.framework/Versions/7.3/Python -lpthread -lpthread -ltk8.5 -ltcl8.5 -lmolfile_plugin -framework Carbon $(VMDEXTRALIBS)

d) LIBDIRS = -F../lib/tcl/lib_MACOSXX86_64 -F../lib/tk/lib_MACOSXX86_64 -Wl,-executable_path . -lmx -L../plugins/MACOSXX86_64/molfile -L../lib/fltk/MACOSXX86_64 -L/Users/jbardhan/tmp/vmdsrc/fltk/lib -L/Users/jbardhan/tmp/vmdsrc/tcltk/lib

e) remove “-m32” from CFLAGS and CPPFLAGS
make depend


make install

Note 8.0: I’m using a different install_name so that I know which vmd
is a standard binary download from their website, and which is my
custom build with Python.

Note 8.1: I’m not sure about pthreads, but everything else seems

Note 8.2: At one point with a different set of configuration options,
I needed to add a space at the end of the line, otherwise the script
would not identify the last word/option on the line (it would truncate
by one character, e.g. complain about PTHREAD not being a valid

Note 8.3: I did not have problems with VMD hanging upon startup, so
I skipped RVL’s step 14, but that may be because I’m building with a
new Tcl/Tk/FLTK rather than with those from MacPorts, see

Note 8.4: The link stage when you run just “make” will seem to crash!
/Developer/Tools/Rez -t APPL -o ../MACOSXX86/vmd_MACOSXX86 vmdmac.r
### /Developer/Tools/Rez – SysError -120 during create of “../MACOSXX86/vmd_MACOSXX86”.
### /Developer/Tools/Rez – Fatal error trying to open the resource file “../MACOSXX86/vmd_MACOSXX86” for writing.
Fatal Error!
### /Developer/Tools/Rez – Fatal Error, can’t recover.
### /Developer/Tools/Rez – Since errors occurred, ../MACOSXX86/vmd_MACOSXX86’s resource fork was not written.

However, the binary is written and seems to run fine. This is the
most worrisome part of the build =) Without “-framework Cocoa” I
always found at the link stage weird things happening. Undefined
symbols for architecture x86_64: “_objc_msgSend” , “_NSApp”,
“_NSFilenamesPboardType” and the FLTK examples all include Cocoa,

9. Edit the script install_name (here vmdpy) which has been copied to your
install_bin directory. Change MACOSX to MACOSXX86.

10. Check if you’ve gotten everything up and running:

a) run the install_name script, which should bring up your standard
two windows.

b) type “gopython” to enter python mode.

c) if you see “module VMD not found” you have a problem.

d) check you have the version of python you want, by running
import sys
print sys.version
Other notes:
1. You _have_ to compile the VMD plugins directory before you try the
main directory. This wasn’t clear to me from stepping into the
vmd-1.9.1 directory, but it is clear once the configure dies and you
start Googling.

2. FLTK is _required_ for the familiar VMD interface. This wasn’t clear
from the installation/configuration options, but again it’s clear from
a moment’s Googling.

BEM++ : Cool new library for boundary-element method (BEM) simulations

BEM++ offers attractive high-level interfaces for doing BEM calculations in Python and C++.

Currently it supports Galerkin BEM for the Laplace, Helmholtz, and modified Helmholtz (Yukawa or linearized Poisson-Boltzmann) equations, using planar triangle boundary elements with either piecewise-constant or piecewise-linear basis functions.  Support for collocation or qualocation would be nice, and it seems like these can be implemented pretty easily.

For fast BEM, the library supports AHMED (H-matrix based) representations only; coupling BEM++ to tree codes or fast multipole methods would be really important to me in production-level work.  At the moment, I’m really just happy to have a high-quality implementation for hypersingular operators.

I’ve gotten BEM++ installed and running without much trouble at all, and I look forward to giving it a real workout over the Christmas holidays (when I’m done teaching).

Congratulations to the BEM++ team, and thanks for releasing it as open-source software under the BSD license!