Hi Ross,
>> I do not agree with Lachele'statement "You should definitely use the
>> different scaling factors". You are free to do what you want.
>
> This should of course come with the caveat (that Francois gives at the end
> of his email but which I think should be in bold at the beginning) that
> while you are free to do what you want you should be able to demonstrate
> that your approach is MORE 'correct' than the approach suggested and be able
> to vigorously defend this decision when it comes to publication.
Yes
> I should add that the FF99SB parameters for amino acids and nucleic acids
> were parameterized with 1-4 scaling factors of 1.2 for EEL and 2.0 for VDW.
> Glycam on the other hand uses no scaling factor for the 1-4s (so 1.0 and
> 1.0). Hence using anything different than this is outside of the way in
> which the parameters were generated and so would need to be explicitly
> defended.
Yes
> But this approach, refitting all the charges etc, is no longer necessary.
No longer necessary to derive charge values for new molecular fragments?
I am sure you do not agree with what you wrote ;-)
> To
> use Dave Case's terminology if you use tleap from a fully patched
> AMBER11+AmberTools 1.5 AMBER just "Does the right thing"(tm). It will
> automatically use no scaling for the glycam-glycam interactions and 1.2/2.0
> for the FF99SB interactions and then 1.2/2.0 for Glycam-FF99SB interactions.
Yes, this was introduced in sLEaP (as a very new feature versus
tx/LEaP) - and then, there was this bug and the approach has been sent
back to tx/LEaP in the middle of uncorrected-related-sugar tx/LEaP
bugs. Moreover, I wonder how are treated the connecting atom (i.e. the
glycosidic exocyclic heteraoatom) between the glyco & peptide parts in
this approach. Related to the unit itself? but this glycosidic
exocyclic heteraoatom can belong to both units depending on how the
force field library is built. Uff... Then, there is this 'two
different charge derivations' approach used by GLYCAM and AMBER which
are by now 'juxtaposed'. All this seems to me like a 'big cuisine'.
This is why we have developed this unique charge derivation derivation
approach, with a unique set of force field parameters and an identical
setting for the treatment of 1-4 non-bonding interactions. Obviously
this has been only tested on cyclodextrins and gluco alpha-1,4, but a
second paper is in preparation.
Considering that L-Rhamnose is a 6-deoxy-L-Mannose and from our
unpublished tests I believe Yun can use the approach we reported or
the GLYCAM approach. But the approach selected has to be demonstrated
that it works; this can be done during the charge validation step. Our
approach is however far more simple and associated with R.E.D., R.E.D.
Server and R.E.DD.B. a user can generate automatically all her/his FF
libraries and easily share them in the community. However, as I said
in one of my previous email our approach so far is not valid when a
galacto configuration is found for instance...
> My point being the same as Lachele's here.
Yes, this is what I expected ;-)
> AMBER now does the correct thing
> with respect to the Glycam and Amino Acid force fields when you mix them and
> thus there is no need to add all the complexities of refitting resp charges,
> adjusting dihedral parameters etc etc unless you are in the business of
> making your own force fields.
'no need to add all the complexities of refitting resp charges' in the
case of Yun?
This statement looks like a bad joke.
Yun will have to validate the charge values obtained whatever the
approach used. This can be done with an homogeneous or heterogeneous
treatment for the 1-4 non-bonding interactions. Once again I think
that Yun should run MD simulations using different input conditions
and validate them whatever what developers suggest. This is the best
way to learn and create his own way. When we first started using
GLYCAM 2006 for cyclodextrins, limitations were encountered even if
GLYCAM developers suggested to use this force field in the Amber
mailing list in this very specific case. Thus, I think testing a force
field before to use is always a good idea...
regards, Francois
BTW, Ross you reported the development of a new feature in tx/LEaP
related to the keyword bug (Num Lk & Scr Lk keys). I wanted to ask to
a student to work on this very same problem, but he did not have the
time to do it. When do you plan to release that? this is quite useful
when one starts... We will release new features in LEaP as well.
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Sep 20 2011 - 01:00:03 PDT
