Recent Posts

1

RNA structures (DSSR) / Re: Wrong junctions

« Last post by xiangjun on September 17, 2019, 11:44:51 pm »

Hi Jun,

I've updated DSSR (still labelled v1.9.6-2019sep16). It should have fixed the junction issue (in the first 3-way junction case) you observed in PDB entry 4wsm. See also my note on junctions with pseudoknots.

Please have a try and report back how it goes. In reporting any further issues, please remain to be specific.

Best regards,

Xiang-Jun

2

RNA structures (DSSR) / Re: Wrong junctions

« Last post by xiangjun on September 17, 2019, 04:49:28 pm »

Hi Jun

Please provide more details with the additional PDB entries, as you did for 4wsm. I believe the underlying issue is similar, most likely associated with extreme cases with distorted structures. The more detailed cases you provide, the better I can test/validate the fixes for the next DSSR release.

Best regards,

Xiang-Jun

3

RNA structures (DSSR) / Re: Wrong junctions

« Last post by lijun on September 17, 2019, 04:05:43 pm »

Hi Xiang-jun,
      Even with --nested option, some RNAs still share the same helix. They are 3j7r, 5mrc, 5mre, 5mrf, 6ost.
      Best,
Jun

4

RNA structures (DSSR) / Re: Wrong junctions

« Last post by xiangjun on September 17, 2019, 01:56:52 pm »

Hi Jun,

A junction loop derived by DSSR may share the same stem when pseudoknots are involved, as emphased in the DSSR paper (https://doi.org/10.1093/nar/gkv716). See for example, Figure 4 for the env22 twister ribozyme, PDB id: 4rge. Generally speaking, this is a unique feature, instead of a bug, of DSSR. Such junctions are noted with a suffix * after the serial number. One can get rid of such loops by specifying the --nested option.

I've a quick look of your reported case on 4wsm, and noticed that there may be a bug in DSSR. The first case (a three way junction) should not be there. The issue is due to stem#101 (with 2 base pairs) which has a highly distorted geometry, and judged as parallel by DSSR. I will look into the issue further, and get back to you soon.

In the meantime, you could take it as a special case, or simply remove junctions with a * suffix.

Thanks for reporting the issue!

Xiang-Jun

5

RNA structures (DSSR) / Wrong junctions

« Last post by lijun on September 17, 2019, 11:48:56 am »

Hi Xiang-jun,
     When I used  dssr to extract junctions, I found the junctions for some RNAs share the same stem.
     For example, for RNA 4wsm, the output is:
          1* 3-way junction: nts=10; [0,4,0]; linked by [#100,#101,#101]
          60* 4-way junction: nts=17; [3,1,1,4]; linked by [#211,#212,#282,#212]
          76* 5-way junction: nts=14; [0,0,1,3,0]; linked by [#332,#333,#335,#333,#334]
      I used the latest version (1.9.6) of dssr, and the command as follows:
          x3dna-dssr -i=4wsm.cif -auxfile=no --isolated-pair=not-in-loop -idstr=long -o=4wsm.out
 
        Thanks and best wishes,
Jun
     

     

6

General discussions (Q&As) / Re: Different shear etc. 3 DNA and Curves+

« Last post by xiangjun on September 11, 2019, 11:04:49 am »

I have the following question. I calculated the shear, buckle etc. for a DNA dimer ( PDB 355d.pdb  same as the one in "Building a bridge between Curves+ and 3DNA") with 3DNA and with Curves+. I would have expected to get identical values for the shear, buckle roll etc. with both programs. However, that is not the case. e.g. shear for the first base pair using 3DNA is  0.28 and using Curves+ is 0.13, propeller -17.31 resp. -18.5

It is unrealistic to expect 3DNA and Curves+ to give identical values of base-pair parameters for a given structure. Even with the same Curves+ program, setting fit=.t. or not would give slightly different results. By adopting the standard base reference frame, 3DNA and Cuves+ give similar (but not identical) values for intra- or inter-base pair parameters. See the following blogposts:

• Curves+ vs 3DNA
• Analyzing DNA/RNA structures with Curves+ and 3DNA
• Building a bridge between Curves+ and 3DNA as you mentioned

Please also refer to the Web 3DNA 2.0 paper where further comparisons were made between 3DNA and Curves+.

Why is there such a difference? Is there a different convention/parameters for the calculation in 3DNA compared to Curves+?

As always, the devil is in the details. The differences between 3DNA and Curves+ come mainly from two aspects: (1) they implement the standard base reference frame differently; (2) they use different algorithms to calculate base-pair and step parameters. Since both programs are open source, you are welcome to dig into the technical details.

HTH,

Xiang-Jun

7

General discussions (Q&As) / Different shear etc. 3 DNA and Curves+

« Last post by ellify on September 11, 2019, 08:58:09 am »

I have the following question. I calculated the shear, buckle etc. for a DNA helix ( PDB 355d.pdb  same as the one in "Building a bridge between Curves+ and 3DNA") with 3DNA and with Curves+. I would have expected to get identical values for the shear, buckle roll etc. with both programs. However, that is not the case. e.g. shear for the first base pair using 3DNA is  0.28 and using Curves+ is 0.13, propeller -17.31 resp. -18.5

Why is there such a difference? Is there a different convention/parameters for the calculation in 3DNA compared to Curves+?

I produced the input for curves using  find_pair -c+ and I'm attaching all relevant files.

8

General discussions (Q&As) / Re: Recognition of stacked base pairs

« Last post by blade2669 on September 09, 2019, 05:31:27 pm »

I downloaded the new version of x3dna (v2.4.4-2019sep09) and I confirm that overlap area is now calculated correctly.

Thank you very much for showing me the root of the problem, comprehensive explanation and release of new version of x3dna.


With kind regards,
Aleš

9

General discussions (Q&As) / Re: Recognition of stacked base pairs

« Last post by xiangjun on September 08, 2019, 06:54:44 pm »

As a follow-up, I've updated 3DNA to v2.4.4-2019sep09. It fixes the issue of inconsistent stacking area you experienced. Using C3GAGA_full.pdb as an example, the output for the overlap area section is as below:

     step      i1-i2        i1-j2        j1-i2        j1-j2        sum
   1 AG/GA  1.87( 0.00)  0.00( 0.00)  0.00( 0.00)  6.49( 4.35)  8.36( 4.35)
   2 GA/AG  7.03( 4.09)  0.00( 0.00)  0.00( 0.00)  6.52( 4.42) 13.55( 8.51)
   3 AG/GA  0.00( 0.00)  6.09( 4.69)  5.95( 4.04)  0.00( 0.00) 12.04( 8.73)
   4 Gc/CG  7.10( 4.01)  0.00( 0.00)  0.00( 0.00)  6.11( 3.06) 13.21( 7.07)
   5 cC/cC  0.00( 0.00)  0.00( 0.00)  4.08( 1.06)  0.00( 0.00)  4.08( 1.06)
   6 CC/cc  0.00( 0.00)  3.84( 0.77)  1.04( 0.00)  0.00( 0.00)  4.88( 0.77)
   7 Cc/Cc  0.00( 0.00)  0.00( 0.00)  2.25( 0.64)  0.33( 0.00)  2.59( 0.64)
   8 cc/CC  0.00( 0.00)  2.66( 0.10)  1.49( 0.00)  0.04( 0.00)  4.19( 0.10)
   9 cC/cC  0.08( 0.00)  0.19( 0.00)  0.63( 0.00)  0.83( 0.00)  1.72( 0.00)
  10 CG/Gc  8.08( 4.05)  0.00( 0.00)  0.00( 0.00)  4.96( 2.33) 13.04( 6.38)
  11 GA/AG  0.00( 0.00)  5.76( 3.86)  6.23( 4.66)  0.00( 0.00) 12.00( 8.52)
  12 AG/GA  5.89( 3.84)  0.00( 0.00)  0.00( 0.00)  4.70( 2.58) 10.59( 6.42)
  13 GA/AG  5.59( 2.76)  0.00( 0.00)  0.00( 0.00)  3.24( 0.73)  8.83( 3.49)

Best regards,

Xiang-Jun

10

General discussions (Q&As) / Re: Recognition of stacked base pairs

« Last post by xiangjun on September 08, 2019, 03:21:28 pm »

Hi,

Thanks for bringing up an insightful case of inconsistent characterization of base-stacking interactions in 3DNA v2.x. The details you provided are reproducible and helped me to detect where the problem is.

1) Is there any explanation why the overlap area in the G4-A5 step in the full structure is zero but in extracted structure is 12.04?
2) Is it possible that zero overlap is result of low threshold?
3) If so, is it possible to change the threshold and how?

The inconsistency is due to the different arrangement bases along the two chains. For C3GAGA_full_analyze.out, it is as below:

            Strand I                    Strand II          Helix
   1   (0.073) ....>A:...7_:[.DA]A-**+-A[.DA]:..21_:C<.... (0.065)     |
   2   (0.087) ....>A:...6_:[.DG]G-**+-G[.DG]:..20_:C<.... (0.071)     |
   3   (0.060) ....>A:...5_:[.DA]A-**+-A[.DA]:..19_:C<.... (0.069)     |
   4   (0.061) ....>A:...4_:[.DG]G-**+-G[.DG]:..18_:C<.... (0.072)     |
   5   (0.060) ....>A:...3_:[HCY]C-**+-C[.DC]:..17_:C<.... (0.049)     |

For G4A5_analyze.out, the bases are swapped, as shown below:

            Strand I                    Strand II          Helix
   1   (0.069) ...3>C:..19_:[.DA]A-**+-A[.DA]:...5_:A<...3 (0.060)     |
   2   (0.061) ...3>A:...4_:[.DG]G-**+-G[.DG]:..18_:C<...3 (0.072)     |

It turns out that this rearrangement is consequential in your case. If you're interested in knowing the technical details, please check the source code; particularly, the two functions with_stacking() and with_ss_overlap() in file ana_fncs.c.

You may give DSSR a try. With the --non-pair option, you'd get a consistent result for the overlap area of any two stacked bases. For example, run the command x3dna-dssr -i=C3GAGA_full.pdb --non-pair, you'd see the following:

Code: [Select]

List of 27 non-pairing interactions
.....
   6 A.DG4   C.DA19  stacking: 6.3(4.7)--pm(>>,forward) interBase-angle=1 min_baseDist=3.46
   7 A.DA5   A.DG6   stacking: 6.5(3.8)--pm(>>,forward) interBase-angle=15 connected min_baseDist=3.08
   8 A.DA5   C.DG18  stacking: 6.1(4.7)--mp(<<,backward) interBase-angle=7 H-bonds[1]: "O4'-N1(imino)[3.20]" min_baseDist=3.23
   9 A.DG6   A.DA7   stacking: 2.4(0.0)--pm(>>,forward) interBase-angle=7 connected min_baseDist=3.55
......
With the --analyze option, you can also get base-pair parameters as from 3DNA v2.x analyze program.

HTH,

Xiang-Jun