using DSSR ct files for input to VARNA

[cllawson]

Dear Xiang-jun,

I have been looking at using VARNA for creating 2D maps of RNA, following what you showed us when we met a few weeks ago.
For the PDB entry 3RG5 (2 tRNA's in the asymmetric unit), VARNA is readily able to read/display using the .ct file DSSR creates for the whole entry from the cif file,
though the result is displeasing--two overlapped tRNAs.

Wwhen I tried to read in either of the individual chain .ct files VARNA chokes (e.g., java.lang.ArrayIndexOutOfBoundsException: -7). 
I've attached one of the problem ct files, wondering if you have seen this type of issue?

[xiangjun]

Hi Cathy,

I am at a meeting right now. This quick response serves to acknowledge that I am aware of the reported issue, and I'll get back to you soon in detail.

Basically, I understand what you mean, and the way would be to extract the two tRNA structures separately and then feed one (or each) to DSSR (and to VARNA via derived .ct file) instead of changing the .ct file from the whole structure manually.

Best regards,

Xiang-Jun

[cllawson]

Thanks for your quick response. For now will follow your suggestion. It would be great if you could follow up on the issue when you have time.

[xiangjun]

Hi Cathy,

I've looked into 3rg5. As guessed in my initial response, DSSR is doing its job here as expected. Specifically, DSSR works on a user-supplied coordinate file (.pdb or .cif). Since 3rg5 contains two tRNA molecules per asymmetric unit, DSSR outputs the secondary structure (in .ct, .dbn, or .bpseq) with information of both molecules included. How to visualize such 2nd structure is another issue, be it with VARNA or quite a few other visualization tools. This is just like how one would display 3rg5 using PyMOL or Jmol in 3D.

Editing secondary structure in .ct format manually may not be a good idea. Not only is it time-consuming, but also error-prone. The way to solve the problem is as originally suggested, i.e., to extract the part (chain) you are interested in, then DSSR --> .ct --> VARNA. There are numerous utility programs to extract a chain or a fragment thereof given a PDB coordinate file.

IF you want to occasionally play around with the 2nd structure file directly, the .dbn file may be a better choice than .ct. Using 3rg5 as an example, DSSR also outputs file dssr-2ndstrs.dbn (in addition to dssr-2ndstrs.ct, and dssr-2ndstrs.bpseq), with content as below:

Code: [Select]

>3rg5 nts=172 [3rg5] -- secondary structure derived by DSSR
GCCCGGAUGAUCCUCAGUGGUCUGGGGUGCAGGCUUCAAACCUGUAGCUGUUUAGCGACAGAGUGGUUCAAUUCCACCUUUCGGGC&GCCCGGAUGAUCCUCAGUGGUCUGGGGUGCAGGCUUCAAACCUGUAGCUGUUUAGCGACAGAGUGGUUCAAUUCCACCUUUCGGGC
(((((((.(..((((((..[.))))))((((((.......)))))).(((((....))))).((((..]....))))).)))))))&(((((((.(..((((((..[.))))))((((((.......)))))).(((((....))))).((((..]....))))).)))))))
The two chains are separated by & (a convention between DSSR and VARNA). To display only the first chain (A), you can simply delete the sequence and dbn parts from the corresponding lines, as below:

Code: [Select]

>3rg5-A -- only chain A
GCCCGGAUGAUCCUCAGUGGUCUGGGGUGCAGGCUUCAAACCUGUAGCUGUUUAGCGACAGAGUGGUUCAAUUCCACCUUUCGGGC
(((((((.(..((((((..[.))))))((((((.......)))))).(((((....))))).((((..]....))))).)))))))
Here again, one must be careful. If there is any Watson-Crick pairs formed between chains A and B, then the new .dbn file will on longer be valid because of unbalanced ()s.

To sum up, prepare a .pdb/.cif input file as desired, then DSSR-->.ct/.dbn/.bpseq-->VARNA. As a general rule, do not manipulate DSSR-derived 2nd files directly.

Xiang-Jun