Hi Ross,
Yes, I understand now the reason for PMEMD, and given the GPU enhanced
performance compared to a number of other packages, it has clearly been a
good route to go down.
The main functionality from the NCSU codes would be the ability to do
metadynamics - quite a popular method of biased MD - which can yield the
PMF, giving in turn reaction paths, and free energy differences. At the
moment (and do correct me if I'm wrong) the three options available for
getting that kind of information in AMBER are:
1) Umbrella Sampling using the nmropt=1 type of harmonic restraints, which
is an excellent method, but very hard to expand past 2 dimensions, whereas
metadynamics is easily expanded to multiple dimensions (albeit with a
corresponding increase in simulation time needed to explore those
dimensions).
2) Thermodynamic integration type methods, but you don't get the PMF, only
the free energy difference
3) MM/PBSA, I believe the limitations are the same as thermodynamic
integration
So I think there is very good reason for wanting to include something of
this sort. I'm not sure that the NCSU methods themselves are absolutely
critical, perhaps the older Metadynamics method that was in AMBER 10 might
be better documented or use the appropriate namelist. There are also very
well documented methods for this used in NAMD, and I believe those same
codes are being modified to be used an another package, so they may also be
useful as a guide.
All that being said, I absolutely agree that it would be a substantial
amount of work. My impression though, is that a lot of people would like
to be able to generate a PMF for say: a ligand binding reaction, or a
conformational change, which metadynamics has been used for previously with
success. I could easily be wrong about that, however, perhaps everyone is
quite satisfied with thermodynamic integration methods and don't feel that
they want/need a PMF or feel that it is any more accurate.
Thanks for taking the time to consider it though, and the very clear
response concerning why we can't just do some crack job of porting it over.
~Aron
On Thu, Mar 1, 2012 at 4:33 PM, Ross Walker <ross.rosswalker.co.uk> wrote:
> Hi Aron,
>
> > If I was going to make an attempt to do that migration, are you aware
> > of
> > any fundamental barriers for putting the NCSU codes on the GPU? I can
> > imagine all kinds of horrible problems, but just wondered if you were
> > aware
> > of some critical issues, or if it was more a matter of time versus user
> > interest at this point.
>
> The issue has until recently been one of funding. Going forward it will be
> one of prioritizing based on user interest. The real problem with the NCSU
> code is that it was effectively dumped into Sander with no real
> documentation, in some cases it duplicates other functionality. It doesn't
> use the same namelist approaches AMBER does, so has to have it's own
> readers
> etc etc. Basically it is just a mess.
>
> This makes it a pain to port over to PMEMD. The real issue being doing it
> in
> a way that keeps PMEMD clean since we don't want to repeat going down the
> Sander route. It also needs to be done carefully such that it doesn't just
> destroy the performance. So I think if we are to port stuff just saying
> porting the NCSU codes is NOT the way to go. The key is to identify the
> specific methods one would like and the justification for why. Then go back
> to the original equations for those methods and implement them in the CPU
> version of PMEMD from scratch with full documentation, test cases etc. This
> should also be documented in the manual. Then it should be tested in serial
> and parallel and it confirmed it doesn't hurt performance. Then it can be
> ported to the GPU, again with test cases etc. Then once that is done the
> method should be back ported to Sander such that sander works the same way
> as PMEMD and then the sander NCSU code corresponding to that should be
> deleted. This way things get done in a careful, documented and user
> friendly
> manner that can be maintained moving forward. Suffice to say I would expect
> this to be a full time job for someone for a year or so to do it properly.
>
> So I think the first thing is to audit the NCSU code and make a clear
> description of specifically which methods are wanted and why. Then if you
> want we could work together on trying to implement those methods in pmemd
> and pmemd.cuda. The bonus being that if we do it this way it gets
> incorporated in the code in a way that ensure it will be maintained moving
> forward.
>
> All the best
> Ross
>
>
> /\
> \/
> |\oss Walker
>
> ---------------------------------------------------------
> | Assistant Research Professor |
> | San Diego Supercomputer Center |
> | Adjunct Assistant Professor |
> | Dept. of Chemistry and Biochemistry |
> | University of California San Diego |
> | NVIDIA Fellow |
> | http://www.rosswalker.co.uk | http://www.wmd-lab.org/ |
> | Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
> ---------------------------------------------------------
>
> Note: Electronic Mail is not secure, has no guarantee of delivery, may not
> be read every day, and should not be used for urgent or sensitive issues.
>
>
>
>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
--
Aron Broom M.Sc
PhD Student
Department of Chemistry
University of Waterloo
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Mon Mar 26 2012 - 11:00:04 PDT
