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 · G-quadruplexes · DSSR-Jmol · DSSR-PyMOL · Video Overview · DSSR v2.9.3 (DSSR Manual) · Homepage

Messages - xiangjun

Pages: 1 ... 44 45 [46] 47 48 ... 67
1126
Message taken -- I'll get DSSR updated by early next week.

Enjoy the weekend!

Xiang-Jun

1127
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

1128
Quote
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.

Quote
  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

1129
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

1130
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


1131
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

1132
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

1133
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

1134
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

1135
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

1136
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

 

1137
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

1138
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

1139
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

1140
MD simulations / Re: issues with x3dna_ensemble
« on: June 03, 2013, 12:32:07 pm »
Glad to see you have Ruby installed.

Quote
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.

Quote
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.

Quote
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

1141
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

1142
Thanks for your kind words about DSSR.

Quote
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.

Quote
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

1143
MD simulations / Re: issues with x3dna_ensemble
« on: May 30, 2013, 02:26:18 pm »
Quote
/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

1144
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.

Quote
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:
Quote
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.
Quote from: the bending angle FAQ
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

1145
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?".

Quote
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

1146
Quote
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.

Quote
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

1147
Hi Pascal,

Thanks for your followup. Overall, I do not intend to make changes as you suggested.

The newly-added non-pairing interactions (H-bonds and base-stacking) are for the cases where the two bases are not paired (as defined by 3DNA/DSSR). The base-pair section contains information related to the two nucleotides, thus all existent H-bonds, be it base to base, base to sugar, base to phosphate, or sugar to phosphate. The GpU story started from the identification of the sugar-phosphate O2'(G)...O2P(U) H-bond, which until then had been ignored by the community: see "What's special about the GpU dinucleotide platform?" and "Is the O2′(G)...O2P(U) H-bond in GpU platforms real?".

To get what you want, please consider to write a parser that combines the two DSSR sections. Also note that the H-bond identification algorithm in 3DNA/DSSR may not be that sophisticated (it is unpublished/undocumented) -- I've added this functionality mainly to make 3DNA/DSSR self-contained, i.e., without relying on third-party tools. For your purpose, you may well find dedicated tools more appropriate.

Alternatively, as a collaborative project, I could add a special option or write a parser, if you provide me with a detailed specification with examples.

HTH,

Xiang-Jun

1148
General discussions (Q&As) / Re: possible rotate_mol labeling issue
« on: May 02, 2013, 02:04:27 pm »
Hi Pascal,

I've updated 3DNA v2.1 to 2013may02 where rotate_mol and frame_mol would preserve atom/residue names in the original PDB file. Please have a try, and report back if that fits your needs.

Xiang-Jun

1149
RNA structures (DSSR) / Re: Rendering Images of RNA
« on: May 01, 2013, 10:04:33 pm »
Hi Pablo Arantes,

Here are the details I used to generate the 1msy schematic image with texture on ribbon. I am using PyMOL v1.5.0.3 on Mac OS X, and 3DNA v2.1 as currently downloadable from the site.

Code: [Select]
# download 1msy.pdb from RCSB PDB; note the -r option to specify the output file "1msy.r3d"
blocview -r 1msy.r3d 1msy.pdb

# run pymol from command line with script "1msy.pml" (see below)
pymol -qc 1msy.pml

The content of "1msy.pml" (also attached) is as below:
Code: [Select]
load 1msy.r3d
bg_color white
set depth_cue=0
set ray_trace_fog=0
ray 1200,1200
png 1msy.png, dpi=300

Here are the three attachments: 1msy.r3d; 1msy.pml; 1msy.png

As you see, I've done nothing special with PyMOL rendering to get the 'texture'. I'm interested in knowing why you're not having it. Maybe it is related to some PyMOL settings.

Xiang-Jun

1150
RNA structures (DSSR) / Re: Rendering Images of RNA
« on: April 30, 2013, 09:14:06 pm »
Hi Pablo Arantes,

Thanks for trying out DSSR and your kind words about it! Note that DSSR is still in beta, and I welcome user feedbacks to guide further refinements of the software.

Regarding the texture on ribbon rendered with PyMOL, I understand what you mean from the attached figures. I honestly do not know how it comes out that way when a blocview generated .r3d file in fed into PyMOL -- I've actually thought that it is an artifact!

I will try to reproduce the 1msy schematic image with texture in ribbon, and post back details for your reference (hopefully by tomorrow).

Xiang-Jun

Pages: 1 ... 44 45 [46] 47 48 ... 67

Funded by the NIH R24GM153869 grant on X3DNA-DSSR, an NIGMS National Resource for Structural Bioinformatics of Nucleic Acids

Created and maintained by Dr. Xiang-Jun Lu, Department of Biological Sciences, Columbia University