-- In the IMPR part of the frcmod file, I am stating that I want to keep the carbonyl group planar ( -C-O-(DH)_2 ). I have used exactly the same frcmod file and did a lot of runs in Amber 8 (with different choice of ntc and ntf and etc.), too. I never had any errors or vlimit messages during the simulations, and the simulations ended up with no problem. When I checked out the .traj files of the simulations I ran, the amino group and carbonyl group (with the 2 dummy atoms attached to O2) were jiggling a little bit but I could see that they were trying to stay planar. I wonder if this frcmod file I am using is compatible with AMBER 9. If so, maybe sander is reading the improper terms wrong. 2. My second thought is that the SHAKE algorithm has a bug in it. But still this does not explain why I am ending up with snap01 and snap02 structures (SHAKE is off). Or maybe there is a bug in multisander. But if this was the case, the test simulation I put into /test directory, $AMBERHOME/test/ti_eth2meth, would not work, either. So, I am wondering if it is possible to check whether sander is using the right improper terms or not. I can send a very detailed email for the case cytosine->isocytosine transformation, but I would like to know, first, if the above frcmod file is compatible with Amber 9. Or if it is possible to check whether sander is using the right improper terms. Best, PS 1: All structures were neutralized first with Na+ ions and solvated in water. I have created my own .prepi files for the nucleic acids and used these files in xleap to create the parm/top files. PS 2: I did not run any equilibration neither in amber 9 not amber 8 simulations. I have used the following input file (and I was changing ntc, ntf, irest, ntx, icfe, etc. in the simulations). I have kept the "tempi = 300.0, temp0 = 300.0" part in all simulations. I did some heating simulations before, and they were also giving the same vlimit messages in the output file. So, I decided to use "tempi = 300.0, temp0 = 300.0" all the time. --------------------------- mdin ----------------------------------- TEST MD &cntrl imin = 0, irest = 1, ntx = 5, ntb = 1, cut = 8, ntr = 0, ntc = 2, ntf = 2, tempi = 300.0, temp0 = 300.0, ig=233, ntp=0,taup=2.0,pres0=1, ntt = 3, gamma_ln = 1.0, nstlim = 10000, dt = 0.001, nscm = 1000, nrespa=1, ntpr = 100, ntwx = 10, ntwr = 1000, icfe=$icfe, klambda=6, clambda=$lambda / -------------------------------------------------------------------- On Tue, 29 Nov 2005, David A. Case wrote: > On Tue, Nov 29, 2005, Ilyas Yildirim wrote: > > > icfe=2, klambda=6, clambda=0.5 > > ... > > > vlimit exceeded for step 218 ; vmax = 22.6949147823007 > > > > Coordinate resetting (SHAKE) cannot be accomplished, > > > > I am not sure why I am ending up with this kind of an error. I > > first thought that the modified .frcmod might be the reason, but this > > mod.frcmod file is working fine with AMBER 8. I have checked out the > > .mdcrd trajectories, and the -NH2 and -O-(DH)2 parts of the structure is > > doing really weird stuff. > > Have you run long-ish equilibrations at both endpoints? You should always do > this first. Look at the trajectories visually...see if you can find out what > the "really weird stuff" is coming from. > > How big are the values of DV/DL that you get? Big values indicate that a > single geometry cannot simultaneously accommodate both endpoint potentials. > Ideally, you want the optimized geometries of the two endpoints to be pretty > similar to one another. Another obvious test is to set icfe=klambda=1, to > make sure that there is not something arising from the new code you added. > > ...dac > > -- Ilyas Yildirim --------------------------------------------------------------- - Department of Chemisty - - - University of Rochester - - - Hutchison Hall, # B10 - - - Rochester, NY 14627-0216 - Ph.:(585) 275 67 66 (Office) - - http://www.pas.rochester.edu/~yildirim/ - ---------------------------------------------------------------
(IMAGE/jpeg attachment: snap01.jpg)
(IMAGE/jpeg attachment: snap02.jpg)
(IMAGE/jpeg attachment: snap03.jpg)