AMBER Archive (2008)

Subject: Re: AMBER: pmemd iwrap trouble

From: Carlos Simmerling (carlos.simmerling_at_gmail.com)
Date: Tue Aug 26 2008 - 09:26:53 CDT

Hi Bob,
no bonds, it is just a dimer with two separate molecules. I suspect
that your code for deciding when to wrap and ptraj's are not quite the
same, or something like that. ptraj and sander use the same- can you
tell me how you wrap? is it deciding based on the first atom in the
molecule, etc. Also I've already run the simulations (hundreds of ns
for 4 systems) so rerunning isn't really an option, I need to find a
way to properly image the current traj files.
thanks
carlos

On Tue, Aug 26, 2008 at 12:38 AM, Robert Duke <rduke_at_email.unc.edu> wrote:
> Carlos -
> I did have one idea on what may be going on here. For pmemd 10 (I presume
> what you are using), in order to support extra points efficiently, I
> introduced a "no_intermolecular_bonds" option. The default value for this
> is 1, and what happens then is any molecules (as defined in the prmtop)
> which have been covalently bonded are redefined as 1 fused molecule. Now, if
> ptraj treats these differently in wrapping, there could be grief (ie., a
> difference in how the wrapping occurs). One option, as long as you are not
> using an extra points forcefield, is to set no_intermolecular_bonds to 0 in
> &cntrl, and then the molecule definition will match the prmtop (but this may
> not be permitted if you have tip4p water for instance). The use of
> no_intermolecular_bonds was absolutely essential for high scaling with extra
> points ff's, though you really could do tip4p and tip5p without this nicety
> (where you would run into problems is with stuff in gaff I believe). I
> actually also believe it to be the better interpretation of the situation,
> but clearly this could create a ptraj/pmemd inconsistency. So the critical
> question - would you have any molecules that would be fused in your system?
> Regards - Bob
>
> ----- Original Message ----- From: "Carlos Simmerling"
> <carlos.simmerling_at_gmail.com>
> To: <amber_at_scripps.edu>
> Sent: Monday, August 25, 2008 12:35 PM
> Subject: Re: AMBER: pmemd iwrap trouble
>
>
>> Bob- a an aside to this, I'm having trouble with ptraj imaging pmemd
>> traj files. I never had this with sander, but with pmemd many of the
>> frames don't properly image a dimer. Do you know which ptraj image
>> syntax/options match that used in pmemd? I'm using this, which always
>> works for sander for an 830 residue protein (415 in each monomer). I
>> want the dimer to be reconstructed properly.
>>
>> center :1-415 mass origin
>> image origin center familiar
>>
>> but often the imaging isn't right- the rmsd for the dimer is a few A
>> larger than it should be, and then it hops back to normal values. you
>> can also see shifts in the dimer during the MD in VMD< then it hops
>> back again. I know it's an imaging issue- do you know how to fix it?
>> thanks
>> carlos
>>
>>
>>
>> On Mon, Aug 25, 2008 at 11:45 AM, Robert Duke <rduke_at_email.unc.edu> wrote:
>>>
>>> Hi Lars,
>>> It should be perfectly compatible; I just checked over the code and iwrap
>>> is
>>> used regardless of box type for both restart and mdcrd. However, I do
>>> believe that if ioutfm = 1 (ie., binary restart file), it is true that
>>> wrapping does not occur. It is actually not needed in the case of a
>>> binary
>>> restart - overflow is not practically possible. We should probably
>>> document
>>> this "feature" or release a patch to change the behaviour (the problem is
>>> caused by the fact that writes of the binary restarts occur on the actual
>>> coordinates, whereas all wrapping is done on a temporary copy of the
>>> coordinates because you don't want to actually wrap the coordinates
>>> internally. This should not be affecting your trajectory, just the
>>> restart
>>> file. Since you see this with ioutfm 0, I suspect this is also an issue
>>> of
>>> the truncated octahedron not looking right in vmd, but am not at all
>>> certain. Seems I once heard Darden say something about this stuff (I
>>> think
>>> he wrote the trunc. oct. wrapping code). Tom? I'll look at all the
>>> relevant code in both pmemd and sander later in the week when I have my
>>> source machine up, talk to other key amber guys, and post something to
>>> the
>>> list as to what, if anything we intend to do about binary restarts not
>>> being
>>> wrapped.
>>> Best Regards - Bob
>>>
>>> ----- Original Message ----- From: "Lars Skjærven"
>>> <lars.skjarven_at_biomed.uib.no>
>>> To: <amber_at_scripps.edu>
>>> Sent: Monday, August 25, 2008 10:58 AM
>>> Subject: Re: AMBER: pmemd iwrap trouble
>>>
>>>
>>>> Hi again,
>>>> I did some more testing without any results.. It seems to me that
>>>> iwrap = 1 is not compatible with octahedral water box?
>>>> Lars
>>>>
>>>> On Mon, Aug 25, 2008 at 3:32 PM, Lars Skjærven
>>>> <lars.skjarven_at_biomed.uib.no> wrote:
>>>>>
>>>>> Hi Bob,
>>>>> Thanks for the quick reply. removing ioutfm=1 does not yield a
>>>>> different result. nor changing to sander. :-/
>>>>>
>>>>> getting rid of some of my input variables the input-file looks like
>>>>> this
>>>>> now:
>>>>>
>>>>> Wrap
>>>>> &cntrl
>>>>> imin= 0, irest= 1, ntx = 5,
>>>>> ntb = 1,
>>>>> cut = 10,
>>>>> ntc = 2, ntf = 2,
>>>>> ntt = 0,
>>>>> nstlim = 1, dt = 0.001,
>>>>> iwrap = 1, ioutfm=0
>>>>> /
>>>>>
>>>>> Am I sure it is not just an imaging problem?
>>>>>
>>>>> I think its not: In the multimer simulation (which gets a few subunits
>>>>> displaced during the run with iwrap=1) the rmsd jumps from 3Å to 80Å
>>>>> when doing rmsd analysis in ptraj. for the monomer simulation the rmsd
>>>>> does not yield an immediate jump, but continuing the simulation after
>>>>> iwrap=1 yields and increasing rmsd value after a few more ns. maybe
>>>>> implying that the protein has been translated and starts interacting
>>>>> with an image?
>>>>>
>>>>> I will continue working on this and let you know if I find anything
>>>>> else..
>>>>>
>>>>> Cheers,
>>>>> Lars
>>>>>
>>>>>
>>>>> On Mon, Aug 25, 2008 at 2:40 PM, Robert Duke <rduke_at_email.unc.edu>
>>>>> wrote:
>>>>>>
>>>>>> Hi Lars,
>>>>>> I am on vacation today, but will look at it tomorrow. There should
>>>>>> not
>>>>>> be a
>>>>>> problem with wrapping in amber 10 pmemd; there was a bug in amber 9
>>>>>> pmemd
>>>>>> for which a patch was released. That said, I am not sure there is not
>>>>>> some
>>>>>> intricacy when binary trajectory files are in use, and I will have to
>>>>>> look.
>>>>>> It should not matter, as the restart file is the primary issue here,
>>>>>> and
>>>>>> it
>>>>>> is not binary, but maybe there is some combination of inputs that
>>>>>> screws
>>>>>> up
>>>>>> on wrapping. Are you sure it is not just an imaging problem? I have
>>>>>> grief
>>>>>> going back and forth between what pmemd or sander does and what ptraj
>>>>>> does
>>>>>> (but I am talking constant pressure here, and ptraj I think hits grief
>>>>>> with
>>>>>> the changing boxsize). Anyway, I will look into it, but you might try
>>>>>> a
>>>>>> 1
>>>>>> step, no binary output run just for grins, or do a single step in
>>>>>> sander
>>>>>> and
>>>>>> see if you get the same result (just gives me more info, in case
>>>>>> something
>>>>>> obvious does not jump out).
>>>>>> Thanks - Bob Duke
>>>>>>
>>>>>> ----- Original Message ----- From: "Lars Skjærven"
>>>>>> <lars.skjarven_at_biomed.uib.no>
>>>>>> To: <amber_at_scripps.edu>
>>>>>> Sent: Monday, August 25, 2008 6:25 AM
>>>>>> Subject: AMBER: pmemd iwrap trouble
>>>>>>
>>>>>>
>>>>>>> Dear Amber users,
>>>>>>>
>>>>>>> I've been running a MD-simulation for about 40ns and needed to wrap
>>>>>>> the water back into the primary box (due to water has swimed too far
>>>>>>> away). As recommended on the mailinglist I used iwrap for only one
>>>>>>> step:
>>>>>>>
>>>>>>> Wrap it
>>>>>>> &cntrl
>>>>>>> imin= 0, irest= 1, ntx = 5,
>>>>>>> ntb = 1,
>>>>>>> cut = 10,
>>>>>>> ntc = 2, ntf = 2, tol = 0.000001,
>>>>>>> ntt = 0,
>>>>>>> nstlim = 1, dt = 0.001,
>>>>>>> ntpr = 1, ntwx = 1, ntwr = 5,
>>>>>>> ioutfm = 1, iwrap = 1,
>>>>>>> &ewald
>>>>>>> dsum_tol = 0.000001,
>>>>>>> /
>>>>>>>
>>>>>>> The restart file produced by this run has about 50% of the solute
>>>>>>> outside the waterbox (when visualized in vmd). I can still carry on
>>>>>>> my
>>>>>>> MD-runs (with iwrap=0) after this, but I am worried about the new
>>>>>>> coordinates for the solute with respect the the water.
>>>>>>>
>>>>>>> However, when I do reimage in ptraj it seems to be ok:
>>>>>>> center :1-224
>>>>>>> image familiar
>>>>>>> trajout test.rst restart
>>>>>>>
>>>>>>> It must be said I use an octahedral water box. Both pmemd9 and 10
>>>>>>> yields the same results for me with this respect.
>>>>>>>
>>>>>>> To wrap it up:
>>>>>>> - should iwrap=1 with pmemd10 work when using a octahedral box ?
>>>>>>> - or should I use ptraj to reimage? if so, are the velocities ok ?
>>>>>>>
>>>>>>> I realise this is a topic that has been discussed on the mailinglist
>>>>>>> earlier and I apologise if my questions are redundant. I searched,
>>>>>>> but
>>>>>>> did not find a clear answer on this..
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Lars Skjaerven
>>>>>>> University of Bergen, Norway
>>>>>>>
>>>>>>> -----------------------------------------------------------------------
>>>>>>> The AMBER Mail Reflector
>>>>>>> To post, send mail to amber_at_scripps.edu
>>>>>>> To unsubscribe, send "unsubscribe amber" (in the *body* of the email)
>>>>>>> to majordomo_at_scripps.edu
>>>>>>>
>>>>>>
>>>>>>
>>>>>> -----------------------------------------------------------------------
>>>>>> The AMBER Mail Reflector
>>>>>> To post, send mail to amber_at_scripps.edu
>>>>>> To unsubscribe, send "unsubscribe amber" (in the *body* of the email)
>>>>>> to majordomo_at_scripps.edu
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> mvh Lars Skjærven
>>>>> Institutt for Biomedisin
>>>>> Universitetet i Bergen
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> mvh Lars Skjærven
>>>> Institutt for Biomedisin
>>>> Universitetet i Bergen
>>>> -----------------------------------------------------------------------
>>>> The AMBER Mail Reflector
>>>> To post, send mail to amber_at_scripps.edu
>>>> To unsubscribe, send "unsubscribe amber" (in the *body* of the email)
>>>> to majordomo_at_scripps.edu
>>>>
>>>
>>> -----------------------------------------------------------------------
>>> The AMBER Mail Reflector
>>> To post, send mail to amber_at_scripps.edu
>>> To unsubscribe, send "unsubscribe amber" (in the *body* of the email)
>>> to majordomo_at_scripps.edu
>>>
>>
>>
>>
>> --
>> ===================================================================
>> Carlos L. Simmerling, Ph.D.
>> Associate Professor Phone: (631) 632-1336
>> Center for Structural Biology Fax: (631) 632-1555
>> CMM Bldg, Room G80
>> Stony Brook University E-mail: carlos.simmerling_at_gmail.com
>> Stony Brook, NY 11794-5115 Web: http://comp.chem.sunysb.edu
>> ===================================================================
>> -----------------------------------------------------------------------
>> The AMBER Mail Reflector
>> To post, send mail to amber_at_scripps.edu
>> To unsubscribe, send "unsubscribe amber" (in the *body* of the email)
>> to majordomo_at_scripps.edu
>>
>
> -----------------------------------------------------------------------
> The AMBER Mail Reflector
> To post, send mail to amber_at_scripps.edu
> To unsubscribe, send "unsubscribe amber" (in the *body* of the email)
> to majordomo_at_scripps.edu
> 

-- 
===================================================================
Carlos L. Simmerling, Ph.D.
Associate Professor Phone: (631) 632-1336
Center for Structural Biology Fax: (631) 632-1555
CMM Bldg, Room G80
Stony Brook University E-mail: carlos.simmerling_at_gmail.com
Stony Brook, NY 11794-5115 Web: http://comp.chem.sunysb.edu
===================================================================
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber_at_scripps.edu
To unsubscribe, send "unsubscribe amber" (in the *body* of the email)
      to majordomo_at_scripps.edu