HI Jason,
Thanks a lot for your feed-back ..
Of course, I know about the order of loading parameters ... The problems
we had with some frcmod files were because of some subtle details as you
say. These were some atom type issues between libraries, parm99.dat and
the new frcmod files .. I solved those a while ago already (I think I
also discussed those problems on the list) ...
However, I still wanted to simplify the whole procedure of loading the
parameters and I fancied working with newer library versions and so on
... So, that's why I tried to use ff10 ... And that's how I realized the
incompatibilities ... And I was wondering if anybody has dealt with it
already ...
Actually my idea of using the Best&Hummer corrections brought me to this
point ...
Probably you are right ... If I start modifying the modifications to be
compatible with f10, I will have quite a bit of work and mistakes can
always happen when dealing with other people's work ...
Vlad
On 03/28/2013 01:20 PM, Jason Swails wrote:
> On Thu, Mar 28, 2013 at 6:56 AM, Vlad Cojocaru <
> vlad.cojocaru.mpi-muenster.mpg.de> wrote:
>
>> Dear all,
>>
>> Yet another question on the use of different modified versions of the
>> ff99sb force field in AMBER12 ...
>> We are currently using ff99SB+pbsc0+ildn+Brueschweiler(NMR-based)
>> modifications.
>>
>> This relies on very old parameter dataset parm99.dat on top of which the
>> frcmods of the modifications are added.
>> While trying to change the set of ion parameters, we noticed that
>> loading an old parameter data set can lead to errors in which the added
>> parameters in the frcmod files were not correctly implemented in the
>> topology files.
>>
> When loading parameter (parm.dat or frcmod) files, order matters. The last
> parameters loaded overwrite the previous parameters that may have been
> there. This is why ff99SB can be implemented as a short frcmod file loaded
> on top of parm99.dat (which is, as you point out, an old parameter
> database). If this is not true, it's either a subtle detail that you're
> missing or a tleap bug that we need to fix. In any case, a reproducible
> case would help us diagnose.
>
> Now, when trying to move to using ff10 by loading parm10.dat and all the
>> corresponding libraries, I realized that the ff10 is not compatible with
>> the ILDN and Brueschweiler modifications. One of the reason for this
>> incompatibility is because the Calpha atoms have now a CX atom type ...
>>
> ff10 and ff99SB are identical for proteins -- I have validated this on a
> number of small peptide chains containing each of the standard amino acids.
> The main difference is in the nucleic acid FF side, where it has a couple
> improvements over ff99.
>
> Since, as you point out, frcmod.ff99SBildn uses the parm99 atom types, you
> would have to modify ff99SBildn to operate with parm10.dat. My suggestion
> is to target the issues you have with loading frcmods and parm99.dat, since
> that will be easier to solve than what you propose below.
>
>
>> My goal is to use the following force field: ff10 + ILDN +
>> Best&Hummer(NMR-nased modifications).
>> The latter modifications are not even included with AMBER, which is
>> rather unfortunate because D.E. Shaw and co-workers has shown that this
>> combination leads to the best results in folding simulations among the
>> AMBER variants (2012 PLoS One publication)...
>>
> HTH,
> Jason
>
--
Dr. Vlad Cojocaru
Max Planck Institute for Molecular Biomedicine
Department of Cell and Developmental Biology
Röntgenstrasse 20, 48149 Münster, Germany
Tel: +49-251-70365-324; Fax: +49-251-70365-399
Email: vlad.cojocaru[at]mpi-muenster.mpg.de
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Mar 28 2013 - 07:30:03 PDT
