Messages

1501

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

1502

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

1503

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

1504

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

1505

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

1506

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]

1507

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

1508

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

1509

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

1510

General discussions (Q&As) / Re: find_pair and HETATM

« on: April 16, 2010, 09:11:51 pm »

Hi Pascal,

Thanks for your verification. We all learn from mistakes, and our change of views serves as another example of the ever-refining process (kaizen; improve; 改善) that is required to keep a (software) product alive. As a general rule, I have never deleted or changed posts from users. I lock a thread when I believe the topic is finished.

3DNA does not read CONECT records from PDB, which is incomplete (by design), inconsistent, and unreliable. Instead, 3DNA implements an algorithm to decide if two atoms are covalently connected based on pure geometrical criteria. If you want to discuss this topic further, please start a new thread.

Best regards,

Xiang-Jun

1511

General discussions (Q&As) / Re: find_pair and HETATM

« on: April 15, 2010, 11:12:25 pm »

Hi Pascal,

Could you provide a step-by-step reproducible example? At the bare minimum, please attach the PDB file you used to generate the image. I checked 1VBZ, but failed to repeat the problem you reported  -- I could not find any BA atom in file "allpairs.pdb".

If verified, it is certainly a bug and I won't hesitate to fix it.

Best regards,

Xiang-Jun

1512

General discussions (Q&As) / Re: A little background on the -negx option and rebuild of s

« on: April 13, 2010, 09:02:38 pm »

Hi Mauricio,

You have touched a subtle point, indeed you are the first to post a question on the -negx option of "rebuild". I do not have time to go into details (due to a couple of deadlines), but here are my quick answers to your questions.

When 3DNA finds a negative twist it reverses the direction of the x- and z-axes.
I would like to ignore this for all cases since I don't have Z-RNA conformations.
Is there another way besides using the -negx command?

The -negx is designed for that specific purpose.

Also, I might be missing out the deeper reason for the default behaviour of reversing the axes directions, I understand the reasons for base-pairs as you explain in your NAR paper of 2003 (page 5109), but I don't understand fully the reasons for the step case. Could you please expand a little bit more on this explanation, or point me to some of your papers which I might have overlooked?

Have a look of my SCHNAaP/SCHNArP papers (J Mol Biol. 1997 Oct 31;273(3):668-80; J Mol Biol. 1997 Oct 31;273(3):681-91), where the "a" and "r" are the origins of the "analyze" and "rebuild" programs in 3DNA (both algorithm-wise and in code base).

HTH,

Xiang-Jun

1513

General discussions (Q&As) / Re: find_pair and HETATM

« on: April 09, 2010, 11:45:18 pm »

Hi Pascal,

Finally we tested your option -attach that works really fine. A lot easier for us. now!

Glad to hear.

The .ana output looks less interesting to us than our workaround since it s lacking some info that we get by rewriting the find_pair output with -pz to a new output readable by analyze. At a later stage, it would be nice to have a complete output for analyze comming out from "find_pair -pz".

Could you be more specific so I (or others who are interested in) can see what exactly you want to achieve? As mentioned before, the "-p" option of "find_pair" was incompatible with "analyze" by design for a valid reason. I understand that 3DNA serves also as a tool kit, being used in "unexpected" ways. I am open and I'd be more than willing to be convinced to new ideas. As a design principle, though, I change 3DNA only in ways that make sense to me. When adding a new feature (excluding experimental and undocumented one, of course), I have always asked myself this question: will I be able to give user a concrete explanation or quickly acknowledge (and possibly fix) a bug? As a supplement and complement, users are always welcome to share their tricks and scripts with the community in the Users' contributions section.

Was just also looking at the RN9-YN1 and RC8-YC6 info you provide in the analyze output. The labeling of this columns seems not appropriate since you do not consider the YY and RR base pairs occurrences, do you ?. The YN1-YN1 and RN9-RN9 columns are missing apparently. From my point of view, the C1'-C1' and the two lambdas provide all the needed info.

Again, be specific (using a concrete example) to show where (you think) is wrong. As fas as I could tell, even though the column headers are always labeled RN9-YN1 and RC8-YC6 (intentionally), 3DNA should handle YY and RR pairs properly. Please verify.

Xiang-Jun

1514

General discussions (Q&As) / Re: find_pair and HETATM

« on: March 29, 2010, 08:13:54 pm »

Hi Pascal,

I have finally found time to update "find_pair" to fulfill your requests:

• I have added an option "-attach=STRING": where STRING is case-insensitive, and if it is "off", "no" or "0", then the attached HETATM groups will not be added to the output coordinate file.
• With the "-p" option, I have added an output file named "allpairs.ana" that can be fed into "analyze".

See my email for detailed instructions to update. Please post back here to confirm that my modifications work as advertised, or if you have further questions.

Xiang-Jun

1515

General discussions (Q&As) / Re: find_pair and HETATM

« on: March 27, 2010, 04:42:22 pm »

Hi Pascal,

What OS do you use? I will compile a version of 'find_pair' that works for you. As with v1.5, I will keep the currently distributed v2.0 as is, unless I notice some significant issues.

Xiang-Jun

1516

General discussions (Q&As) / Re: find_pair and HETATM

« on: March 24, 2010, 10:01:23 pm »

Dear Pascal,

Regarding our last post, we would also really appreciate if you could at one point consider providing an output for "find_pair -p" (using the -p option) that could be run through analyze (its not the case right now). This would be also more than helpful for us.

I may consider adding a new output file from "find_pair -p" that can be fed directly into "analyze" when I turn into "programming mode" to address your HETATM request. In the meantime, it should be straightforward to write a script that parses the output file from "find_pair -p" to feed into "analyze". More generally, as demonstrated in the 2008 Nature Protocols paper, 3DNA should be taken as a toolset that, when combined with other programs, can be explored with command line scripts to fulfill specific needs.

Yet, I understand that you are really busy combining several jobs.

As mentioned several times in the forum and on the 3DNA websites, and made clear in my blog post titled "On maintaining the 3DNA forum", my supporting of 3DNA and the forum is purely on a voluntary basis, not a "job" duty at all:

Over the past few years, maintaining the 3DNA forum (i.e., answering questions, performing administrative tasks) has taken up a significant amount of my spare time. Sometimes it could be quite demanding, especially because I need to pay great attention to details. Overall, though, it is a valuable experience, and I feel that the time is well-spent: 3DNA has been continuously refined and more widely used; my knowledge of nucleic acid structures (especially RNA) has been significantly sharpened; I have stayed aware of progress in related research fields and see more of the world; and I feel great pleasure in being of help to the community.

I do enjoy what I am doing with 3DNA and I have learned a lot, even from a negative comment on my effort (BTW, the thread is well worth reading):
[hr:1txo5elk][/hr:1txo5elk]

You [Xiang-Jun] clearly have the ability to avoid answers to the questions. You lecture me how to pose a question, I recommend you learn how to answer a question. I read your answers to other questions and the pattern is the same: to give as little help as possible. Still I like your program better than the other programs, so please, try to be more helpful. Do you think Wilma knows how to use this program? Maybe I should write to her?

[hr:1txo5elk][/hr:1txo5elk]

Best regards,

Xiang-Jun

1517

General discussions (Q&As) / Re: find_pair and HETATM

« on: March 23, 2010, 11:42:15 pm »

Dear Pascal,

Over the years, I have always been surprised by your sharp observations of some fine details of undocumented 3DNA features, through our extensive email communications (mostly before the 3DNA forum was set up) and your posts in the forum.

Just found out that for some base pairs, find_pair extracts some additional atoms (CA, K, TL, MG among others) and also complete modified residues like in 1MO5 (bp 12) and 2PIS (bp 9) (see attached files). Is that how it should be. Did we miss an option or misunderstand something ? This does not occur with the -a option, yet info related to modified residues are then lost.

Yes, the attached HETATM moieties (including metals, and modified nucleotides) you observed are expected, thus you did not miss any option or misunderstand something. Based on my experience with PDB format 2.x, I checked for possible linkage between a hetero group (e.g., a drug molecule) and the base residue, and added the HETATM group to the output coordinates file if it is connected to the nucleotide.

Obviously, the extra-mileage I took seems too far for your purpose. So I am considering to add a new command line option to “find_pair” that, if specified explicitly, would exclude such HETATM groups (metals, or modified residues). I am pretty busy for my job right now, but I would keep your request in mind. Hopefully, I would be able to get a working solution for you in a week (by the end of this month).

Xiang-Jun

1518

General discussions (Q&As) / Re: findpair -p and -z options

« on: March 12, 2010, 08:53:09 pm »

Hi Pascal,

The "-p" option of find_pair is for pairwise checking of all possible base-pairs, and for identifying higher-order base associations as demonstrated in the 2008 3DNA NP paper (Recipe no. 5). It was not intended to be used with analyze, as I initially added the option there. The "-z" option, on the other hand, was mostly used to decide suitable criteria of which base-pair should be included in a helical region. Its output information is far too technical for outside users.

Regarding the output parameters from the "-p" option, the header section should be of some help:
[pre:byvny7l4]Six-line information for each base-pair as follows:
   #1: Overall serial number, local serial number, paired residue numbers,
       detailed pairing residue information.
   #2: One-letter base-pair followed by six base-pair parameters (shear,
       stretch, stagger, buckle, propeller, opening). The parameters are
       with respect to the Watson-Crick base reference frame. There are
       two types of base-pair orientation: M-N means the two bases have
       opposite orientations as in Watson-Crick base-pair; M+N means the
       two bases have the same local orientations as in Hoogsteen base-
       pair. All possible base pairing patterns can then be classified
       based on the six parameters, among which shear, stretch and opening
       are most discriminative.
   #3: H-bonding information (atom pair followed by their distance).
   #4: Overall classification of the base-pair (anti-parallel vs parallel
       based on relative z-axis of the two bases, cis vs trans based on
       x-axis and C1-RN9/YN1 directions).
   #5: Relative directions of the three axes and their numerical values.
       The last 3 numbers are the angles between the glycosidic bonds, and
       the two chi torsion angles.
   #6: The actual parameters used to locate the base-pair in question.[/pre:byvny7l4]
Some of the undocumented features of 3DNA are experimental or are related to still unpublished work. I am hoping to be able to devote more efforts to research on nucleic acid structures, but it all depends.

Xiang-Jun
[hr:byvny7l4][/hr:byvny7l4]
PS. BTW, isn't FR3D sufficient for tasks related to the identification and classification of base-pairs? The FR3D webpage contains tons of information; some of which you may find helpful.

1519

General discussions (Q&As) / Re: Finding non-sequential base step parameters

« on: March 08, 2010, 07:53:39 pm »

I am wondering if it's possible to find all base step parameters

No, it is not possible. There are simply too many possibilities, e.g., for 23S rRNA in 1jj2, and most of them make no sense at all.

I am aware that I can isolate the base_step and calculate the step parameters for them

What do you mean to "isolate the base_step"? If you separate find_pair -s from analyze, you could simply play with the output file from the former to get what you want.

HTH,

Xiang-Jun

1520

General discussions (Q&As) / Re: Error Running X3DNA_setup script

« on: February 01, 2010, 11:11:23 pm »

The Perl script x3dna_setup is a simple, straightforward utility program with source code available. Apparently, you are more a Windows users, not that familiar with Linux/Unix and Perl. So it would be most helpful if you could find a local expert to help you out.

Here are some specific suggestions:

• Is x3dna_setup executable? You may need to run "chmod u+x *" in X3DNA/bin/ directory.
• What "which perl" outputs? If not /usr/bin/perl, you will need to change the first line in the script to reflect your local setting.
• Does your Perl installation have modules "FindBin" and "File::Basename"? If not, you will need to have then installed.
• What is the output of the following:
  
  Code: [Select]
  echo $HOME
echo $SHELL
and the directory of you 3DNA installation?

Since I am basically a non-Windows person, I am hoping other 3DNA users using Cygwin and MinGW would help out with more detailed instructions.

Xiang-Jun

1521

General discussions (Q&As) / Re: RNA 2D structure

« on: January 24, 2010, 07:28:38 pm »

I would like to get the secondary structure of all these 3D structures. Is it possible with 3DNA software? If so please let me know how to use that.

From a 3D RNA structure in PDB format, find_pair in 3DNA can identify all the double helical regions. Maybe that would serve as a starting point?

You may also find my blog post titled "Does 3DNA work for RNA?" relevant.

HTH,

Xiang-Jun

1522

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

« on: January 23, 2010, 08:36:27 pm »

Hi I buy the software 3DNA AND I can not access the download add-on WORLD, can you help me :roll:

Where did you buy "the software 3DNA" :? ? This 3DNA forum is on "Topics Related to the 3DNA Software Package for the Analysis, Rebuilding & Visualization of Three-dimensional Nucleic Acid Structures", and it does not have "add-on WORLD" at all.

Xiang-Jun

1523

General discussions (Q&As) / Re: DNA Step Values for DNA Mismatches

« on: January 21, 2010, 10:33:57 pm »

...... reading file: baselist.dat ......
unknown residue DG 1 on chain E [#1]
Check the base and add one more item in file <baselist.dat>

Take the hint, and read FAQs on "How to fix missing (superfluous) base pairs identified by find_pair?" and "How to handle modified (uncommon) bases?" to see how to handle such cases.

Notice that it complains about the DG residue. As well, it is unable to produce the corresponding 2O8B.out file. I think that this is due to the unrecognized naming convention "DG" which should be written as "GUA" instead. This is why I had extracted the coordinates before and renamed them all to GUA, ADE, THY, and CYT.

Following the suggestion above, you do not need to manipulate PDB file at all. 3DNA v1.5 works in such situation as well, and this topic has been brought up in the forum before.

...... reading file: baselist.dat ......
uncommon residue ADP 936 on chain A [#1793] assigned to: a
uncommon residue ADP 202 on chain B [#1795] assigned to: a
................................................................
Instead of complaining about the DG (which I assume is "fixed" in v2.0), it complains about the ADP nucleotides which are present in the PDB file (of 2O8B.pdb, not the modified one).

Note that this is for information only. Again, reading and understanding the above mentioned two FAQs would help.

ii) They both still do NOT contain the first G-C base pair information (even with v2.0 using an unmodified PDB file downloF:..30_:[.DC]Caded from PDB.org).

I have just checked and reproduced your result with the distributed 3DNA v2.0. The missing first G-C base-pair is due to the distortion of C30 on chain F.

iii) The output format for v2.0 is slightly different from v1.5 (so my parsing script written in Perl will need to be modified)

iv) The final column in each row for each base step is different (-1.13 vs. 1.03). I think I read somewhere that this value is simply being calculated differently?

v) The base-pair criteria used appears slightly different.

Over the time, there are some internal changes in find_pair. Moreover, contents following "#" are for information only, undocumented, and are subjected to changes.

4) I will try modifying the helix break parameter as you had suggested (just for experience) but from what you said, it looks like I could just extract the pertinent information directly from the "bp_step.par" file without having to do that since it will always include a complete set of parameters. Is that correct?

If you are just interested in getting the numbers, yes, 'bp_step.par' contains all the base-pair and step parameters.

HTH,

Xiang-Jun

1524

General discussions (Q&As) / Re: DNA Step Values for DNA Mismatches

« on: January 17, 2010, 05:45:42 pm »

Hi Sean,

Thanks for the well-formulated question. I am impressed that you noticed the fact that a set of step parameters is omitted in 3DNA main parameters file (*.out) of 2o8b, but available in file 'bp_step.par'. In my support of 3DNA over the years, you are the first who has dug into this detail.

First, a clarification:

After extracting the DNA coordinates and analyzing it with 3dna, ...

Did you that you do not need to first perform "extracting the DNA coordinates" from the PDB file? With "find_pair", you can analyze a nucleic acid structure directly from a PDB file. See FAQ for an example.

Now to your specific questions:

Code: [Select]

5 GC/GC -0.20 0.24 3.45 2.85 -2.55 38.63
6 CG/TG ---- ---- ---- ---- ---- ----
7 GC/GT 3.87 0.83 3.32 -11.26 0.08 6.18I should point out that step 6 is where the G-T mismatch is located but I don't understand why the parameter values are missing.

If you check carefully the output file from "find_pair" (BTW, your output file apparently lacks the first G-C base-pair, why?),

Code: [Select]

2o8b.pdb
2o8b.out
    2         # duplex
   15         # number of base-pairs
    1    1    # explicit bp numbering/hetero atoms
    1   30  0 #    1 | ....>E:...1_:[.DG]G-----C[.DC]:..30_:F<....  1.14  0.36 14.09  9.30 -0.44
    2   29  0 #    2 | ....>E:...2_:[.DA]A-----T[.DT]:..29_:F<....  0.89  0.82 26.82  9.09 -1.13
    3   28  0 #    3 | ....>E:...3_:[.DA]A-----T[.DT]:..28_:F<....  0.23  0.03 18.38  9.24 -3.78
    4   27  0 #    4 | ....>E:...4_:[.DC]C-----G[.DG]:..27_:F<....  0.78  0.19  8.59  8.93 -3.40
    5   26  0 #    5 | ....>E:...5_:[.DC]C-----G[.DG]:..26_:F<....  0.56  0.29 17.33  9.24 -3.00
    6   25  0 #    6 | ....>E:...6_:[.DG]G-----C[.DC]:..25_:F<....  0.29  0.27 19.28  9.01 -3.20
    7   24  9 #    7 x ....>E:...7_:[.DC]C-----G[.DG]:..24_:F<....  0.22  0.01 24.18  9.04 -3.55
    8   23  0 #    8 | ....>E:...8_:[.DG]G-**--T[.DT]:..23_:F<....  5.22  0.31 43.28  9.87  7.00
    9   22  0 #    9 | ....>E:...9_:[.DC]C-----G[.DG]:..22_:F<....  0.44  0.33 20.98  8.84 -2.85
   10   21  0 #   10 | ....>E:..10_:[.DG]G-----C[.DC]:..21_:F<....  0.41  0.39 10.80  9.05 -3.28
   11   20  0 #   11 | ....>E:..11_:[.DC]C-----G[.DG]:..20_:F<....  0.26  0.01 12.86  9.06 -4.07
   12   19  0 #   12 | ....>E:..12_:[.DT]T-----A[.DA]:..19_:F<....  0.85  0.47 11.88  8.95 -2.62
   13   18  0 #   13 | ....>E:..13_:[.DA]A-----T[.DT]:..18_:F<....  0.53  0.18  9.30  8.85 -3.65
   14   17  0 #   14 | ....>E:..14_:[.DG]G-----C[.DC]:..17_:F<....  1.17  0.94 21.28  8.97 -0.89
   15   16  0 #   15 | ....>E:..15_:[.DG]G-----C[.DC]:..16_:F<....  1.17  0.05 37.85  8.66 -1.83
##### Base-pair criteria used:   4.00   0.00  15.00   2.50  65.00   4.50   7.50 [ O N]
##### 1 non-Watson-Crick base-pair, and 2 helices (0 isolated bps)
##### Helix #1 (7): 1 - 7
##### Helix #2 (8): 8 - 15
you will find that the structure has been broken into two helical fragments, at the middle G-T pair. If you set the helix_break parameter in file 'misc_3dna.par' (see the FAQ) from the default 7.5 Å to a larger value, e.g., 8.5 Å as below (3DNA v2.0),

Code: [Select]

#   distance criterion for helix break
<helix_break>8.5</helix_break>"find_pair" will take the whole double helix as a single unit, and the "analyze" output parameters would have included the "missing" step.

Alternatively, with default 'misc_3dna.par' parameters, you can still recover the "missing" step parameters by adding '-c' option to "analyze". Type "analyze -h" to see how it works, and yet another alternative.

In addition, I notice that another output file (bp_step.par) that contains the base-pair step parameters actually has values for the mismatch:
.............................
The (shift, slide, rise, tilt, roll) values are essentially identical in both cases with the exception of the missing values for the mismatch. What do the values in the latter case actually mean and why are they missing in the first case?

No matter how many helical regions are involved in the input file to "analyze", the fixed-named output file 'bp_step.par' always include a compete set of parameters, including the inter-helix steps. This is to ensure that "rebuild" has enough information to construct a model of the whole structure. Thus, the values in the two cases (*.out vs "bp_step.par") mean exactly the same thing; they just serve two different purposes.

HTH,

Xiang-Jun

1525

SCHNAaP/SCHNArP / Re: backbone utility program

« on: January 06, 2010, 08:49:12 pm »

I am glad that you find my SCHNArP program useful to your project.

The 1997 publication on SCHNArP mentions that there is a utility that "traces the path of the backbone by connecting the C1' or RN9/YN1 atoms in the atomic models and the sugar atoms in the schematic models." I cannot locate that utility program in the SCHNAaP/SCHNArP package.

The connection is for visualization purpose only, i.e., to help "traces the path of the backbone". As far as I can recall, the utility was initially written in Matlab, and was intended to be with used with Rasmol. The atomic models in PDB format normally do not contain explicit bond connections. So in the C version distributed, I decided to support this functionality only for the schematic models in Alchemy format; it is now integrated into SCHNArP directly.

For your verification, in the Examples/ directory, you will find several example files DNAp76[a-d].cnt which contain such "backbone" trace. I have also just run SCHNArP using DNAp76a.dat as input, and got two files: CEHS_gen.cnt and CEHS_gen.out. The attached image corresponds to CEHS_gen.cnt. It was generated with Rasmol 2.6.4. (see my blog post: http://xiang-jun.blogspot.com/2009/06/r ... sayle.html)

Note that the file DNAp76a.cnt was generated using a different base-pair BLOCK model. See README.1st and options available in BaseGeo/BLOCK*.alc files; feel free to play with it.

Also, are there source codes available that provide atomistic coordinates of the backbone sugar/phosphate atoms between 2 existing bases?

There must be such source codes available somewhere, but not in SCHNArP or 3DNA. In my understanding, given the geometry of two bases or base-pairs, there is no unique/object ways to define the backbone conformation. So in SCHNArP/3DNA, I've only provided simple rigid-body A-, or B- conformations, attached to the bases. Such approximate full atomic models with backbone could be useful as starting points for other explorations (see our 3DNA 2008 Nature Protocols paper for further explanation on this topic).

HTH,

Xiang-Jun