Hi Jason,
we should keep this discussion going- I think you missed out on the
HREMD brainstorming session at the bar during the amber meeting.
exchanging coordinates will likely be quite inefficient for many
problems, but needed for others. we talked a lot about how we need to
generalize the exchange, and really track down impact on the code (for
example, needing to redo load balancing and spatial decomposition
work, etc).
great work!
carlos
On Fri, Apr 8, 2011 at 10:44 AM, Jason Swails <jason.swails.gmail.com> wrote:
> Just to elaborate here as to my plans a little bit. The way I envision this
> going is that each "type" of exchange gets its own subroutine where it
> calculates what needs to be calculated and determines the exchange criteria
> (and success), updates each replica as necessary, then kicks back to the MD
> loop. All the "multi-D" REMD will do is determine which dimension will be
> exchanged within, determine which "type" of exchange that is, and call the
> appropriate subroutine to do it.
>
> Therefore, the natural progression is to implement T-REMD, H-REMD, then
> multi-D REMD. Just a minor modification to what Adrian has said, H-REMD
> *should* be able to handle both different H's and different (or identical)
> Ts. I have to work the detailed balance equations out to make sure that all
> of them can fit within the same subroutine.
>
> In fact, I think you *should* even be able to do T-REMD through the H-REMD
> subroutine, but that's wasteful in the sense that it has to send/receive
> coordinates AND calculate energies during the exchange attempt, which are
> completely unnecessary for T-REMD. This performance difference is marked
> enough to demand its own subroutine.
>
> But this approach allows me to implement bits at a time in a non-general
> way, verify that it does what I want it to do, then build the next layer of
> generality.
>
> All the best,
> Jason
>
> On Fri, Apr 8, 2011 at 6:39 AM, Adrian Roitberg <roitberg.qtp.ufl.edu>wrote:
>
>> Yes, that is the plan
>>
>> We 'separate' T and H-remds in the sense that Jason mentioned already.
>>
>> T-remd uses the SAME hamiltonian for the replicas, and different
>> temperatures.
>>
>> H-REMD uses different hamiltonians and same T.
>>
>> The equations are different in these two sets but always the same
>> within. They require either two energies and two temperatures (T-remd)
>> or four energies and one temperature (H-remd)
>>
>> One the multi-D remd is in place, you could imagine doing T-T-REMD
>> H-H-REMD, H-T-remd, etc etc.
>>
>> I have not decided yet it it is worth our time to put Pressure-REMD,
>> which has its own set of equations.
>>
>> As far as we can imagine, most exchanges one can invent fall into H-remd
>> in general, so it would be up to the developer to provide the exchange
>> code a proper set of energies. The rest is always the same.
>>
>> Cheers
>> Adrian
>>
>>
>> On 4/8/11 3:31 PM, Sally Pias wrote:
>> > On Thu, Apr 7, 2011 at 11:21 AM, Jason Swails<jason.swails.gmail.com>
>> wrote:
>> >> The multi-D-REMD should be this generalized functionality. For a
>> >> generalized, N-dimensional replica exchange simulation, I can't see how
>> more
>> >> exchanges than just basic T-REMD (where only T exchanges because the
>> rest of
>> >> the hamiltonian is the same) and H-REMD (where the coordinates exchange
>> and
>> >> recalculate energies, so we have 4 energies total) could be needed to
>> make
>> >> it as general as possible (and then just allow for an arbitrary number
>> of
>> >> exchanging dimensions).
>> >
>> > Would multiple dimensions of H-REMD without T-REMD be possible? -- for
>> > example, exchanging along two restrained reaction coordinates but not
>> > exchanging temperatures?
>> >
>> > This sounds exciting!
>> >
>> > Sally Pias
>> > ---
>> > Postdoctoral Associate, Simmerling Group
>> > sallypias.gmail.com
>> >
>> > _______________________________________________
>> > AMBER-Developers mailing list
>> > AMBER-Developers.ambermd.org
>> > http://lists.ambermd.org/mailman/listinfo/amber-developers
>> >
>>
>> --
>> Dr. Adrian E. Roitberg
>> Associate Professor
>> Quantum Theory Project, Department of Chemistry
>> University of Florida
>>
>> on Sabbatical in Barcelona until August 2011.
>> Email roitberg.ufl.edu
>>
>> _______________________________________________
>> AMBER-Developers mailing list
>> AMBER-Developers.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>>
>
>
>
> --
> Jason M. Swails
> Quantum Theory Project,
> University of Florida
> Ph.D. Candidate
> 352-392-4032
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Fri Apr 08 2011 - 08:00:06 PDT
