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 Manual · G-quadruplexes · DSSR-Jmol · DSSR-PyMOL · DSSR Licensing · Video Overview· RNA Covers

Messages - xiangjun

Pages: 1 ... 59 60 [61] 62 63
Hi Mathew,

Thanks for your cooperation. I am aware of the xDNA story, and actually helped a 3DNA user on a modified purine a while ago. I need to dig it out -- it is buried in somewhere... Now you see the importance of this forum!

I am pretty occupied right now, but I will get back to you about your modified bases when I get time. Please check back in a week or so.


Thanks for adding the attachments -- now the problem becomes quite clear.

Your modified bases, with an additional benzene ring, are so different from the normal cases where the modifications are on the exocyclic atoms, or some of the base ring atoms,  that the mechanism provided with 3DNA (baselist.dat") is no longer applicable.

For example, for residue #3 (XTY, a modified pyrimidine) there is no "N1" atom but a "N" atom. Moreover, it is the C8 atom on the benzene ring that connects to the sugar, not the normal "N1" atom.

If you attach all of the modified Atomic_?.pdb files, I would like to look further: maybe I could make some modifications to the code to incorporate these dramatic changes.

Hope this clarifies the issue.


Hi Mathew,

Thanks for using 3DNA. As suggested, could you provide us a minimal reproducible example (using attachment) so others see clearly what's going wrong? I understand your description of the problem, but need more details to provide you a solution.


General discussions (Q&As) /
« on: November 17, 2007, 07:53:21 pm »
Hi Yurong,

3DNA uses a set of simple, pure geometric criteria, for locating all possible base-pairs and double helical regions. The helical regions are defined from a base-stacking prospective, thus continuous and quasi-continuous (or no backbone at all) helices are handled in exactly the same way. The detailed underlying algorithm will become clear when I find time to write a paper on it and get the work published. Before that happens, you can simply acknowledge 3DNA for your helical region findings.

Among the two parameters you listed (which are made explicit in 3DNA v2.0 to be released soon -- following a new publication on 3DNA), only "helix_break" is relevant here. The other one is a criterion to decide if the analyzed structure is strongly curved. It is used to decide if to ls-fit a helical axis, as shown in section "Global linear helical axis defined ...", and to calculate a set of global parameters.



General discussions (Q&As) /
« on: November 02, 2007, 01:10:21 am »
The two files you uploaded to the 3DNA server did help clarify the issue.

The negative Rise and strange tilt etc parameters are all related to the 6th G+G pair: the syn-G on strand I (X:...8_:[..G]G) has reversed "face" (base orientation) relative to others. The bp frame z-axis direction follows that of strand I base (the leading strand). Have a look at file "ref_frames.dat" following running the command (I am using "Ganti_Gsyn.pdb" as the PDB file name):
Code: [Select]
find_pair Ganti_Gsyn.pdb stdout | analyzeYou will see:
Code: [Select]
...     5 U-A ...
   27.5971    26.4873    48.4652  # origin
    0.7980    -0.6022     0.0226  # x-axis
   -0.5501    -0.7432    -0.3809  # y-axis
    0.2462     0.2915    -0.9243  # z-axis
...     6 G+G ...
   28.7994    26.9129    45.4857  # origin
    0.9194    -0.3494     0.1807  # x-axis
    0.2865     0.9096     0.3009  # y-axis
   -0.2695    -0.2249     0.9364  # z-axis
...     7 A-U ...
   31.2226    28.5432    44.1020  # origin
    0.0211    -0.9974     0.0687  # x-axis
   -0.9847    -0.0326    -0.1714  # y-axis
    0.1732    -0.0641    -0.9828  # z-axis
When two z-axes have opposite directions as in the cases here for the 5th UG/GA (a "blocview" generated structure is attached) and 6th GA/UG steps, the mean z-axis of the middle-frame is not well-defined, leading to the "strange" step parameters you noticed. Nevertheless, this set of parameters can still be used to rigorously rebuild the structure.

In such case, we could reverse the z-axis of the 6th G+G pair, making it pointing in the same direction as other bases along the strand. This will ensure that rise will be positive. However, there are some side-effects with this approach: for one thing, structure "rebuilding" won't work as before; secondly, when taking the 5th and 6th steps separately, there is an ambiguity as to which z-axis should be reversed. For these reasons, I prefer to keep the program as is.

Now if you think about it, the "strange" numbers are actually a good thing: it pinpoints the special structural features in this region, which is not directly comparable to other steps. As with any software tools, it is not just about getting the numbers, but most importantly understanding what the numbers really mean.

The "strange" numbers are directly tied to the choice of base-centered reference frame. The base-pair normal and RC8-YC6 based reference frame as used in SCHNAaP/CEHS (which follows NewHelix) is more intuitive. As a matter of fact, 3DNA also include a utility program "cehs" which calculates authentic SCHNAaP/CEHS parameters. Run it as follows:
Code: [Select]
find_pair Ganti_Gsyn.pdb stdout | cehsand check file "Ganti_Gsyn.outc".

For your structure, please also check the section titled "Global linear helical axis defined ..." from 3DNA "analyze" output. The global parameters based on C1'-C1' vectors make sense to me: it is these C1'-C1' vectors that show the periodicity, not being disturbed by the G+G pairs.



PS. The attached image was generated as follows:

Code: [Select]
find_pair Ganti_Gsyn.pdb stdout | analyze
ex_str -5 stacking.pdb s5.pdb
blocview -o -i=s5.png s5.pdb

General discussions (Q&As) /
« on: October 30, 2007, 08:37:53 pm »
Thanks for using 3DNA and posting your question at the forum.

Which version & commands are you using? Could you provide me a working example so I can reproduce your problem? As always, a minimal reproducible example is far more effective than general remarks.

At the base-pair level, 3DNA differentiates M-N vs M+N type pairs:

More generally, when the two bases (M and N) forming a pair have opposing faces, the scalar product of their z-axes is negative. 3DNA designates such pairs, e.g. Watson–Crick A–U, A–T and G–C pairs, as M–N with the ‘–’ symbol used to emphasize the opposing directions. If the M and N bases in a pair share the same face, such as in the Hoogsteen base pair in Figure 2b, the pair is recorded as M+N, with the ‘+’ symbol used to emphasize the similar directions of the bases.

At the dinucleotide step level, it also checks the z-axis directions to calculate reasonable parameters (as in a structure with B-Z junction, implemented in v2.0).

A negative rise is not expected for a reasonable helical structure. Before seeing your structure, however, I don't think I could provide you with a concrete explanation.


General discussions (Q&As) /
« on: October 28, 2007, 11:50:43 pm »
As Yurong pointed out, the "poc_haxis.r3d" file is produced when "analyze" finds the structure being analyzed is not "too curved" (check "misc_3dna.par" for default setting of the parameter). It corresponds directly to the "Global linear helical axis defined ..." section from the "analyze" main output file. It does not matter if the helical region is "quasi-continuous" or not.

To make it more concrete, here is an example:
Code: [Select]
find_pair bdl084.pdb stdout | analyzeYou will get file "poc_haxis.r3d" with contents as follows:
Code: [Select]
### Linear global helical axis if not strongly curved
#   17.536   25.713   25.665    9.424   12.911   15.677   -9.080    9.424    1.000    0.000    1.000
#   17.536   25.713   25.665    6.368   12.911   15.677   -9.080    6.368    1.000    0.000    1.000
#   17.536   25.713   25.665    5.849   12.911   15.677   -9.080    5.849    1.000    0.000    1.000
   17.536   25.713   25.665    0.060   12.911   15.677   -9.080    0.060    1.000    0.000    1.000
Check also the following section from "bdl084.out":
Code: [Select]
Global linear helical axis defined by equivalent C1' and RN9/YN1 atom pairs
Deviation from regular linear helix: 3.30(0.52)
Helix:    -0.127  -0.275  -0.953
HETATM 9998  XS    X X 999      17.536  25.713  25.665
HETATM 9999  XE    X X 999      12.911  15.677  -9.080
Average and standard deviation of helix radius:
      P: 9.42(0.82), O4': 6.37(0.85),  C1': 5.85(0.86)

BTW, the poc in file "poc_haxis.r3d" stands for P (phosphorus), O4', and C1' atoms.



General discussions (Q&As) /
« on: October 28, 2007, 11:31:37 pm »
Dear Baoqiang,

Thanks for using 3DNA and welcome to the forum!

In building a DNA (RNA) structure, the "rebuild" program first generates the base-pair structural unit based on bp parameters (propeller, buckle, etc) and then set the bp with reference to the middle bp frame. Have a look of the file "bp_step.par" following "analyze" to check the format (for v1.5, see file $X3DNA/Examples/Analyze_Rebuild/README). If no bp parameters are available, they are assumed to be zeros (see $X3DNA/Examples/Calladine_Drew/p56a.dat for an example).

Once the first bp is set w.r.t. to its middle frame, the step parameters (slide, roll etc) are applied, which defines the position and orientation of the 2nd bp.  As with the 1st bp, the 2nd bp needs to be constructed with corresponding bp parameters and set w.r.t. to its middle frame, This is repeated as many times as needed until the full structure is built. It  follows that the "rebuild" structure is always set w.r.t. the 1st bp reference frame.

For a more detailed description, please refer to the SCHNArP paper: 3DNA uses exactly the same procedure.



General discussions (Q&As) /
« on: October 09, 2007, 11:01:05 pm »
Hi Keven,

Thank  for reporting your explorations on the x-, y-, and z-axis direction convention adopted in the "ref_frames.dat" file generated with 3DNA.

Firstly, I like the clarity and completeness you pose this question: it serves as an example for most others to follow in asking questions, not only in the 3DNA forum, but also in a more general context.

Secondly, you are right in figuring out that
Quote from: "Keven"
the x-axis vector is composed of elements [a11, a12, a13]

As you can imagine, this feature is not documented (neither are many other features, as a matter of fact). From the very beginning, I had anticipated that some users would be able to take advantage of this file as they dig more deeply into 3DNA. In fact, this reference frame file is generated by several programs from 3DNA. It is mostly used internally by the utility "frame_mol", and I have never been asked for clarification. You are the first user (I know of) who has checked into such technical details.

Thirdly, as a response to your question, I have modified the source code of 3DNA  (for future release, v2.0) and the file now reads as follows:
Code: [Select]
...     1 C-G ...
   17.1274    25.9624    25.8783  # origin
   -0.9873     0.1544     0.0378  # x-axis
    0.1215     0.8864    -0.4467  # y-axis
   -0.1025    -0.4365    -0.8939  # z-axis

Does this clarify the issue? What text would you suggest to make its meaning more explicit?



General discussions (Q&As) /
« on: October 09, 2007, 10:32:25 pm »
Dear Janek,

Indeed, the following two steps have no bearings on the result. I put them here simply for illustration purpose: i.e., to see with RasMol how the base atoms rebuilt from 3DNA overlap with their original crystal structure counterparts when properly aligned. As shown in the 3DNA paper (2003 NAR), usually the RMSD would be less than 0.05 angstroms.
Code: [Select]
cat pd0001_mut.pdb pd0001_bp1.pdb > pd0001_cmb.pdb
rasmol pd0001_cmb.pdb
Another minor issue relates to the C1' atoms: it really does not matter whether to include them when you perform the mutations. I included them in my previous post simply because they was generated by default with 3DNA.

Cheers, and thanks for your efforts in polishing your recipe!

[hr:3ic50y69][/hr:3ic50y69][red:3ic50y69]Note[/red:3ic50y69] (added June 5, 2011):
[pre:3ic50y69]Please see the thread "change one base pair in a double-strand DNA structure file"
where the Perl script [mono:3ic50y69][red:3ic50y69]mutate_bp[/red:3ic50y69][/mono:3ic50y69] and the ANSI C program [mono:3ic50y69][red:3ic50y69]mutate_bases[/red:3ic50y69][/mono:3ic50y69] are introduced.[/pre:3ic50y69]

General discussions (Q&As) /
« on: October 08, 2007, 09:37:28 pm »
Hi Yurong,

Thanks for reporting the case: it is indeed a bug. I have fixed it and committed the change to the code base of 3DNA v2.0. Before I have the time to produce an updated binary of v2.0 for users to try out, you can simply ignore it, or set H-bonding distance cut-off to 3.5 A instead of 4.0 A with the "-p" option. I will let you know when I have a new compiled version for Linux/Mac OS X/Cygwin etc.

FYI, the bug was due to a very special case where a character string was not initialized. The program produced that garbage string where it should have been empty.

Keep in mind that, to me, the more bugs you report, the merrier! 3DNA becomes more robust by fixing bugs ...


General discussions (Q&As) /
« on: October 07, 2007, 03:26:24 pm »
Hi Janek,

Thanks for reporting back and giving a detailed account on how you get it done. You have provided the community a very useful working example from a user's prospective. This type of communication is what I value the most. Along the same line, I am hoping 'dnaserver' could follow your lead in getting back to 3DNA forum community.

To make it more accurate, your 4th step: running "frame_mol" with option "-1" is to re-orient the structure with reference to the first base-pair. This step is necessary because 3DNA rebuilt structure (from "rebuild") is always set w.r.t. to the first base-pair, and it has nothing to do with attaching local helical frames.
Quote from: "Janek Kosinski"
4. Run frame_mol to attach local helical frames and set the orientation of a structure.
frame_mol -1 ref_frames.dat 2oaaA.pdb 2oaaA_bp1.pdb

Properly aligning the original (crystal) structure and 3DNA rebuilt one is the essence of this method, and it is exactly the point of the following steps in my original post trying to illustrate.
Code: [Select]
rebuild -atomic bp_step_mut.par pd0001_mut.pdb
cat pd0001_mut.pdb pd0001_bp1.pdb > pd0001_cmb.pdb
rasmol pd0001_cmb.pdb

It would be helpful if you could revise your procedures slightly, and re-post   it, with necessary attachments, in the Users' Contributions section. Putting your recipe there will make it standing out so others can easily find it.

Once again, thanks for contributing back to the 3DNA forum!


General discussions (Q&As) /
« on: October 02, 2007, 10:29:01 pm »
Nice to see two questions in a row asking for the possibility of performing base mutations while keeping the backbone unchanged. Given this is such a common and clearly defined function, it is hard to imagine there is no such a handy standalone utility program from so many other resources to get the job done. Am I missing something here?

Even though no such a standalone program exists (yet) in 3DNA, this job is certainly doable with currently available tools in 3DNA, and in a conceptually very simple way. Indeed it is a case in my mind for quite some time. I will provide a new utility program, temporally named "mutate_bases" (anyone has suggestion for a better name?), which is very generic and easy to use in future release of 3DNA. For the time being, here is a working example to illustrate how this could be done in 3DNA. I am hoping either or both of you would be able to automate this job by writing a script and contribute it back to the community. Shorting of or in addition to that, please do share with the community on how the following recipe goes with your projects.

I am using pd0001.pdb,  the X-ray structure of the nucleosome core particle at 2.8 A solved by Luger. This structure is distributed with 3DNA, so you can easily access it.  I would like to mutate the 5th base-pair from A-T to G-C while keeping the DNA backbone conformation and protein untouched. This method is generic by allowing for multiple mutations and/or to a non Watson-Crick base-pair as well.

Code: [Select]
find_pair pd0001.pdb pd0001.inp
analyze pd0001.inp
frame_mol -1 ref_frames.dat pd0001.pdb pd0001_bp1.pdb

cp bp_step.par bp_step_mut.par
cp pd0001_bp1.pdb pd0001_mutok.pdb

# manually mutate the 5th bp from A-T to G-C in file 'bp_step_mut.par'; see attachment link below
rebuild -atomic bp_step_mut.par pd0001_mut.pdb
cat pd0001_mut.pdb pd0001_bp1.pdb > pd0001_cmb.pdb
rasmol pd0001_cmb.pdb

find_pair pd0001_mut.pdb pd0001_mut.inp

# for the 5th base-pair, compare 'pd0001.inp'
#  810 1093  0 #    5 | ....>I:...5_:[..A]A-----T[..T]:.288_:J<....  0.57  0.07 16.19  8.75 -3.48
# with 'pd0001_mut.inp'
#    5  288  0 #    5 | ....>A:...5_:[..G]G-----C[..C]:.288_:B<....  0.57  0.07 16.18  8.85 -3.48

# now manually replace coordinates of the BASE (including C1') in residue ....>I:...5_:[..A]A
# of file 'pd0001_mutok.pdb' with those from ....>A:...5_:[..G]G of file 'pd0001_mut.pdb'
# and similarly T[..T]:.288_:J< by C[..C]:.288_:B<



General discussions (Q&As) /
« on: September 24, 2007, 09:57:28 pm »
3DNA v2.0 is not released yet ... so you are ahead of others in trying out the Linux version. I will compile a Mac OS X and Windows Cygwin version in due time.


General discussions (Q&As) /
« on: September 24, 2007, 09:54:57 pm »
Hi Yurong,

Structure ar0062 (1zev) is sort of special in its handling of alternative location in ATOM or HETATM records. It is a crystal structure, yet the PDB format follows NMR ensemble by having two set of MODEL ... ENDMOL pairs, one for each alternative location (A and C). Normally, the alternative location is within a single PDB structure entry.

By design, the basic parts in 3DNA (find_pair/analyze etc) handles only a single structure. Here it corresponds to the first model, which happens to have A as indicator of its alternative location. By default, 3DNA recognizes "A1 " (e.g., A, 1, or  space) as alternative location.

To process the 2nd model, do the following:

Code: [Select]
ex_str -nmr -2 1zev.pdb 1zev_modelC.pdb
# change 'misc_3dna.par': "alt_list: C"
find_pair 1zev_modelC.pdb stdout



General discussions (Q&As) /
« on: September 24, 2007, 09:40:06 pm »
Thanks for using 3DNA!

Please refer to Lu et al A-DNA paper (J. Mol. Biol. 300, 819-840, 2000) on the definition of Zp. ZpH is similarly defined, but w.r.t. to the middle helical frame.

3DNA does not provide groove depth info (yet). Please refer to Curves for it. Also note the "-c" option of "find_pair" in 3DNA to generate input to Curves directly from a PDB file.

In the meantime, if you or anyone know of "a clear definition of groove depth", or better yet, with implementation, please do let me know. I am interested in adding groove depth parameters in future 3DNA release.



General discussions (Q&As) /
« on: September 22, 2007, 09:10:41 pm »
Of course, such a function is implemented in the 3DNA source code. However, please see FAQ #3.

There is no such a stand-alone program distributed with 3DNA. As you guessed, your best bet is to refer to the 3DNA user's manual for a detailed step-by-step example on how this is done in 3DNA. Following the procedure, it then should be a straightforward process to implement the algorithm in your favorite programming language.



General discussions (Q&As) /
« on: September 06, 2007, 11:55:42 pm »
Hi Kevin,

Thanks for using 3DNA and for your kind words regarding the 3DNA software! It has always been a pleasure to do something meaningful to myself and helpful to the community. Over the years, it is users like you that help move the project forward. So I always welcome any (technical) questions regarding various aspects of 3DNA.

Now back to your questions. Two issues need to be clarified.

Firstly, the base-pair reference frames as output from 3DNA are indeed as advertised for Watson-Crick base-pairs where the minor groove side of the two bases in a pair aligns (facing the same direction). Specifically, in such cases, x-axis points from minor groove side to the major groove side, and y-axis points to the leading strand, and z-axis completes a right-handed coordinate system and would point in the 5' to 3' direction of the leading strand. As always, this is best illustrated with an example, and I am using bdl084.pdb, which is distributed with 3DNA. Try to reproduce the following:

Code: [Select]
find_pair bdl084.pdb bdl084.inp
frame_mol -f ref_frames.dat frame.pdb frame.alc

block_atom bdl084.pdb
comb_str bdl084.alc frame.alc bdl084_frame.alc

rasmol -alchemy -noconnect bdl084_frame.alc

Please note that there is a bug w.r.t. displaying Alchemy file in RasMol 2.7.x. I've been using v2.6.4, the version directly from Roger Sayle, the original author of RasMol.

Secondly, when a pair is no-longer of Watson-Crick type, the minor groove side of the two bases in a pair could be in quite different relative orientation. In such cases, where would the minor groove side of the pair be? And this is where you noticed "the axes appear to be pointing in these strange directions". Check carefully the base-pair parameters from the 3DNA main output file, and you would see the point. The "strange directions" are actually not that strange in that they are also the "middle" base-pair frame, as in the Watson-Crick pairs.



General discussions (Q&As) /
« on: September 05, 2007, 01:05:43 am »
I do not think that I am in a position to provide any concrete suggestion on how to analyze the irregular nucleic acid structures from your MD simulation. Nevertheless, it would seem to push 3DNA (or any analyzing tool for that matter) too much trying to calculate base-pair parameters for a flipping out base or step parameters for a non-double helical region.

You could, however, calculate all the backbone and chi torsion angles, and sugar conformational parameters (with find_pair -s option). You can also generate a blocview image (blocview -d my.pdb) and display the block image with PyMOL (pymol t.r3d).

As with any software tool, the issue is not just about   calculating some numbers, but more importantly on understanding what the numbers really mean.



General discussions (Q&As) /
« on: August 22, 2007, 10:29:18 pm »

Thanks for using 3DNA. The number of local helical parameters should be ONE less than the number of base-pairs.

Note that helical parameters refer to a double helix region, and the smallest helix fragment is a dinucleotide step, which is one less than the number of bps. In 3DNA, the helical parameters for each dinucleotide step are defined symmetrically such that they are exactly the same for the two bps.

Hope this clarifies the issue a little bit.


PS. Please make use the file attachment facility -- it is a much better choice than enclosing a long file with your post.

General discussions (Q&As) /
« on: August 12, 2007, 11:41:23 pm »

So nice to see the first 3DNA user's contributed script in this forum! Two other users' contributions are given in the current 3DNA homepage.

To facilitate future such contributions from 3DNA users, I have created a specific section under the title "Users' Contributions". Could you please repost your script there so it is separated from this Q&A section?

You might also want to add attachments for your script, and ideally include a step-by-step sample case with all related files (PDB, .r3d, and image etc) so others can reproduce your result for verfication purpose.

Thanks for your contribution! And hopefully we will see more to come from other 3DNA users.


General discussions (Q&As) /
« on: August 04, 2007, 09:39:48 am »

Thanks for reporting the DNA residue name changes in the PDB. However, it would have been more helpful if you provide a concrete example, e.g., by giving the NDB or PDB id of an entry with such new names. Is this change only in NDB or PDB or both? Any link to the documentation for the changes?

What does you mean exactly "So now if we directly run 3DNA for current pdb files downloaded from pdb, it will clash"? Please provide a reproducible example step-by-step to show what error message you get.

Without knowing the details, I would guess that the issue is related to "unknown bases" to 3DNA, which was solved from the very beginning. Have you read the FAQ #7?


General discussions (Q&As) /
« on: July 30, 2007, 11:23:51 pm »
You use the Perl script "blocview" -- it calls Molscript, Raster3D, and ImageMagick, so you also need to have them installed (they are readily available from the internet).

Type "blocview -h" for help info, and check the script to understand how it works.

Once everything is properly installed, to get the image as in the NDB is trivial. E.g., for BD0054 (1jgr.pdb1), you just need to type:
Code: [Select]
blocview -i=BD0054.jpg 1jgr.pdb1
display BD0054.jpg
Code: [Select]
blocview -d 1jgr.pdb1
with a default image name "t.jpg"



General discussions (Q&As) /
« on: July 30, 2007, 12:48:15 am »

The chain color is controlled by file "col_chain.dat" under directory $X3DNA/BASEPARS in 3DNA v1.5. It is copied below:
Code: [Select]
# Coloring scheme for chains in "blocview" generated images.
# This list contains one-letter chain-ID and corresponding color name
#      which should be one of MolScript's 164 pre-defined names stored
#      in file "mcolname.dat". Otherwise, the default color corresponding
#      to "*" at the end is used.
# 0-9 are assigned the same color as A-J
# Users might change colors here or add new chains and their colors
A       red
B       yellow
C       yellow
D       cyan
E       blue
F       brown
G       violet
H       wheat
I       pink
J       bisque
K       khaki
L       magenta
M       peru
N       plum
O       green
P       tan
Q       tomato
R       orange
S       turquoise
T       salmon
U       blanchedalmond
V       firebrick
W       blueviolet
X       darkgreen
Y       darkturquoise
Z       orangered
0       red
1       yellow
2       lawngreen
3       cyan
4       blue
5       brown
6       violet
7       wheat
8       pink
9       bisque
*       goldenrod

# protein by_chain [default] or a specific color
protein   purple

# nucleic acid by_chain [default] or a specific color [coil_radius]
nucleic_acid    by_chain  0.8

The file BD0054 has chains A & B for DNA, PD0254 has chains B & C, so you should now understand the reason for the different coloring of DNA in these two structures (e.g., in the NDB website).

Simply change the color name for a specific chain to you liking will do the trick. You might want to copy the file "col_chain.dat" to your current working directory for local effect instead of changing it under $X3DNA/BASEPARS for global effect (see also ... #find_pair).



General discussions (Q&As) /
« on: July 25, 2007, 12:11:28 am »
The short answer is no -- currently no such option to output torsion angle in the range of [0, 360]. I picked up the range [-180, +180] because it is more natural to me. I vaguely remembered it is the standard in chemisty & biology, e.g., it is the way reported in the NDB.

You are actually the first user to ask this question. It is not a big deal to convert between the two, as you did with R or any (script) language.

I thus prefer to keep the torsion range as is in 3DNA. Of course, you are welcome to contribute your R script to be included in the users' corner.



Pages: 1 ... 59 60 [61] 62 63

Created and maintained by Dr. Xiang-Jun Lu [律祥俊] (
The Bussemaker Laboratory at the Department of Biological Sciences, Columbia University.