CARA Issue Tracker

Hi Alex, Have a look at www.cara.nmr-software.org/downloads/NMR.017-1.1_Online.pdf and the equations in §4.5.1, eg. Eq. 12. Best regards Rochus

I just realized that I "complained" about this function before. Sorry..., if no new solution yet, please ignore this track.

Could you provide a link to the original issue as follow-up to this issue describing this feature request?

I agree that it would be useful to have the same type of control over print preview (set contour levels ) as available for Monoscope. For the test case I used, autocontour worked pretty well. It behaves best if you exclude intense signals (solvent, diagonal) from the zoomed region since autocontour sets the lowest level based on the AVERAGE intensity in the selected region. Ofcourse this is not always an option and therefore I can see the need to control the contours of individual spectra separately using "set contour levels".

I mentioned in 2008 with title "Print preview improvement ". However, I think that I explained more clear here. It would give users much better control if contour level of each spectrum can be adjusted separately in a spectral overlay situation.

To me, sometimes the signal intensity of top spectrum (HSQC) appears too strong and completely covered the underneath spectrum/spectra. If I use "set contour levels", there is no popup window asking me which spectrum to adjust, and it would change all spectra, not just the one I wanted.

To demonstrate what I meant, I attached two 1h-15N HSQC spectra to be overlapped for your testing, spectrum 1 on top, 2 on bottom. The goal is to have signals from spectrum 1 relatively small, so we can still see signals from spectrum 2 for comparison, while keeping the noise invisible. Thank you,

Use the right scopes for the right spectra:

Backbone assignment PolyScope or StripScope: triple-resonance spectra anchored on H-N like HNCA, HNCO, HNCACB, HcccoNH, CccoNH etc

Sidechain assignment SystemScope: HCCH-TOCSYali, HCCH-COSYali, etc you must load them into the project in the right orientation and also open them using SystemScope(rotated) in the right orientation.

For additional advice see the Tutorials on backbone and sidechain assignment on the cara wiki

wiki.cara.nmr.ch/HeteronuclearBackboneAssignment

wiki.cara.nmr.ch/HeteronuclearSidechainAssignment

Hi Peter, welcome to CARA! An anchor is a pair of spins which define the X and Z dimension of a strip. Usually they are connected through a single bond in the structure. When you pick a new shift in the strip of SystemScope you create a new spin in the spin-system of the anchor pair. This new spin is used to predict additional correlations in any strip that they are expected to occur in. Depending on which strip you look at, the intensity of peaks involving this spin may be stronger or weaker (because TOCSY transfer efficiency depends on the network of intervening spin couplings involved in TOCSY mixing).

The anchors are used for defining the regions of the 3D spectrum displayed in the strips. They are generated dynamically by CARA and are not fixed objects you need to construct. What matters in the end is the spin-systems which you build up (your assignments) and whether CARA displays crosspeak symbols (generated with peak inference) which conincide with real peak maxima.

Hi Fred,

Thank you very much for the clear explanation!

Do you have a specification of the .nv file format? I will then check how much work it would be to write an adapter. In positive case it would then also be necessary to have confirmed 2D and 3D spectrum pairs in .nv and an already supported format (e.g. Bruker or Xeasy). Cheers Rochus

I found only a simple description of the *.nv format on the page 10-11 of the book http://www.onemoonscientific.com/nmrview/nvbook.pdf
The NMRView file contain a 2048 bytes header, and following submatrix of data. However, the detail description of the header is not found.

Of course I can provide the sample spectra in nv and pipe format. Here is a 2D HSQC spectrum. Where can I put the 3D spectrum?

Thanks for the information. I will try to get more information about the header and to develop an adapter. Cheers, Rochus

Did this ever lead to an adaptor for NmrView spectra?

I would also be interested in such an adaptor. I am currently converting my lab over from NMRViewJ to Cara. I have already re-processed my spectra so for me there is no big rush. Although it would be convenient if I ever have to go back to a previous group memeber's work.

In Olivia there is a converter which can convert spectra from nmrview to nmrPipe, and it is open source.
ht tp://fermi.pharm.hokudai.ac.jp/olivia/

I hope this may help CARA to write the adptor:-)

Can anyone please tell me How to convert .nv (NMRView) file format to CARA format? I am new in NMR and I dont know much/anything and I have all spectrum files in .nv format

Please inform

From reading the followups preceeding your question there are a couple of options:

1. Reprocess from NmrPipe to NmrPip format. 2. Use the converter in Olivia described by Yingang Feng.

Try commenting out the line:

Project:setShift( Spin, Spin:getShift() + Delta )

A few lines later, you loop through all spectrum IDs to shift the aliases, but it includes specID 0, which is the unaliased spin. Without commenting the line out, you shift aliases once, but unaliased spins twice.

Thank you, now everything works fine. It would be nice, if the script on the download page could also be corrected. I checked this today, but it is still the old version.

André

This is a known problem with high priority to fix it.

Workarounds:

1. You can make the linewidths of the peak model very small so there is no interaction between peaks or
2. Run the script CopyPeakAmpToVol.lua from the CARA wiki CALUA page which copies the amplitudes to Volumes (i.e. raw intensities are stored in peaklist)

Here are two issue reports which describe the same problem.

Issue 0639 includes a repository with an example based on the Demo project

Issue 0652 is a short description of the same problem

http://www.cara.ethz.ch/Tracker/0639 http://www.cara.ethz.ch/Tracker/0652

Please find included a repository which demonstrates the problem. You can open it in the directory containing the Demo project and select the HSQC15N.nmr spectrum. Look at the comments in the Description Memo of the repository.

This bug is still present in cara_1.5.5 and cara_1.7.0a7.

This continues to be an issue for 1.8.1 (using the provided test repository in the followup). E.g. Peaks 4 and 141 have negative volumes even though the intensity at the peak position is positive. As long as Integrator behaves this way, it cannot reliably be used.

I tried this using 1.8.4a5. I still get the negative volumes which do not correspond to what is seen in the spectrum. I once proposed generating additional grid points to include in the matrix in order to make Integrator more robust to this error. Shouldn't we try this solution? The people I know are all using Workaround 1 and 2 which basically avoid the integrator algorithm altogether.

intergration in CARA ...negative peaks
I am a new user of CARA, but I have the same problem... I will try to use the Workarounds 1 and 2 reported, but maybe nowadays the problem is solved in another way... Any help and suggestions are welcome.
Thank you very much!

Hi Nick Thanks for your investigation; unfortunately there is no generally accepted standard on how to relate the points of the spectrum matrix with the ppm values (e.g. left, center or right). I attached a document how it is done in CARA; I also attached Scale.h, where all mappings from ppm to index and vice versa are done; please have a look at it. Cheers Rochus

Hi Rochus,

After looking at your code, I took a look at some of the documentation for FFTW as well as general stuff about the discrete Fourier transform itself. I still think it would be prudent to adjust your setup. Here's why:

If there are N points in the transformed spectrum, the zero-frequency point (i.e. the carrier) is defined (by the FFT) to be at sample position N/2+1. This position is the only position that's guaranteed to be invariant after multiple zero-fills. If one were to look at a Fourier transform of a zero frequency (DC) signal, that contour plot should be centered around the carrier frequency (regardless of the number of points).

You're right in that there's no specific convention for how to contour, but I think that the definition from the FFT indirectly requires that the middle of the sample be used. That is, if I have a DC spectrum with X points, I expect the contours of my DC spectrum to be centered at the carrier. If I have a DC spectrum of 100*X points, the contours should be centered at the same frequency. The contours should always be centered around the middle of the N/2+1 "box."

If it's helpful, I've attached an NMR Pipe script to generate a 2-D DC spectrum. When transformed, the spectrum will be non-zero only at the N/2+1 point. You can then confirm whether CARA displays this spectrum as being centered on the carrier frequency.

The script also generates a spectrum with a series of diagonal peaks which can be used to test the values near the edges.

I spoke to Frank about this, and he said that the biggest disadvantage is that the spectrum is now "off-center" by a single point - the number of points to the right isn't equal to the number on the left. Unfortunately, handling this inconvenience is the only way to ensure that the N/2+1 point is indeed invariant.

Regards, Nick

Hi Nick, I compared NEASY and CARA. They represent the contour maxima in the same place. I recall that we made some effort to insure that CARA and NEASY agree. At the time we did not have access to other programs. NEASYs referencing therefore suffers from the same shift in the maxima when zero-filling is changed. I note that spectra displayed within Bruker's Topspin also show this effect.

I ran your nmrPipe script and had to make two modifications to get it to run:

add a space between the flag -aq and option 2D in:

simTimeND -nots -in diag.tab -ndim 2 -aq 2D Complex \

and

added the option -real throughout for -fn FT

(see attachment).

I then read center.ucsf and diag.ucsf into CARA. center.ucsf is empty. diag.ucsf contains an array of "diagonal" peaks (see screenshot). The central one is located at 4.940,4.863.

When I open diag.ft2 in nmrDraw the middle "diagonal" peak is located at 4.940,4.980 (screenshot in attachment of the next Followup to this issue). center.ft2 is also empty in nmrDraw.

The difference between the x and y coordinate in nmrDraw is small but real. Before I continue - what needs changing to obtain the center.ucsf spectrum with signal in the center? Is there still something wrong with the speccal.csh script which could explain the difference between x and y coordinate in nmrDraw? Shouldn't the central peak be located at 5.00,5.00?

Attached: the screenshot of the central peak of diag.ft2 displayed in nmrDraw.

Hi Fred,

Yes, I think the culprit is the csh script... Would you please let me know what the error in the simTimeND command was; "-aq2D Complex" should be a valid option, and I'm not sure why it would have given you a problem. Sometimes it's a little unclear what Frank does when the command line arguments don't parse completely, so I'm hesitant to suggest what adding the space will do to the simulated time output.

The diagonal spectrum should be 15 peaks, and so even though you can get data by adding the -real flag, the spectrum you're using still doesn't match what I started with (it only has 7.5 peaks, so the spectrum is cut in half). Similarly, adding -real to the center.ft2 spectrum is trying to do a real transform of what should be complex data. When I do it, center.ucsf isn't strictly empty

the farthest downfield point has a non-zero value.

Anyway, let me know what the simTimeND error is and I'll see what I can come up with. It may be helpful for me to know your nmrDraw version (at the top of the NMRDraw window), too. At the same time, I've attached the UCSF spectra that I get when run the script.

Thanks for looking in to this, Nick

Hi Dmitry, there is a problem with forwarding the issues from the CARA IssueTracker and so that I only now noticed you entered an issue. I cannot reproduce the bug in the linux version 1.9.0b3 so you might be going crazy. ;-) Can you reproduce the problem in cara 1.9.0b3 for linux? I was working in StripScope and used the context menu "Link to reference".

Hi Fred,

Yes i can still reproduce the issue using 1.9.0b3 version that I downloaded back in October 2010, the problem appears to be in the automatic strip matcher. The suggestions that come out of the strip matcher are reversed. I did it from the main cara window. Go to Strips, run automatic strip matcher. suggestions are reversed: best successors are offered as best predecessors and vice versa. Thanks for looking into it.

Hi Fred,

I have same problem. After running automatic strip match, possible candidates are listed. However, the "icon" which shows relationship (pred or succ) are wrong. And when I tried to connect one of candidate, linking action followed type of the "icon". Although they have score of successor and listed in successor panel, they will be linked as predecessor.

By the way, I appreciate your great work!

Unfortunately, there is no way to do this within LUA right now. You can write a script in python or awk to search and replace the corresponding sections of the CARA repository file. I realize this is not ideal but currently it seems the most efficient approach if you have many files. Alternatively rename them externally using a system script and then import them into CARA.

I have uploaded DefineInfo.lua to the wiki.

I would indeed like this. I have scripts that load in large groups of spectra (like 50) and they are all named "2rr" which makes it impossible to distinguish them in the Scopes. Manually setting all the names is very tedious and time-consuming.

I agree that this would improve useability. For some reason this was overlooked in PrintPreview. In the meantime my workaround when autocontour is not satisfactory is to store the .set file from PrintPreview and then export the PDF once for each set of contours in a different color (using the .set file to make sure each PDF displays the same region) and then combine them using an external program such as PhotoShop or Inkscape.

One could treat this like Overlay layers with an "active spectrum" whose parameters could be set. Ofcourse more convenient would be a way to look at parameters for all the displayed spectra together.

ID SpectrumName contour_level level_spacing number_of_levels color_of_positive_contours color_of_negative_contours

But that would be a luxury...

Done in 1.2.4. It doesn't crash anymore, but I'm not completely convinced yet whether everything is visible as it should.

However, it does not display ANY spinlinks.
The spinlinks are visible in PolyScope(unrotated) and in PolyScope(rotated) where the HSQC15N is displayed in the normal orientation.

Maybe this is related to the way the peak inference handles spinlinks?

After the anchor is found, possibly CARA is starting on N and then there is no spinlink found to H spins.

CARA should do the following:

Determine anchors in plane by inference.
Determine the peaks in the strip by:
1) starting with the anchor pair ONLY.
2) start the pathway simulation on this pair (HN-N)
3) determine that in the first step of the experimentProcedure, these two spins are connected N->HN.
4) determine that in the next step (which generates the strip peaks) HOPS = -1. Therefore determine the set of all spins which share a spinlink with the starting spin HN and display their peaks in the strip.

This should guarantee the correct display of peaks in the strips in both normal PolyScope and PolyScopeRotated with the 90deg rotated HSQC15N.

This same procedure should be used for StripScope. I.e. the Pathway simulation should always start ONLY on the anchor pair.

opened this again, since there is still a problem with the display of spinlinks in PolyScopeRotated.

I made some tests with rotated N15-Noesy and could see the correct spin links. There was also no crash anymore.

Not reproducable.

Possibly you are not setting up the test in the same way as we are. I still do not see the spinlinks from HN to HN.

Here a step-by-step for reproducing the problem:

Start with a project containing both HSQC15N & 3D 15N-resolved [1H,1H]-NOESY. At least two spin systems and one spin link from the HN of system 1 to the HN of system 2.

1) Open HSQC15N wit PolyScopeRotated (X=N,Y=HN)
2) Select 3D NOESY in the Strip window.
3) Turn off show inferred in strips.
4) Select System 1 in the plane

The strip does NOT display the spinlink from HN of system 1 to the HN of system 2.

Try the same thing with PolyScope and the standard orientation of HSQC15N. The spinlink is visible.

Opening this up again. For me the Spinlinks are not visible and this is reproducible also in 1.3.

Now I see it. I try to debug.

Still an issue in 1.9.0b3!

If the method for generating the observed crosspeaks depends on the fact that the X axis has the same AtomType as the Y axis in the strip, then this would explain the missing NOE.

The set of expected peaks (3D coordinates) should not depend on the orientation of the spectrum. Perhaps the algorithm needs to be made more general for NOESYs.

I find that this crash occurs on my Linux laptop running Ubuntu 6.06 with cara versions 1.7.1 to 1.8.2. After Print, I select a printer and then click OK. At this point the crash occurs.

On my Linux Desktop running Red Hat Enterprise Linux, with CARA 1.5.5-1.8.2, PrintPreview lists NO printers in the printer window. If I click "print to file" and print then I observe the following behaviors:

1. CARA 1.5.5 to 1.8.1: Prints file and PrintPreview closes normally.
2. CARA 1.8.2: Prints file, When I close PrintPreview window, CARA crashes with message to console: cara_1.8.2_linux: Subject.cpp:86: void Root::Subject::removeObserver(Root::Messenger*): Assertion `next && next->d_observer == o' failed. Abort

Perhaps this is unrelated, but the resulting file that CARA 1.8.2 prints has a frame that covers only about 1/4 of the page, even though I tell it to fit frame to page.

Thats quite strange. But as - I understand it - "Print to file" works? There was an issue with removeObserver, which I (hopefully) resolved in 1.8.3. Maybe your print crash has also gone with it. Anyway printing is still the weak part of Qt some features (scaling, printer selection, etc.) don't work properly. R.K

Yes, Print to File works, but closing PrintPreview AFTER that causes a crash (only true for 1.8.2 - haven't tested 1.8.3 yet).

CARA 1.8.2 PrintPreview:

Shows two catagories of crashes involving PrintPreview

1. selecting File-Print and then clicking OK in the dialog box causes and immediate crash.
2. If the "print to file" checkbox is activated before clicking OK, then no crash occurs immediately. However after closing the PrintPreview CARA does crash (with the messagesto terminal described in my second feedback). This second type of crash only occurs when the PrintPreview was opened with HomoScope or PolyScope! If you opened PrintPreview with MonoScope or StripScope, no crash occurs upon closing PrintPreview.

CARA 1.8.3 PrintPreview.

I cannot reproduce the second catagory of crash, but the first catagory still occurs. I note that my Print menu does not display any choices for printer on my desktop linux (Redhat).

The catogory 1 crash (print directly) sends the text "broken pipe" to the parent terminal of the Cara instance just before the crash occurs.

Catagory 1 crash still occurs in Cara 1.8.4a5

It still crash on Ubuntu 8.0.4 LTS (32bit), print to file works, when cara crashes i have errno set to 141 (EAOVLP), i have also noted that when i start cara, it fails on locking assertion on libxcb-xlib, I have tried to set the enviroment variable LIBXCB_ALLOW_SLOPPY_LOCK=1, but the result is the same

I am using cara 1.8.4..

cara 1.8.4 also crashes on Redhat enterprise after clicking on [Print] in the Print Dialog which appears in PrintPreview after File-Print.

Using cara 1.9.0b3 on Redhat enterprise, no crash occurs after clicking [Print] in Print Dialog. However, the printer does not print anything either.

The workaround for this bug therefore continues to be:

1. Export to PDF
2. Print PDF with external program

Here are screenshots for other versions

and finally the screenshot from Cara 1.8.4 (1.8.4a4 looks the same)

Sorry, maybe I should have said that I am refering to the canvas function in LUA scripts.

cara 1.9.0b3 has the same problem as 1.8.4.

1D SliceScope is also unavailable in the Spectrum-Explorer of cara 1.9.0b3 for linux

Yes, this is a known problem. I too will be happy when it is fixed. It is probably related to this issue:

www.cara.ethz.ch/Tracker/0821

Sorry, didn't see this previous issue. Thanks!

Link color codes are working in PolyScope of release 1.9.0b3. However, it is still not working for the other scopes.

See related issue:

tracker.cara.nmr.ch/0967

There are no asymmetric spinlinks (although interestingly spinlinks do have a left and a right spin) but always both peaks are shown in PolyScope,SyncroScope,HomoScope,StripScope & SystemScope.

You will perform the integration using a peaklist in MonoScope. Therefore you could generate the peaklist as usual (export to peaklist from PolyScope) and then use a script to delete the peaks that you don't want. Alternatively you could manually remove them using shift-click drag. If you need help with the script let me know. It should not be too difficult.

when you have several thousands of peaks in 13CNOESY-HSQC, this approach is quite consuming, because You will need to manually type this peaks into the script. So You do the double work, first find peak, assign it, then understand that it is overlapped in another region, go to the script and type it in. Maybe asymmetric spin links could be introduced into Cara? For example, propose spin will generate two different spin links, which can be treated separately. Or visibility property of spin link could be made more flexible, like "visible for the right anchor and ivisible for the left".

The idea behind spinlinks is to simulate the expected NOESY peak positions.These usually occur in both complementary positions of the NOESYs. It is actually thought of as an help during the assignment part of the project.

We usually use automated NOE assignment routines like ATNOS/CANDID and this eliminates the need to manually assign NOEs. Moreover the algorithm compensates for errors in peak intensities that are expected due to overlap.

However, if you want to objectively eliminate peaks where overlap could falsify the integrated peak intensity, perhaps the easiest way is to define a minimum distance between two peaks in each dimension of the NOESYs and then use a script to remove all peaks that are below these minimum distances.

Thank you for advise, I think, I'll implement it next time I'll calculate structure. By the way, we also use CANDID, but It makes mistakes, and if you want to accurately define the local structure, you need some manual assignment after automated procedure. And that is the time, when the problem comes. So I still thing that asymmetric properties of links could be useful.

In the HNCO you pick systems that link H,N to the neighbour C-1, (H,N,C-1) systems where as the 2D CACO and 3D CBCACO spectra show only intraresidue connectivity CA,C and CB,C (CB,CA,C) systems. The only overlap of the spins picked by these two types of systems is the C-1 and C. If you find a match then you could link the (CB,CA,C)->(H,N,C-1) as i,i+1 neighbours. However there is no way to continue because you have no additional sequential connectivity. In other words, how do you figure out what the CB,CA or C resonances of a (H,N-C-1) system are?

I do have HNCA and HNCACB experiments. My concern is if you do not assign the backbone is there a way to display the C-1 peaks or the CA/CB peaks in the 2D CACO or CACBCO spectra?

This should be possible if you define the Experiment Procedure of the SpectrumType right. You should always end in a destination System which will not have spin labels with offsets (i.e. it should not be the system with the C-1).

For the CACO this would mean that your Experiment Procedure would follow this order:

CO->CA

and for the CBCACO

CO ->CA -> CA & CB

Slow and intermediate exchange regime:

The best approach is to assign the two conditions independently. If you are in slow or intermediate exchange then you must do this. The peaks with the largest shifts are not assignable by moving them to the closest position at the new conditions. Then use the script ShiftDiffBetweenTwoProjects.lua to generate a file with the results suitable for plotting.

Fast exchange regime:

If your system is in fast exchange, you can measure a series of spectra where the condition is gradually changed (in your case this means adding the ligand in small steps until you reach the 1 to 1 stoichiometry of the binding site and then follow the peak positions during the titration. Ofcourse it is still safer to assign the shifts independently at the new conditions (1:1 ligand:binding site ratio).

If you are comparing HSQC15N spectra you may have to move 100 to 200 peaks which is some work. However, this way you looked at each one and checked its surroundings. With automatic methods, you have the danger that the peak will be shifted onto the wrong position esp. when there is overlap. Then your chemical shift mapping will give erroneous results. Particularly for the peaks with larger shifts the automated approach can be prone to errors and these are the most important for the chemical shift mapping!

In Cara, you can make the manual work more efficient with some scripts and shortcuts.

1. Load all the spectra into one project which contains the chemical shifts corresponding to the starting conditions. Name them so that they appear in the order of the titration. Example: HSQC15N ratio 0.0, HSQC15N ratio 0.2, HSQC15N ratio 0.4, etc...
2. Open the first spectrum in the series using HomoScope (HSQC ratio 0.0). The signals should all be at their correct location already. Now type ''ns'' to see the next spectrum. Here the positions are slightly shifted and need to be adapted. Work as follows:
3. zoom into a region and click on a peak to select it. Shift-right-click at the correct cursor positon where the signal actually appears. This will move the cursor without deselecting the peak.
4. Hit the ''a'' key on the keyboard and immediately afterwards right-click. This will create alias shifts for this spectrum and the peak will appear at the new position in only this spectrum.
5. repeat this for all the peaks in the region.
6. move to the next region of the spectrum and do the same until all peaks are adjusted.
7. Sometimes it can be helpful to type ''ns'' ''ns'' ''ns'' or ''ps'' ''ps'' ''ps'' a few times to see the trend of the peaks in a crowded region before adjusting their positions.
8. Now use the script CopyAliases.lua to copy the aliases from the second spectrum to the third spectrum in your titration. In your case from hsqc15N ratio 0.2 to hsqc15N ratio 0.4. This will adjust the peak positions in spectrum 3 so that they are at the position of your signals in spectrum 2 which is helpful since they are closer to the actual positions.
9. repeat steps 3 to 7 for the remaining spectra always copying the aliases from the current spectrum to the next spectrum before starting on that spectrum.
10. When you are done you can write out the titration curve or obtain the chemical shift mapping using the script WriteTitrationCurveDataToFile.lua. The shift mapping is just the column with the shifts from the final condition hsqc15N ratio 1.0 minus the shifts from initial condition hsqc15N ratio 0.0.

If you want to combine shifts you can write out one table for H and one for N, load them into a spreadsheet and then calculate the combination there. Or you can use the script ShiftDiffBetweenTwoProjects.lua which calculates the combined shifts optionally using aliases. In this case set the two project names to be the same.

Thank you very much, i hope this will solve my problem. It is true that automatic methods leads to erroneous results in case of large perturbartions and in case where there is noise in spectra and real shift is missing. i will try the method as described above. thank you very much.

The 3D peak-picker looks for local maxima. You should not use .nmr spectra for peak-picking. These often have flat maxima due to the amplitude compression scheme in cara spectra and the 3D peak-picker picks multiple peaks on the maximum. If the strips are not centered then 3D peak-picker may not pick the maximum because it only makes a one dimensional search along the strip center.

I do not use the 3D peak-picker to pick triple resonance spectra. These can be picked very quickly and accurately manually using polyscope. In addition you can use multiple triple resonance spectra like HNCO and HN(CA)CO together to distinguish sequential from intraresidue peaks. Switch back and forth between the spectra using pt and nt.

You can see the distance between two peaks in Hz by click-dragging the mouse and looking at the number in parenthesis on the status line (one for each dimension). Note that there is a bug in the indirect dimension so that the value in Hz is wrong. (It assumes the same spectrometer frequency as in the direct dimension).

How to deal with related peak positions in a set of spectra (e.g. for titrations or for IPAP-type experiments to measure splittings):

You should work with peak aliases.

1. Generate a peaklist from your assignments using the script PeakListNumberedByResidue.lua
2. Open the reference spectrum with MonoScope and then open the peaklist and Add to repository
3. Spectrum-Setup BatchList and select additional spectra belonging to the set.
4. Now you can switch between the spectra in the batchlist using Spectrum-Select Spectrum or with the keyboard shortcuts ns and ps.
5. Show the peaklist using sp. Double-click on the peak entries in the list to navigate the cursor to a peak and zoom in.
6. Adjust the peak position by moving the cursor to the contour maximum and then shift-click on the crosspeak symbol.
7. Right-click and select Move peak alias or use the shortcut ma.
8. Double-click on the next peak in the peaklist and repeat.

There is a very detailed description of how to integrate series of spectra which is relevant to this in the CARA wiki.

www.cara.ethz.ch/Wiki/BatchIntegration

When you have all the peaks adjusted you can write out a peaklist of the two spectra (in ppm) and use an external program to determine the difference in Herz.

Alternatively, you can use a CARA/LUA script to analyse the peaklists and write out a file in appropriate format. If you need help with this (it is not very complicated) just ask.

Hi, I dont see anything changing when I click drag. Is there any special keys/commands involved ?

After writing the peak list, I cannot see that in the monoscope open peaklist option, though I see that file in the directory. Do I miss something?

Thanks!

Sorry, I mean ctrl-shift-click-drag. Open Peaklist is for peaklists that are already in the project. You need to import the peaklist first.