Messages

1141

General discussions (Q&As) /

« on: July 30, 2007, 12:48:15 am »

Hi,

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 http://rutchem.rutgers.edu/~xiangjun/3D ... #find_pair).

HTH,

Xiang-Jun

1142

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.

HTH,

Xiang-Jun

1143

General discussions (Q&As) /

« on: July 08, 2007, 10:51:31 am »

Good question!

The utility "blocview" was designed to generates a schematic image which combines base block representation with protein ribbon. The image has informative color coding for the nucleic acid part and is set in the "best-view" by default.

For the nucleic acid part, the "primary" object is the planar base rings which are simplified by corresponding rectangular blocks. Base-pairs are only secondary objects, abstracted at a higher level. Moreover, except for normal Watson-Crick base-pairs, there is an issue of how to represent the "faces" of a pair. Also, think of triplets and higher order base associations. Those are the rationales that "blocview" generates only a block representation for each individual base.

I did have the bp block issue in mind when I wrote 3DNA, and it is possible to generate bp blocks for normal Watson-Crick base-pairs with 3DNA v1.5. Using bdl084 as an example, try the following steps:

Code: [Select]

   blocview bdl084.pdb
    cp t.pdb bdl084_bv.pdb
    find_pair bdl084_bv.pdb stdout | analyze

    frame_mol -s ref_frames.dat bdl084_bv.alc

    alc2img -r -n bdl084_bv.alc bdl084_bp.r3d
    cat t.r3d bdl084_bp.r3d > bdl084_all.r3d
    render < bdl084_all.r3d > bdl084.avs

    convert -trim +repage -border 5 -bordercolor white bdl084.avs bdl084.jpg


The generated image is attached below. Knowing what you are doing and taking 3DNA as a toolkit, you should be able to get what you want in a script. A possible simple starting point is by modifying the "blocview" Perl script. You might want to have a try and possibly contribute back once you are happy with your script. Do not forget that there is a Users' Corner section in 3DNA homepage. With enough interest,  I might consider to add a new script in 3DNA v2.0

As a side note, the ".r3d" file "bdl084_all.r3d" can be fed into Pymol directly to generate photo-realistic quality images. Please also refer to another post in this forum for further example images. Of course, you might be aware that "blocview" generated images are used in the NDB, and as a nice surprise (to me), now also  used in the PDB!

HTH,

Xiang-Jun

1144

General discussions (Q&As) /

« on: July 01, 2007, 10:58:56 am »

Thanks for using 3DNA.

Firstly, a detour: you mentioned the "o1p_o2p" utility program which was designed to check for correct labelling of the O1P and O2P atoms of nucleotides in a PDB file. The utility was initially written when I noticed the incorrect O1P/O2P labelling problem in the NDB entry adh008 (9dna) used as a test case in the 3DNA distribution.

To my surprise, even as of today, the problem is still there in the NDB (adh008) and PDB (9dna). To make it concrete, here is the except from corresponding data files in PDB format:

NDB Asymmetric Unit coordinates

[pdb format, Unix compressed(.Z): pdb9dna.ent]:

Code: [Select]

ATOM     24  P     C A   2      35.309  46.286  11.717  1.00 28.71      9DNA  87
ATOM     25  O1P   C A   2      35.789  44.945  11.170  1.00 26.94      9DNA  88
ATOM     26  O2P   C A   2      36.213  47.108  12.492  1.00 25.98      9DNA  89[/list]

NDB Biological Unit coordinates

[pdb format: 9dna.pdb1]:

Code: [Select]

ATOM     20  P     C A   2      35.309  46.286  11.717  1.00 28.71           P  
ATOM     37  OP1   C A   2      36.213  47.108  12.492  1.00 25.98           O  
ATOM     38  OP2   C A   2      35.789  44.945  11.170  1.00 26.94           O  [/list]

PDB coordinates [

9DNA.pdb]:

Code: [Select]

ATOM     24  P     C A   2      35.309  46.286  11.717  1.00 28.71      9DNA  87
ATOM     25  O1P   C A   2      35.789  44.945  11.170  1.00 26.94      9DNA  88
ATOM     26  O2P   C A   2      36.213  47.108  12.492  1.00 25.98      9DNA  89[/list]
Have you noticed the inconsistencies?

I am impressed you cared to run "o1p_o2p" to check for the correct O1P/O2P labelling in your interested DNA structures. From my limited experience, I feel those days people are much more interested in solving problems of "grand importance". Yet, whenever checked seriously, even "simple" issues claimed to have been resolved for so many years still have left so many details to be worked out. From SCHNAaP and SCHNArP, to resolving the discrepancies, to 3DNA and its continuous support/further refinements over the years (in my spare time), I have been trying to solve one specific problem that apparently has made a much bigger impact than I originally expected ten years ago.

Now, to answer your question. As of 3DNA v1.5, the auxiliary.par file does not contain the O1P (and O2P for that matter) xyz coordinates w.r.t. the middle frame. I am getting that info into v2.0 which hopefully could be released in the near future.

In the meantime, please check the file "stacking.pdb" which contains all the info you asked and much more. Of course, you need to have some (script) programming skills to extract the info you need and be careful about other technical details such as residue numbering, and direction of middle frame etc. I would say it's well worth the efforts ...

HTH,

Xiang-Jun

1145

General discussions (Q&As) /

« on: June 15, 2007, 10:00:19 pm »

Firstly, please refer to a related post for background information.

More specifically, your DNA structures are too irregular to be recognized by "find_pair" as you would expect. The output file from "analyze" follows whatever base-pair information produced by "find_pair", and thus the "problems" your noticed. You could run "find_pair" to create an approximate starting input file and modify it accordingly as you see fit. The file format produced by "find_pair" is documented at the 3DNA homepage.

Also note that you can now add attachments to your post in this forum.

HTH,

Xiang-Jun

1146

General discussions (Q&As) /

« on: June 15, 2007, 09:49:09 pm »

As explained in my reply to your original question, what you now propose to do is perfectly fine. It is actually the preferred way for MD trajectories and NMR ensembles, where the DNA structure changes only in conformation not in its base-pairing. You can thus start with a representative structure to derive the correct pairing information with "find_pair" (and make manual changes where necessary), and you then need only to change the first two lines (PDB file and corresponding output file) of the input file to "analyze/cehs". Of course, this is best done automatically with a script.

The program "find_pair" makes analyzing nucleic acid structure so easy that people normally use it together with "analyze/cehs" as an integrated unit. As a matter of fact, "find_pair" has more functionalities (as another application, see SWS from Pascal Auffinger) than just providing input to the analysis routines, and it is best to think them as two separate entities.

Based on my experience, "find_pair" has been working really great for what it was designed for. Over the years, it has been refined and thus become more robust and sophisticated in the coming new release of 3DNA v2.0. At this time, I feel confident to say that whenever "find_pair" (and accordingly "analyze/cehs") produces some weird base-pairing results, it is because the nucleic acid structure is too distorted in the corresponding region(s). Whenever in doubt, it certainly helps to have a look of your structure using a molecular viewing program such as Rasmol/Pymol.

As always, we welcome users' feedback for specific cases where the algorithm could possibly be improved. That's why I asked you to send me some structures you felt that "find_pair" was not working as expected. To make life easier for future communications, I have installed the phpBB2 "Attachment Mod" for this forum. Please make good use of it!

HTH,

Xiang-Jun

1147

General discussions (Q&As) /

« on: June 13, 2007, 09:28:10 pm »

I do not know if I understand exactly what you mean. Why not post a specific (minimal) sample case to illustrate your point?

Also, I find it hard to read a sentence such as "its showng jst 3 residues and in some 4 nd lk wise." -- Maybe that's because English is not my native language? In some sense,   this post might help.

Thanks,

Xiang-Jun

1148

General discussions (Q&As) /

« on: May 16, 2007, 10:34:04 pm »

Thanks for using 3DNA! I am glad that you solved your two previous problems by browsing the forum -- that's exactly why the forum was created in the fist place.

While 3DNA is not a point-and-click package, setting it up should be straightforward and requires minimum effort, i.e., by setting the environment variable X3DNA and put $X3DNA/bin into your command line search path. To make life even easier for inexperienced Linux/Unix users, I have created a Perl script (setup_x3dna) to detect the SHELL and set up these two items automatically -- it will be included in the coming new release.

Now come to your question. The main output file name is derived from your PDB file by changing to (or appending) the ".out" extension. It will be in the same directory as your PDB structure file. Have a look at .inp file -- the 2nd line will tell you where the .out resides. Now I notice a bit of inconsistency here -- all other files are written in the current working directory (CWD), but this .out file is not. Maybe it is more logical to put the .out file in the CWD as well. I will make this change into the new release of 3DNA.

HTH,

Xiang-Jun

1149

General discussions (Q&As) /

« on: May 08, 2007, 10:06:40 pm »

Hi Whitney,

I deliberately skipped the details on calculating bp-reference frame when writing that part of the manual for two reasons: (1) it is identical to the procedure used for the step "middle-frame"; (2) it gives serious users like you an opportunity to figure it out (normal users won't bother tech part anyway). In my experience, this is the best way to have a clear understanding of the mathematics under 3DNA -- which is actually quite simple.

For your verification, the bp frame origin is the direct average of the two bases forming the pair. The bp z-axis is actually the averaged and normalized vector of the two base z-axes. This is not the case for bp x- and y-axes.

Code: [Select]

AG1_o = [15.1632 -0.0362 -4.4678]
AG1_z = [-0.4004 0.4012 0.8238]

BC8_o = [14.9124 0.2803 -4.7498]
BC8_z = [-0.3422 0.5326 0.7741]

bp_o = mean([AG1_o; BC8_o])
         % ====> 15.03780    0.12205   -4.60880

zave = mean([AG1_z; BC8_z])
         % =====> -0.37130   0.46690   0.79895
bp_z = zave / norm(zave)
         % =====> -0.37239   0.46826   0.80128

stagger = dot(AG1_o - BC8_o, bp_z)
         % =====> -0.015638


I am using Matlab (octave) syntax for illustration. In 3DNA, the bp z-axis is calculated along with bp x- and y-axes after symmetrically rotating the two base frames along the buckle-propeller hinge axis. Please have a try and hopefully you would post back step-by-step how you proceed to clarify your own understanding and for the benefit of other 3DNA users.

HTH,

Xiang-Jun

1150

General discussions (Q&As) /

« on: April 16, 2007, 09:50:13 pm »

"find_pair" generates an input file in text format that you can edit to suit your specific need before feeding into "analyze" (or "cehs").

Just imagine the situation without access to "find_pair": how would you prepare (from a nucleic acid containing structure in PDB format) an input file for an analysis program such as Curves etc?

In the 3DNA homepage, I have also maintained a list of citations to 3DNA compiled from Web of Science. It is not  necessarily complete, but could serve as a good starting point to related published work.

So far, I've been the only person in answering questions in the forum. That's fine as a starting point. In the long run, I do hope other colleagues would get more actively involved: not only in asking questions, but also in answering them; moreover, in sharing your experiences, or contributing scripts/programs etc. Your contribution can make a difference!

HTH,

Xiang-Jun

1151

General discussions (Q&As) /

« on: April 13, 2007, 10:02:55 pm »

Hi,

Please check carefully the PDB file format. As I understand it, REMARK 210 contains info about which one is the best representative structure in an NMR ensemble, which is used by "ex_str". If no such info is available, or the PDB is somehow inconsistent for certain entry, the first structure is extracted. That's exactly what my previous message is about. It also contains some example PDB entries that you can verify. These were the samples I tested when adding such functionality in "ex_str".

A better understanding of the PDB format would certainly help. In any event, you can always check the PDB file itself to see what's in there -- it is a text file anyway.

Hope this clarifies the issue a little bit.

Xiang-Jun

1152

General discussions (Q&As) /

« on: April 12, 2007, 09:16:19 pm »

Hi,

Please down the 3DNA v1.5 from its homepage. The Linux version, as I checked it just a moment ago, has the content of file "misc_3dna.par" as follows:

Code: [Select]

4.0 0.0 ON A1 # upper H-bond length limits/atoms, alternative location
15.0          # max. distance between paired base origins (FIND_PAIR)
2.5           # max. vertical distance between paired base origins (FIND_PAIR)
65.0          # max. angle between paired bases [0-90] (FIND_PAIR)
4.5           # MIN. distance between RN9/YN1 atoms (FIND_PAIR)
7.5           # max. distance criterion for helix break (FIND_PAIR)
0.6           # r7 criterion to decide if a helix is curved
3.2           # r8 H-bond distance for water molecules with base N/O atoms
4.5           # r9 maximum O3'--P distance for linkage (REBUILD)


So it seems you are using an earlier version.

HTH,

Xiang-Jun

1153

General discussions (Q&As) /

« on: April 12, 2007, 12:21:05 am »

Hi,

There is a default cut-off threshold (0.6) used in 3DNA to decide if a structure is too curved to calculate the global parameters based on C1'-C1' vector. It is defined in the file "misc_3dna.par" (under directory $X3DNA/BASEPARS) on the 7th line -- increase the value (based on your data) will make 3DNA output the parameters you request.

Needless to say, the file "misc_3dna.par" is a bit cryptic -- the parameters were added while 3DNA was under actively development. In the coming new release of 3DNA v2.0, the file is much easer to understand, as show below.

Code: [Select]

# Section 4: is this double helix curved?
std_curved: 0.6         # criterion to decide if a helix is curved (0.6)

HTH,

Xiang-Jun

1154

General discussions (Q&As) / Re: TA-DNA dataset

« on: April 10, 2007, 08:56:56 pm »

This question has popped up a few times. Now with this forum, I do not need to repeat myself, but refer you to the thread "DNA standards/statistics using 3DNA", which contains a detailed list of the TA-DNA dataset used in the 2003 NAR 3DNA paper.

HTH,

Xiang-Jun

1155

General discussions (Q&As) /

« on: April 09, 2007, 11:38:36 pm »

Hi,

The following is taken directly from the C-source code comment:

Code: [Select]

/* Best representative NMR conformer, use #1 if not assigned in REMARK 210.
 * Typical cases:
 *    BEST REPRESENTATIVE CONFORMER IN THIS ENSEMBLE : NULL [pdb28sp]
 *    BEST REPRESENTATIVE CONFORMER IN THIS ENSEMBLE : 1    [pdb2bj2]
 *    BEST REPRESENTATIVE CONFORMER IN THIS ENSEMBLE : 3    [pdb2lef]
 *    BEST REPRESENTATIVE CONFORMER IN THIS ENSEMBLE : 5    [pdb3php]
 *
 * For structures pdb1qby, pdb1djd & pdb1bjd, the REMARK 210 says the
 *    best representative conformer is #12 or #13, but the data file
 *    actually does not has that model. Reset inum to 1 for such cases.
 */
HTH,

Xiang-Jun