dimensionality reported in peak table not correct
- Hi fellow nmrPipe users,I've run into an unexpected situation. The details are below. Thanks in advance for any suggestions.This is what I'm doing:1) A 256 x 256 x 512 data set is processed in the Rowland NMR Toolkit.2) The spectrum is saved as an nmrPipe file.3) The pipe2xyz command is used to write a directory of F1-F3 planes.4) The planes are loaded into nmrDraw by using the "template" option.5) The peak picker in nmrDraw is executed.Here's the dilemmaPart of the output from the seepar command in the Toolkit:Domain : (slow) F1 (fast) F2 (v slow) F3Points : 256 R 256 R 512 RPpm high : 69.001 134.000 11.758Ppm low : 45.094 102.125 4.786Part of the header from the nmrDraw peak table:DATA X_AXIS F1 1 258 69.002ppm 44.906ppmDATA Y_AXIS F3 1 514 11.758ppm 4.758ppmDATA Z_AXIS F2 1 258 134.000ppm 101.875ppmNote how the peak table header reports the spectra to be bigger by 2 points along each dimension, with the low end of each dimension's ppm range getting extended.Curiously, in the nmrDraw window, the title bar correctly indicates that the spectra is 256 x 256 x 512. The GUI for cycling through the F2 planes also correctly goes from 1 to 256.Here's what I've done to troubleshoot this1) Rather than loading and picking the 3D spectrum, I loaded and picked a single 2D plane. The same incorrect dimensions are registered in the peak file, while the correct dimensions are shown in the nmrDraw interface.2) Rather than using the putnmrpipe command in the Toolkit, I saved the spectra in Toolkit format. I used Spectrum Translator (http://connjur.uchc.edu) to convert the Toolkit file to a series of nmrPipe files. The dimensionality error persists.3) I used the Toolkit to truncate the 3D data set. When writing out nmrpipe files and peak picking them, the dimensions in the peak table header are all off by 2. I tried this because unfortunately there are peaks near the borders. Since the peak picker identifies off-grid peak locations, it seemed possible that the border peaks were forcing the peak picker to "pad" the data to give enough room. Truncating the data as to not have peaks near the border seems to address this, but the error persists.