Ah, this turns out to be a subtle point, but definitely a bug rather than
a feature. So to copy peak lists we use a generic copying function called
copySubTree(), which is horrendously complicated. It turns out (for
reasons I don't know yet) that this explicitly sets an attribute of a
peakDim called realValue, and it is the latter that is used in the shift
calculation, not the actual peakDim value (which is what you see in the
peak table). Now the way realValue works is that it returns value if it
has not been explicitly set, but once it has been set it never changes
unless you explicitly change it. So setting it explicitly in the copying
function is a mistake (unless the original peakDim had it set, which is
not normally the case). I hope this makes (some) sense. In the copying
peak list function I have now added some clean up code to explicitly unset
the realValue if it should not have been set (so until copySubTree() gets
fixed). So hopefully copying the peak list will now have the intended
effect.
Wayne
On Thu, 18 Mar 2010, Justin Lecher wrote:
>
> Hello,
>
> thanks Tim for that. But unfortunately this copy thing, doesn't worked
> like accepted. The new peaklist has problems. That's actually what I had
> in my post some weaks ago.
> The copied peaks do not contribute their PeakDims to the resonances
> resonances. Although newly picked peaks in this peaklist behave like we
> wanted them to. So the weighting is like normal. But as all the already
> assigned ones do not contributing to the resonances, I did not gain
> anything. Feature or bug? ;)
>
> thnaks justin
>
> --
> Justin Lecher
> Institute for Neuroscience and Biophysics
> ISB 3 - Institute for structural biochemistry
> Research Centre Juelich GmbH,
> 52425 Juelich,Germany
> phone: +49 2461 61 5385
>
>
>
|