To add to what Carlos has said, the main problem might arise during
mpi_send() and mpi_recv() calls. Currently, different variables are sent
and received during REMD using the MPI protocols. I am not sure how these
would work when odd number of replicas/processors are used. Maybe others
might know how to overcome this. In terms of doing the exchange calculation
itself, it should be trivial to perform with odd number of replicas.
On Wed, Sep 25, 2019 at 11:38 AM Carlos Simmerling <
carlos.simmerling.gmail.com> wrote:
> I think conceptually it isn't hard. An easy way would be to alternate
> having the first or last replica not involved in exchanges, leaving an even
> number to pair for exchange. Right now the first/last attempt exchange on
> alternate attempts, which usually fails, so having one of them do nothing
> every other time would be similar. The bookkeeping would need to be updated
> for things that assume even numbers, and selection of partners is a little
> more complicated, but I think it should work without too much rewriting. It
> was always easier to code with even numbers, and an extra replica didn't
> seem to cost much so we did it that way.
> Others might know of specific issues in the current code that would be
> difficult to change...
> carlos
>
> On Wed, Sep 25, 2019, 10:12 AM David Case <david.case.rutgers.edu> wrote:
>
> > Does anyone have a feeling of how easy/hard it would be allow an odd
> > number of replicas in (Hamiltonian) replica exchange?
> >
> > ...thx...dac
> >
> >
> > _______________________________________________
> > 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
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Sep 25 2019 - 09:30:03 PDT
