Hello,
Right, that definitely implied it was an edge of spectrum effect, and
indeed it was. For those who want to read the gory details, see below.
Otherwise just update. (But let me know if you see anything odd.)
So for those who want to know, the problem was that in dimensions with
number of points (say) 256, then for peak positions between 1 and 257 (but
< 257) we want numAliasing to be 0 and the peak position to be as stated.
For peak positions above 257 (until 513) we want numAliasing to be 1 and
the peak position to be as stated - 256. Well, to get the intensity
(before interpolation) for a peak, we look to the nearest grid point and
get the spectrum value there. Only for points between 256.5 and 257 (but
< 257) the nearest position is 257, which is outside the grid, so the code
was getting an error because it was not correcting for this. It is now
wrapping around to point 1 instead.
Two things worth noting. This wrap-around to 1 only makes sense if
numPoints = numPointsOrig (so you haven't thrown any data out when you
processed the spectrum). Otherwise in fact we wouldn't really have the
data for the real position 257. There's not a heck of a lot we can do
about that. But basically, beware of edge-of-spectrum peaks in these
circumstances.
And also, the bug above was only be noticed in the third dimension because
the way the code was calculating where in the file on disk to get the
information, it was happily doing something for the other dimensions but
just going to the wrong point (so not good!). It failed for the third
dimension because it was asking for information beyond the end of the
file. So I've now added some more error checking in the code to make sure
that shouldn't happen again either. (But it won't in this particular
circumstance in any case because of the other fix.)
Wayne
On Fri, 29 Feb 2008, Jolyon Claridge wrote:
> Hi,
>
> the "number points" reads 512 x 128 x 256 so the spectrum is less than
> 257 in the third dimension.
> As far as I can tell the spectrum is drawing ok.
>
> cheers,
> Jo
>
>
> Wayne Boucher wrote:
> > Hello,
> >
> > I assume the spectrum is drawing ok (so no such error when producing the
> > contours, even when you are zoomed out).
> >
> > Is your spectrum less than 258 x 52 x 257 in size in at least one of those
> > dimensions? (If you don't know you can check what Analysis thinks the
> > size is in Experiment -> Edit Spectra -> File Details, in the "Number
> > Points" column.)
> >
> > (So this question will help determine whether this is more likely an error
> > in the Python or in the C. My guess is the former and I'll see if I can
> > find anything obvious.)
> >
> > Wayne
> >
> > On Wed, 27 Feb 2008, Jo Claridge wrote:
> >
> >
> >> Hi,
> >>
> >> I got the following error when using predict from shifts with an HNCO spectrum:
> >>
> >> Exception in Tkinter callback
> >> Traceback (most recent call last):
> >> File "/usr/local/software/ccpnmr/python2.4/lib/python2.4/lib-tk/Tkinter.py", line 1345, in
> >> __call__
> >> return self.func(*args)
> >> File "/usr/local/software/ccpnmr/ccpnmr1.0/python/ccpnmr/analysis/EditPeakListsPopup.py",
> >> line 540, in synthesiseFromShifts
> >> progressBar=progressBar)
> >> File "/usr/local/software/ccpnmr/ccpnmr1.0/python/ccpnmr/analysis/PeakBasic.py", line 2416,
> >> in makePeakListFromShifts
> >> peak = pickPeak(peakList, position, unit=shiftList.unit)
> >> File "/usr/local/software/ccpnmr/ccpnmr1.0/python/ccpnmr/analysis/PeakBasic.py", line 1353,
> >> in pickPeak
> >> setupPeak(peak, doFit=doFit)
> >> File "/usr/local/software/ccpnmr/ccpnmr1.0/python/ccpnmr/analysis/PeakBasic.py", line 1546,
> >> in setupPeak
> >> setupPeakFit(peak)
> >> File "/usr/local/software/ccpnmr/ccpnmr1.0/python/ccpnmr/analysis/PeakBasic.py", line 1579,
> >> in setupPeakFit
> >> center = peak.cPeak.fitCenter(fitMethod, spectrum.block_file, dimDone)
> >> Peak.error: could not get point: 258 52 257
> >>
> >> cheers,
> >> Jo
> >>
> >>
> >
> > .
> >
> >
>
|