replica exchange

LAMMPS LAMMPS Mailing List Mirror
1

Dear LAMMPS developers and users,

Greetings. First, please accept my apologies if I have bothered you too many times on this issue. I thought I have solve this problem, but there are apparently something I overlooked. So please kindly share your wisdom, and I am truly thankful for all the help and comments.

I am modifying the temper command to increase its capability to swap both volume (density) and temperature among replicas. The idea is simple: I mimic what the author did in T swap and employ the process to V swap. Say, I am having the following 9 replicas:

0 1 2
3 4 5
6 7 8

Replicas in the same column are of the same temperature, and those in the same array are of the same volume (density). So, replica 4 swaps with 3 or 5 for T swap, and it swaps with 7 or 1 when a V swap is employed.

Since the domain size is changed after the V swap, I need to deal with the atom allocation (and neighbor list) problem. I checked the logic of change_box.cpp and fix_deform.cpp, but neither of them can be readily transplanted into my code.

change_box: it is defined between runs, so the atoms are properly allocated at the beginning of the next run.
fix deform: it has pre_exchange and end_of_step to deal with the neighbor list/kspace problem, but mine is a command. I do not know how to write a fix to force_reneighbor=1 and force->kspace->setup() when it is not perform in each step but after my V swap.

Currently I am issuing the following three lines at the bottom of each volume change (the idea is to build the neighbor list/kspace grid/ghost atom list from scratch):

update->integrate->cleanup();
lmp->init();
update->integrate->setup();

It works ok, but, occasionally(probably once several ns), my MD stops running, sometime showing a lost atom, sometime not. This lost-atom thing gets rarer if I enlarge the skin depth, but the pay is painful: much longer simulation time. This seems to defeat the whole purpose of employing REMD (to save time)…

Aside from the above cure, which does not work well, I think my last choice is to brutally insert the neighbor list/irregular migration/kspace pieces into verlet.cpp? But this is quite il-legitimate…

Thank you again for your attention. Any comment/suggestion is gratefully welcomed.

Sincerely,

LC Liu

2

Two ideas:

a) you are already doing this in the temper
command:

update->integrate->run(nevery);

to perform a series of short runs of length Nevery.
Presumably between then you perform your volume
exchange, and start up again. You can also insert
a setup() call before the run()
if a volume was exchanged so that
things need to be re-setup.

b) Your temper command could instantiate a fix
on its own, that sets force->reneighbor and does
the kspace operation. The temper command would
call its methods if volume exchanges occurred.

Steve

3

Hi, Steve,

Thank you so much for the valuable comments. I forgot to formulate my logic…here it is:

for (int iswap = 0; iswap < nswaps; iswap++) {

update->integrate->run(nevery);

if(iswap % vevery != vevery-1) {

// T swap

} else
{

// V swap

update->integrate->cleanup();
lmp->init();
update->integrate->setup();

}
}

Please correct me if I am wrong…it appears that update->integrate->run(nevery) does not do an initial re-construction to neighbor list(and so on), so I need to do that before the next run. That is why I attache the setup() there, and I though the system should be correct for the next run.

However, my system seems occasionally encounter bad dynamics. I wonder if this is caused by my coding errors, or the numerical limitation? (namely, it is system inherent and the only cures are decreasing the density change or the time step).

Because the numerical limitation is not mentioned in the manual for fix_deform, so I assume the fix_deform is robust and free from the bad dynamics problem…am I correct?

Thank you again for the help.

LC Liu

4

I would not do the cleanup() and init(), only
the setup() and only when you actually did
an exchange.

Steve

5

Hi, Steve,

Thank you so much for the comments. I will look into the code piece as advised.

LC Liu

2013/7/24 下午9:51 於 “Steve Plimpton” <[email protected]> 寫道：