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 - 05:30:02 PST
