[gmx-users] Replacing charges of a residue, pdb2gmx -rtpo alternative?

[J. Nathan Scott]

On Tue, Dec 7, 2010 at 3:17 PM, Mark Abraham <Mark.Abraham at anu.edu.au> wrote:
> On 8/12/2010 4:07 AM, J. Nathan Scott wrote:
>>
>> Hello all! I spent some time searching the archive and can't find an
>> answer to this question. Is there a replacement for the -rtpo option
>> for pdb2gmx? This option is mentioned in the v 4.5.3 (the version I am
>> using) manual (pg 115) but does not seem to work, and yields the error
>> "Invalid command line argument: -rtpo" when I try to use it
>>
>> I would basically like to have the OPLSAA aminoacids.rtp file in my
>> working directory (which has some modified charges for the TRP
>> residue) supersede the one in the Gromacs force field share directory.
>> Is there a way to do this?
>>
>> So far I have resorted to copying the shared oplsaa.ff folder to my
>> working directory and modifying the aminoacids.rtp file in that
>> directory, and then selecting that directory to source my force field
>> when I run pdb2gmx.
>
> This is the intended behaviour. Rather than modifying your installed
> database, or having to mess with the GMXLIB environment variable, you can
> copy the whole xx.ff directory into a local directory and have local
> modifications. pdb2gmx reports clearly on stdout which directory(s) it is
> (considering) using.
>
>>  This of course works, but I have noted a peculiar
>> behavior using this method. No matter whether I select force field 1,
>> which is OPLSAA from my working directory, or force field 15, which is
>> OPLSAA from the share directory, my topology file ends up with charges
>> in the working directory oplsaa.ff folder's aminoacids.rtp file. Even
>> when I select that pdb2gmx should use the share version, it is clearly
>> still using the force field folder in my working directory. I
>> confirmed this by renaming the aminoacids.rtp in the working directory
>> file to aminoacids.rtp.bak, which produced the error "Could not find
>> any files ending on '.rtp' in the force field directory 'oplsaa.ff'"
>
> That sounds very weird. I'd suggest you start a new working directory, copy
> the oplsaa.ff over fresh, make the .rtp modifications and see if you can
> reproduce the issue. If so, please file a Bugzilla.

Thanks for your reply Mark. I have confirmed this behavior many times
now, and so I have filed a Bugzilla report as you suggested. I did
find a quick fix: as long as the copy of the .ff directory in the
working directory is named something different than the copy in
share/top then pdb2gmx seems to differentiate between the two
perfectly well, as confirmed by the charges in the topology files it
is generating. It is only when they are named the same thing
(oplsaa.ff, for instance) that the force field selection problem
happens. Perhaps the programmers assumed users would be smart enough
to rename the modified force field directory? ;)

Best Wishes,
-Nathan

>
>> Can someone recommend a better method for what I am attempting to do?
>> Also, is pdb2gmx's handling of force field directories appropriate? I
>> had assumed that selecting the share version of a force field would
>> force all the necessary files to be read from that share directory,
>> but this is clearly not the case.
>
> It should be the case.
>
> Mark
> --
> gmx-users mailing list    gmx-users at 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-request at gromacs.org.
> Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>



-- 
----------
J. Nathan Scott, Ph.D.
Postdoctoral Fellow
Department of Chemistry and Biochemistry
Montana State University