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 · Web-DSSR · DSSR Manual · Reproduce DSSR · DSSR-Jmol · DSSR-PyMOL · Web-SNAP

Messages - xiangjun

Pages: 1 ... 75 76 [77] 78 79 80
1141
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!

Xiang-Jun
[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]

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

Xiang-Jun

1143
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!

Xiang-Jun

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

HTH,

Xiang-Jun

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

Xiang-Jun

1146
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

HTH,

Xiang-Jun

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

HTH,

Xiang-Jun

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

HTH,

Xiang-Jun

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

HTH,

Xiang-Jun

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

HTH,

Xiang-Jun

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

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.

Xiang-Jun

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

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

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.

Xiang-Jun

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

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?

Xiang-Jun

1154
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
or
Code: [Select]
blocview -d 1jgr.pdb1
with a default image name "t.jpg"

HTH,

Xiang-Jun

1155
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

Pages: 1 ... 75 76 [77] 78 79 80

Created and maintained by Dr. Xiang-Jun Lu [律祥俊], Principal Investigator of the NIH grant R01GM096889
Dr. Lu is currently affiliated with the Bussemaker Laboratory at the Department of Biological Sciences, Columbia University.