CARA Issue Tracker

When you make assignments like CG-1 a spin is created in the system you picked them in. These are called projected spins because they have a nonzero offset (in this case -1). When you write out the assignments to an external file only spins in their own system are written (spins with zero offset). This is in order to avoid redundancy between projected spins (e.g. CG-1 in system i+1) and origin system spins (e.g. CG in system i).

CA and CB probably appear in your assignments because you assigned them directly as CA and CB in their own spin-system using experiments like HNCA and HNCACB that include intraresidue correlations.

In the CARA wiki section "Tutorials" there is a link to "Heteronuclear Sidechain assignment". There you will find the relevant section "Working with HCCONH-type spectra":

wiki.cara.nmr.ch/Tutorials

wiki.cara.nmr.ch/HeteronuclearSidechainAssignment

Best Regards,

Hi Himanshu, welcome to CARA. It sounds like you may not have loaded the template before setting up your project. Without a template loaded, there are no ResidueTypes or SpectrumTypes defined.

See here for help with loading the template:

wiki.cara.nmr.ch/ImportingTemplate

Are you starting from a new protein with no assignments available? In that case, next you load the sequence to create a new project:

wiki.cara.nmr.ch/CreateNewProject

Alternatively, if you have assignments available from a BMRB deposit, you don't need to load the sequence. You can create a project from the BMRB .str file. See the bottom part of

wiki.cara.nmr.ch/CreateNewProject

Next you can load the spectra into your newly created project:

wiki.cara.nmr.ch/ImportSpectra

Both 2D NOESY and 2D TOCSY should be available since they are included in the template file Start1.3v8.cara.

If you started a fresh project without BMRB assignments then there are initially no spin-systems associated with the residues and no atomlist. These you build up gradually during the assignment process.

As you recognized, you will work mostly with HomoScope since you only have homonuclear 2D spectra available. PolyScope is an alternative which has the same functions as HomoScope but includes the ability to work with 3D spectra. MonoScope will not help you during assignment. It is intended for work with Peaklists which are not needed for the assignment process. Hints on this process can be found here:

wiki.cara.nmr.ch/HomoScope

It may be helpful if you also had a 2D COSY or DQF-COSY available to support assignment of the sidechains.

If you find questions you posed in this issue are unanswered, please add a follow up to this issue. If you have other questions that you cannot find answers to in the CARA documentation then please start a new issue.

Regards,

Dear Fred,

Thanks a lot for your prompt reply and I really appreciate your help. I will try all these things and I have one more doubt if you don't mind. I am working on small peptides of 20 amino acid long and all tocsy and noesy spectra are recorded in bruker 600 MHz and I have all the raw files in rr format. I will try to make my project in CARA using these files but is it possible to make BMRB file from these rr files. If possible please let me know the way and second thing can you tell me is it possible by CARA to prediction of assignment after selecting the peaks? Or If you don't mind can you tell me the step wise assignment process in homoscope or polyscope?

Thanks a lot and I really appreciate the work you people are doing.

Best Regards, Himanshu

BMRB .str files

By "BMRB .str file" I mean depositions at the Biological Magnetic Resonance Bank located here: www.bmrb.wisc.edu

I mentioned this in my first followup to your issue because there are two ways to set up a project in CARA. If someone else already worked on your protein or peptide and made a deposition to the BMRB then you can download this file as a .str file. It contains the sequence and chemical shifts of the molecule. This file can be opened with CARA to create a project.

See the bottom of this page: wiki.cara.nmr.ch/CreateNewProject

This can also be useful if you intend to assign a molecule very similar to one that is deposited at BMRB.

If you are working with a molecule that has not been assigned yet then you will have to start from scratch.

See the top of this page: wiki.cara.nmr.ch/CreateNewProject

Spectra types

In either case you will want to load spectra into your project. CARA recognizes many standard spectrum formats including brukers 2rr files.

Automated assignment

CARA does not offer automated assignment of 2D spectra. However, a 20 residue peptide can be assigned manually in a reasonable time.

Manual assignment

Follow the instructions here under Homonuclear assignment but skip step 1 which is no longer needed:

wiki.cara.nmr.ch/HomoScope

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.

this is not a complete bmrb file. several infors are missing. Have a look into a standard .str file and edit it, it should work afterwards.

If you use the convention to name the signals in the strips CA-1 CB-1 then you will have to copy these projected spins to the origin system (i-1 position in sequence).

There are a number of scripts to do this and some documentation about it in the wiki too.

wiki.cara.nmr.ch/HeteronuclearBackboneAssignment

wiki.cara.nmr.ch/HeteronuclearSidechainAssignment

CreateProjectedSpins.lua

CopyProjectedSpinsToOriginalSystem.lua

CreateOriginSystemsFromProjectedSpins-v3.lua

Mi Maria, sorry there was such a delay in responding. The Cara issue tracker is not forwarding messages correctly. I hope you could solve your problem.

For completeness I answer your question:

wiki.cara.nmr.ch/HeteronuclearBackboneAssignment

describes how to deal with proline assignments obtained with experiments like HCCCONH.

I found this quickly by entering "PROLINE" in the search window on the top right of the CARA wiki.

I found that the peaks picked by pick2D.lua or pick3D.lua appear only when we show up the unlabeled peaks. It takes many peaks but many times it do not picks the peaks that are present in a strip above the given thresh hold. Another question is how can i use these unlabeled peaks for automated NOE assignments and subsequent automated structure calculation.

regards prem

The peak-pickers only pick peaks that are aligned on the line in the center of the strips (i.e. where your 2D peaks were picked by the 2D picker). If they are off-center it will not pick them. This is intentional to avoid picking peaks that do not belong to the spin system. You can pick additional peaks manually.

To export peaklists to external programs for automated assignment see the following documentation.

wiki.cara.nmr.ch/ManualStructureCalculation

An alternative to working with these peak-pickers is to use Atnos/Candid within the free (for academics) package Unio.

perso.ens-lyon.fr/torsten.herrmann/Herrmann/Software.html

I have already founded. There are no any problems. Thank you!

Hi Winston, I haven't measured any of these experiments. Here are a couple of thoughts:

You can control which signals appear in the through-space transfer experiments by defining the labeling schemes and samples for the spectra using the specifically labeled samples. Unfortunately, this does not work in the NOE dimension of NOESYs.

You can adjust for deuterium isotope shifts with the script IsotopeShiftAliases.lua.

You could proceed in one of two ways:

1. Create alias shifts for the H/N signals in the two IPAP experiments and then use a script to write out the difference in the position of the signals in the two spectra in Hertz.
2. Create a PeakList (e.g. with PeaksNumberedByResidue.lua) and define a BatchList for it containing the two IPAP experiments. Then adjust the alias position of the peaks and write out the two peaklists. Or modify the script HetNOE.lua to calculate and write out the difference in position of corresponding signals in Hertz (instead of the HetNOE values).
3. s. I wouldn't call this a bug report. ;-)

There is no SpectrumType for this experiment, but you are welcome to develop one. There are instructions for making SpectrumTypes and testing them here:

wiki.cara.nmr.ch/CreateSpectrumType

I think the first problem I was having is simply that the screen doesn't refresh properly when spins are added or removed, so that I can't see the effects of the changes I make.

The second problem seems to be consistent in both versions. For a while, going backwards or forwards strip by strip using the keyboard only worked immediately after selecting that option from the menu, which made it really cumbersome to use. This problem doesn't seem to be so predictable, though.

This sounds reminiscent of a problem which used to occur for key board shortcuts which I thought we had eliminated.

These keyboard shortcuts would only work in a given scope instance after the corresponding command had been used once with the conventional menu item.

Dear Mei-I Su, I'm sorry you waited so long for a reply. There has been a problem with the forwarding of issues from the CARA issue tracker.

Since you give so few details it is hard to guess what the problem could be.

Here are some hints:

1. The script will pick peaks only for strips of the NOESY with anchor chemical shifts defined by the selected HSQC.
2. The selected HSQC must have a SpectrumType with labels defined in both dimensions.*
3. The selected 3D must have a SpectrumType with the SAME labels defined in the two INEPT (non-NOE) dimensions.*
4. The script picks local maxima along the NOE dimension of strips only if they are above the entered threshhold.
5. The peaks must be in the center of the strip. I.e. the strips of the NOESY must be properly centered or peaks will not be picked.

The points with * are referred to in a NOTE included on the download page from the script which reads:

"You must define labels in the SpectrumTypes? so that the script can match the corresponding dimensions of the 2D and 3D. See the script header for details."

At the top of the script there are additional instructions which explain how to use the script.

The script is not really helpful in the process of assignment and is not a necessary component of CARA analysis. I do not use the script in my projects.

If you are trying to generate NOESY peaklists for structure calculations, an alternative to this script is to use the Atnos/Candid peak-picker in the UNIO package:

perso.ens-lyon.fr/torsten.herrmann/Herrmann/Software.html

Please somebody help me.

Thanks

Muru

Hi Muru, very sorry for the long delay in replying. The CARA issue tracker has a problem forwarding new issues.

Regarding the HetNOE.lua script. In addition to the instructions at the top of the script you may want to look at this page of the CARA wiki

wiki.cara.nmr.ch/BatchIntegration

see section 4 on setting up a BatchList. You need to open your peaklist with MonoScope and then make a BatchList with only two spectra (the reference and the NOE spectrum).

Hi Tiago, sorry about the long delay in replying to your CARA issue. There is some problem with notification of when new issues appear.

Regarding writing out DNA assignments, you are probably right. There are other problems related to the use of the prime symbol within the repository. I am working on a template which uses "p" in the place of the prime symbol. But there may be additional issues in getting CARA to actually write out the prime symbol. I will let you know when I have something working via the tracker.

Hi Carine, sorry that you waited so long for a reply. There is a problem with the forwarding of issues from the CARA IssueTracker and I only now noticed that you entered this question.

When you pick a "peak" in the planar spectral region of HomoScope, SynchroScope or PolyScope, you are actually creating a new SpinSystem which contains two spins. This is why the menu item is called "Pick New System". E.g. if you pick a signal in an HSQC15N, you create a new system containing two spins of AtomType "H" and "N" with labels "H" and "N" and these spins have the chemical shifts of the x and y cursor positions respectively. If you type sl in these scopes you can see the SystemList where these new SpinSystems appear. These SpinSystems are used in an algorithm called "Peak inference" to dynamically predict the positions of signals in any Spectrum you view. Peak inference makes use of the SpinSystem together with SpectrumTypes and ResidueTypes to predict the signal positions. You cannot delete individual "peaks" of this type because what you observe is generated by the algorithm and the contents of the SpinSystems. When you click on such a signal in HomoScope and select "Delete Peak" you are actually deleting the two spins that generate this peak. The menu item should really be renamed "Delete Spins" to avoid confusion.

This sounds complicated, but in practice it can save a lot of time and hassle because you work with a single database containing spin-systems rather than one peaklist for each spectrum which need to be manually coordinated with one another.

CARA does provide "real peaklists" but these are not used during the process of assignment. They are used for the following tasks which usually occur after assignments are completed:

1. integration of peaklists.
2. generation of peaklists for external programs.

I advise you to follow the tutorials for assignment which lead you through the steps:

wiki.cara.nmr.ch/Tutorials

Here are some resources in the CARA wiki FAQ that may help clarify how peak inference works and what the different objects Spin, SpinSystem, Peak and SpinLink are:

Peak inference:

wiki.cara.nmr.ch/FAQ#II3

Peaks, Spins & Systems:

wiki.cara.nmr.ch/FAQ#I3

SpinLinks:

wiki.cara.nmr.ch/FAQ#I5

Hi Maayan, sorry that there was such a long delay before you received a reply. There is a problem with forwarding new issues entried into the CARA IssueTracker. I only now noticed your question.

The short answer is yes. If you have spins in some systems with labels like X+1 or X-1 (called projected spins) and other systems with labels like X (called origin spins), then CARA will match them up as long as they are within a specified cutoff of one another in ppm. All the matches are considered in a weighting function to determine the top matches which are displayed when you use StripScopes functions like "All Best Successors".

From Rochus Keller:
Concerning the TALOS script from Andrew Severin: original script could not handle unassigned residues. Rochus modified it and now it is running also for not completely assigned proteins!! The modified TALOS file - see attachment.

I have made some additional improvements to the script and uploaded the new version to the CARA wiki pages devoted to LUA scripts.

It would indeed be nice to include colors for SpinLink symbols in the SystemList (as in PolyScope - see attached image) for the other Scopes.

There is a general useability issue with the Dialogs and Tables generated by the new QT Toolkit. The headings of the tables have a minimum width which is much to large (compared to the data contained in the column). This results in very wide tables and a scroller bar. Often the data of interest are off screen and the user must scroll them everytime he uses a dialog. See the screen image. I have expanded the tables so all the data are visible. They cover more than half the screen and the spectrum is crowded into the corner.

I would say this issue is high or critical to solve for useability.

Which platform/version are you using?

I have the answer! I need the the following lua script for that:
"CopyProjectedSpinsToOriginSystem"

Please use this page for downloading the templates: http://wiki.cara.nmr.ch/TemplatesPage

I assume that you mean that you have assigned the crosspeaks in the 15N-HSQC to residues in the sequence using StripScope as described in the tutorial on backbone assignment.

In order to assign side chain resonances you will need spectra like 15N-resolved TOCSY, H(C)H-COSY, HC(C)H-TOCSY, H(CCCO)NH and (H)C(CCO)NH. You can also use 3D 15N- and 13C-resolved NOESY spectra.

After loading these into the project using the correct SpectrumType, you can use SystemScope and PolyScope to perform side chain assignments.

I have already finished side-chain assignment using the above mentioned procedure. I was asking about how to assign, Aspargine (ASN) and Glutamime (GLN) side-chains from 15N-HSQC.

oh, that was not clear to me from how you stated the question initially.

I assign NH2 groups of ASN and GLN using the 3D NOESY spectra. First you have to assign the NH2 groups.

Open the HSQC15N with PolyScope and select the 3D 15N NOESY in the strip and then pick all the NH2 signals as follows:

• pick a new system after clicking an NH2 signal in the HSQC15N and select SystemType ASN at the top of the pick system dialog. Then select labels HD21/ND2
• use Shift-arrow to move the cursor to the HD22/ND2 of the same system and extend horizontally. Check that there are strong NOEs between HD21 and HD22 in the 3D 15N NOESY strip. Otherwise try another position for HD22.
• look for NOEs to HB2 and HB3 of the ASN in the 3D 15N NOESY strip. Right-click on NOEs in the HD21/ND2 and HD22/ND2 strips with appropriate chemical shift for a HB2/HB3 and propose spin to tentatively assign the NOEs. Then try confirming them by looking in the HB2/CB and HB3/CB strips of the 3D 13Cali NOESY (see below).

Open the 3D 13Cali NOESY with StripScope.

• navigate to a ASN backbone system by using goto residue or gr and then entering the residue number.
• in the downfield region of the NOEs strips of HA/CA, HB2/CB and HB3/CB look for potential NOEs to HD21 or HD22. If you already used proposed spin to assign a NOE to a HD21 or HD22 in the 3D 15N NOESY (see above) then this NOE should appear in the corresponding strip of the 3D 13Cali NOESY. If it does not you can undo or ctrl-z the last action and try another propose spin assignment.
• in the 3D 13Cali NOESY strips from the ASN you should see NOEs in the downfield region to HD21 and HD22. Right-click on these and use propose spin to try to assign them. Good candidates appear on multiple strips and show NOEs to both HD21 and HD22.
• if you didnt do it already, check whether the NOEs you found in the 3D 13Cali NOESY are present in the strips of the 3D 15N NOESY (see above). Otherwise undo and try another assignment.

Once you have found a convincing assignment of a NH2 system to a backbone ASN system, you will want to incorporate the spins from the NH2 system into the backbone system.

• Determine the SystemId of the NH2 system. If you click on the HD21/ND2 crosspeak in the HSQC15N, the SystemId appears in the status line. You can also use show horizontal or sh to expand the System in the SystemList. Then check the SystemId of the expanded System.
• Next scroll up or down in the SystemList to the backbone system of the ASN. Right-click the puzzle icon of the System and select eat system. Enter the SystemId of the sidechain system (no undo for this!). This transfers the spins in the sidechain system into the backbone system.
• if the backbone system is a GLN, you will have to relabel HD21 -> HE21, HD22 -> HE22, ND2 -> NE2. Expand the backbone system of the GLN in SystemList. Right-click on the HD21, HD22 and ND2 spins and select label spin relabeling them appropriately.

Note that similar strategies can be applied to the assignment of aromatic side chains.

Hi, When we identified the side chain amide's of ASN/GLN and then want to transport them to 15N-HSQC spectrum using EAT SYSTEM command, I get this error message "One of the spins in the Source system is not acceptable by the target system", though I see all the spins are reasonable. Any suggestions on the error and how to rectify? Thanks!

I can think of two reasons:

1. The target system already has a spin with the same label in it as in the source system. Erase one of the spins or change the label of either spin.
2. One of the spins in the source system has a label which does not occur in the amino acid residue of the target system. Change the label of the spin or erase it.

An easy way to avoid problems. Change the labels in the source system to have a ? at the front.

Hi Fred,

I came up with a similar problem and hence tried to follow your protocol. However I got stuck at his:

pick a new system after clicking an NH2 signal in the HSQC15N and select SystemType ASN at the top of the pick system dialog. Then select labels HD21/ND2

Because I don't have ASN as a possible system type. The closest thing I have is AMX, but it's not enough because it doesn't have ND2 and HD2s for Asn. In the same way, I can't go with Glns.

Do you know why that is? I looked up in the repository and, accordingly, ASN is not defined as a systemtype. Hope you can help me,

Luciano

Yes, this should be quite straightforward. You can use the script "ExportToPaces.lua" as a guideline for how to write out assignment data for external programs. It is included in the script collection at the cara wiki. See the section "Scripts to Export Files to Program".

When you have something that works we can post it to the wiki.

Did you ever get a script working to write out CARA assignments in a format suitable for MARS input?

Here is a functioning script for generating input for MARS.

The script to generate input for MARS has been added to the lua script collection on the CARA wiki.

I can not use this script to generate Mars peakslist from unassigned systems. The script seems need the assignment first ,otherwise the "Lines " and "Table" will be nil.

Yes, we have noticed this problem as well, while using CARA version 1.8.4. We also tried opening the CARA repository created in 1.8.4 in version 1.4.2 as a work around to change the generic residue type from BB to SSS, but we were still unable to change this. This is a problem when looking at any other atoms (outside the backbone). For example, looking at a CCONH or HCCONH spectrum, we are unable to pick CG-1, CD-1, HD-1, etc. Even when forcing a label, these selected peaks cannot be viewed in any of the Scopes that we tried. This will become a further problem when analyzing other non-backbone spectra.

Is there another work around so that we can select these peaks (CG-1, CD-1, etc) as a default selection when peak picking in PolyScope or StripScope?

Changing GenericResidueType

It is not really intended that the GenericResidueType is frequently changed. This is the default ResideType used to determine labels when no other information is available. None-the-less this is an annoying bug. You can also change the GenericResidueType by directly editing the repository. It is a global variable near the top of the file. Don't forget to backup your repository before editing it.

Assigning sidechain resonances after the backbone is assigned

When you link a SpinSystem to an assigned residue than all the labels become available and the picked peaks are visible. Normally you first assign the backbone and link up spin systems, then assign the fragments in the sequence. At this point the sidechain labels become available because the ResidueTypes are known.

Assigning sidechains when the system is not assigned to a residue in the sequence

Sometimes you want to make a guess about a SpinSystems ResidueType before it is assigned in the sequence and tentatively assign the sidechain. In this case use "set SpinSystemType" to select the appropriate ResidueType. Then the labels of that ResidueType will become available. In case that your desired ResidueType is not available in the list, then add it to the list of SpinSystemTypes in the SpinSystem explorer.

Assiging side chains of the predecessor system when the predecessor has not been assigned to a residue in the sequence yet

If you are trying to assign the predecessors spins I suggest using a GenericResidueType with a long sidechain like LYS. This way you will be able to pick HA-1,HB-1,HB2-1,HB3-1,HG,HG2-1,HG3-1,HD,HD2-1,HD3-1 which includes many of the expected labels. Alternatively you can create the predecessor SpinSystem using the script CreateOriginSystemsFromProjectedSpins and assign the predecessor System to the expected ResidueType.

Assigning SpinSystems that are not connected to the backbone

Some SpinSystems like aromatic side chains, NH2 groups, and methionine methyls cannot be linked to the backbone using scalar couplings. These systems may be assigned independently and later linked to the backbone using NOEs. The strategy here is to pick the resonance from the sidechain and then define the appropriate SpinSystemType. This makes all the expected labels available. For example you might pick an HD/CD peak in the aromatic 13C-HSQC and then define the newly created SpinSystem to have SpinSystemType PHE. This would make it possible to add HE/CE and HZ/CZ peaks to the sidechain system. Later when you identify NOEs from HD/CD to the backbone HA,HB2,HB3 and/or H signals you will want to move these sidechain spins into the correct backbone system. Right-Click on the backbone system and select eat system and then type in the system number of the sidechain PHE system.

Done in upcoming 1.9. The concept works like this: 1) if the Residue Type of interest (RTOI) has an assigned System Type, the Generic Neighbor of the System Type is used (if available); otherwise 2) if a Generic Residue Type is defined, this one is used; otherwise 3) the RTOI itself is also used as Generic Neighbor.

I get the crash only in 1.8.4 but not in 1.5.5. However, in 1.5.5 it returns nil. I tried all SpectrumTypes in the standard template.

My code is attatched.

Upcoming 1.9 with experiment_test.lua gives following output: HB H ..N ....CA ....CA-1 HA

Test-spec.createExperiment.lua assumes that spec.createExeriment returns a table; this is not the case; instead createExperiment returns an Experiment object, which offers methods like toString or getPath

Upcoming 1.9

Upcoming 1.9 will adhere to the number of dimensions of the corresponding peaklist

When you load a 3D with MonoScope, there is one horizontal slice (the acquisition dimension) and two vertical slices: the left one is the vertical dimension of the current plane view, and the right one is the "depth dimension" which determines which plane you are looking at. In order to navigate to a different plane, you need to click at a new cursor position in this right vertical slice. Before you do this, CARA may indeed show some noise because you are at the starting position of the cursor is at the edge of the spectrum.

However the navigation in 3D spectra looks like it is working.

I don't have a decent 4D spectrum to test this with. But the tests I have done with the one I do have seem to show problems with the slices in the two indirect dimensions (the two left slices). Is this what you are seeing? Can you provide a test spectrum with limited size?

This is absolutely correct. The 3D is working fine.

However, the issue is about the 4D, which is not working fine. As we both now found out, there are problems with the slices of the two indirect dimensions. Since you also found this bug with your 4D spectrum, I do not need to send you another 4D spectrum.

I really hope this bug can be fixed - Thanks.

Done in upcoming 1.9

registry.plugindir is fixed in upcoming 1.9 DLL files and shared libraries are not yet supported for security and platform compatibility reasons; we are working on this though.

Hi Alex,

That issue is not yet resolved. I have forwarded your inquiry (and another one about the same issue which was also added to the tracker today) to the author.

Please see this issue for progress on the issue:

www.cara.ethz.ch/Tracker/0891

You can search for issues in the search field of the IssueTracker and add your constructive comments regarding issues there or you can contact me via email to get status info about particular issues.

Done in upcoming 1.9

Bug with 4D display in Monoscope resolved in upcoming 1.9. There are also new CARA/Lua features in 1.9, but the full dynamic scope building features are still a lot of pending work.

Hi Melissa,

I don't know what start file you used. The one based on Start1.2.cara can be updated with the script LoadBmrbStats.lua. See the header for details on how to do this. However, I doubt that this is the problem since the stats only change slightly from one bmrb update to the next.

My guess is that the problem is related to calibration. I suppose that you calibrate your methyls in a separate dimension from the amide H signals. If you had an offset there you would systematically penalize the methyls. Do the "random coil" methyls of your protein (from your spectra) have the expected average chemical shifts (the ones in the ResidueType)?

There are a number of scripts available on the CARA wiki that can help to recalibrate spin shifts and spectra.

As a workaround you could do one of the following:

1. try using CARA 1.5.5 to do the editing
2. define ave and dev values which are very permissive (since presumeably you do not know what shifts to expect for these unnatural amino acids). You could make a reasonable guess for the average shift by measuring 1D spectra of the amino acid (as part of a short peptide) or by using an on-line predictor of chemical shifts.

Thanks!

Fixed in 1.9

Fixed in upcoming 1.9

Sorry, this is possible in synchroscope!

Thanks

Dorothy

New Script Pane with split bar in CARA 1.9

I cannot offer a command line as in the Scopes, but I can implement a command which opens a dialog box where you can enter the Lua expression.

Will this dialog box "freeze" other actions such as switching between explorer windows or expanding explorer nodes? In this case it would not address the "use case" i describe.

Still waiting for this feature. Why is it not possible to have the same command line available at the bottom of the right window in the other panes of Cara-explorer?

CARA Explorer Menu Tools / Lua Terminal CTRL+L

Indeed ;-)

This problem seems to be solved in 1.8.4.

Picking peaks as ?i will cause ambiguity in the peaklist generation stage. CARA puts these spins in the spinsystem and they will generate intraresidue peaks in all the NOESY spectra even if these are not wanted. The label ?i tells CARA nothing about what the spin is connected to.

If you have already assigned all aliphatic protons then you can use propose spin in either StripScope or PolyScope to assign NOEs. This will create spinlinks between the associated 1H spins. You can then export the peaklist from StripScope or PolyScope to MonoScope (or directly) to a XEASY format peaklist) using File-Export-Strip Peaklist.

An alternative is to use a program to perform automated peakpicking and assignment of NOEs. In this case you do not need to pick NOEs at all. You write out your chemical shift list and let the program do the rest. This is much faster than the manual approach.

You can find descriptions of both approaches in the CARA wiki:

www.cara.ethz.ch/Wiki/StructureCalculation

Thanks for the suggestion. Let me ask some more issues. I wanted to make peak-lists manually using 15n or 13c noesy-hsqc (by picking it using stripscope or polyscope for all strips) and export to xeasy-format peak-list using cara. This peak-list (.peaks) along with .prot (chemical list table from cara) can be used for CYANA calculation. I want to pick all peaks for an amino acids (X) in 15N-hsqc and so on. Similarly, this trick can be done for 13C case as Cyana calculation takes .seq/.prot/.aco and .peaks file. Is there a way to do so?

i feel, it is better to do the peak-picking manually (specially in case of overlap). Hope to hear from you.

The usual manual approach in CARA is to pick spinlinks in the scopes PolyScope or StripScope and then convert these to a peaklist as described in the link included in my last reply. This will create a XEASY format peaklist which shows peaks at all the expected positions derived from the spinlinks.

I am not sure what you mean by "I want to pick all peaks for an amino acids (X) in 15N-hsqc and so on". In CARA you pick spinsystems consisting of spins in the HSQC15N. You cannot generate peaklists until you have completed the assignments as described in the wiki.

Using spinlinks option is always good but if we have several match for the same Hs, it would be difficult. Rather, i wanted to pick all peaks from one strip and export. Similarly, i would like to do for all strips. This way, i create a peak-list (corresponding to all N,H pairs) and along with chemical-shift table, cyana could do the structure-calculation in automated-fashion. This will take lots of burden of a user (like me).

I used to run the 2D script and 3D script for peak-picking. Pick_2D_Peaks.lua works fine for 15N hsqc but Pick_3D_Peaks.lua doesnot give any peaks for 3D 15N noesy-hsqc, it shows like this

spin_system: 2 picked spins: 0

spin_system: 3 picked spins:0

. . . .

What could be reason behind this. i am held up here, just before structure calculation. Let me have suggestion (probably solution).

It could be that you set the theshhold too high for peakpicking in the 3D.

We use automated peak-picking and assignment using the program Atnos/Candid together with CYANA. Atnos/Candid uses the assignments and the structure (which is generated after the first round) to pick and assign NOEs. It is quite robust and we have used it for many structure determinations. You can ofcourse work with manually picked peaklists but it is a lot of work and much slower. What about a hybrid approach? First automatically pick and assign and then modify the peaklists generated to do a final refinement of the input?

i tried using above mentioned reply on 30th april and 1st may. I also looked into "Some Special Topics-Including unassigned peaks in the peaklist" from "manual structural calculation note". I was thinking to make a peak-list using this method and use it for candid-cyana. But, when i exported the peaklist using "strip peaks to monoscope", i am getting negative volumes whereas these unassigned peaks are positive in NOESY-hsqc.

Any guess or idea how to do it!

There are some problems encountered with the peak-integrator when peaks are very close together. Be sure to exclude the inferred peaks in Polyscope (turn off the option) when you generate the peaklist for MonoScope. The following issue describes the problem with negative peaks in more details and strategies to avoid it.

tracker.cara.nmr.ch/0722

Note that the CARA has migrated to a new site (since Nov. 2009) and this address is on the new wiki.

What I meant to say is that the CARA wiki has migrated to a new site.

To convert from bruker to cara format, in the main CARA menu select Tools-Convert to CARA spectrum Then select the 2rr file then select 16 bit uncompressed. This creates a .nmr file.

Load this into a project or open it Tools-Open Spectrum

Assuming that you did that, here are some ideas for why you see a blank spectrum:

• The intensity scale is very low and your lowest contour level is above the most intense peak intensity. Try to either lower the contour level with cp or use autocontour with ac.
• Perhaps it is related to the referencing? You could be looking outside the spectral region (though this is not normally how CARA functions). What happens when you "View-Show-Folded"? (or use the shortcut sf to turn this on).
• Third possibility: there is something wrong with the input spectrum. For example, you moved the 2rr file somewhere other than the usual location inside the pdata subdirectory. (pdata should also be inside the spectrum subdirectory. CARA needs the parameter files in order to get information about referencing etc..

Did you try to open the 2rr file directly? You can open this file also with either Tools-Open Spectrum or by loading it into a project and then opening the spectrum with the appropriate scope.

I have 50% of the spectra with noise and the other 50% black. I tried to lower the contour level and in the back part i managed to see the water signal (I suppose). I did not move the rr file so CARA has all the files available, and i cannot open the 13CHSQC spectrum directly too. Also it does not happen anything when i put "View-show-folded". If the problem is referencing, do you know any way to solve it? I was able to convert and open a TOCSY spectrum without any problem.

I don't think that referencing is the problem since you saw no change when you turned on show folding

It sounds like the spectrum is corrupted. Try to reprocess the data in bruker software and then load it into CARA.

Thanks very much! I reprocessed the data and it worked!

Glad to here it.

Hi Fred and Rochus,

Forgot to mention that I'm using v1.8.4 for Linux.

Yes, you are right. Apparently this was overlooked. Perhaps you can write a script that uses PeakList:setGuess( Peak, AssigGuess, probability [0.0..1.0], dim1, dim2, ... ) as a workaround. The pl:getHome() was also overlooked. Unfortunately, I can think of no workaround for this missing feature. You will need to determine the owner spectrum manually and edit your scripts accordingly.

I tried testing your script (after a little modification) on the Demo project using the 15N-resolved-[1H,1H] TOCSY. At least for me, after pl:rotate( 1,3,2 ), the N and H dimensions were swapped and the peaklist was correctly displayed in the 3D TOCSY.

See the attatched script and screenshot.

Hi Fred,

Thanks for a prompt response. I have to admit that using "Map to Spectrum..." does help to get a peaklist show properly.

Anyway, the requirements of the pl:setHome(spectrum) method seem too stringent to me. For comparison, one can call "Export -> Strip Peaks to MonoScope..." from PolyScope, then rotate the peaklist in MonoScope and add it to repository. In this case, the spectrum owner is set irrespective of peaklist orientation.

Another nice feature besides getHome() would be for the setHome() method to return, for example, nil on failure and non-nil on success. As implemented now, setHome() crashes the whole LUA script if peaklist orientation does not match the spectrum.

There is no object to store the integration method of a peak in the CARA object model (but possibly it is just not described in the CALUA manual). In any case I don't think you can change the value of the integration method.

One strategy: Create an attribute in either PeakList object or the individual Peaks which stores the integration method using createAttr("IntMethod"). Then you could write a script which writes out Peaklists similar to the one which writes out ProtonLists WriteProtonList.lua. You can access the Peaks IntMethod attribute with setAttr() and getAttr(). Then you would have full control of the output format.

Or you could simply use an awk script or similar to replace "-" by "m" or "e" in the PeakList after exporting it normally.

Reference the 1D containing the reference compound so the compound is at 0 ppm within the software of the NMR instrument. Then measure the position in ppm of a resolved signal that belongs to your protein. Reference your spectra so that this signal has the measured chemical shift.

The 1D display tool of cara is very rudimentary. You cannot pick peaks or reference spectra using the graphic interface. What you could do is measure the distance from the reference peak to a peak from your protein using shift-click drag. Then recalibrate the 1D by adding this number to cal in the "calibrate spectrum" dialog window of the 1D in the Spectra Explorer.

If you have already worked with a project and assigned spins, and want to be able to write out referenced shifts, then you will need to shift the spin positions by an amount determined from your calibration. Use the scripts ShiftSpinsAndAliases.lua or ShiftSpinsInCatagory.lua to do this. Then use RecalibrateSpectra.lua to adjust the spectrum calibrations to the new shift positions of the spins.

It must be related to the processing parameters of the input spectrum. I am able to read in both xeasy *.param & bruker 1D 1r spectra without any error message using both cara 1.5.5 and cara 1.8.4. Note that only 1.5.5 allows you to visualize the 1D spectrum using SliceScope.

I can reproduce your error message using bruker 1D data if I edit the procs file in the pdata/1 directory so that the line defining the spectrometer frequency gives 0 as the frequency: ##$SF= 0

Originally the line looked like ##$SF= 600.13

If you are using XEASY spectrum format then the line you want to change looks like

Spectrometer frequency in w1 .. 600.1300

You should edit it so that the correct spectrometer frequency is given in MHz

thanks for your quick response,but I have not solved the problem. I send the attached the folder containing all the necessary files, including the specterum.

Thanks , Roby

It is because your data are in varian format which are not supported. You will need to convert it to one of the supported formats such as xeasy or bruker.

his observation is correct, but I have transformed the spectrum in format .ft1 with nmrPipe. When I transform the spectra 2D in format .ft2 with nmrPipe they are recognized by CARA. Can you give me some advice on how to transform one-dimensional spectrum in a correct format? many thanks

There is not much support for 1D spectra in CARA. There is a rather basic 1D scope SliceScope. I am not sure whether you can load .ft1 spectra. Perhaps the best way to work with 1D spectra in CARA is to load several of them into a pseudo 2D.

Assignment in CARA is done using spin systems. The peak positions in spectra which you load into the project will be automatically determined by CARA. For example if you load the HNCA now and open it using StripScope, you will see all the strips from the spin systems you just picked using Pick_2D_Peaks.lua. You can now pick CA and CA-1 spins which are added to the spin systems.

CARA only uses peaklists for specialized tasks not related to assignment. Here are some examples:

• Integration of peaks
• displaying peaklists from external programs on spectra.

Please see the online tutorials for details:

www.cara.ethz.ch/Wiki/Tutorials

If you want to generate a peaklist from your picked systems you can do one of the following:

• Open the HSQC using HomoScope or PolyScope and select the menu item File-Export PeakList to Monoscope.
• Execute the script PeakListNumberedByResidue and then open MonoScope and import the peaklist.

Hi Morgan, you can follow the instructions from the tutorial on sidechain assignment. You will need to use the script CreateOriginSystemsFromProjectedSpins.lua. See the following page of the CARA wiki for details.

www.cara.ethz.ch/Wiki/HeteronuclearSidechainAssignment

Thank you Fred.

In this case open your 3D 15N-NOESY with StripScope or PolyScope and use Propose Spin to pick the NOEs. If you export the SpinLinks to UPLs you will then have only UPLs from the 3D 15N-NOESY. Ofcourse if you already picked the 3D 13C-NOESY with Propose spin then you created spinlinks for this NOESY and when you write out the UPLs the ones you picked from NOEs observed in the 3D 13C-NOESY will be included. If you want to control which spinlinks are visible in which NOESY spectra you can use the link parameter visible to turn them on or off. You could use the visibility to control which UPLs are written out (see below).

Setting the visibility of a SpinLink in a given NOESY

Open the HSQC15N with PolyScope. In the strip select the 15N-NOESY. Click on a system (or type goto residue and the residue number like gr 2). Click on an NOE and select Propose Spin. This will create a SpinLink. Now execute show horizontal spin sh.Expand the spin by clicking on it to display the spinlink symbol o-o. Right-click on it and select set link parameters. You can click on the CheckBox visible to change the visibility of the SpinLink in the currently displayed NOESY spectrum. You could use the same strategy for the HSQC13Cali & 3D 13C-NOESY.

To write out the UPLs from only one NOESY, you would need to modify the script ExportSpinLinksToUpls.lua so that you could select one NOESY spectrum and so that the script checks whether each spinlink is visible in the selected spectrum before writing out a UPL.

The relevant lua function is named isVisible and returns the visibility (true or false) of a SpinLink for a spectrum which is given as a parameter. It is documented in the class SpinLink in the CARA/LUA programmers manual.

This approach will not work. When you pick a spin in CARA and label it "?", CARA does not know how it is connected to the remaining spins in the system. When you use File-Export-Strip peaklist in PolyScope, you will generate a peaklist containing some nonsense peaks. If you picked only ? peaks in the 3D N15 NOESY we could recover your work by writing a script that creates a file with peaks like f1:H, f2:N, f3:? but since you also picked ? spins in the 3D C13-NOESY, you have mixed up the information from the two NOESYs.

There are two ways to generate constraints with NOESY spectra:

1) Use "Propose spin" in the strip menu of PolyScope to create spin-links. These represent NOE constraints. You can then either generate a constraint list with the script ExportSpinLinksToUpls.lua or generate a peaklist using File-Export-Strip peaklist in PolyScope.

2) Write out the assignments using WriteAssignments.lua and use the automated peak-picking and NOE assignment of Unio (free for academics)

perso.ens-lyon.fr/torsten.herrmann/Herrmann/Software.html

together with structure calculation with cyana. In this case you do not need to pick the peaks in the NOESYs at all.

There is online documentation for structure calculations at the wiki:

www.cara.ethz.ch/Wiki/StructureCalculation

The only significant change is that Unio has now replaced Atnos/Candid for automated structure calculation.

HI Abhay, thanks for your interest in CARA. As I understand it you have loaded a BMRB str file to generate a new project. Everything has functioned correctly. CARA creates the sequence, spin-systems and spins which are assigned to the atoms given in the BMRB file. You need to provide the spectra of the molecule yourself. These are loaded into the "Spectra" part of the project as described in the CARA wiki:

www.cara.ethz.ch/Wiki/WorkingWithOtherProgramsImportExport

See step 6 of the instructions for "Importing an XEASY project".

I realize that we should include the step for loading spectra also in the instructions for users who are not starting from an XEASY project. I will update this in the wiki. Thanks for drawing my attention to this.

Dear Fred, Thanks for your prompt reply. As I figured out from your post, I have to add a spectrum manually. Incidentally I dont find any spectra in BMRB string file. So even if I think of adding any spectra, I cannot do it due to this limitation. Nevertheless, I found other way round after several hours of posting my problem. Let me explain my problem first. I have taken HSQC of my sample and now I want to compare it to the available HSQC in BMRB of same sample for quick assignment. Later I realize that I am not able to overlay HSQC spectra of my sample over that of provided by BMRB string files in CARA. During this time I mailed you for help. Now I think I have got a lengthy but workable process to do the same. I opened a project for BMRB string file. Then I exported it in mapper format. This helps me in getting my desired assignment combination (like C vs N or N vs H). This mapper file is then changed to .peaks file using MS Excel and notepad and by changing its header. After this I open my sample HSQC, then go to import peaklist and import .peaks (originated from BMRB string files). Now I can overlay and compare and assign peaks (if they are matching!!!). This way I am able to overlay any BMRB string files over my measured spectra. Am I making any sense??? Kindly correct me or show me the shortcut of this process. Abhay

Hi Abhay, It seems that you have overlooked a crucial aspect of how CARA functions which is peak inference. CARA uses the assigned chemical shifts of the project to predict the position of peaks in the spectra you display.

If you load a BMRB file with assignments into a project, then CARA will display the expected peaks on any spectra that you open with the following scopes: HomoScope, PolyScope, StripScope, SystemScope.

There is no need for the elaborate technique that you describe. Possibly there was some confusion because you attempted to display the peaklists using MonoScope? This is a special tool used specifically for working with peaklists that are used by other programs and can also be used for performing integrations. However for your stated purpose of comparing BRMB assignments to a spectrum that you have measured you should use the other scopes. In this case open the HSQC15N using either HomoScope or PolyScope.

See also the related issue:

www.cara.ethz.ch/Tracker/0913

Please let me know how to fix this ProposeAndshow.lua script.

Thank you.

Hi Morgan, sorry for the long delay in my reply. I did not write this script (although parts of the code were borrowed from a script that I have helped to write). After looking into it, I conclude that you need to edit three lines near the top of the script which define the SpectrumId of the 3 NOESY spectra that are used for the analysis in your project.

t.specnumberaro=NN -- NN is the SpecId of the 3D 13C aromatic NOESY

t.specnumberali=NN -- NN is the SpecId of the 3D 13C aliphatic NOESY

t.specnumberN15=NN -- NN is the SpecId of the 3D 15N NOESY

And then you need to use it within PolyScope (do not execute it from the Terminal window.

1. Open the HSQC15N with PolyScope.
2. Select the 3D 15N NOESY
3. Click on a H-N system of interest in the HSQC15N.
4. In the 3D 15N NOESY strip click on an NOE to an aliphatic proton and then right-click propose spin.
5. The propose spin dialog will open with a list of potential assignments for the aliphatic proton. You will see an empty selector box at the top of the dialog window (see the region highlighted with a red oval in the ScreenshotBefore). Click this and select the script ProposeAndShow.lua. (Should look like ScreenshotAfter)

Now the behaviour of Propose spin has been changed so that after you select one of the proposed spins, it shows an expanded view of the region corresponding to the complementary NOESY spectrum (the 3D 13C aliphatic NOESY in my example). This is to help you to decide what the correct NOESY assignment is. If you see a signal which aligns with the crosspeak at the displayed location then it means that the complementary NOESY has a peak which supports the assignment.

This is an experimental script written by A. Severin and currently you need to manually close the windows after you are done with viewing each proposed spin assignment. Also you need to delete the spinlink to the proposed spin if you were not convinced that the assignment is correct. This is done most easily using the undo feature (ctrl-z).

If you want Propose spin to return to the old behaviour of just showing a list of spins with matching shifts then use the selector to again select an empty entry (no selected script). Note that if you select a different script you may get unwanted effects since the selected script is selected everytime you use Propose spin so be careful what script you select!

The last sentence of my last Issue followup should read

Note that if you select a different script you may get unwanted effects since the selected script is executed everytime you use Propose spin so be careful what script you select!

You need to use the "show folded" feature. If you type sf the regions outside of the spectral width SW=36 will be displayed. See the following wiki documentation for details.

www.cara.ethz.ch/Wiki/FoldingAndAliasing

Perhaps I didnt answer your question. You can load the folded 13C-resolved NOESY just the same as you would load one that is not folded.

Regarding the replacement of residues: You must do it manually in the repository file. Please see this issue:

www.cara.ethz.ch/Tracker/0787

Regarding the display of systems. There is no way to display only one system unless you are using SystemScope. You can navigate to the system using the following approaches:

• gs or gy Goto sYstem (enter system number: gy 13)
• gr Goto Residue (enter residue number: gr 10)
• sl Show List (double click on puzzle piece of system/residue)

If you are having problems with overlap you will need to zoom in (but ofcourse you will not see all resonances of a system this way).

In SystemScope the frequency lines are displayed automatically. In the other scopes, you can turn on View-synch to global cursor in different scopes so that the cursor position corresponds along the equivalent axes.

The filename must have the suffix .seq

For example mysequence.seq

There is also a lua script which converts a file containing single-letter aminoacid code to a .seq file. This file must have the name ending in .aa. The script is called OneLetterFileToSeqFile.lua

You can shift a set of spins by a fixed amount using the either of the scripts

ShiftSpinsAndAliases.lua

ShiftSpinsInCatagory.lua

The new script:

RecalibrateSpectra.lua

allows the spectral dimensions to be recalibrated to reflect the changed spin positions.

This is an old bug in the script included with the template repository. You can obtain the latest version of AssignmentReport.lua at the cara wiki calua page. You can write out a deposit file for BMRB using the latest version of WriteAssignments.lua.

This issue is fixed by updating the script from the script collection at the cara wiki so I marking it as "completed".

I tried many variations but there is no way to do this using ExperimentProcedures. The ExperimentProcedure simulation of possible correlations is done within CARA by branching into the predecessor residue i-1 at the END of the ExperimentProcedure (see HNCACB for example). Furthermore once in the predecessor residue, it is no longer possible to return to the original residue i.

You can simulate the effect of different ExperimentProcedures by using the menu item SpectrumType-Show Experiment Path.

In order to properly simulate any experiment using two linked residues with an ExperimentProcedure, the code of CARA would have to be rewritten to simulate always on the dipeptide rather than treating the two residues separately.

However, there is a workaround!

CARA still provides a more primitive method to define correlations that are observed in an experiment. This is through the use of Labels in the dimensions of the SpectrumType. You need to select two dimensions of the 3D that have a single label each. In this case I recommend N for Dim1 and C-1 for Dim3 since all crosspeaks in your NCOCACB spectrum include these two nuclei. The remaining Dim2 can contain the multiple labels CA,CA-1,CB,CB-1.

See the first screenshot for how to do this (right-click on the dimension and select Add label to add the shown labels).

Next you need to create a 2D spectrum which has just these two dimensions: an N/CO-1 correlation spectrum. You could make this spectrum simply by using the Tools-project spectrum function.

Then create a new SpectrumType NCO which correlates N with C-1. Define Dim1 with a single label N and Dim2 with a single label C-1. These are KEY labels and will help CARA to match up these two dimensions to the two dimensions Dim1 and Dim3 respectively of the 3D NCOCACB experiment.

See the second screenshot for how to define the SpectrumType NCO.

Now import the two spectra NCO and NCOCACB into your project making sure that they are oriented properly (check the ppm ranges against the Dim number in the Spectra viewer).

Open the 2D NCO using SynchroScope (SynchroScope is an old scope that determines the possible correlations using the old Labels format in SpectrumTypes).

Select the 3D NCOCACB in the strips menu. Pick system in the 2D NCO plane. Click on one of the resonances in the strip and pick spin. Next label spin. You should have available all the labels CA,CA-1,CB,CB-1 from Dim2 of the SpectrumType definition from the NCOCACB.

See third screenshot for an example of how this looks.

This setup will allow you to pick the peaks in the NCOCACB experiment using SynchroScope. However, you will not see the labels for CA and CB in StripScope because this Scope simulates peaks with the ExperimentProcedure. You can none-the-less use the functions Find Best Predecessor and Find Best Successor to link up the strips.

Hope this helps get ahead with your project.

Here is the third screenshot demonstrating how SynchroScope looks after opening the NCO, selecting the NCOCACB in the strips, picking a system in the NCO, picking a spin in the strip and then labeling the spin.

Hallo Fred! Thank you very very much for your great help!!! It is working and I think I will come forward. I have one more small guestion. When I open the 2D_CON spectrum in SynchroScope I can see only the peaks without picking and labels. But when I open the spectrum in PolyScope or HomoScope the peaks are already picked and labeled. Can you tell me please why is it so? Thank you very much in advance! Best regards, Michaela.

This is because SynchroScope is an older scope with not so many options. It only shows the system number of the picked systems, not the spin labels. You could open HomoScope or PolyScope in addition to SynchroScope and turn on View Synch Zoom and View Synch Cursor in both scopes. Then if you are not sure about the labels in SynchroScope just switch quickly to HomoScope or PolyScope and the cursor will be on the same system (and the label will be visible).

Thank you very much!!

Hallo Fred! You made a replay to my question yesterday and it was clear. I have a new question. It is a matter of the 2D_CON spectrum opened in SynchroScope. The peaks are not picked. I must pick them. When I make it, the peak is labelled with a new system number. Concretely: I pick one peak in CON spectrum, CO and N+1 become a new spin number. Then I select 3D CbCaCON spectrum and pick Ca and Cb which also become new spin number. But the CO, N+1, Ca, Cb have already a spin number from the assignment with other spectra. Now they have two spin numbers. I dont understand, why? And I can't assign the two system numbers to the same amino acid but they are the same amino acid. It is maybe quite simple and you are maybe laughing about this but can you explain it please? Thank you very much in advance!!! Michaela.

I don't have this problem. I see all the C-1/N correlations that I expect based on the assignments in my project. There must be a difference in your SpectrumType definition or perhaps the spins have different labels in your project or possibly they are not yet linked up into systems. When you simulate your SpectrumType on ALA do you get N .. C-1 ? Do you have a spin with label C-1 defined in the systems which are not linked to a predecessor? If the predecessor is linked, does that predecessor system have a spin with label C?

Hmm, I think I didn't understand you correctly a few days ago. My systems are linked and wenn I open the CON spectrum in Homoscope or polyscope the peaks are labeled due to previous assignment. But in Synchroscope not. You wrote me, that Synchroscope an older Scope is. Shall I understand it so, that it isn't possible to do pick peaking in CON spectrum-Synchroscope mode when I already made assignment? I use the C detected spectra especially for Proline assignment and adittionaly I make a check of the assignment. Many thak's!!!

Hallo Fred, I have an another question...I picked a new system in CON spectrum which is a Proline. The predecessor and successor are already assigned with other experiment types. How can I link the Proline with the two amino acids from the previously assignment, please? Many thank´s.

Hallo Fred, it is really funny! I don't know what I done but my peaks in the CON spectrum synchroscope are labelled with the right system numbers and a I can also link the Prolines with the predecessors and successors. I have no trouble in the moment. Thank you very much for your great help until now!!!! It was very helpfull!!!! Best regards, Michaela.

It seems that this issue has been resolved so I am marking it as "completed" it in the Issue-Tracker

Here is a script to automatically do this. (I thought I had uploaded this a long time ago, but apparently not).

I added this to the script collection.

added a script to the script collection which fixes this problem. The next update of the standard template will fix this issue.

It should not matter, as long as you process both the heteronuclear NOE and reference experiment the same. I have expanded the discussion of the Integrator PeakModel somewhat in the wiki.

I don't know. The fit should really just reflect the distance from the cursor ppm value to the spins ppm value. I will look into it. But in any case I suggest that you always use the origin spin. Once you have copied the projected spin to the origin system you have committed to that assignment. Then the projected spin is just a place-holder.

I checked this using the demo project and I don't see what you describe. The fit values for HA-1 A15 and HA L14 are identical and all other examples I check work properly. Could it be that you have alias shifts defined for one of the spins? This is the only way I can create the situation you describe. But then the ppm values for HA-1 A15 and HA L14 are also different.

I think alias shifts could be the reason, but I did try to use the script "Removeallalias" before working on the spectrum. I will double check on my project. Thank you very much for your help!!

I think there was an error in the script RemoveAllAliases.lua released with template Start1.2.cara which causes it to fail to remove aliases. The updated version on the CARA wiki works. However, there is a new version of RemoveAliases.lua which has an option allowing ALL aliases to be removed and it uses a menu interface so that it is not necessary to edit the script when using it.

In Topspin, you can probably use STSR and STSI parameters in F3 dim to reduce by factor of 2 or more the size of file in direct dim. Possibly other dimensions can also be zerofilled less (smaller SI). Then use compression in CARA tools "convert to CARA spectrum".

See also this issue which I found by searching for "file size" using the Issue Trackers search window.

www.cara.ethz.ch/Tracker/0868

There is no way to overlay 3D spectra. You have to switch back and forth for example using the commands nt and pt in Polyscope. You can currently overlay only 2D spectra using the overlay menu of PolyScope.

To analyse your 1J-IPAP-HNCA spectra, I would peak pick one of the HNCA spectra in Polyscope or Stripscope and then switch to the other one and use "move alias" to create alias positions for that one. Then you could write a simple script to extract the difference in position by comparing spin shift to alias shift.

This should not be possible if your Spectrum types are properly defined in the Experiment Procedure. For C to C transfer steps: hops=1 and mean=40, deviation=35. Use the SpectrumType from the standard template.

You need to define labels for the dimensions of the SpectrumType appropriately

HSQC13Cali. Dim 1: ?HA, Dim2: ?CA

3D C13ali-NOESY Dim 1: ?HA, Dim 3: ?CA, Dim 2: none needed

The labels are assigned to spins that are created during peak-picking of the 2D. They are also used to match up the corresponding dimensions of the 2D and 3D experiments.

I modified the Pick_3D_Peaks.lua script (ver. 4) so that it complains if matching labels are not found in the 3D. It also is modified so that it can pick negative intensity peaks. So you should download ver. 4 from the wiki.

It means you probably have some peaks that are so close together that CARA considers them unresolved. CARA in this case will split the local intensity equally between them. There are a number of Issues discussed in the Tracker regarding integration. I suggest you do a search on integration or integrator to find them.

Problem solved.Thank you Fred.

In CARA when you pick a sequential peak in the CBCAcoNH strip from a system A, you should give it a label like CA-1 or CB-1. This indicates that the picked resonance actually correspond to the CA or CB of a predecessor system. However the spins are stored in the current system A. When you use show best predecessors, CARA matches these spins shifts to the shifts of spins labeled CA and CB in other systems and ranks the systems according to how close the fit is.

As soon as the matching spins are assigned, (i.e. the predecessor system B which has spins CB & CA is linked to system A with spins CB-1 and CA-1 AND the fragment that these two systems are within is assigned to the sequence), CARA displays the position of the CB and CA spins from system B in the strip of system A with the full assignment label. The spins CB-1 and CA-1 are not lost. They are still stored in system A. The display of the shift CB from the assigned predecessor system in place of the CB-1 of a system is called resolving projected spins. You can turn this effect off using the menu View-resolve projected spins.

The point is that this effect is intended. CARA is showing you where your signals SHOULD appear if your assignment is correct. This is help the user to avoid making inconsistent assignments. The CB-1 of system A should anyway be very close to the CB of system B. If they are not, then something is wrong with the assignment.

Dear Fred, thanks for your answer, but I guess I didn´t describe the problem properly. Of course if linking two systems together, the labeling changes. Lets say there is a spin system 1 which has been identified as the predecessor for spin system 2 (which means that CA-1 and CB-1 spin shifts from System 2 are matching with CA and CB spin shifts from System 1). When I link them together with the function "Link to Reference", the CA-1 spin from System 2 will get the labeling "CA 1" and the CB-1 spin from system 2 will get the labeling "CB 1", whereas CA and CB from system 2 are still labeled "CA 2" and "CB 2", respectively.

After a more detailed reinvestiagtion I could pin down the following observations: In SynchroScope (the already descibed phenomenons): 1)Either two CA and two CB are present in the strip pane, so the information for the originally picked CA-1 and CB-1 got lost. 2) CA-1 and CB-1 are defined as CA and CB respecively, but the correct CA and CB peaks are no longer picked. For most of the spin systems SynchroScope and StripScope show the same pattern, but in some cases StripScope showed the Spin System properly whereas SynchroScope had the fault. In StripScope: 1) For Spin Systems which are at the Start of a fragment: CA-1 and CB-1 are still present but the picked CA and CB spins are lost. Neither unlinking the spin system from the fragment didn´t restore the picked CA and CB shifts nor did relinking into the fragment. 2) For Spin Systems which are inside a fragment: 2a) CA-1 & CB-1 are still present and labeled correctly with the predecessor spin system (e.g. labeled with "CA 1" and "CB 1" in system 2 corresponding to the example above), but the picked CA and CB spins got lost. 2b) CA and CB spins are still present and CA-1 and CB-1 as well, but CA-1 is not labeled with the predecessor spin system whereas CB-1 is labeled with the predecessor spin system.(e.g. CA-1 from system 2 ist labeled "CA 1" but CB-1 from system 2 is still labeled "CB-1 2") 2c) CA, CB, CA-1, CB-1 are all present but CA-1 and CB-1 are not labeled with the predecessor spin system (e.g. CA-1 and CB-1 for spin system 2 are still labeled "CA-1 2" and "CB-1 2", respectively). The function "resolving project spins" is always active, so as soon as a predeccessor is defined it should appear in the labeling of the CA-1 and CB-1 spins of a corresponding system.

Somehow the picked spin information gets lost after recombining some systems into fragments. This doesn´t apply for all spin systems in fragments but it occurs for some. New spin picking, labeling and linking into fragments doesn`t help in all cases. Often this phenomenons happen again when opening the cara file on a different day, but sometimes also with different spin systems.