Subject: GPL'd MD packages

From: Avijit Ghosh <[email-masked]>
Date: Wed, 31 Jan 2001 18:42:02 -0500 (EST)

I was wondering whether anyone has any GPL'd code for MD?
 Particularly, whether there are any GPL'd force field
implementations out there (I.E. MM*/OPLS*/AMBER* ). Cornell U. has a
package (MOIL) here that is more or less public domain which includes an
Amber88/(soon to be 95 implementation). There  are a series of
very nice programs that are available with source (NAMD/VMD  from UIUC),
Tinker from wustl (which is a really nice package btw) but is definitely
copyrighted. However the licensing on these doesn't really encourage code
reuse rather just personal code modification, and it would seem to me
that code reuse might be beneficial in some circumstances rather than
everyone reimplementing everyone elses algorithms/methods/force fields.

	In any case i'm curious as to what is out there already if
anything.

	-Avi

(W/ apologies about fomenting the Fortran/C++ war into a source
 code licensing war :) )

Actually w/ regards to programming languages, let me mention that I did
my undergrad. in CS and at the time we did every class (except for
operating systems) in Pascal which isn't obviously "useful". Really,
language doesn't matter; you can write equally crap/unmaintainable code
in all! :)

---

From: Georg Schreckenbach <"h.g.schreckenbach"@dl.ac.uk (Georg Schreckenbach)>
Date: Thu, 01 Feb 2001 10:26:46 +0000

Hi everybody,

this is a very interesting thread, and I cannot resist adding my $0.02 to it
...

What I am mostly missing from the discussion so far is the question: WHY do you
want to teach
the students a programming language? What is this intended to achieve?

Do you want them to be able to do computational chemistry? - Then the answer
would probably
be FORTRAN. Many arguments have been brought forward for this pojnt of view.

Do you want them to gain skills that are useful in the job market, not
necessarily working as a
chemist? - By todays standards, the answer wold probably be C/C++ in this case.

Do you want them to gain skills that they can apply right away? - Then perhaps
JAVA isn't that bad,
because they can use it for their websites etc., as has been pointed out.

Do you want them to learn logical thinking? - Again, the answer would be
different: this point
of view has been discussed already, and I will not repeat it.

I guess my point is that there is not just one 'right answer' to the question!

Best regards, Georg

--
Dr. Georg Schreckenbach          phone: +44-1925-603849
CLRC Daresbury Laboratory      FAX: +44-1925-603634
Daresbury, Warrington, Cheshire, WA4 4AD, UK
[email-masked]   http://www.geocities.com/gschreckenbach/

---

From: Richard Gillilan <[email-masked]>
Date: Thu, 01 Feb 2001 09:57:23 -0500

In a C++ vs Fortran performance summary I wrote
for this list a couple years ago, (see http://www.ccl.net/cgi-bin/ccl/message.cgi?1999+10+26+007 )
I cited a paper that gives some examples where C++ is actually
faster than FORTRAN. It appears that the paper is
no longer available online, but I'm fairly certain
I have an electronic copy archived somewhere:

               The best paper I've seen so far was suggested by Oliver Kohlbacher:
               "Will C++ be faster than Fortran?" by Veldhizen and Jernigan
               (downloadable at www.acl.lanl.gov/iscope97/agenda.htm)
               The authors give some real-world examples where
               C++ is as fast or faster than Fortran. They also list
               reasons why C++ has been slower in the past and give
               some features of the language that may allow it to be
               faster in the future.

This reference is a bit outdated now, but I don't know of anything like it
more recently. If you'd like a copy, I'll see if I can find the file.

Though I've never stopped to tally up statistics on languages, in my 7 years
at a national supercomputing center (CTC), I'd certainly agree that the vast majority of
scientific code was FORTRAN. It's interesting to note, however, that two of the
largest center-wide projects underway at the CTC now (genomics and digital materials) are
being implemented in C++. These are very complex, very numerically intensive projects that are
being implemented by folks who are well versed in compilers and code optimization and have done
plenty of FORTRAN in the past. That's not to say I think Object-oriented programming is right
for all jobs, or that FORTRAN is on it's way out, but that C++ and OOP work just fine for
scientific computing. If I recall from a talk I heard 10yr ago or more, CAChe scientific was one
of the early commercial comp chem software developers to go C++ (http://www.cachesoftware.com/), though I'm not sure to what extent.  VMD/NAMD from Klaus Schulten's group is a
excellent recent example of
clean, well-written open code ... well worth emulating. One of the big values supposedly offered
by OOP is much better ability to create, maintain and extend huge code bases. Anecdotally, I certainly
feel this way, but it would be interesting to see if companies and groups are measurably doing better
when they adopt this style. I suspect only time will tell .... truely extensible, maintainable code
will live on when all its original authors are gone and continue to grow and evolve.

Richard

---

From: David Case <[email-masked]>
Date: Thu, 1 Feb 2001 10:23:19 -0800

On Wed, Jan 31, 2001, Avijit Ghosh wrote:
> implementations out there (I.E. MM*/OPLS*/AMBER* ).

NAB (Nucleic acid builder) implements the Amber95 force field.  It includes
generalized Born calculations, but *not* periodic boundary conditions
simulations, so it may or may not satisfy particular needs.  In spite of the
name, it is designed to work on proteins as well as nucleic acids.

Whether or not the code itself (mainly in file sff.c) would be useful
to transfer to other applications is of course a subjective decision, but
you are certainly free to do anything allowed by the terms of GPL.

See my web page (below) for more info.

....good luck...dac

-- 

==================================================================
David A. Case                     |  e-mail:      [email-masked]
Dept. of Molecular Biology, TPC15 |  fax:          +1-858-784-8896
The Scripps Research Institute    |  phone:        +1-858-784-9768
10550 N. Torrey Pines Rd.         |  home page:                   
La Jolla CA 92037  USA            |    http://www.scripps.edu/case
==================================================================