Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Netiquette · Download · News · Gallery · Homepage · DSSR · Web-DSSR · DSSR Manual · Reproduce DSSR · DSSR-Jmol · DSSR-PyMOL · Web-SNAP

Messages - xiangjun

Pages: 1 2 [3] 4 5 ... 82
Programs / Re: blocview
« on: June 20, 2018, 01:21:05 pm »
Hi Mauricio,

Nice to see you again on the 3DNA Forum!

I would also like to change the radius of the sticks representing the sugar-phosphate backbone bonds.

The default radius of the sticks is set via the r3d_atom -r=0.16 option in the blocview script. See the excerpt below:

Code: Ruby
  1.         # color nucleic-acid base/sugar by residue type
  2.         Utils.run_cmd("#{$x3dna}r3d_atom -ncz -r=0.16 tb.pdb #{$temp_r3d} #{$msg}")
  3.         Utils.append_r3dfile(opts[:r3dfile], $temp_r3d)

So you may change the radius 0.16 to your preferred value.

Alternatively (and preferably), you may want to give DSSR a try. DSSR has integrated blocview as a command-line option, and employes PyMOL for rendering. See the DSSR User Manual for more details.




You're welcome to post your code, with worked examples, to the section "Users' contributions". Your use case may be quite specific right now, from your perspective. Others in the community, however, could also benefit from your effort (probably in the long run). The 3DNA Forum could help build "an online community for DNA/RNA structural bioinformatics".

Best regards,


DBN is a simple, compact way to represent RNA secondary structure, as matched (),[], {} etc of canonical pairs (Watson-Crick and G--U wobble). The DSSR implementation of DBN follows the convention. DBN extensions that account for non-canonical pairs have been reported in the literature. No standard representation of such extensions exists, as far as I know.

In addition to non-canonical pairs, triplets and quadruplets (or higher, generally termed multiplets in DSSR) also exist in RNA, but they cannot be properly represented by DBN either. I'm generally in favor of keeping DBN simple in DSSR, at least by default. However, I'd consider expanding DBN by additional options, if necessary. I can be easily convinced by seeing concrete/worked examples.


Try running DSSR with the --h2o (or --water) option. For example,

Code: [Select]
x3dna-dssr -i=2gdi.pdb --h2o --get-hbond | grep X.HOH373

 1415  3572  #400   o    2.790 O:O OP2@X.G76 O@X.HOH373
 1427  3572  #407   o    2.836 N:O N7@X.G76 O@X.HOH373

By design, DSSR does not output H-bond between waters. So your item 2), i.e. the H-bond between X.HOH373 and X.HOH492, is not available. It should be straightforward to add X.HOH494 to the list, based on available info and a distance cutoff. You're welcome to contribute back your code/script with examples so the community could benefit from it.




Thanks for posting on the 3DNA Forum!

Could you elaborate on what you want to achieve specifically? Please use a concrete example so that I (and others) can better understand you.

Best regards,


Interesting observation. When you upload a structure from your local machine, it is first parsed by Jmol. The coordinates (which are smaller than the initial .cif file) are then passed to DSSR on the server. That explains your test case of 5afi.

Overall, the simple interactive DSSR-Jmol website is not designed to handle those large ribosomal structures.


Hi Shuxiang,

The ribosome structures 5afi and 5j4b are huge. In CIF format, they are 26M and 37M respectively, which exceed the 18M size limit. See the DSSR-Jmol paper. The relevant section is shown below.

DSSR web service

The web service is hosted at Columbia University, via a single-file PHP script that calls the DSSR command-line tool for back-end analysis. The DSSR web service runs independently of Jmol, and accepts atomic coordinates in mmCIF or PDB format. The service also takes a four-letter PDB id to automatically fetch the corresponding mmCIF formatted coordinate file from the RCSB PDB (20) (see the Supplementary Data). For an NMR ensemble, only the first model is analyzed by default. For X-ray crystal structures, the asymmetric unit is analyzed. The DSSR algorithm works for both DNA and RNA, either in isolation or in their complexes with proteins. The server has an 18MB-size limit for uploaded coordinate files. For DNA/RNA structures with <300 nucleotides, it takes DSSR less than one second to run (see Table 1 of reference (9)).

So what you observed is as expected. It is a documented limitation of the DSSR-Jmol website.


Hi Shuxiang,

The '&' symbol in DSSR-derived dot-bracket-notation (DBN) is a convention between DSSR and VARNA to signify different chains or breaks between different segments of the same chain. Other 2D viewers may not recognize it, as is the case for FORNA.

You could use the --dbn-break=no option to remove them, as documented in the DSSR manual (Section 3.16.12, shown below).

3.16.12 The --dbn-break option

By default, DSSR employs the symbol ‘&’ to separate multiple chains or
chain breaks in dbn, for compatibility with VARNA. By using
--dbn-break, one can choose any of the characters in the string
“&.:,|+”. For example, by running the following command on the
Dickerson DNA dodecamer [16] structure 355d, one would get a
whole-structure dbn composed of those from the two chains
connected by ‘+’:

x3dna-dssr --dbn-break=+ -i=355d.pdb

>355d nts=24 [whole]

With --dbn-break=no, no symbol will be used to separate different
chains or intra-chain breaks: for 355d, the dbn would be



Hi Mandar,

I am analyzing Z-DNA duplex (PDB ID: 1I0T.pdb) using 3DNA (v2.3-2017feb08) and Curves+ both. I have removed water and other molecule from PDB and only DNA coordinates are present. The input for Curves+ is generated using find_pair -c+ option.
3DNA command:
find_pair 1I0T.pdb stdout | analyze -c stdin
Curves+ command:
find_pair -c+ 1I0T.pdb curves_1I0T.inp
./Cur+ < curves_1I0T.inp
I have attached PDB file and both output files to the mail.

Thanks for providing the detailed commands you used and attaching the corresponding data files. I can reproduce your reported results from 3DNA (v2.3) and Curves+.

3DNA is working as expected for the Z-DNA structure (1I0T). For your reference, you could run the following commands:

Code: [Select]
find_pair 1I0T.pdb | analyze   # generate 1I0T.out
rebuild -atomic bp_step.par 1I0T-3dna.pdb
find_pair 1I0T-3dna.pdb | analyze   # generate 1I0T-3dna.out

Comparing the parameters in files 1I0T.out and 1I0T-3dna.out, you'd notice that they are virtually the same. See Table 3 of the 2003 3DNA NAR paper, "Root mean square deviation (in Å ) between rebuilt 3DNA models and experimental DNA structures", for A-, B-DNA, and a DNA-protein complex. Moreover, the simple relationships between step and helical parameters,  see equations 3 and 4 of the above mentioned 3DNA paper, still hold as for right-handed A- or B-DNA.

Note also that you do not need to remove water and other molecule from the PDB file for 3DNA to work.

I observed that the Shift and TIlt values for dinucleotide steps have similar values but exactly opposite signs. Also, X-displacement, Y-displacement, Inclination values are totally different (ignoring terminal base pairs) compared to 3DNA results.

This is a sharp observation. In my understanding (from the perspective of 3DNA), the opposite signs for Shift and Tilt values in Z-DNA are due to different conventions for base-pair reference frames between 3DNA and Curves+. The differences in helical parameters (X-displacement, Y-displacement, Tip, and Inclination) are a bit more complicated, but they are also directly related to the differences in base-pair reference frames. No right or wrong parameters here, just different results based on (maybe slightly) different underneath assumptions. It is up to the users to make their own choices.

In the future, it may be possible that 3DNA and Curves+ could reach an agreement on the analysis of Z-DNA structures or those with non-canonical base pairs. Since both 3DNA and Curves+ are open source, you're welcome to dig into the details of these differences and report back your findings. User-feedbacks are always welcome on the 3DNA Forum.

Hope this clarifies your confusions a bit.


Dear Mandar,

Thanks for using 3DNA and for posting your questions on the Forum.

The questions on differences between 3DNA and Curves+ for Z-DNA structures have not been asked before. Given the sample files you provided, I understand what you mean. I will look into the questions carefully. Since these questions are out of 3DNA per se and technical in nature, it may take me some time to get back to you.

Best regards,


The issues you experienced with "find_pair" have been reported many times (searching the Forum should give you some hints). The source of the missing or mis-assigned pairs is due to the irregularity of the structure under consideration. Some of the 'assumed' pairs are simply too distorted to be taken as a pair. Using your attached 'plus2.MD.traj.09.pdb' as an example, DA86 and DT587 certainly do not form a pair in any (canonical) sense -- see the attached fragment with DA86 and DT587 embedded.

In such cases, if you insist that nucleotides such as DA86 and DT587 should be taken as a pair, you can manually edit the output from "find_pair" as desired. You can think of the scenario where "find_pair" does not exist, and you have to prepare an input file with pairing info by hand.

The "analyze" program will follow strictly the pairing info as provided in the input file.


General discussions (Q&As) / Re: build a DNA triangle for Gromacs
« on: April 17, 2018, 11:43:22 pm »
Hi Luxuan,

Thanks for your interested in using 3DNA and for posting your questions on the 3DNA Forum. Is your DNA triangle a planar structure? Is it equilateral? What the length of each side? Are the three sides connected?

There may be tools (e.g., "AMBER NAB") that better fit your needs. 3DNA does not provide a command to directly construct such a DNA triangle. Nevertheless, 3DNA has some low-level facilities for applications like this. For examples, you could use the fiber command to build three straight helices (in B-or A-form DNA) of selected sequence. Using analyze, you can locate the positions of a regular helix. Combined with case-specific geometric operations, 3DNA may help lead to a bottom-up approach that is reproducible via a script.

Check "build dna bulges and extend dna duplex at both terminals via 3dna" and search the Forum for more applications.


Thanks for posting a DSSR-related question on the 3DNA Forum, and for correcting the link to the CompAnnotate paper. I became aware of this work shortly after its publication, and believe it is a useful resource in RNA structural bioinformatics.

As a meta-analysis tool, CompAnnotate takes advantage of other tools (including DSSR) in the initial identification of base-pairs, as noted below:

"Annotated base-pairing lists from the existing methods (MC-Annotate, RNAView, FR3D, DSSR and ClaRNA) are used as input for CompAnnotate and the corresponding modified base-pairing lists come as output."

To better appreciate the difference between DSSR and CompAnnotate, take a look of another tool "WebSTAR3D: a web server for RNA 3D structural alignment" developed by the same group. In the WebSTAR3D paper, the authors wrote:

Before aligning structures, STAR3D preprocesses PDB files with base-pairing annotation using either MC-Annotate (Gendron et al., 2001; Lemieux and Major, 2002) (for PDB inputs) or DSSR (Lu et al., 2015) (for PDB and mmCIF inputs) and pseudo-knot removal using RemovePseudoknots (Smit et al., 2008).

It is worth noting the following update on the WebSTAR3D website (see the attached screenshot),

Update 7/11/2017: WebSTAR3D no longer employs MC-Annotate for base pairing annotation.

Further down the webpage, it is noted "Before aligning structures, WebSTAR3D preprocesses PDBs with base pairing annotation using DSSR". So now DSSR is the only choice left for base-pair annotation.

As documented in the User Manual, DSSR has many more features to offer than just identifying and annotating base pairs. In case users have any questions, the 3DNA Forum is the way to go.

Hope this clarifies some of your confusions.


Ths link you gave is invalid. Could you fix it?


RNA structures (DSSR) / Re: Centre of Mass Pseudodihedral Angle
« on: April 03, 2018, 11:29:30 am »
Thanks for your followup. Now I can understand your original question a bit better. So COM stands for "center of mass" based on the attached figure caption. I still do not know what "CPD" stands for.

From the attached figure, it is still not clear to me what the two sugars above the target base are. Do the corresponding bases (attached to the sugars) must form a Watson-Crick (WC) pair? Do the three nucleotides where the base is in the middle must be consecutive in sequence?

Based on my understanding, I do not think adding this pseudo torsion angle (θ) is a good fit for DSSR (at least at this stage). See my post titled "Request for new features".

Why not ask for help from the author who defined this parameter? If that does not work out, you may write your own code or hire someone with basic programming skills for this purpose. Assuming the structure is a double helix with WC pairs, it should not be a big deal.


Pages: 1 2 [3] 4 5 ... 82

Created and maintained by Dr. Xiang-Jun Lu [律祥俊], Principal Investigator of the NIH grant R01GM096889
Dr. Lu is currently affiliated with the Bussemaker Laboratory at the Department of Biological Sciences, Columbia University.