Rasmus,
You are correct, and none of your current clusterType would seem to fit. So, if this was to really be implemented, a new clusterType would need to be defined. What we really want to track is if a peak is "well" resolved or not. The simplest way to define that characteristic which I have seen in the literature is using the difference in peak position and the linewidths. Two peaks are resolved if there difference in position is greater than two times the sum of their linewidths. This relativistic definition gives some flexibility depending on the size of molecule, experimental set up and processing.
Hope this helps.
Cheers,
Mike
Michael Latham
Graduate Student
Department of Chemistry and Biochemistry
University of Colorado, Boulder
Phone: 303-492-8085
Fax: 303-492-2439
---- Original message ----
>Date: Wed, 13 Feb 2008 16:43:05 +0000
>From: Rasmus Fogh <[log in to unmask]>
>Subject: Re: Linewidth information from exported peak table
>To: [log in to unmask]
>
>Dear All,
>
>Thanks for waking me up.
>
>The data model actually has a PeakCluster class, with a many-to-many link
>to Peak, and attributes serial, annotation and clusterType. As you might
>guess this goups peaks together in clusters, with the clusterType defining
>what kind. A Peak can be in many clusters. The currently supported
>clusterTypes are givenbelo, as from the model documentation.
>
>It is really a question for those who understand nlinLS, but I do not
>think that any of the existing clusterTypes would fit. It would be dead
>easy to add a new clusterType, provided somebody can give me a string to
>use for the clusterTypa and a couple of lines to use for documentation.
>The harder bit would be to change the code that should use this.
>
>Yours,
>
>Rasmus
>
>
>Current clusterTypes:
>
>'multiplet': peaks in cluster are subcomponents of the same multiplet.
>They share the same mainPeakDimContribs and hence the same central
>assignment.
>
>'static': peaks in cluster represent the same peak in different
>experiments, where the experiments share the same shift list. The
>peakDimContribs, and hence the assignment, are the same for all peaks. A
>typical example would be peaks in a T1 experiment series.
>
> 'shift': peaks in cluster represent the same peak in different
>experiments, where the experiments belong to different shift lists. The
>peakDimContribs, and hence the assignment, is the same for all peaks. A
>typical esample would be peaks in a titration or temperature series.
>
>'symmetry': peaks are symmetry equivalent. They may belong to the same or
>different experiments. Examples are peaks on opposite sides of the
>diagonal in a 2D NOESY or 4D HCCH experiments. Also possible would be a
>H-CH and a HN-H peak from different experiments that represented the same
>H-H NOE. Their assignments are correlated, but exactly how would depend on
>the context.
>
>
>
>
>---------------------------------------------------------------------------
>Dr. Rasmus H. Fogh Email: [log in to unmask]
>Dept. of Biochemistry, University of Cambridge,
>80 Tennis Court Road, Cambridge CB2 1GA, UK. FAX (01223)766002
>
>On Wed, 13 Feb 2008, Brian Smith wrote:
>
>> Hi Mike,
>>
>> Thank goodness you & Wim are awake! I had totally misremembered
>> what the clustIDs were about. As you point out and as I had in my
>> original notes:
>>
>> CLUSTIDs must be set for nlinLS
>> (could be set in formatConverter NmrDrawFormat.py self.clustId but
>> concept not supported in analysis yet?)
>>
>> clustTab.tcl is really the right solution for dealing with these then
>> unless the data model is going to support the notion of "peaks that need
>> to be fitted simultaneously". I guess this is one for Rasmus then - is
>> this anything like what you are doing for multiplets?
>>
>> Brian
>>
>> On Wed, 13 Feb 2008, Michael Parker Latham wrote:
>>
>> > Just to put my two-cents in...
>> >
>> >>> NmrDraw documentation says:
>> >>>
>> >>> CLUSTID
>> >>> identifies the cluster of peaks that a given peak over-
>> >>> laps. Peaks with the same CLUSTID value are considered
>> >>> to be in one overlapped group.
>> >>>
>> >>> So this is quite different from a spin system, no? Or at least it would
>> >>> depend on the type of spectrum (and overlap).
>> >>
>> >> In the sense of this generic definition you're right of course. In the
>> >> context of fitting peaks from a series of (HSQC based) experiments, the
>> >> CLUSTID seems to be used to identify peaks from the different spectra that
>> >> originate from the same spin system. I guess this is also how they're used
>> >> in 3D 15N or triple resonance spectra en route to automatic assignment
>> >> etc. Given the generic definition they may also be used to associate sub
>> >> peaks of multiplets or all sorts of other context specific things.
>> >
>> > The CLUSTID is completely different from a spin system. It simply tells nlinLS to fit a given set of peaks together. Under no given circumstance do this peaks have to be in the same spin system... for a 2D 15N HSQC, they absolutely would not be.
>> >
>> > In Johnny's analysis of pseudo3D relaxation data, the peak INDEX number identifies the "spin system" or amide which is relaxing in each pseudo3D. A given peak will then be fit simultaneously across the pseudo3D. If two peaks are overlapped and share a CLUSTID, they will be fit together across the pseudo3D.
>> >
>> > Finally, CLUSTID has nothing to do with triple resonance data or automatic assignments. It does not seem to me that there is a function in Analysis analogous to CLUSTID. Again, it only exists in NMRPipe for lineshape analysis, so overlapped peaks can be fit simultaneously.
>> >
>> >> How about just a "treat spin systems as clusters" flag/button on export
>> >> and vice versa on import? The only thing I wondered was whether
>> >> NmrPipe/Draw insisted on numbering them from 1 or something.
>> >>
>> >
>> > Given what I have written above, this would only work if every peak in the spectrum were well resolved.
>> >
>> > Like I said.. just throwing this out there.
>> > Cheers,
>> > Mike
>> >
>> > Michael Latham
>> > Graduate Student
>> > Department of Chemistry and Biochemistry
>> > University of Colorado, Boulder
>> > Phone: 303-492-8085
>> > Fax: 303-492-2439
>> >
>> >
>> > ---- Original message ----
>> >> Date: Wed, 13 Feb 2008 12:59:13 +0000
>> >> From: Brian Smith <[log in to unmask]>
>> >> Subject: Re: Linewidth information from exported peak table
>> >> To: [log in to unmask]
>> >>
>> >> Hi Wim,
>> >>
>> >> On Wed, 13 Feb 2008, Wim Vranken wrote:
>> >>
>> >>>>> 3. Is there anyway to get analysis to assign groups of peaks (akin to the
>> >>>>> ClustID found in nmrDraw). I don't know if analysis has any such use for
>> >>>>> this, but it will be nice to have as nLin uses these ID's to
>> >>>>> simultaneously fit clustered peaks. There is a tcl macro in nmrDraw
>> >>>>> called clustTab.tcl that works okay, but really requires close (and often
>> >>>>> time consuming) inspection by hand after running. It would be nice to
>> >>>>> have these from analysis (if possible).
>> >>>>
>> >>>> In nmrDraw clusters roughly map to analysis/data model spin systems for
>> >>>> assigned peaks, at least for this purpose. The problem is in storing the
>> >>>> mapping between spin sytem and cluster. I can't remember the constraints
>> >>>> on cluster numbering. As far as I remember formatConverter knows about
>> >>>> clustIDs but we need to figure how to map these to spin systems in the data
>> >>>> model. In principle I guess this could be done at the level of a spin
>> >>>> system annotation string (nmrdraw.clustid=X) that could be parsed by
>> >>>> formatConverter? Of course it would be nice to make this a two way process
>> >>>> for peak checking and and reimport of the linewidths. Any thoughts Wim?
>> >>>
>> >>> I can track the clustId, sure... probably best on a peak level though. Anyway
>> >>> the question is how to generate these for the first time when exporting - the
>> >>> NmrDraw documentation says:
>> >>>
>> >>> CLUSTID
>> >>> identifies the cluster of peaks that a given peak over-
>> >>> laps. Peaks with the same CLUSTID value are considered
>> >>> to be in one overlapped group.
>> >>>
>> >>> So this is quite different from a spin system, no? Or at least it would
>> >>> depend on the type of spectrum (and overlap).
>> >>
>> >> In the sense of this generic definition you're right of course. In the
>> >> context of fitting peaks from a series of (HSQC based) experiments, the
>> >> CLUSTID seems to be used to identify peaks from the different spectra that
>> >> originate from the same spin system. I guess this is also how they're used
>> >> in 3D 15N or triple resonance spectra en route to automatic assignment
>> >> etc. Given the generic definition they may also be used to associate sub
>> >> peaks of multiplets or all sorts of other context specific things.
>> >>
>> >>> Importing them from an nmrDraw file, then exporting the same numbers is easy
>> >>> enough, but probably not very useful I imagine (also any new peaks picked in
>> >>> Analysis would 'drop out'). To do this thoroughly you would need some
>> >>> interface window in Analysis.
>> >>
>> >> How about just a "treat spin systems as clusters" flag/button on export
>> >> and vice versa on import? The only thing I wondered was whether
>> >> NmrPipe/Draw insisted on numbering them from 1 or something.
>> >>
>> >> Brian
>> >>
>> >> --
>> >> Dr. Brian O. Smith ---------------------- B Smith at bio gla ac uk
>> >> Division of Biochemistry & Molecular Biology,
>> >> Institute Biomedical & Life Sciences,
>> >> Joseph Black Building, University of Glasgow, Glasgow G12 8QQ, UK.
>> >> Tel: 0141 330 5167/6459/3089 Fax: 0141 330 8640
>> >
>>
>> --
>> Dr. Brian O. Smith ---------------------- B Smith at bio gla ac uk
>> Division of Biochemistry & Molecular Biology,
>> Institute Biomedical & Life Sciences,
>> Joseph Black Building, University of Glasgow, Glasgow G12 8QQ, UK.
>> Tel: 0141 330 5167/6459/3089 Fax: 0141 330 8640
>>
|