Messages

1376

General discussions (Q&As) / Re: Re:stacking diagrm

« on: November 06, 2010, 08:03:17 pm »

Hi Raman,

Thanks for posting questions related to stacking diagrams. You are actually the first to ask such details, and the documentation is sketchy, thus no wonder you "couldn't locate it".

How we can generate different color diagram other than the default

Assuming you are using 3DNA v2.0, the config files are stored in the [mono:24t3qvd3]$X3DNA/config[/mono:24t3qvd3] directory, named [mono:24t3qvd3]ps_image.par[/mono:24t3qvd3], [mono:24t3qvd3]fig_image.par[/mono:24t3qvd3] and [mono:24t3qvd3]raster3d.par[/mono:24t3qvd3]  for PostScript, Xfig, and Raster3D formats, respectively. They are pure ASCII text files and should not be that difficult to follow. You may  copy a chosen-format-config file to a local directory for the stacking diagrams and tweak it as you see fit. Note the format is rigid -- make your change by directly overwriting the default one. [See FAQ http://3dna.rutgers.edu/x3dna/faqs#find_pair on local vs global effects for a config file.]

how one can hide hydrogen atoms in the generated stacking diagram.

You can run "[mono:24t3qvd3]get_part -d[/mono:24t3qvd3]" to remove H atoms first, and then feed the resulting PDB file to [mono:24t3qvd3]stack2img[/mono:24t3qvd3].

[hr:24t3qvd3][/hr:24t3qvd3]
Needless to say, the above-outlined procedures are not that user-friendly. However, they should work as expected, and allow for reproducible results with a script. Given an opportunity, I'd make the config file more flexible in future versions of 3DNA.

Have a try and report back if you have any problem.

Xiang-Jun

1377

General discussions (Q&As) / Re: Rebuild from sugar-phosphate backbone

« on: October 30, 2010, 08:56:41 pm »

As far as I understood, "rebuild" builds structure from base parameters. So you wrote in your blog "The structural parameters can be used to rebuild the structure, which is virtually identical in base geometry (i.e., without taking consideration of the sugar-phosphate backbone) to the original structure"

Yes, as shown in Table 3 of the 2003 3DNA NAR papers, and the corresponding examples in the directory [mono:3i9kwmym]$X3DNA/examples/analyze_rebuild/[/mono:3i9kwmym].

Tell me please, is it possible somehow to rebuild structure using only sequence and sugar-phosphate backbone parameters? I.e. without time-consuming minimization to define approximately Calladine parameters for each nucleotide pair of a given sequence, having only backbone?

No, as far as 3DNA is concerned. Also, what do you mean exactly by "sugar-phosphate backbone parameters"?
[hr:3i9kwmym][/hr:3i9kwmym]
Please note that the 3DNA [mono:3i9kwmym]analyze/rebuild[/mono:3i9kwmym] pair is purely geometry-based, without any "time-consuming minimization" involved. Building a DNA structure with or without the sugar-phosphate backbone should be (virtually) equally efficient.

HTH,

Xiang-Jun

1378

General discussions (Q&As) / Re: How to make a nice visualization for angle distribution?

« on: October 12, 2010, 11:30:56 pm »

Thanks for your interest in my GpU paper. I am glad that your find Fig 1C "a very nice representation for plotting the histogram of angle".

Per your request, here is the detailed step-by-step procedure I originally used to generate Fig 1C, up to the "raw" histogram of the phase angle of sugar ring pseudorotation.

• The data file named "key_pars_gu193.txt" is attached. It contains the phase angle of pseudorotation of the U and G sugar rings.
  
• The following R script is used to generate the "raw" figure (attached).
  Code: [Select]
  library("circular")

pdat <- read.delim("key_pars_gu193.txt")
attach(pdat)

xfig(file="sugar_raw.fig", onefile=TRUE)
par(mfrow = c(1,2))
plot(circular(p1, units="degrees", rotation="clock"), zero=pi/2,
     stack=TRUE, bins=150, shrink=1.5)
plot(circular(p2, units="degrees", rotation="clock"), zero=pi/2,
     stack=TRUE, bins=150, shrink=1.5)
par(mfrow = c(1,1))
dev.off()
Please note the followings:
  • The R 'circular' package is used (http://cran.r-project.org/web/packages/ ... index.html)
  • The xfig (http://www.xfig.org/) output device is used for later manually editing (not data points, but only cosmetic styles, of course) of the generated figure.
   

[attachment=1:1vq0n9no]key_pars_gu193.txt[/attachment:1vq0n9no]
[attachment=0:1vq0n9no]sugar_raw.png[/attachment:1vq0n9no]
HTH,

Xiang-Jun

1379

General discussions (Q&As) / Re: DNA Structure prediction with a heteroatom !

« on: October 10, 2010, 10:34:26 pm »

Thanks for using 3DNA and your kind words about it.

But, I'm interested to build the 3D structure of the DNA with a heteroatom which is a dye in my case. Can 3DNA be used to accomplish the task ? We have a NMR structure of the DNA with the dye but thats 20 mer. Is there a way to cut n paste the dye to the predicted 30 mer from the NMR using any tool ?

If I understand it correctly/clearly, I do not think 3DNA can be applied directly for your purpose. However, if you are very specific as to what you have tried, what problem you have experienced and what you'd like to achieve, others and I may help you more concretely. For one thing, I am interested in expanding 3DNA's capability for model building.

Other tools you may try include coot and NAB -- I have not used either of them, but I have heard of them mentioned quite a bit.

Xiang-Jun

1380

General discussions (Q&As) / Re: Global Helical Axis Information Missing

« on: September 24, 2010, 08:12:47 pm »

...so I tried changing the parameter from 0.6 to 2.0 but I am still unable to obtain the values for the helical axis. Does this mean that I should also change other parameters?

You've identified a bug in 3DNA v2.0  , so a big thank you! No other parameters need to be changed.

Technically, the bug is related to the tag [mono:hqpg41e9]"std_curved"[/mono:hqpg41e9] match; in the source code, it was mistaken as [mono:hqpg41e9]"std_curved "[/mono:hqpg41e9], i.e., with an extra space in the end. I've fixed this bug in the source; so the next release of 3DNA won't have this issue. As a temporary work around, simply add a suffix space in the tag, as below and it will work as expected:

Code: [Select]

<std_curved >0.6</std_curved >   # add a space in the end!As a side note, v1.5 does not have this bug.

HTH,

Xiang-Jun
[hr:hqpg41e9][/hr:hqpg41e9]
PS. As always, the more bugs reported, the merrier ! In future release of 3DNA, I will also add an acknowledgement list.

1381

General discussions (Q&As) / Re: Global Helical Axis Information Missing

« on: September 23, 2010, 09:57:20 pm »

That's because 1E3M is curved, thus fitting a global linear helical axis would be meaningless. More specifically, the section:

Code: [Select]

Global linear helical axis defined by equivalent C1' and RN9/YN1 atom pairs                    
Deviation from regular linear helix: 3.04(1.34)
shows a "deviation" of 1.34, which is larger than the default cutoff of 0.6, as defined in file 'misc_3dna.par'.

Code: [Select]

# Section 4: is this double helix curved?
#   criterion to decide if a helix is strongly curved.
#   if relatively straight, 'analyze' will output a set of
#   global parameters, the normalized axis vector, and the
#   two end points the helical axis passes through
<std_curved>0.6</std_curved>
HTH,

Xiang-Jun

1382

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

« on: September 17, 2010, 10:34:42 pm »

Hi Alpay,

You may find it helpful to have a look of the recently published article "Designing Triple Helical Fragments: The Crystal Structure of the Undecamer d(TGGCCTTAAGG) Mimicking T.AT Base Triplets" by Van Hecke et al in Cryst. Growth Des. (DOI: 10.1021/cg1009048).

Xiang-Jun

1383

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

« on: September 11, 2010, 12:13:12 am »

135D and 136D pdb structures do have the GGC triplex with GG base pair step similar to my repeat. May be that is a good place to start.

I had a quick look of 135D/136D and senses that the GGC triplet could serve a good starting point.

A simple way I can think of is: build B-DNA helix of 5 GAG repeats. cp the file, separate the the strands in one file and than dock the single strand on the double helix. I am going to be working this angle as well. ( as soon as I get my hands on a decent docking software  )

That appears to be a good/practical idea. Remember that [mono:3b4grcve]find_pair[/mono:3b4grcve] and [mono:3b4grcve]rebuild[/mono:3b4grcve] works for single strand as well. As long as you have a duplex, a single strand, and a triplet building block, the utility program [mono:3b4grcve]rotate_mol[/mono:3b4grcve] should be of help in assembling the two parts together, even though it may not qualify as "a decent docking software". Have a try, and see how far you can go. Once you get a prototype for GGC, it should be straightforward to apply it to AAT.

Xiang-Jun

[hr:3b4grcve][/hr:3b4grcve]
PS. Please be a bit patient -- I am quite occupied recently, and could be slow in getting back to you, especially on issues that require more explorations. Hopefully, I will able to devote more time/efforts on 3DNA-related stuffs to respond to the user community more promptly and to the depth/extent I'd like to.

1384

General discussions (Q&As) / Re: single-stranded base stacking

« on: September 10, 2010, 11:28:18 pm »

I am wondering if this software provides the information of possible single-stranded base stacking?

In addition to what Alpay has suggested, you can also run 3DNA as follows:

Code: [Select]

find_pair -s your.pdb stdout | analyzewhich will generates a file named [mono:3vpvq2pu]your.outs[/mono:3vpvq2pu], containing overlap areas between neighboring base rings. As an example, see "RNA Tetraloop Folding Reveals Tension between Backbone Restraints and Molecular Interactions" by Mohan et al. (J Am Chem Soc. 2010 Sep 15;132(36):12679-89).

Note that under the hook, w3DNA calls exactly the above commands.

HTH,

Xiang-Jun

1385

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

« on: September 08, 2010, 08:05:31 pm »

I only have sequence info that is predicted to form a triplex, no structure information at all!. I am assuming that the triplex will form regular W-C bps on the B-DNA double strand and regular Hoogsten bps with the single strand.

It is helpful to know this background information. Then the question becomes what the "regular Hoogsten bps with the single strand" look like for the G.G-C and A.A-T triplet building blocks? While the A.U Hoogsteen pair is well-characterized, how about the G.G and A.A Hoogsteen pairs? They are prerequisite to build the triplexes you want. Wherever possible, I'd like to help you get started.

Xiang-Jun

PS. Thanks for your kind words about 3DNA, and for sharing your Python script for the analysis along the md trajectories.

1386

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

1387

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

1388

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

1389

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

1390

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

1391

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

1392

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

1393

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

1394

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

1395

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

1396

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

1397

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

1398

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

1399

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

1400

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