Re: [AMBER] problem in solvation

From: Bill Ross <ross.cgl.ucsf.EDU>
Date: Wed, 9 Nov 2011 14:22:12 -0800

> >That's good ;-) My wild guess is that given leap's internal method of
> >traversing the atoms, somehow some atoms are missed. Are the ones
> >that come close to the box in the protein, or the other molecules?
>
> yes they are protein atoms

Hmm, this makes me less confident of my hypothesis, since proteins
are basic Amber ff residues (less subject to new errors), and more
likely to be first in leap's iteration over atoms, plus it is strange
that only some of the residues would touch the edge of the box in
one direction.

> >I think atom numbering doesn't matter, but residue numbering could
> >be important. In which case the actual numbers may not differ so
> >much as making sure that adjacent residues have different numbers.
> >The case to be most concerned about is adjacent residues with the
> >same name and number. Maybe a TER between such residues (if chemically
> >appropriate) would be enough distinction.
>
> I modified the residue numbers and put TER line too.. still giving errors.
>
> >I'd have to see the loadpdb output to guess.
>
> please look at my previous email

None the emails I can find give the errors, and my bandwidth is
limited for extensive search. But I found your original post on
this thread with the picture (visible in the browser but not in
my antique email program), and it is certainly as you describe.

> >Is clearance in the opposite direction correctly the 8A specified, or
> twice that?
>
> yes I measured distance ~ 16-18 A

I wish that I still worked on Amber, to debug it. Since the 'combine'
method for building seems in general use, I think it is worth fixing.

Bill

>
> >
> > Bill,
> >
> > I am still quite new to Amber things and have used leap in the same way
> > as Senthil did in order to set up a protein-ligand complex. Hence, I
> > used something like:
> >
> > p = loadpdb protein.pdb
> > l = loadpdb ligand.pdb
> > c = combine {p l}
> > [addions, solvateoct, saveamberparams]
> >
> > The system was built and simulated properly this way. I am wondering why
> > this should be an unusual way. Do most people set up PDB files with the
> > entire complex before starting leap?
> >
> > If combine works well for two objects, shouldn't it perfectly upscale
> > with more items? Also, why should it matter to the solvation code how
> > the set of coordinates it receives as input has been created?
> >
> > It would be nice to see if the solvation behavior changes when Senthil
> > prepares his complex in one big PDB file and skips the combine step. I
> > don't hope so.
> >
> > Jan-Philip
> >
> >
> > On 11/09/2011 12:05 AM, Bill Ross wrote:
> > > Hi Senthil,
> > >
> > >> complex = combine {protein HQN MYR1 MYR2 MYR3 MYR4 MYR5 MYR6}
> > >
> > > This is unusual - if you just 'savepdb complex' at this point,
> > > is the structure reasonable? Maybe the default coordinates of
> > > all these units would fall in the right place without loadpdb
> > > assigning them, but if so I would be surprised. But even in
> > > that case, you are taking a route for building the system that
> > > few have used before, I believe, and this could explain why it
> > > hasn't been seen before. Certainly it is one that I never thought
> > > to test.
> > >
> > > Bill
> > >
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>

_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Wed Nov 09 2011 - 14:30:06 PST
Custom Search