4 ms·

So no one will mention the Clasp (Lisp on LLVM developer)? He built a language to build better, albeit not visualize, better molecules. If you are on this art

• dalke 11y ago
  I just watched it. I heard pretty much the same aspirations since the 1980s. See https://www.fourmilab.ch/autofile/www/section2_82_2.html https://www.fourmilab.ch/autofile/www/section2_82_2.html for when AutoDesk looked at entering this field. At 15:56 the speaker says "Synthetic chemists normally they design things with plastic model sets." This just isn't true, and hasn't been for a very long time. At 17:54 he even says there's GUI-based software now to design molecules. That's what most chemists use. My experience is that it doesn't take 20 minutes to draw a molecule using the current generation of tools. In fact, you can try it now - go to http://web.chemdoodle.com/demos/sketcher http://web.chemdoodle.com/demos/sketcher or https://pubchem.ncbi.nlm.nih.gov/edit2/index.html https://pubchem.ncbi.nlm.nih.gov/edit2/index.html or http://scitouch.net/ketcher-demo/ketcher.html http://scitouch.net/ketcher-demo/ketcher.html and draw one yourself. (This is for small molecule chemistry. For large molecule chemistry, there are other tools and other issues to worry about.) In minute 23 he talks about computing the second derivative of the force fields, and how complex it is. Thing is, my co-worker did that manually when he wrote the original NAMD implementation. (NAMD is a molecular dynamic program.) So it's not something that's all that hard to compute. It's just tedious. (And his code is 10% slower than the hand-written code, so he knows that people do this sort of thing manually.) While it's useful to have automatic code generators if you want to add new force fields often, we just don't do it all that often, because parameterizing the force field is the hard problem, not computing the second derivative. At 31:25 he says that SciPy is only really possible because of Boost.Python. This isn't true. I just downloaded scipy-0.16.0b2 and verified that it does not use Boost.Python. ("ag -i BOOST_PYTHON_MODULE" finds no matches.) At 49:30 he talks about a technique that sounds like pharmacophore models, which have been around since at least the 1990s. There are tools that will build molecules to fit pharmacophore models. What I didn't see was anything about dealing with waters, and counter-ions, toxicity, or AMDE (absorption, distribution, metabolism, and excretion) issues. I didn't hear anything which required multiple years of tool building ("yak shaving") to get to what he wanted. Every technique he mentioned is something that people have been doing already, in C/C++/Python.
  • dekhn 11y ago
    scipy uses cython (previously swig). It is correct that its performance depends on C and Fortran code (but you knew that). Are you sure your coworker found the derivates for the force field? They were already published when VMD was written. I think you're trying to quibble with some of his minor points. Schaf's quite aware of water and counterions (we used to work in the same room at UCSF when he was writing AMBER's LEaP tool that adds water and counterions to molecules).
    • dalke 11y ago
      The speaker said that SciPy uses Boost Python. My comment here was that it does not. I said nothing about SciPy's performance. I didn't say that my co-worker was the first to compute the derivatives. I said that it wasn't that complex of a task. Mark Nelson worked out by hand the second derivatives for the force fields and implemented them in NAMD (note: NAMD is not VMD). He also checked it against a couple of other implementations, including the one in XPLOR. I think he also checked against PMD and YAMD, and I believe he noticed that the PMD implementation was copied from XPLOR. My point is that it's not hard to find these manually. In any case there's little need to figure it out from scratch since nowadays the force-fields are available in code with a permissive license, and the math available in publications like https://books.google.com/books?id=GYTuCAAAQBAJ&pg=PA168&lpg=PA168&dq=automatic+differentiation+%22force+field%22&source=bl&ots=G61DuaDKJw&sig=ho9GFl30kOUoqCrej8HXUXHzSDI&hl=sv&sa=X&ei=XYCJVcrML8LlywPWvLrAAQ&ved=0CC0Q6AEwAQ#v=onepage&q=automatic%20differentiation%20%22force%20field%22&f=false https://books.google.com/books?id=GYTuCAAAQBAJ&pg=PA168&lpg=... . It can make sense to develop new tooling to generate code automatically. The result might be faster than manual code, but as we heard, the auto-generated code is currently 10% slower than manual code. Or it might make sense when developing many different types of force fields, like what Konrad Hinsen does in ScientificPython (see http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97.9462&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97.... ). However, I heard nothing about developing new force fields, and in any case, parameterization is the limiting factor, not computing the second derivatives. My 'quibbles' are two-fold. The major one is that I heard or read 30+ years of history on how molecular modeling can be used to design solutions to real-world problems. The 1980s thought that it would be a CAD problem (which it wasn't). The late 1990s thought it was a simple matter of nanotech, with all sorts of designs for nifty diamond-based structures with no real-world hope. We've had special purpose programming languages for molecular modeling, custom computers with specialized networks, custom designed chips, GPU-based implementations, and more. There's no evidence that the limitation is in the tooling, which is a major part of the speaker's thesis. The minor one is that if someone makes minor mistakes that end up placing the speaker in a brighter light, and says them with confidence, then I believe it's reasonable to discount more the major points said with confidence which have less evidence, and which also place the speaker in a brighter light. What you see as quibbles for minor points I see as a way to judge how strongly the speaker is willing to trust personal beliefs over evidence and proof. (Yes, those personal beliefs might be right, but that's my previous point.)