Yes, my system is described at atomic level. No, I can't see any "strange" value around exchanges. I analyzed only a very little number of trajectories, but temperature, volume, potential energy, pressure seem all to be around normal fluctuations.
2013/5/2 XAvier Periole <x.peri...@rug.nl> > > Did you look at some data like temperature/pressure/box size/Epot as a > function of time and especially around some exchanges? > > Your system is atomistic I presume. > > On May 2, 2013, at 12:38 PM, Simone Conti <simone...@gmail.com> wrote: > > > I'm running remd in NPT ensemble for a small peptide and all is ok if the > > maximum temperature is below 510/520 kelvin. I use Nosé-Hoover termostat > > and Parrinello-Rahman barostat. Ref T from 285 to 500K and ref P equals > to > > 1bar. Gromacs version 4.5.5. Exchange trials every 5 ps. > > If I try to add replica at a higher temperature the system crash, but I > > think it is a problem of equilibration. > > > > > > 2013/5/1 XAvier Periole <x.peri...@rug.nl> > > > >> > >> Ok here is my current status on that REMD issue. > >> > >> For info: I use > >> Temperature: v-rescale, tau_t = 2.0 ps > >> Pressure: berendsen, tau_p = 5.0 ps, > >> time step: dt=0.002 - 0.020 fs, > >> COM removal on for bilayer/water separately > >> > >> The symptoms: explosion of the system after 2-5 steps following the > swap, > >> first sign is a huge jump in LJ interactions and pressure. This jump > seems > >> to be absorbed by the box size and temperature when possible … see > example > >> I provided earlier. A large VCM (velocity centre of mass?) is often > >> associated with the crash. But also pressure scaling more than 1% ... > >> > >> 1- the problem mentioned above remains in gmx-4.5.7 and it might > actually > >> got worse. I was able to run a 500 ns simulation with gmx405 using > similar > >> setup as for gmx457. The following point happened in gmx457. > >> 2- it persists with a time step of 2 fs. Actually all tests performed in > >> the following used dt=2fs. > >> 3- if I perform an exchange that explodes within mdrun myself > (externally > >> to the remd gromacs by getting the gro file with the mdp adjusting the > >> temperature) it goes all fine. > >> 4- the issue gets much worst when the consecutive replicas differ > >> (different protein conformations and the box size etc) … explosion at > first > >> exchange. > >> 5- the use of parrinelo-raman does not help > >> 6- cancelling the centre of mass removal does not remove the problem. > >> 7- switching to NVT ensemble does not help but makes it worst (crash in > 2 > >> steps). All exchanges accepted at first attempt crash with the message > >> "Large VCM(group SOL): -0.0XXX , -0.XXX, -0.16XXX, Temp-cm:6.55XXX > >> 8- using a unique conformation (the same) for all replicas in the NVT > REMD > >> simulation after equilibration in the same NVT ensemble (for 1 ns) > removes > >> the problem. > >> 9- taking the equilibrated NVT conformations, equilibrate them in an NPT > >> ensemble (1 ns) and let go the exchanges afterwards restores the > problem … > >> one exchange is not properly done at the second trial, while the first > ones > >> were fine. Well if errors were made that was with reasonable > >> 10- note also that the coarse grain I use is extremely forgiving, > meaning > >> you can perform really nasty transformations and run it further after > >> simple minimisation … so even abrupt changes in temperatures should be > fine > >> and relax quickly. > >> 11- when looking at the conformations themselves nothing appears to have > >> jumped over or nothing funky. > >> > >> At this point I am not sure what to think and what to do next. There is > >> definitely something not going right during the exchanges. > >> > >> Anyone has been able to run a REMD simulation in an NPT ensemble without > >> crashes? I would imagine someone has and something particular to my > system > >> is making it going wrong but I am really wondering what it could be. My > >> feeling is that something relative to the box size or pressure is not > going > >> across but it might be something completely different, when the > consecutive > >> systems differ reasonably. > >> > >> However that would suggest that the manner the exchanges are made is > >> severely wrong in some cases. > >> > >> Any help to resolve the problem would be greatly appreciated. > >> > >> XAvier. > >> > >> On Apr 26, 2013, at 9:21 AM, Mark Abraham <mark.j.abra...@gmail.com> > >> wrote: > >> > >>> On Thu, Apr 25, 2013 at 11:05 PM, XAvier Periole <x.peri...@rug.nl> > >> wrote: > >>> > >>>> > >>>> Thanks for the answer. I'll check gmx4.5.7 and report back. > >>>> > >>>> I am not sure what you mean by GROMACS swaps the coordinates not the > >>>> ensemble data. The coupling to P and T and not exchanged with it? > >>> > >>> > >>> The code in src/kernel/repl_ex.c: > >>> > >>> static void exchange_state(const gmx_multisim_t *ms, int b, t_state > >> *state) > >>> { > >>> /* When t_state changes, this code should be updated. */ > >>> int ngtc, nnhpres; > >>> ngtc = state->ngtc * state->nhchainlength; > >>> nnhpres = state->nnhpres* state->nhchainlength; > >>> exchange_rvecs(ms, b, state->box, DIM); > >>> exchange_rvecs(ms, b, state->box_rel, DIM); > >>> exchange_rvecs(ms, b, state->boxv, DIM); > >>> exchange_reals(ms, b, &(state->veta), 1); > >>> exchange_reals(ms, b, &(state->vol0), 1); > >>> exchange_rvecs(ms, b, state->svir_prev, DIM); > >>> exchange_rvecs(ms, b, state->fvir_prev, DIM); > >>> exchange_rvecs(ms, b, state->pres_prev, DIM); > >>> exchange_doubles(ms, b, state->nosehoover_xi, ngtc); > >>> exchange_doubles(ms, b, state->nosehoover_vxi, ngtc); > >>> exchange_doubles(ms, b, state->nhpres_xi, nnhpres); > >>> exchange_doubles(ms, b, state->nhpres_vxi, nnhpres); > >>> exchange_doubles(ms, b, state->therm_integral, state->ngtc); > >>> exchange_rvecs(ms, b, state->x, state->natoms); > >>> exchange_rvecs(ms, b, state->v, state->natoms); > >>> exchange_rvecs(ms, b, state->sd_X, state->natoms); > >>> } > >>> > >>> I mis-stated last night - there *is* exchange of ensemble data, but it > is > >>> incomplete. In particular, state->ekinstate is not exchanged. Probably > it > >>> is incomplete because the 9-year-old comment about t_state changing is > >> in a > >>> location that nobody changing t_state will see. And serializing a > >> complex C > >>> data structure over MPI is tedious at best. But that is not really an > >>> excuse for the non-modularity GROMACS has for many of its key data > >>> structures. We are working on various workflow and actual code > structure > >>> improvements to fix/prevent issues like this, but the proliferation of > >>> algorithms that ought to be inter-operable makes the job pretty hard. > >>> > >>> Other codes seem to exchange the ensemble label data (e.g. reference > >>> temperatures for T-coupling) because they write trajectories that are > >>> continuous with respect to atomic coordinates. I plan to move REMD in > >>> GROMACS to this approach, because it scales better, but it will not > >> happen > >>> any time soon. > >>> > >>> That would explain what I see, but let see what 4.5.7 has to say first. > >>>> > >>> > >>> Great. It may be that there were other issues in 4.5.3 that exacerbated > >> any > >>> REMD problem. > >>> > >>> Mark > >>> > >>> Tks. > >>>> > >>>> On Apr 25, 2013, at 22:40, Mark Abraham <mark.j.abra...@gmail.com> > >> wrote: > >>>> > >>>>> Thanks for the good report. There have been some known issues about > the > >>>>> timing of coupling stages with respect to various intervals between > >>>> GROMACS > >>>>> events for some algorithms. There are a lot of fixed problems in > 4.5.7 > >>>> that > >>>>> are not specific to REMD, but I have a few lingering doubts about > >> whether > >>>>> we should be exchanging (scaled) coupling values along with the > >>>>> coordinates. (Unlike most REMD implementations, GROMACS swaps the > >>>>> coordinates, not the ensemble data.) If you can reproduce those kinds > >> of > >>>>> symptoms in 4.5.7 (whether or not they then crash) then there looks > >> like > >>>>> there may be a problem with the REMD implementation that is perhaps > >>>> evident > >>>>> only with the kind of large time step Martini takes? > >>>>> > >>>>> Mark > >>>>> > >>>>> > >>>>> On Thu, Apr 25, 2013 at 1:28 PM, XAvier Periole <x.peri...@rug.nl> > >>>> wrote: > >>>>> > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> I have been recently using the REMD code in gmx-407 and gmx-453 and > >> got > >>>> a > >>>>>> few systems crashing for unclear reasons so far. The main tests I > made > >>>> are > >>>>>> using gmx407 but it is all reproducible with gmx453. The crashing > was > >>>> also > >>>>>> reproduced (not necessarily at the same time point) on several > >>>>>> architectures. > >>>>>> > >>>>>> The system is made of a pair of proteins in a membrane patch and for > >>>> which > >>>>>> the relative orientation is controlled by non-native > >>>> bond/angles/dihedrals > >>>>>> to perform an umbrella sampling. I use the MARTINI force field but > >> that > >>>>>> might not be relevant here. > >>>>>> > >>>>>> The crashes occur following exchanges that do not seem to occur the > >>>>>> correct way and preceded by pressure scaling warnings … indicative > of > >> a > >>>>>> strong destabilisation of the system and eventual explosion. Some > >>>>>> information seems to be exchanged inaccurately. > >>>>>> > >>>>>> Trying to nail down the problem I got stuck and may be some one can > >>>> help. > >>>>>> I placed a pdf file showing plots of bonded/nonbonded energies, > >>>>>> temperatures, box size etc … around an exchange that does not lead > to > >> a > >>>>>> crash (here: md.chem.rug.nl/~periole/remd-issue.pdf). I plotted > stuff > >>>>>> every step with the temperature colour coded as indicated in the > first > >>>>>> figure. > >>>>>> > >>>>>> From the figure it appears that the step right after the exchange > >> there > >>>> is > >>>>>> a huge jump of Potential energy coming from the LJ(SR) part of it. > >>>> Although > >>>>>> there are some small discontinuities in the progression of the bond > >> and > >>>>>> angle energy around the exchange they seem to fine. The temperature > >> and > >>>> box > >>>>>> size seem to respond to it a few step latter while the pressure > seems > >>>> to be > >>>>>> affected right away but potentially as the Epot will affect the > viral > >>>> and > >>>>>> thus the Pressure. > >>>>>> > >>>>>> The other potential clue is that the jumps reduce with the strength > of > >>>> the > >>>>>> pressure coupling. A 1/2 ps tau_p (Berendsen) will lead to a crash > >>>> while a > >>>>>> 5/10/20 ps won't. Inspection of the time evolution of the Epot, box > … > >>>>>> indicates that the magnitude of the jumps is reduced and the system > ca > >>>>>> handle the problem. > >>>>>> > >>>>>> One additional info since I first posted the problem (delayed by the > >>>> file > >>>>>> first attached but now given with a link) the problem is accentuated > >>>> when > >>>>>> the replicas differ in conformation. I am looking at the actual > >>>> differences > >>>>>> as you'll read this email. > >>>>>> > >>>>>> That is as far as I could go. Any suggestion is welcome. > >>>>>> > >>>>>> XAvier. > >>>>>> MD-Group / Univ. of Groningen > >>>>>> The Netherlands-- > >>>>>> gmx-users mailing list gmx-users@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-requ...@gromacs.org. > >>>>>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists > >>>>> -- > >>>>> gmx-users mailing list gmx-users@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-requ...@gromacs.org. > >>>>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists > >>>> -- > >>>> gmx-users mailing list gmx-users@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-requ...@gromacs.org. > >>>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists > >>>> > >>> -- > >>> gmx-users mailing list gmx-users@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-requ...@gromacs.org. > >>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists > >> > >> -- > >> gmx-users mailing list gmx-users@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-requ...@gromacs.org. > >> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists > >> > > -- > > gmx-users mailing list gmx-users@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-requ...@gromacs.org. > > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists > > -- > gmx-users mailing list gmx-users@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-requ...@gromacs.org. > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists > -- gmx-users mailing list gmx-users@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-requ...@gromacs.org. * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists