[gmx-users] issue in replica exchange
Michael Shirts
mrshirts at gmail.com
Thu May 2 14:36:45 CEST 2013
Both. So if 4.6.1 doesn't work, I want to know so we can patch it
before 4.6.2 comes out. If it does work, then there is probably stuff
that can be backported.
On Thu, May 2, 2013 at 8:32 AM, XAvier Periole <x.periole at rug.nl> wrote:
>
> You mean working with or working on the code?
>
> I'll try gmx-4.6.1
>
> On May 2, 2013, at 2:26 PM, Michael Shirts <mrshirts at gmail.com> wrote:
>
>> Quick check here -- is 4.6 behaving correctly? I actually spent some
>> time working on REMD in 4.6, and it seems to be behaving correctly in
>> my hands with temperature and pressure control.
>>
>> Thanks for any additional info on this!
>>
>> On Thu, May 2, 2013 at 8:18 AM, Mark Abraham <mark.j.abraham at gmail.com> wrote:
>>> On Thu, May 2, 2013 at 12:58 PM, XAvier Periole <x.periole at rug.nl> wrote:
>>>
>>>>
>>>> I saw that redmine report, which could be related but it seems to happen
>>>> only for runs done outside the domain and particle decompositions.
>>>>
>>>> I'll fill up a red mine.
>>>>
>>>> Anything I could do to help speeding the fix?
>>>>
>>>
>>> What'd be really nice is some thought on how one can demonstrate that the
>>> implementation of the exchange matches what would be expected from the
>>> theory. For T-exchange under NVT, it is sufficient to rescale velocities
>>> and quantities derived from them by the correct factor. That includes
>>> various things like T-coupling history and integrator half-step quantities
>>> (and does REMD with leap-frog make sense anyway?). For NPT, there's
>>> probably also some P-coupling quantities to scale, and the box to exchange.
>>> Anything I've missed? Hopefully virial contributions don't matter either
>>> way?
>>>
>>> Perhaps a decent first step is to hack the code to do a "self exchange," by
>>> clearing the entire state and rebuilding with what would/should be received
>>> from an exchange with a hypothethetical replica in an identical
>>> pre-exchange state. Only if the code can do that (i.e. mdrun -reprod
>>> produces a trajectory indistinguishable from a run that does not attempt
>>> this self exchange) is it worth considering proper state exchanges, and the
>>> process of making the code do the former should illustrate what is required
>>> for the latter.
>>>
>>> Mark
>>> --
>>> gmx-users mailing list gmx-users at gromacs.org
>>> http://lists.gromacs.org/mailman/listinfo/gmx-users
>>> * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
>>> * Please don't post (un)subscribe requests to the list. Use the
>>> www interface or send it to gmx-users-request at gromacs.org.
>>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>> --
>> gmx-users mailing list gmx-users at gromacs.org
>> http://lists.gromacs.org/mailman/listinfo/gmx-users
>> * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
>> * Please don't post (un)subscribe requests to the list. Use the
>> www interface or send it to gmx-users-request at gromacs.org.
>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> --
> gmx-users mailing list gmx-users at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-users
> * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
> * Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-users-request at gromacs.org.
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
More information about the gromacs.org_gmx-users
mailing list