Messages

1476

General discussions (Q&As) / Re: triplex building

« on: September 02, 2010, 09:45:50 pm »

Hi Alpay,

Thanks for posing an interesting question which is, however, beyond 3DNA's current capability. The triplex fiber models with 3DNA are based on experimental data collected from literature, and they require fixed sequences. Are your purine-purine-pyrimidine (RRY) triplex models (AAT and GGC) regular?  If so, do you have the structure data of the corresponding triplet repeats, A.A.T and G.G.C, and how such triplets stack over one another (twist, rise)? I am always interested in extending 3DNA's capabilities to meet users' needs. You may also find NAB (Nucleic Acid Builder) from Dr. David Case's group useful.

Xiang-Jun

1477

General discussions (Q&As) / Re: What do numbers in *.inp files mean?

« on: August 26, 2010, 12:06:32 am »

Well, this is a clearly defined question with a concrete example  and I am in a unique position to answer it   .

Could you please tell me what all five numbers in "0.32 0.17 17.11 8.91 -0.83" exactly mean?

The content after the # sign is not documented because it was initially used for debugging purpose only. Since you asked, here is a brief account of what the five numbers mean, using your specified example with unit in () at the end:

• the distance between origins of the two base reference frames (0.32 Å).
• the vertical distance between the base planes, i.e., |stagger| (0.17 Å).
• the angle between the two base normals (17.11°).
• distance between RN9 and YN1 of the pair (8.91 Å).
• an empirical measure combining a few other quantities; for deciding if a pair should be included in a double helix (-0.83).

Overall, the first four numbers are for identifying a base pair, while the fifth number is for checking its inclusion/exclusion in a duplex.

Over the years, [mono:3bemt574]find_pair[/mono:3bemt574] has turned out to be an essential 3DNA application that makes analyzing nucleic acid structure straightforward.  See my blog post "What find_pair in 3DNA can do". As I've mentioned in several occasions, a detailed account of the underlying algorithm of  [mono:3bemt574]find_pair[/mono:3bemt574] has still to be written. I've been continuously refining [mono:3bemt574]find_pair[/mono:3bemt574] internally, and hopefully I will be able to write a paper on it in the not too distant future.

HTH,

Xiang-Jun

1478

General discussions (Q&As) / Re: Transformation of DNA keeping it's curvature constant

« on: August 24, 2010, 08:03:51 pm »

Thanks for your clarification. It is certainly clearer. However, I am still confused how one could make base-pair movement while "keeping absolutely constant the backbone shape". Are you trying to make rigid body transformation; i.e., moving bp1 to bp2 while keeping the internal structure (base + backbone) unchanged? As suggested in my previous post, a simple/concrete/reproducible example would make your point unambiguous.

At this point, I do not think 3DNA has direct support to what you presumably want to do. However, if I could have a clear understanding of your question, I may be able to help in a more concrete way. Of course, always keep your mind open and try to explore other available tools.

Xiang-Jun

1479

General discussions (Q&As) / Re: Transformation of DNA keeping it's curvature constant

« on: August 23, 2010, 10:35:56 pm »

Hi Mikhail,

Thanks for posting such an interesting question. As you guessed, the operation you'd like to make "may seem strange to some people". Indeed, I do not fully understand what you are trying to achieve, exactly. Could you use a simple, concrete example so others can see your point clearly? I am always interested in adapting 3DNA in ways that make sense to me and helpful to users like you.

Xiang-Jun

1480

General discussions (Q&As) / Re: Re:pdb problem in 3DNA

« on: August 12, 2010, 10:02:26 pm »

Dear Raman,

I was trying to use 3DNA web server for analyzing of the RNA double stranded (CCGCUGCGG)2 but the server seems not to recognize the file.

w3DNA works (or should work) for the most common/standard cases, but it is not that sophisticated yet. Technically, I am not involved in supporting w3DNA per se. See the section "w3DNA web server topics".

I am not able to figure out the error source. I think it might be some atom types are not recognized. I will appreciate if you can give me any insight into how I can modify the files for proper format for 3DNA. I have attached the pdb file.

Thanks for your attached file, the issue becomes clear: it is related to the 'non-standard' PDB format you use -- read carefully the "Coordinate Section" of the standard PDB documentation. For illustration purpose, here is an comparison of two ATOM records, one from your file, another in standard PDB format:

Code: [Select]

# 1st from your file; 2nd in standard format
ATOM     40  O3' C A    2      -6.273 -12.136   8.883  1.00  0.00           O  
ATOM     47  O3'  DC A   3      24.468  20.110  19.126  1.00 15.21           O  
What software package did you use to generate the pseudo-'PDB' file? There should be a utility for converting it to standard PDB format. It is easy to write an ad hoc script for converting as well, see the following Ruby script (note while it works in this case, it serves only as a starting point for further refinement):

Code: [Select]

File.open('cug_new_3_3_ok.pdb', 'w') do |aFile|
    File.open('cug_new_3_3.pdb').each_line do |line|
        if line =~ /^(ATOM|HETATM)/
            sb = line[0, 17] # upto atom name plus alt-loc
            resname, chain_id, resnum = line[17, 8].split
            se = line[26..-1]
            aFile.puts "%17s%3s %1s%4s %s" % [sb, resname, chain_id, resnum, se]
        else
            aFile.puts line
        end
    end
end
With the above script, [mono:2x0a5suh]find_pair[/mono:2x0a5suh] will get the following base-pairing info

Code: [Select]

   1   18  0 #    1 | ....>A:...1_:[..C]C-----G[..G]:..24_:B<....  0.58  0.24 21.25  8.84 -2.88
    2   17  0 #    2 | ....>A:...2_:[..C]C-----G[..G]:..23_:B<....  1.20  0.86 31.10  8.66 -0.52
    3   16  0 #    3 | ....>A:...3_:[..G]G-----C[..C]:..22_:B<....  1.54  1.27 25.83  8.63  0.37
    4   15  0 #    4 | ....>A:...4_:[..C]C-----G[..G]:..21_:B<....  0.21  0.06 44.98  8.77 -2.42
    5   14  0 #    5 | ....>A:...5_:[..U]U-*---U[..U]:..20_:B<....  2.89  1.60 22.74  8.20  6.22
    6   13  0 #    6 | ....>A:...6_:[..G]G-----C[..C]:..19_:B<....  0.84  0.67 23.53  8.88 -1.66
    7   12  0 #    7 | ....>A:...7_:[..C]C-----G[..G]:..18_:B<....  0.65  0.46 35.94  8.95 -1.64
    8   11  0 #    8 | ....>A:...8_:[..G]G-----C[..C]:..17_:B<....  0.21  0.14 25.89  8.78 -3.22
    9   10  0 #    9 | ....>A:...9_:[..G]G-----C[..C]:..16_:B<....  0.84  0.69 25.34  8.83 -1.50HTH,

Xiang-Jun

1481

General discussions (Q&As) / Re: bending angle of DNA

« on: August 05, 2010, 12:38:59 am »

Dear Ralf,

Thanks for posting a question which should be of general interest. Overall, a (bending) angle is defined by two vectors. For DNA bending angle, the question then becomes how the two (helical) axes are calculated. In 3DNA, if the input structure is not heavily curved, the following section is produced (using [mono:330yz4f2]355d/bdl084[/mono:330yz4f2] as an example):

[pre:330yz4f2]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)[/pre:330yz4f2]

If your structure is curved overall, but with two relatively straight fragments (via a kink), you will need to analyze the two segments separately to get the above information. With the two unit vectors (defined in Helix: line), it is straight forward to calculate the angle between them. Of course, another way to think of the issue is to fit a perfectly straight B-DNA fiber model onto each of the two relatively straight fragments, and calculate the angle between them. The two approaches should give comparable (but usually not identical results).

Several ago while at Rutgers, I helped Chen et al. (in Dr. Berman's group) analyzed some CAP-DNA complexes to quantify bending angles. I sense your case is similar to his. Please see: http://www.ncbi.nlm.nih.gov/pubmed/11724532 and http://www.ncbi.nlm.nih.gov/pubmed/11724533.

The DNA bending question has appeared quite a few times in the forum; you may find it helpful to check "Calculating the angle of DNA curvature".

Specifically, you may want to repeat 3DNA NP2008 paper, protocol (recipe) no. 4 on "Automatic identification of double-helical regions in a DNA–RNA junction", which provides detailed steps on calculating the angle between helices #1 and #3. Note also:

The chosen view allows for easy visualization and protractor measurement of the overall bending angle between the two relatively straight helices (the red horizontal helix h1 and the green vertical helix h3). This intuitive approach, initially developed to quantify the bending angles of a series of catabolic activator protein–DNA complexes67, yields sensible results when other methods fail.

HTH,

Xiang-Jun

1482

General discussions (Q&As) / Some details on PNAS98 DNA sequence-dependent deformability

« on: July 25, 2010, 11:54:58 am »

Recently I received a request from Mauricio, a graduate student from Dr. Olson's laboratory, for a technical question on generating the potential energy contour plots in the Olson et al. 1998 PNAS paper [PNAS98], "DNA sequence-dependent deformability deduced from protein–DNA crystal complexes." Then I vaguely remembered another PNAS98-related request from Dr. Olson several years ago, regarding details of data processing procedures.

PNAS98 is published a dozen years ago, and over the years it has made a big impact on the area of DNA-protein interactions, as evident by its over 400 citations. In retrospect, I was involved in the project mostly from a "technical" perspective: Andrey Gorin collected and analyzed (using CompDNA) the original DNA-protein complexes, and left the Olson lab before I came. I took over the project and performed further processing to generate all the table and figures used in PNAS98.

After publishing PNAS98, I have never done any follow up work regarding energetics of DNA-protein interactions. So all PNAS98-related files and scripts had been sleeping around, until I was contact by Dr. Olson in early 2006. It took me quite a while to dig them out, cleaned up and put them together. Four years later, now when Mauricio asks me a related question again, I tried to trace the emails I communicated with Dr. Olson on this matter. Unfortunately, my rutchem email account ceased to function from around summer 2006. So I have to check  backups from old machines I used ages ago ... It is from this time-consuming process (again) that I've decided to write this post to put together all PNAS98-related information I have collected, for the benefit of easy future reference.

The tarball PNAS98_Data.tar.gz contains the raw data I received from Gorin, and the scripts I used for further processing. See the included README.pdf and index.html for details. The Matlab script Ro_Tw_WKO.m was used to generate the ellipsoids contour plots of potential energies.  Around 1998, I think the version of Matlab I used was 5.x. Note that I do not have access to Matlab on my desktop nowadays.

For reasons detailed above, if you have further questions regarding PNAS98, please post them here instead of sending me emails, and I will try my best to answer them.

Xiang-Jun

1483

General discussions (Q&As) / Re: Methodology for sugar puckering calcualtion

« on: July 23, 2010, 07:34:52 pm »

The reference is: Altona, C. & Sundaralingam, M. (1972) "Conformational analysis of the sugar ring in nucleosides and nucleotides. A new description using the concept of pseudorotation." J. Am. Chem. Soc. 94, 8205-8212. See the SHCNAaP paper for further details; as mentioned in Section SCHNAaP/SCHNArP of the forum, [mono:2tedyoak]analyze[/mono:2tedyoak] in 3DNA is derived directly from SCHNAaP.

HTH,

Xiang-Jun

1484

General discussions (Q&As) / Re: analysis along the md trajectories

« on: July 21, 2010, 10:16:16 pm »

3DNA per se does not (yet) have direct support for the analysis of MD simulation of nucleic acid structures; mostly because of my unfamiliarity with AMBER or other MD packages, up to this point. So you have to extract each snapshot in PDB format to analyze each separately, as you would normally do for a NDB/PDB entry. With some (Perl/Python/Ruby) script, this should be a straightforward/efficient process, I guess.

From literature, I know that 3DNA is increasingly being used (mostly) with AMBER to analyze MD trajectories. It would be very helpful to hear from those who have hand-on experiences; is there anyone willing to share? As noted in my blog post "3DNA in the PCCP nucleic acid simulations themed issue", I am more than willing to offer my help to make MD users' life easier.

Xiang-Jun

1485

General discussions (Q&As) / Re: rotate_mol ambiguous orientations

« on: July 10, 2010, 01:20:53 pm »

Hi Pascal,

Here is another one. Thanks for taking care of it.

This GA pair provides me yet another great example to further refine [mono:ct3w1txr]rotate_mol[/mono:ct3w1txr]  to eliminate an ambiguity in specifying the orientation. Attached below is the properly orientated 671 GA pairs based on your file "GA_all.pdb":

[attachment=1:ct3w1txr]GA_all_set2_rotmol.png[/attachment:ct3w1txr]

Another one, hope it will come to an end or do you have to write a patch for each specific base pair?

This time, it is your fault  .  As shown in the figure below, "GA_bis_57.pdb" does not belong to the same class of base pair as represented by "GA_bis_1.pdb" (of 56 other examples). Running [mono:ct3w1txr]find_pair/analyze[/mono:ct3w1txr], you will immediately see that they have quite distinct base pair parameters; they certainly belong to different classes according to the Leontis-Westhof classification. Simply thinking of overlapping an AU Watson-Crick pair over an AU Hoogsteen pair -- do not expect to align them.

[attachment=2:ct3w1txr]GA_all_set2_rotmol.png[/attachment:ct3w1txr]

[hr:ct3w1txr][/hr:ct3w1txr]
Up to this point, I believe that your problem has been solved, from my understanding of the issue. Of course, do not be shy to show me further counterexamples  .

Xiang-Jun

1486

General discussions (Q&As) / Re: rotate_mol ambiguous orientations

« on: July 07, 2010, 10:27:50 pm »

Hi Pascal,

Yes, it works fine for the AC cWCWC base pairs I sent you. Many thanks for that.

Glad to see we are making progress.

Yet, unfortunately it"s not the end of the story.

That's completely understandable and well expected.

Here is another example with an ensemble of AC tHWC pairs, for which three orientations can be distinguished (see AC1, AC2, and AC42). Any clues ? Can rotate_mol provide a consistent orientation for all base pair types ? Again, many base pair types seem to be affected by this issue. Do you take into account the mass of the atoms and/or the C1' atoms with the base (-b) option ? Although this might not change a lot of things.

Your new set of example AC pairs provides me yet another opportunity to refine [mono:2ovkr65m]rotate_mol[/mono:2ovkr65m] to specify the orientation. See the following image generated with Jmol of the 107 AC pairs. Hope this solves your problem.

[attachment=0:2ovkr65m]AC_all_set2_rotmol_jmol.png[/attachment:2ovkr65m]
As always, have a try and report back how it goes. As time permits, I am willing to solve other related issues you may experience.

Xiang-Jun

1487

General discussions (Q&As) / Re: rotate_mol ambiguous orientations

« on: July 06, 2010, 12:04:50 am »

Dear Pascal,

Yet, I am not quite sure that its only a matter of positive and negative shear value. Here is another example for AC cWCWC pairs. AC1 and AC3 are oriented similarly, also they have positive and negative shear values while AC66 has a different orientation.

Nice follow-up with an even tricker example of AC pairs . All our previous discussions are still valid, especially Shear etc values with regard to AA pair (or other NN pairs, i.e., with the same type of nucleotide). Note that your three AC cases have the following base-pair parameters:

Code: [Select]

 bp            Shear    Stretch   Stagger    Buckle  Propeller  Opening
  AC1  1 A-C    -2.72     -0.48      0.14      2.60    -12.14     10.78
  AC3  1 A-C    -2.40     -0.35      0.15     -4.40     -8.70      9.47
AC66   1 A-C    -1.27     -0.46     -0.10     -2.06    -10.93      2.43As is clear, AC1 is more similar to AC3  than to AC66. That explains why "AC1 and AC3 are oriented similarly" but "AC66 has a different orientation."  Note also all three AC pairs have [red:1w2yfc0t]negative[/red:1w2yfc0t] Shear values.

Any clues since I do really not know how to solve this ? I join a pymol file that contains a superposition of about 150 similar AC cWCWC base pairs on which you can see some further ""misoriented"" base pairs.

I have refined [mono:1w2yfc0t]rotate_mol[/mono:1w2yfc0t] using your AC examples as a test case, so that now all the "150 similar AC cWCWC base pairs" are oriented as you would expected; see the attached figure below.

[attachment=0:1w2yfc0t]AC_all_rotmol.png[/attachment:1w2yfc0t]
Please have a try and report back how it goes -- there could be some other subtleties to check [mono:1w2yfc0t]rotate_mol[/mono:1w2yfc0t] against.

Xiang-Jun

1488

General discussions (Q&As) / Re: rotate_mol ambiguous orientations

« on: July 03, 2010, 11:24:14 pm »

Hi Pascal,

Yes it works as you say.

Glad to hear that it works.

The fact that spurious characters were present in the files originated from the fact that I used MSW to edit them when I transfered them from a linux to a mac (sorry about that). The original files do not contain these characters.

Thanks for sharing the background information about the issue related to the Mac 'r' line break character. It is actually a good thing that I have access to these two file so that I could refine 3DNA in future versions to handle such cases automatically. Remember, I always welcome concrete/reproducible examples that can show 3DNA's deficiencies so I can further improve it.

Although, using the -b option worked in the previous case, here is another example (which I should have sent you at the first) place of what is troubling me. Could you check this one ? Its an AA pair.

It really helps that you posted the issue with the GA pair first. The AA pair follows the same principle, but in a much subtler way. There is a directionality with AA pair, which is best seen using the base-pair parameters:

[pre:326fe38j]find_pair AAA.pdb stdout | analyze
#     bp        Shear    Stretch   Stagger    Buckle  Propeller  Opening
#    1 A-A     -6.15     -4.93     -0.22    -13.63     -5.09    -23.13

find_pair AA.pdb stdout | analyze
#     bp        Shear    Stretch   Stagger    Buckle  Propeller  Opening
#    1 A-A       6.12     -4.47      0.17      0.49     -6.69    -22.10[/pre:326fe38j]
As mentioned in the 2003 3DNA NAR paper, the [mono:326fe38j][yellow:326fe38j]M-N[/yellow:326fe38j][/mono:326fe38j] type pair (as is the case here, so are the A-T/G-C Watson-Crick base pairs) has the sign reversed for x-axis parameters (i.e., Shear and Buckle) if the order of the bases is reversed (i.e., [mono:326fe38j][yellow:326fe38j]N-M[/yellow:326fe38j][/mono:326fe38j]). Again, as documented in that paper, among the six base pair parameters,  Shear, Stretch and Opening are most discriminative of different types of base pairs.

Note that for AAA.pdb, the A-A pair has a negative Shear of [mono:326fe38j]-6.15[/mono:326fe38j] ångström, whilst the A-A pair in AA.pdb has positive [mono:326fe38j]+6.12[/mono:326fe38j] ångström. In such case, reverse the order of the two adenines in either PDB file (but keep the other file as is), and repeat the script from my previous post, you will get what you want (as shown below).

[attachment=0:326fe38j]A-Ar_rotmol_b.png[/attachment:326fe38j]

Given the above information, one could solve the orientation problem by writing a purpose-specific script to automate the above process.

Xiang-Jun

1489

General discussions (Q&As) / Re: rotate_mol ambiguous orientations

« on: July 03, 2010, 09:43:36 am »

Dear Pascal,

Thanks for providing an example of ambiguous orientations generated by the utility program "rotate_mol". For your two attached structures, "GA_1.pdb" and "GA_2.pdb", the default option "-b" does what you want:
[pre:1qwe6ej8]# GA_1.pdb and GA_2.pdb have Mac 'r' instead of 'n' as line separator
sed 's/r/n/gi' < GA_1.pdb > GA_1x.pdb
sed 's/r/n/gi' < GA_2.pdb > GA_2x.pdb

# -b is the default, thus can be ignored
rotate_mol -b GA_1x.pdb GA_1x_rotmol.pdb
rotate_mol -b GA_2x.pdb GA_2x_rotmol.pdb

# combined into a single PDB file
cat GA_1x_rotmol.pdb GA_2x_rotmol.pdb > GA_rotmol.pdb

# displayed with RasMol (note -nmrpdb option); see attached image
rasmol -nmrpdb GA_rotmol.pdb[/pre:1qwe6ej8][attachment=0:1qwe6ej8]GA_rotmol.png[/attachment:1qwe6ej8]
Does this solve your problem? Do you have more examples with the mis-orientation issue?

Xiang-Jun

1490

General discussions (Q&As) / Re: superimpose original structure with rebuilt structure

« on: June 30, 2010, 11:39:05 pm »

Dear Mike,

Thanks for sharing your knowledge of AMBER PDB format, which "which has designations for RNA that are distinct and differentiate terminal and internal residues".

Your series of commands produces full and rebuilt molecules with the same coordinate frame.

Glad to know that my command script works.

But the helix axis from the *.out file is still in a different coordinate frame. I need that axis for the fitting routine that uses this standard helix. I solved that problem simply by analyzing the rebuilt bases and getting the axes from that out file.

That's expected, and I am happy you have solved your the problem with helix axis.

Did you also notice that that parameters (in .out file) of the rebuilt structure are virtually identical to those from analyzing the original PDB file? This is another way to verify that the analyze/rebuild pair in 3DNA are rigorously defined and completely reversible.

Xiang-Jun

1491

General discussions (Q&As) / Re: superimpose original structure with rebuilt structure

« on: June 28, 2010, 10:50:53 pm »

Did you notice the "Upload attachment" tab below the post composition window? Simply click on it, and follow the instructions. Attachments, along with step-by-step instructions, are required to allow for reproducible examples.

Xiang-Jun

1492

General discussions (Q&As) / Re: superimpose original structure with rebuilt structure

« on: June 27, 2010, 07:58:24 pm »

Dear Mike,

There is some subtlety to "superimpose original structure with [3DNA] rebuilt structure". Your example serves to illustrate how to do it properly. In your original post:

Code: [Select]

find_pair bot_hlx.pdb stdout | analyze
cp bot_hlx.pdb bot_hlx.xse.pdb
grep HETATM bot_hlx.out >> bot_hlx.xse.pdb
rebuild -atomic bp_step.par bot_hlx.3dna.pdb
frame_mol -1 ref_frames.dat bot_hlx.xse.pdb bot_hlx2.xse.pdbYou do not need to bother with the "cp ..." and "grep ..." steps. Instead, you can achieve what you want simply as below:

Code: [Select]

find_pair bot_hlx.pdb stdout | analyze
frame_mol -1 ref_frames.dat bot_hlx.pdb bot_hlx_frame1.pdb
rebuild -atomic bp_step.par bot_hlx.3dna.pdbThen compare "bot_hlx_frame1.pdb" and "bot_hlx.3dna.pdb"; the coordinates for the base atoms would be very close. Have a try and report back how it goes. It would help if you have attached the example file "bot_hlx.pdb" so others can follow the steps.

Note that both analyze and rebuild generate the file "ref_frames.dat"; however, they are in different coordinate system.

Xiang-Jun

1493

General discussions (Q&As) / Re: Curves link

« on: June 27, 2010, 07:40:54 pm »

Dear Mike,

Thanks for pointing out the obsolete Curves link; I have made corrections in both 3DNA v1.5 and v2.0 websites to link to the new Curves+ program.

I am only hoping other 3DNA users could follow your lead to report any typos, bugs, broken links and make constructive suggestions. Working together, we can make 3DNA a better tool to serve the community.

Best regards,

Xiang-Jun

1494

General discussions (Q&As) / Re: relative phase of two helicies

« on: June 25, 2010, 11:46:19 pm »

Welcome to join the forum!

What is described by the three numers follwing "Helix:" in this section?

They are the direction cosines of the global linear helical axis, defined in the coordinate frame of the PDB file. Again, the point is best illustrated with an example. For 355d (bdl084), the portion from 3DNA analyze output is like this:

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.080The two HETATM records are the two ends point defining the helix; using octave (matlab), we have the following relation:

Code: [Select]

XE = [12.911  15.677  -9.080]
XS = [17.536  25.713  25.665]
dd = XE - XS             % [-4.625  -10.036  -34.745]
helix = dd / norm(dd)    % [-0.12685  -0.27526  -0.95296] which is ~ [-0.127  -0.275  -0.953]
Regarding DNA bending analysis, you may also want to play with Curves+ released by Dr. Lavery. As mentioned in my blog post, Curves+ vs 3DNA, Curves+ has features still lacking in 3DNA.

I am not sure how to get relativet twists (helical phases) of the two segments. I am considering fitting helices in a trajectory to a standard average helix and then compare the RN9/YN1 lines of the first base pair in each fit helix. Any better sugestions?

Could you be more specific, i.e., illustrated with an example what you want to achieve?

HTH,

Xiang-Jun

1495

General discussions (Q&As) / Re: Suggestions

« on: June 25, 2010, 08:15:19 pm »

Could find_pair be modified to recognize explicit ribonucleotide abreviations (RG,RA,RC,RU,RG5,...,RC3,...)? These are used by AMBER's ptraj and have to be substituted with single-letter base desigations before find_pair recognizes them.

I am not familiar with AMBER, but I guess RG is for G, RA is for A etc. So they fall into the FAQ entry How to handle modified (uncommon) bases?. Specifically, add the following into file baselist.dat:

Code: [Select]

RA    A
RG    G
RC    C
RU    U
RG5   G
RC3   CPlease verify.

Is it intended that when you enter "find_pair -h" the previous set of files from a find_pair analysis are erased?

Not necessarily "intended", but just the way it is: the file clean-up operation is performed before parsing the command line options. You are the first to raise this question; it indeed makes more logical sense to just show help information with the "-h" option and I will consider change this behavior in future version of 3DNA.

Thanks for making suggestions; please keep coming -- the more, the better.

Xiang-Jun

1496

General discussions (Q&As) / Re: 3DNA on a tablet PC

« on: June 08, 2010, 08:10:58 pm »

Hi Sophie,

Thanks for your interest in 3DNA. I do not have access to a tablet PC (10" screen) with windows 7. Your said the unit is "without a mouse or keyboard."  I am just wondering if there is any way to type in characters? I assume there must (at least) be a virtual keyboard to interact with it. If that's the case, then there are should be no problem in running 3DNA. You could have a try of the MinGW or Cygwin version.

Please let us know how it goes.

Xiang-Jun

1497

General discussions (Q&As) / Re: RNA strucuture analysis error

« on: May 26, 2010, 11:54:51 pm »

Dear Ouyang,

I am not familiar with Material Studio4.3 you used to generate the RNA structures. However,  thanks to your attached PDB file, I could check why 3DNA did not work. As is clear from the RasMol rendered image (attached below),  your RNA structure is heavily distorted.  To make my point even clearer, I extracted base-pair A51 vs U33 (coordinates attached) and rendered it with RasMol (also attached below): note the extra-erroneous connections in A, and the non-planar geometry of U. Moreover, the distance of N6(A)...O4(U) is 4.9 A, and N1(A)...N3(U) is 5.6 A.

Based on my experience, I would hardly take this as a valid pair at all. Still, if you define A51 and U33 in 'baselist.dat' and set H-bond distance cut-off to 5.0 A instead of the default 4.0 A in 'misc_3dna.par'

Code: [Select]

# Section 1: parameters defining H-bonding, in angstrom
#   primary H-bond
<hb_dist1>5.0</hb_dist1>A51 and U33 will still be identified as a pair:

Code: [Select]

   1    2  1 #    1 + ....>-:...0_:[A51]a-**--u[U33]:...0_:-<....  3.47  1.12 43.35 10.92  7.88
##### Base-pair criteria used:   5.00   0.00  15.00   2.50  65.00   4.50   7.50 [ O N]HTH,

Xiang-Jun

[attachment=2:1psgyjp7]ARNA-ms.png[/attachment:1psgyjp7]
[attachment=1:1psgyjp7]ARNA-bp1.png[/attachment:1psgyjp7][attachment=0:1psgyjp7]ARNA-bp1.pdb[/attachment:1psgyjp7]

1498

General discussions (Q&As) / Re: 3DNA published in Nature Protocols 2008

« on: May 25, 2010, 09:14:23 pm »

The citation to 3DNA [Nat Protoc. 2008;3(7):1213-27.] is correct.
See also http://www.ncbi.nlm.nih.gov/pubmed/18600227

Xiang-Jun

1499

General discussions (Q&As) / Re: 3DNA version 2.0

« on: April 28, 2010, 06:54:57 pm »

Welcome to join the forum! You (and every subscriber) are welcome to post any question that is related to the 3DNA software package, just remember to follow common-sense rules.

Xiang-Jun

1500

General discussions (Q&As) / Re: non planar base pairs

« on: April 17, 2010, 09:44:02 pm »

Hi Pascal,

This is clearly posed question.

In file "misc_3dna.par", there is the following section:

Code: [Select]

#   maximum angle between base normals (in range 0..90)
<max_plane_angle>65.0</max_plane_angle>In your specific case, setting the number from the default 65.0 degrees to 60.0 will solve your problem.

For more details, please see FAQ "How to fix missing (superfluous) base pairs identified by find_pair?"

[hr:2mhasqib][/hr:2mhasqib]
Furthermore, in our recent GpU paper (see also my blog post: "What's special about the GpU dinucleotide platform?"):

We chose the following set of stringent parameters to ensure that the geometry of each identified base pair is nearly planar and supports at least one inter-base H-bond: (i) a vertical distance (stagger) between base planes ≤1.5 Å; (ii) an angle between base normal vectors ≤30°; and (iii) a pair of nitrogen and/or oxygen base atoms at a distance ≤3.3 Å.

HTH,

Xiang-Jun