Dear Carlos,
Thanks for your
answer and helpful comments!
About the
sampling.. I initially performed two independent 50 ns-long SA's and then the
procedure that described previously. My aim was to describe the possible complex
formation of two proteins that consist of nearly 750 residues each. Thus, I
included initially only the epitope residues (about 60) and the study was
concentrated on the question whether the loop X of protein X can interacts with
definite portion of protein Y. I didn't
expect that will obtain the "perfect" conformation of loop X, but
some general information of this structurally unknown complex. I decided to use
such approach because can benefit of the Amber 11 CUDA version.
If you have some
additional comments I will be thankful!
I also want to
thanks to Ross, Scott and all Amber team that made possible one to perform more
then 650 ns simulation of such complex on a desktop machine!
All the best,
Filip
________________________________
From: Carlos Simmerling <carlos.simmerling.gmail.com>
To: filip fratev <filipfratev.yahoo.com>; AMBER Mailing List <amber.ambermd.org>
Sent: Monday, March 5, 2012 3:19 PM
Subject: Re: [AMBER] Question about Simulated Annealing procedure
this qualifies as SA, but the bigger question is whether it is enough to sample your loops. I wouldn't worry about what is "normal" SA, since annealing schedules can vary greatly and the definition is not as important as how you determine whether it was adequate for your particular problem.
On Sun, Mar 4, 2012 at 9:29 PM, filip fratev <filipfratev.yahoo.com> wrote:
Hi all,
>I need of
>probably elementary advice... I wanted to perform a "deep sampling"
>on two protein portions (mainly loops) that are involved in protein-protein
>interactions (relatively large system 240 000 solvated). I performed fifteen 25
>ns-long simulations at 600K and 800K (8 heating at 600K and and 7 at 800K) and then cooled back the systems to 310K
>via 100K steps for another 25ns. Can I call this "normal/regular" SA
>simulation or it is SA-"like"?
>
>Regards,
>Filip
>
>
>________________________________
> From: Ross Walker <ross.rosswalker.co.uk>
>To: 'AMBER Mailing List' <amber.ambermd.org>
>Sent: Thursday, March 1, 2012 11:33 PM
>Subject: Re: [AMBER] ABMD in pmemd.cuda in AMBER 12
>
>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
>_______________________________________________
>AMBER mailing list
>AMBER.ambermd.org
>http://lists.ambermd.org/mailman/listinfo/amber
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Mon Mar 05 2012 - 06:30:01 PST
