Hello,
On Thu, 24 Jan 2008, Johnny Croy wrote:
> Hi all,
>
> I have been running into a bit of a problem here. I want to export out
> my assigned peak table for a 15N-HSQC (in nmrPipe) format, so that I can
> then use nLinLS (nmrPipe) program to calculate out a peak volume for
> each of my assigned peaks. However, there is no information on the
> linewidths (in either X or Y), which nLin needs to calculate a volume.
> These values are all set to zero in the peak table that is output from
> format converter. Is there anyway to get this information encoded from
> format converter or do I have to repeak the peaks in nmrPipe (which
> calculates the linewidth on the fly when the peak is picked)?
>
> Thanks for your input.
>
> -J
>
Analysis doesn't use peak (well peakDim) lineWidth for anything (except in
s small way). In particular we don't set it. This is why the
FormatConverter is exporting 0. As it happens, in the C world (where the
peaks are determined) we actually calculate the linewidth (well, more
accurately we could calculate the linewidth, but normally that step
happens to be skipped, currently). So it should just be a matter of
passing that information back up to the Python world. I'll talk with Tim
about this but I don't see any great issues stopping this, it ought to be
a relatively small fix.
(The linewidth estimate is courtesy of Sparky.)
> PS: I have tried the volume fitting functions in analysis, but I find
> that nLin does a much better job in getting the volumes correct (less
> scatter in a T1 decay plot).
>
I'm not surprised about that. The volume estimates in Analysis do not do
any fitting and so are fairly crude. NLinLS does an actual fitting (using
products of 1D line shapes). This is the kind of thing we'd like people
to be able to do seamlessly from inside Analysis (or any other similar
application): run arbitrary algorithms to do NMR analysis. That is the
whole point of the data model, and trying to encourage NMR software people
to develop against it. Currently to do NLinLS you do indeed have to
export using the FormatConverter. In future we do expect to have better
methodologies on the volume front available, and not necessarily developed
by us but by others.
(I have never used NLinLS but I would guess that they must use the initial
lineWidth estimate just as a starting point, and then provide a refined
estimate on output. Otherwise it would be a bit of a cheat. So their
algorithm ought to allow 0 as an initial estimate, but it's quite possible
it does not converge very well in this case, i.e. you need to be closer to
the real value to converge to it.)
Wayne
|