From: Ryan McGreevy (
Date: Wed May 24 2017 - 11:07:44 CDT

I have never used coot, so I can't say for sure. For the "mdffi" and
"Timeline" calculations, the threshold is not in sigmas, but instead is a
direct cutoff for voxel values. "mdff ccc" is, however, in sigmas.

What do you mean by "weird" scores? If the per-residue correlations are not
looking as you expected them to, it is probably because of the resolution
of the map. 4-5A is not quite good enough to really see side-chains, so the
correlations for individual residues may be misleading. Also, because each
residue contributes density to its neighbors, it is hard to get a clear
correlation because it is hard to separate the contribution from the
surrounding area. This is another reason we don't generally do per-residue

On Wed, May 24, 2017 at 10:52 AM Karol KASZUBA <>

> Hello again,
> Can you tell me, which treshold value would correspond to sigma=6 in coot?
> Map resolution 4-5A.
> I am asking since I am getting some weird scores.
> thanks
> ------------------------------
> *From:* Karol KASZUBA
> *Sent:* Wednesday, May 24, 2017 5:22 PM
> *To:* Ryan McGreevy;
> *Subject:* RE: vmd-l: MDFF time line ccc score
> OK.
> thanks
> ------------------------------
> *From:* Ryan McGreevy []
> *Sent:* Wednesday, May 24, 2017 5:11 PM
> *To:* Karol KASZUBA;
> *Subject:* Re: vmd-l: MDFF time line ccc score
> Just to be clear, you said you had tried "mdff ccc" which is different
> from the "mdffi cc" that I am proposing you use. "mdffi cc" uses exactly
> the same algorithm as Timeline and will give you exactly the same results,
> whereas "mdff ccc" will not (and will also be much slower).
> On Wed, May 24, 2017 at 10:09 AM Karol KASZUBA <>
> wrote:
>> Hi,
>> Yes. Exactly, I want to do it for a single frame.
>> Using mdffi cc was my plan from the very beginning, but as I said, the
>> ones computed with Time Line appear to be more reliable. However, to be
>> sure I need to run additional tests. I will keep you posted
>> thanks!
>> ------------------------------
>> *From:* Ryan McGreevy []
>> *Sent:* Wednesday, May 24, 2017 5:03 PM
>> *To:* Karol KASZUBA;
>> *Subject:* Re: vmd-l: MDFF time line ccc score
>> Timeline wasn't really designed to give a per-residue cross correlation
>> because (a) calculating the correlation for each residue for an entire
>> trajectory is very computationally heavy, even with the fast algorithm
>> Timeline uses and (b) most cryo-em maps are too low resolution for
>> per-residue calculations to make sense.
>> If you really want to do this though, you can write a fairly simple
>> script using the "mdffi cc" command. "mdffi" (note the 'i' at the end) is
>> the newer, faster algorithm that both Timeline and "mdff check" uses,
>> versus the older, slower "mdff ccc" command (though mdff ccc too will be
>> changed in the future, once all the bugs are worked out). Using this, you
>> can just calculate the mdffi cc for each residue you want in a tcl loop. I
>> would recommend only doing this for a single frame, however, and not an
>> entire trajectory if you have one.
>> On Wed, May 24, 2017 at 9:42 AM Karol KASZUBA <>
>> wrote:
>>> Hi Ryan,
>>> Thank you for your prompt reply.
>>> This is cryo-em model and in certain places there is no density at all,
>>> which would explain these low negative values.
>>> (1) Actually, I played with treshold a bit and now the values are quite
>>> nice, between 0.5-0.78.
>>> The value of treshold corresponds to the sigma values I use. So, it
>>> looks good now.
>>> (2) I also found that Timeline cc gives a much more reasonable score
>>> than mdff ccc.
>>> I played quite a lot with selection in Timeline. Can you tell me what
>>> would be the proper selection to get a per-residue score for a given
>>> segment of residues. For example, when I try {segname PRT1 and resid 1 to
>>> 29} it returns one number, most likely treating selection between {} as one
>>> segment. However, what I need is per-residue score.
>>> I have a big structure, so typing {resid 1} {resid 2} and so on will not
>>> work for me.
>>> thank you very much
>>> ------------------------------
>>> *From:* Ryan McGreevy []
>>> *Sent:* Wednesday, May 24, 2017 4:16 PM
>>> *To:* Karol KASZUBA;
>>> *Subject:* Re: vmd-l: MDFF time line ccc score
>>> (1) In general those values are pretty low. Having a high of .35 is not
>>> very good. The extremely low negative values are most likely due to pieces
>>> of the structure that are sticking out of the map significantly, where
>>> correlation is undefined. You could also try using the "threshold" option
>>> in the Timeline cross correlation parameters (try 0.1 for example) which
>>> will remove some of the excess noise around your structure from the
>>> calculation. Is your structure that you are analyzing the result of a
>>> fitting, like MDFF? Without actually seeing the map and model it is hard to
>>> say anything more concrete.
>>> (2) It is okay that Timeline and mdff ccc do not give exactly the same
>>> results. First, if you ran Timeline with default options, the correlations
>>> are calculated on sections of contiguous secondary structure, not
>>> per-residue, so the CC's are not being calculated on exactly the same
>>> parts. Second, the algorithms used by the Timeline and mdff ccc are not
>>> exactly the same, so there will be small discrepancies, but shouldn't be
>>> more than a few hundredth.
>>> On Wed, May 24, 2017 at 2:50 AM Karol KASZUBA <>
>>> wrote:
>>>> Hi,
>>>> I am trying to calculate the cross-correlation score between my map
>>>> and a model. The map is in .mrc format.
>>>> (1) At first I used time line plugin and "calculate cc" option.
>>>> So, I got the scores. They make sense, but what I am worried is the
>>>> scale: it starts from -100 and finishes at 0.35. Is it normal?
>>>> I would expect a score from 0 to 1, where low values would correspond
>>>> to poor density fit, while higher (positive) values would denote a good
>>>> match.
>>>> (2) I also calculated cc using "mdff ccc" command in tcl console. I
>>>> just choose one residue to see whether the cc score calculated in time
>>>> line and from command line. will be the same. These were not.
>>>> Please let me know what do you think
>>>> thanks
>>>> Karol