Author: jbardhan

Walter Rocchia at Istituto Italiano di Tecnologia in Genova, Italy has posted an opening for a postdoctoral position in his group for “development of computational tools for implicit solvation and continuum approaches.”

Walter is a terrific, thoughtful scientist and would be an awesome person to work with.  If I were just finishing my PhD now, this would be a dream job!

If you’re about to finish a Ph.D. in computational science (or closely related field), you should look at the excellent J. H. Wilkinson Fellowship at Argonne National Lab’s Mathematics and Computer Science (MCS) Division.   They are now accepting applications for the 2014-2015 fellowship!   I was honored and humbled to be the Wilkinson fellow from 2006-2008, and hope the following will encourage you to apply.

(Disclaimer:  The following statements are my own and do not in any way represent the official views of the MCS division, Argonne itself, or the US Department of Energy.)

First of all, the professional development afforded by the Wilkinson is incredible.  The fellowship offers a degree of independence that’s essentially unheard of in computational science postdoctoral positions; that freedom, that intellectual space, was essential for me to identify what really matters to me, and my strengths and weaknesses.  The MCS division offers a dynamic workplace full of sharp minds and friendly colleagues from all walks of science and engineering, which makes for a terrific learning environment.  Of the many academic institutions I’ve seen, none have matched MCS’s collection of truly integrative computational scientists who keep up with everything, and have thought so deeply about the big picture.

In addition, the fellowship provides fantastic support to travel for conferences and meet collaborators.  For one thing, I was able to spend six weeks in Europe attending a series of meetings in Linz, Austria; many thanks to the Radon Institute of Computational and Applied Mathematics at Linz for hosting me, and to Bob Eisenberg of Rush University for facilitating.  Another example: when I began to collaborate with experimental scientists in the Biosciences Division, I could actually support tying theory to experiment by buying real proteins!

Plus, you can live in downtown Chicago, which is a totally awesome place to live, especially when you look at the cost of living around some other national labs near big cities.

Principle 1: Deliver the goods.

Every visitor to your poster wants something: figure out what it is and give it to them.

What might a visitor want?

1. To know about the problem. They’ve heard this area is really blowing up and your poster looked like good work in the area, or they know or have heard of one of the authors, or your poster was aesthetically appealing, or was just the first one they saw on this problem. It’s your opportunity to bring an outsider into the area, and success will bring you gratitude and esteem.
2. To know about your scientific results. Competitors both friendly and adversarial want to know what you’ve been up to; people in related fields want to know if what you’ve found impacts their own work, hoping to get an edge on their competitors; curious smart people may think your work is an important step forward and want to hear your thoughts on the broader context and implications of your research.
3. To know about the methods you’re using.  This is especially common in my kind of theoretical/computational work, where things often transfer between domains. Perhaps some feature of your approach lets you do things that the visitor can’t: usually, he or she hasn’t ever admitted that inability publicly, and won’t tell you either.
4. To know about you the scientist/engineer (or your advisor, or the team… but most likely just you). Would you be a good colleague, whether at a national lab, a university, or a company? Everyone wants to work with the best people; even if the visitor isn’t someone who would hire someone in your area, she may well _know_ somebody who would. True story: I once went to an interview where the very first person I met sat me down and said, “I don’t know what you said to that woman you sat next to on the flight over, but she’s convinced you’re God’s gift to [my institution]!” Even if the visitor isn’t hiring or trying to put your name into the mix elsewhere, it’s a small world, and it’s always better to have more people believe,  “That person really knows how to think about tough problems.”

Notice that this is a slightly skewed, more personalized version of “Know your audience.” One of the most critical aspects of a successful poster presenter/reader interactions is how efficiently and accurately the giver calibrates what the reader is after, and there are few approaches more effective than simply asking the reader about her background and interest in the poster. This tells the reader that the giver is serious about the job of giving a poster, and therefore empowers her to say things like, “OK, I don’t care so much about that part of the work…” if the discussion veers. Furthermore, it reminds the presenter that this can be a two-way interaction: it’s perfectly acceptable to communicate the important stuff more efficiently: “Are you familiar with [esoteric numerical simulation technique]? If so, I’ll just skip ahead to what you really care about, [implementation on GPUs].”

Note that the list includes “your results” before “your methods.” (Of course, for many CSGF-affiliated scientists, the “results” themselves are sometimes called “methods,” but there should be no confusion if you call such results “algorithms” and leave the word “methods” to refer to the means by which you obtain your results.)

Principle 2: It’s a quid pro quo.

Every visitor to your poster expects to have to accept something _else_ in addition to what they really want. Drive a hard bargain—give them what they want, but work to make sure they walk away with your message as well.

What can you leave a visitor with? Basically, the possibilities fall into the same categories:

1. You’re working on a good problem, where “good” can mean interesting, important, challenging, relevant to the visitor’s own research.
2. Your results are surprising/important/relevant to the visitor.
3. Your methods are sound/impressive/relevant. Perhaps the visitor is skeptical about your working hypothesis, and the best you can hope for is diminishing their skepticism.  After all, in the 5-15 minutes of most poster conversations, you’re not going to change someone’s mind about much of substance.  Kudos to the presenter who can recognize her visitor’s skepticism, respect it, and communicate her efforts without trying to force a conversion.
4. You’re really smart and they should keep track of what you’re up to.

This is clearly the second level of the calibration problem—that is, beyond identifying what the visitor would like from your poster.

Principle 3: Efficiency is a win-win situation.

The poster advice “keep it simple” (with or without a half-hearted ad hominem attached at the end) is about efficiency.  Especially in conference posters, being a responsive presenter is critical!

If you’re spending time talking about things that your visitor doesn’t really care about, you are wasting your opportunity to make an impact on him or her in other ways. A visitor will allow you a certain freedom to get to what they want to know, but you have to get there quickly. The freedom–the leeway–that the visitor gives you is your only chance to get your own message across.  If you fritter away that leeway on secondary or tertiary issues, you’re wasting your time.

If the visitor gives up and tunes out before you’ve delivered the goods they wanted, they probably won’t take away what you might want them to–and what they might have, if you had delivered on your side of the transaction.

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?

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!

Onward.

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.

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.

http://www.ks.uiuc.edu/Research/vmd/mailing_list/vmd-l/16171.html

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
~/tmp/vmdsrc/

and it holds

fltk-1.3.2-source.tar.gz
tcl8.5.13-src.tar.gz
tk8.5.13-src.tar.gz
vmd-1.9.1.src.tar.gz

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
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
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
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”
make MACOSXX86_64 TCLINC=$TCLINC TCLLIB=$TCLLIB
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
MACOSXX86_64 FLTKOPENGL FLTK TK TCL PYTHON PTHREADS

edit configure for the final destination of your VMD scripts and files:
$install_name = “vmdpy”;
$install_bin_dir=”/Users/jbardhan/tmp/bin”;
$install_library_dir=”/Users/jbardhan/tmp/lib/$install_name”;

./configure

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

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
essential…

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
option).

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
http://www.ks.uiuc.edu/Research/vmd/mailing_list/vmd-l/15280.html

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,
unsurprisingly.

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.