Messages

1126

RNA structures (DSSR) / Re: dealing with symmetrics

« on: June 17, 2013, 10:36:15 am »

Okay, I got the idea, and I will take segid into consideration in the next release of DSSR.
To use fixed space font, you could try Tt button, # button for code, or pre-formatted text button -- all on the menu, in a similar fashion as in Word.

Xiang-Jun

1127

RNA structures (DSSR) / Re: dealing with symmetrics

« on: June 17, 2013, 09:01:57 am »

Could you provide (a link to) the full specification of the PyMOL-customerized PDB format with a complete example? I may consider to handle the extra symmetric fragment if the functionality fits the overall design of DSSR.

Xiang-Jun

1128

RNA structures (DSSR) / Re: Delineating the components of bulges, internal loops, junctions, etc

« on: June 10, 2013, 11:23:01 pm »

Please download and play DSSR beta-r12-on-20130610 -- it's likely that we've moved one step forward. As always, please let me know if you have any comments or suggestions.

Note that I've slightly refined the format to make the bulges, internal loops, and helical junctions more explicit in the delineated output. Further changes are possible in future releases of DSSR, based on user feedback and other considerations.

Xiang-Jun

1129

RNA structures (DSSR) / Re: Delineating the components of bulges, internal loops, junctions, etc

« on: June 10, 2013, 05:30:48 pm »

I have revised DSSR to output loops in the format you suggested. Before I make a new beta release, please have a look of the sample run on 1s72 (attached), and report back how it goes.

Note that I have kept the original list which contains all nts in a loop. The new additions for each loop fragment are listed underneath. For the two cases you mentioned, the new output looks like below:

Code: [Select]

  55 asymmetric internal loop: 7 nts; [1x2]; linked by [#168, #169]
       0.G2855+0.A2856+0.C2857+0.G2900+0.C2901+0.A2902+0.C2903 [GACGCAC]
       1 base(s) 0.A2856 [A]; 0.G2855+0.A2856+0.C2857 [GAC]
       2 base(s) 0.C2901+0.A2902 [CA]; 0.G2900+0.C2901+0.A2902+0.C2903 [GCAC]

  20 3-way junctions: 12 nts; [1x1x4]; linked by [#138, #-43, #140]
       0.C2329+0.U2330+0.C2331+0.G2355+0.A2356+0.G2357+0.C2366+0.A2367+0.A2368+0.A2369+0.A2370+0.G2371 [CUCGAGCAAAAG]
       1 base(s) 0.U2330 [U]; 0.C2329+0.U2330+0.C2331 [CUC]
       1 base(s) 0.A2356 [A]; 0.G2355+0.A2356+0.G2357 [GAG]
       4 base(s) 0.A2367+0.A2368+0.A2369+0.A2370 [AAAA]; 0.C2366+0.A2367+0.A2368+0.A2369+0.A2370+0.G2371 [CAAAAG]
Xiang-Jun

1130

RNA structures (DSSR) / Re: Delineating the components of bulges, internal loops, junctions, etc

« on: June 07, 2013, 05:14:24 pm »

Message taken -- I'll get DSSR updated by early next week.

Enjoy the weekend!

Xiang-Jun

1131

Bug reports / Re: rotate_mol small bug

« on: June 07, 2013, 02:07:26 pm »

Hi Pascal,

I've fixed the bug in rotate_mol and frame_mol which was introduced in the 2013may02 release to retain original residue and atom names. The updated 3DNA v2.1 release is dated 2013jun07. Please have a try and report back any issues you may have.

Thanks, and have a good weekend!

Xiang-Jun

1132

RNA structures (DSSR) / Re: Delineating the components of bulges, internal loops, junctions, etc

« on: June 07, 2013, 01:53:42 pm »

Let me ask around the lab and get their input and I'll make a suggestion based on what they suggest that would be most "user-friendly" and easily readable.

That's great -- once I get your feedbacks, I will implement them in the next beta release of DSSR. I'm planning to add some new features to DSSR, including detection of kink-turns, but would take priority on refinements of existing functionality.

  55 asymmetric internal loop: 7 nts; [1x2]; linked by [#168, #169]
       1 loop bases [A]; 0.G2855+(0.A2856)+0.C2857 [G(A)C]
       2 loop bases [CA]; 0.G2900+(0.C2901+0.A2902)+0.C2903 [G(CA)C]

I like your idea for internal loop. Maybe stem loop, bulge, and junctions can follow the same pattern?

Xiang-Jun

1133

RNA structures (DSSR) / Re: Delineating the components of bulges, internal loops, junctions, etc

« on: June 07, 2013, 12:43:29 pm »

Okay, how about junction loops, and stem loops? Do you have any suggestions for formatting? I'd like to consider all loops in a consistent frame work.

Up to this point, I've been focusing on the underlying algorithm for identifying the various RNA structural components, and their interactions. I'd consider carefully user requests to the extent that's makes sense to me in a global/general sense. Bear in mind, though, some purpose specific scripting/programming may well be necessary.

Xiang-Jun

1134

RNA structures (DSSR) / Re: Delineating the components of bulges, internal loops, junctions, etc

« on: June 07, 2013, 11:48:21 am »

Thanks for your feedback. As always, the more, the merrier! DSSR is currently in beta, and I am fully open to user suggestions for every aspect of the software, including format changes.

In writing DSSR, I came across many basic concepts in the literature of RNA structures that are well-known, yet not clearly defined (at least to my understanding). I tried to follow the conventions (where exist) as much as practical, and came up with my own 'ways' where necessary. It is my hope that DSSR would help in establishing pragmatic ways in charactering RNA (secondary) structures.

For your example case:

Code: [Select]

List of 12 bulge(s)
   1 bulge: 6 nts; [2x0]; linked by [#19, #-8]
       0.C245+0.G246+0.A247+0.A248+0.U265+0.G266 [CGAAUG]
It means that DSSR detects 12 bulges in the structure (1s72). For each bulge, DSSR outputs its type as a special case of internal loops with one strand containing 0 nts. Here the first bulge contains 2 nts, so of type [2x0]. Plus two enclosing canonical bps (here from stem #19, and lone bp #-8), the loop contains 6 nts (2+2+2). The listing below contains the 6 nts in sequential order, as would be obvious if one extracts just the nts and displayed them in Jmol or PyMOL. Here the two bulged out nts are 0.G246+0.A247.

I see your point for making components of the loop explicit, and will consider to implement extra output fields in future release of DSSR.

Xiang-Jun

1135

Bug reports / Re: rotate_mol small bug

« on: June 07, 2013, 10:38:01 am »

Thanks for reporting this bug. I'll get it fixed ASAP.

Xiang-Jun

1136

RNA structures (DSSR) / Re: C-H...O bonds

« on: June 06, 2013, 03:30:09 pm »

There are provisions in DSSR for weak H-bonding interactions, but I take them as experimental. I will not get into the details until the fundamental parts of DSSR are done and written up.

Xiang-Jun

1137

MD simulations / Re: issues with x3dna_ensemble

« on: June 06, 2013, 01:10:27 pm »

Hi,

By default, find_pair finds only 11 base pairs in your sel.pdb structure. The nucleotides ....>A:...1_:[..C]C and ....>B:..24_:[..G]G do not form a pair -- as is evident by using a Jmol or PyMOL. If you insist on getting 3DNA output involving this bp, you can manually modify the find_pair generated bp file as below:

sel.pdb
sel-all.out
    2         # duplex
   12         # number of base-pairs
    1    1    # explicit bp numbering/hetero atoms
    1   24
    2   23  0 #    1 | ....>A:...2_:[..G]G-----C[..C]:..23_:B<....  0.51  0.33  9.29  9.08 -3.37
    3   22  0 #    2 | ....>A:...3_:[..C]C-----G[..G]:..22_:B<....  1.01  0.90 38.28  8.76 -0.28
    4   21  0 #    3 | ....>A:...4_:[..G]G-----C[..C]:..21_:B<....  0.62  0.42  8.68  9.05 -3.12
    5   20  0 #    4 | ....>A:...5_:[..A]A-----T[..T]:..20_:B<....  0.34  0.07 24.63  9.03 -1.29
    6   19  0 #    5 | ....>A:...6_:[..A]A-----T[..T]:..19_:B<....  0.44  0.14 27.81  9.19 -2.88
    7   18  0 #    6 | ....>A:...7_:[..M]c-----G[..G]:..18_:B<....  0.60  0.39 16.09  8.90 -2.81
    8   17  0 #    7 | ....>A:...8_:[..G]G-----C[..C]:..17_:B<....  0.19  0.02 12.30  9.07 -4.15
    9   16  0 #    8 | ....>A:...9_:[..C]C-----G[..G]:..16_:B<....  0.50  0.35 15.49  9.12 -3.03
   10   15  0 #    9 | ....>A:..10_:[..G]G-----C[..C]:..15_:B<....  0.13  0.09 12.22  9.02 -4.07
   11   14  0 #   10 | ....>A:..11_:[..C]C-----G[..G]:..14_:B<....  0.49  0.40 12.81  9.03 -3.07
   12   13  0 #   11 | ....>A:..12_:[..G]G-----C[..C]:..13_:B<....  0.44  0.06 25.76  8.98 -3.15

Not the changes in red color.

HTH,

Xiang-Jun

1138

MD simulations / Re: issues with x3dna_ensemble

« on: June 04, 2013, 11:47:45 pm »

Yes, for one frame, you do not need to run x3dna_ensemble at all. The find_pair/analyze command combination is sufficient.

Xiang-Jun

1139

MD simulations / Re: issues with x3dna_ensemble

« on: June 04, 2013, 04:49:17 pm »

Hi Shyno,

Thanks for providing a detailed example with corresponding data files. Now things are clear.

If you run:

Code: [Select]

find_pair sel.pdb bpfile.dat
analyze bpfile.dat
x3dna_ensemble analyze -b bpfile.dat -p sel.pdb -o ensemble.out
x3dna_ensemble extract -p shift

The output file 'sel.out' contains the following section:

****************************************************************************
Local base-pair step parameters
    step       Shift     Slide      Rise      Tilt      Roll     Twist
   1 GC/GC      1.29      0.44      2.62      6.32     -3.86     31.01
   2 CG/CG     -1.11     -0.04      3.86     -6.40     14.10     35.74
   3 GA/TC      0.78     -0.30      3.57     -0.97      2.92     36.20
   4 AA/TT     -0.44     -0.77      3.48     -0.74      2.14     35.20
   5 Ac/GT      0.00      0.04      3.09      2.14      0.76     39.12
   6 cG/CG      0.68      0.41      3.21     -2.61     17.38     29.80
   7 GC/GC      0.40     -0.35      3.28     -0.47      0.89     32.94
   8 CG/CG     -0.64      0.39      3.04      3.76      9.39     29.46
   9 GC/GC     -0.36     -0.89      3.40     -6.53      1.69     37.52
  10 CG/CG      0.93     -0.64      3.45      2.40     10.67     32.12
          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      ave.      0.15     -0.17      3.30     -0.31      5.61     33.91
      s.d.      0.78      0.50      0.34      4.16      6.84      3.33

The shift parameters (extracted by command: x3dna_ensemble extract -p shift) are:

Code: [Select]

sel 1.29 -1.11 0.78 -0.44 0.00 0.68 0.40 -0.64 -0.36 0.93 Here the first column ('sel') is the name of the PDB file (without extension), and the next 10 columns are the shift values for the 10 dinucleotide steps. Since your pattern is very specific, it matches only one PDB file ('sel.pdb').

HTH,

Xiang-Jun

1140

MD simulations / Re: issues with x3dna_ensemble

« on: June 04, 2013, 11:49:44 am »

Thanks for your feedback. There are quite a few options in x3dna_ensemble analyze to make it flexible. Depending on your specific run, the output file may contain slightly different info. In your example for the shift parameter, it appears you have 10 structures (models/frames) corresponding to the 10 data columns.

Regarding the file cf_7methods.par, it contains 3DNA's implementation of seven analysis methods using the same base reference frame. The part of Curves may not be identical to that of Curves+, due to subtle differences in reference frames. But they should be directly comparable for Watson-Crick base pairs and steps. You can safely ignore cf_7methods.par, going for Curves+, or using 3DNA default.

As always, please provide a reproducible example to make your point unambiguous.

Xiang-Jun

 

1141

RNA structures (DSSR) / Re: Parsing the base pair identifiers - separating base type from base number

« on: June 03, 2013, 11:38:37 pm »

I've updated DSSR to beta-r11-on-20130603 which contains a new option --long-idstr to delineate fields of nucleotide id string. The format is:
 

model-number.chain-id.nucleotide-name.nt-sequence-number.insertion-code

It has five fields, and some of them (model number, insertion code) can be missing. For example, with the new option, B.U31/16 in 1d9h would become .B.U31.16..

I believe this DSSR update would fulfill your needs -- please verify and report back how it goes.

Xiang-Jun

Updated on 2013-06-18: the new format is:

model-number.seqid.chain-id.nt-name.nt-number.insertion-code

1142

MD simulations / Re: issues with x3dna_ensemble

« on: June 03, 2013, 09:57:51 pm »

• The mapping between bases and corresponding reference frame files is controlled by $X3DNA/config/baselist.dat, with modified bases in lower case. By default, the corresponding canonical vs modified base frames are identical, so whether putting
  M C or M c in baselist.dat (preferred) won't make a numerical difference in calculated parameters.
  
  Note that in 3DNA-analyze output, the top section provide the full detail to uniquely identify a nucleotide. So in later sections, only an one-char short-hand form is used.
  
  As noted in my post "Curves+ vs 3DNA", Curves+ has unique features unavailable from 3DNA. So users are encouraged to pick their favorite one or try both -- see "Building a bridge between Curves+ and 3DNA".
• The step parameters in ensemble.out are not taken bp_step.par, but they have strict correspondence; the serial number is used in ensemble.out for simplicity. Here again, you may find Curves+ more convenient.
• For definition of groove widths used in 3DNA, please see: M. A. El Hassan and C. R. Calladine (1998). "Two Distinct Modes of Protein-induced Bending in DNA.'' J. Mol. Biol., v282, pp331-343.

If you are interested in knowing 3DNA better, please try to reproduce the recipes reported in the 2008 3DNA Nature Protocols paper. Then the output of x3dna_ensemble would make more sense.

HTH,

Xiang-Jun

1143

General discussions (Q&As) / Re: Single stranded DNA simulation

« on: June 03, 2013, 09:19:49 pm »

With 3DNA, you can build a straight single-stranded DNA (ssDNA) of arbitrary sequence using fiber as shown below:

Code: [Select]

fiber -seq=aaatttt -single fb.pdb
or a sequence-dependent ssDNA structure by providing a sequence and associated step parameters.

Note that 3DNA's model building facility is purely geometry-based, employing base-pair parameters, and it takes no consideration of energetics. Overall, you may find 3DNA useful in certain aspects of  your project, and need to try other tools (e.g., NAB/AMBER etc from the Case lab) as well.

HTH,

Xiang-Jun

1144

MD simulations / Re: issues with x3dna_ensemble

« on: June 03, 2013, 12:32:07 pm »

Glad to see you have Ruby installed.

1. When I run the command "find_pair sample_md0.pdb bpfile.dat", the output file bpfile.dat is different from the one given initially. For example, this file has 13 base pairs as opposed to 12 base pairs in the initial file.I noticed you said this is ok in your post which I referred in the first message.

That's understandable. The point of creating a bpfile explicitly is to provide flexibility as to which bps to analyze. If you run find_pair on each frame of a MD trajectory, the identified bp info may be different.

2. I am assuming the sample_md0.pdb is generated from the initial frame of the trajectory. For example, I have a trajectory consisting of 5000 frames and I am analysing all frames except the first 999 frames. So in this case, the file equivalent to sample_md0.pdb, will be the pdb file  corresponding to 1000 frame.

The file 'sample_md0.pdb' is provided by a 3DNA user, and I've used it as a test case in developing the x3dna_ensemble script. The ensemble file contains 21 models (numbered 0,1,..20) delineated with MODEL/ENDMDL in PDB format. The content of the file is entirely up to you. The x3dna_ensemble script will analyze each model sequentially.

3. Now for the next step,
x3dna_ensemble analyze -b bpfile.dat -p 'pdbdir/model_*.pdb' -o ensemble.out
All the model_*.pdb files in the pdbdir are pdb files created for different frames (or timesteps)?
I am assuming this step works for just one frame also. Since my system contains water, and other ions, and I am writing a pdb file for each frame just selecting the dan alone.

You can put anything there. The post "Using Glob with Directories" may be helpful to you.

HTH

Xiang-Jun

1145

RNA structures (DSSR) / Re: Parsing the base pair identifiers - separating base type from base number

« on: May 31, 2013, 11:25:44 am »

Hi,

I am glad that you noticed this subtle point. Since the nucleotide is named U31, ending with digital numbers, it obviously would be confused with the residue number 16. That's why I decided to add a slash (/) in between. I will write a post on the details of nt id string in DSSR.

HTH,

Xiang-Jun

1146

RNA structures (DSSR) / Re: Parsing the base pair identifiers - separating base type from base number

« on: May 30, 2013, 08:39:47 pm »

Thanks for your kind words about DSSR.

Separating by chars vs. integers would be okay, but some alt. residues have numbers in them which makes it more difficult.

Could you provide some specific cases to make your point clearer?

Indeed, there are more complications in the nt identifier than the very simple case you mentioned. For example, model number and insertion code etc are also (need to be) considered in DSSR.

Is there any way you would want to add another separator for base type from base number?
Ex. "0.C_309" or the like?

I'd like to keep the default settings for DSSR simple/succinct, targeting more towards human apprehension than computer parsing. That said, I may consider to add an option to make the id string software friendly.

Xiang-Jun

1147

MD simulations / Re: issues with x3dna_ensemble

« on: May 30, 2013, 02:26:18 pm »

/usr/bin/env: ruby: No such file or directory

It seems you do not have Ruby installed on your machine. What happens if you issue the following command:

Code: [Select]

ruby
Xiang-Jun

1148

w3DNA -- web interface to 3DNA / Re: DNA bend angle calculation

« on: May 11, 2013, 07:58:36 am »

Okay. Now I see where the problem is.

HETATM 9998  XS    X X 999      68.227   2.641 -26.513
HETATM 9999  XE    X X 999      67.797  -2.012  34.748

Those pseudo HETATM records are just the two end points one helix passes through. As shown in the bending angle FAQ, The normalize helical axis is:

Helix:    -0.007  -0.076   0.997

So this section defines only ONE (1) helix. You need another relatively straight helical fragment to define a second helix in a similar fashion, then you can get the bending angle using the simple mathematical formula.

Read carefully the following paragraph from the FAQ on bending angle calculation, and repeat recipe #4 of the 2008 3DNA Nature Protocols should clarify your confusion.

With the two HETATM records, one can easily add them into the original PDB file to display the helical axis using a molecular graphics programs (e.g., RasMol, Jmol or PyMOL). Moreover, the two helix vectors can be used to reorient the original PDB structure into a view so that one helical fragment lies along the x-axis, and the other in the xy-plane. As documented in detail in recipes #4 on "Automatic identification of double-helical regions in a DNA–RNA junction" of the 2008 3DNA Nature Protocols paper, "The chosen view allows for easy visualization and protractor measurement of the overall bending angle between the two relatively straight helices."

Please report back in details how it goes. Based on your feedback, I will consider to refine the FAQ post to make it clearer.

Alternatively, you may want to try Curves+ which provides a more comprehensive bending analysis.

Xiang-Jun

1149

w3DNA -- web interface to 3DNA / Re: DNA bend angle calculation

« on: May 10, 2013, 12:27:35 pm »

Thanks for posting your question on the forum. I guess you are referring to the FAQ post "How to calculate DNA bending angle?".

we use the equation given below to solve the problem and we were unsuccessful. ...

Could you be specific on how you "were unsuccessful"? What vectors did you use and what result bending angle did you expect?

Xiang-Jun

1150

RNA structures (DSSR) / Re: list nucleotide/nucleotide contacts involving a phosphate group.

« on: May 07, 2013, 01:56:40 pm »

I am sure that some other things will have to be detected in RNA structures
and for that we really need the maximum of info and your software is a great tool for this.

Yes, other things can be detected in RNA structures, and DSSR has laid the basis (a framework) for more features to be built upon.

Thus, providing another output type seems a great option and I suggest
a roughly identical file format where in the first section only base base interactions are listed
and where base-backbone and backbone-backbone interactions appear in the "non-pairing interaction" list
which could be labeled more appropriately "Base-base and base-backbone interactions".

Okay, I will add a new option in DSSR beta r11 that puts all pair-wise nucleotide interactions (pairing or non-pairing, with various types of H-bond) in one file. Any suggestion for a name of the option? How about --pair-wise-nt-interactions? Note I am busying right now to meet a deadline, but should be able to get the proposed work done by next week.

Your proposed format is not that clear to me. As always, please use concrete examples to illustrate your point.

Xiang-Jun