On Aug 21, 2007, at 11:20 AM, Jakob Toudahl Nielsen wrote:
> Citat af John Kuszewski <johnk at mail.nih.gov>:
>>
>> On what basis did you assign the peakAssignments' likelihoods?
> I use statistics performed on several hundred protein structure
> corelating structure and secondary designation built into our
> program to estimate the likelihoods.
Sounds a bit like AutoAssign's mechanism. Can you share the details
with me? It might be broadly useful.
> My system is 76 residues. I count the restraints differently, I
> combine the restraints on both of the diagonal into one single
> restraint and, furthermore, filter out the restraints with no
> information (i.e. one and two-bond restraints). Finally my program
> removes restraints with very small likelihoods.
This is not necessarily the best way to go, since you're removing any
chance of a good (but, according to your
assignment statistics, unlikely) peak assignment from ever being
used. Better to just set its previousLikelihood to zero.
>
>>
>> Since you have a reference structure, are you using it in the
>> initialMatch
>> and summarize_pass scripts? That'll give you some valuable
>> statistics in the
>> headers of your .peaks and .shiftAssignments files.
> I don't use these scripts.
Pity. They really do a good job for the general case.
> I have 16 long-range restraints (i.e. restraints with solely long-
> range assignment posibilities) of which 13 agree with the
> structure. I think this is few.
Indeed, that is a very small number of long-range restraints. Sounds
like a marginal case.
>
> Many thanks for your help, I aggreed with you and started from
> pass3 which I tried to modify in different ways. However, I still
> have problems getting my system to converge.
I noticed my updates in the latest release helped, so I'll just
confine myself to some general comments here.
> I realize that pasd protocols differ significantly from other
> annealing protocols in that the noe constant is ramped up during
> cooling rather ramped down.
Actually, the NOE force constant is ramped up during cooling in
almost every annealing protocol I know of.
> I guess the procedure must be followed in order to ensure no bias
> towards prior likelihoods.
I try to bias the structures toward the previous likelihoods. I just
try to avoid bias toward the previous generations (if any) of
structures themselves,
by always starting from random torsion angles.
> Is it true that pasd somehow scales the violation energy to agree
> with the total number of NOEs?
The violation energy is the sum of the energies of the individual
peaks. So yes, it scales with the number of peaks in your spectrum.
That's true of all the normal NOE energy terms, too.
> Does it have anything to do with the concepts of "-
> noeCompletenessWeight" or "-scatterWeight" in the sa_protocols.tcl
> script - I don't understand the meaning of these variables.
No--those are for activating/inactivating entire shiftAssignments,
rather than just individual peakAssignments.
I'm writing up a manuscript about this now, which will explain that
in more detail.
> Obveously, I would like my calculations to converge using all NOEs,
> have you had similar problems? I notice that you choose the number
> of long-range violations as your criteria for convergence rather
> than the total energy. Is this because there were to many
> structures with lower total energy being incorrectly folded?
No, it's because the energy isn't a great measurement of what we're
trying to do. Xplor isn't trying to simulate physics. It's trying
to find a minimum to a
high-dimensional potential function. Since Marvin typically deals
with systems that have significant numbers of bad peaks (or bad peak
assignments to
good peaks), looking at the energy isn't too enlightening. You
really just care about finding structures that have small numbers of
violations. So
that's what I look at.
>
> Do you have suggestion of what goes wrong in my case? Since I use
> solid state data I have restraints between carbon atoms. The
> ambiguity is rather large for my restraint ca. 4-5 degeneracy (as a
> geometric average) after doing prefiltering. I think this should
> not be a problem.
No, that degree of degeneracy isn't too bad. Picking up on what
Charles said in his initial followup, I presume you're expressing
that degeneracy as
separate peakAssignments for each peak, rather than by selections
that cover large numbers of atoms. That is, your .shiftAssignments
and .peaks files
should look more like
shiftAssignment sa1
-protonSeletion (resid 3 and name ha)
-heavyatomSelection (resid 3 and name ca)
-from
end
shiftAssignment sa2
-protonSelection (resid 9 and name ha)
-to
end
shiftAssignment sa3
-protonSelection (resid 21 and name ha)
-to
end
shiftAssignment sa4
-protonSelection (resid 44 and name ha)
-to
end
peak 1
peakAssignment 1_1 sa1 sa2 -likelihood 0.9
peakAssignment 1_2 sa1 sa3 -likelihood 0.5
peakAssignment 1_2 sa1 sa4 -likelihood 0.1
end
rather than looking like
shiftAssignment sa100
-protonSelection (resid 3 and name ha)
-heavyatomSelection (resid 3 and name ca)
-from
end
shiftAssignment sa101
-protonSelection ((resid 9 and name ha) or (resid 21 and name ha)
or (resid 44 and name ha))
-to
end
peak 1
peakAssignment 1_1 sa100 sa101 -likelihood 0.9
end
In the former case, marvin can tease out the separate possibilities
and give likelihoods to each.
In the latter, marvin is stuck doing sum averaging, in which case its
error tolerance is largely reduced
to the level of ARIA.
Otherwise, the general advice I can offer you is:
1. Increase the number of long range restraints you have available,
even at the cost of including bad peaks as well.
2. In applying your likelihood filters, don't remove peaks or
peakAssignments entirely if they don't pass your pre-filter.
Just set their previousLikelihoods to zero.
Hope this helps,
--JK
