Messages

1451

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

1452

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

1453

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

1454

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

1455

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

1456

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

1457

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

1458

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

1459

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

1460

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

1461

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

1462

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

1463

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

1464

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

1465

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

1466

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]

1467

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

1468

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

1469

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

1470

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

1471

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

1472

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

1473

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

1474

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

1475

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