Messages

1226

General discussions (Q&As) / Re: Helices and Isolates in output of find_pair

« on: July 15, 2012, 09:36:07 am »

Thanks for providing detailed info about a mis-assigned helix by find_pair. As shown in the attached image, in PDB entry 1z58, nucleotides 336-338 and 346-348 should indeed be assigned into a helix. While the helix assignment algorithm of find_pair works elegantly for the majority of cases, it is clearly not sophisticated enough to properly handle complicated structures such as 1z58 (the large ribosomal subunit from the eubacterium Deinococcus radiodurans): if you pay close attention to the output from find_pair, you will see warning messages in such cases.

I'm interested in refining 3DNA on those complicated structures, and your reported example is a concrete case to start with. Do you have more examples? The more varied and detailed cases I have, the easier to test find_pair against, and the more 3DNA can work for you in the end.

Xiang-Jun

1227

General discussions (Q&As) / Re: Helices and Isolates in output of find_pair

« on: July 13, 2012, 05:28:10 pm »

For model #5 of PDB entry 1aju, let's store its coordinates in file 1aju-m5.pdb. Run

Code: [Select]

find_pair 1aju-m5.pdb 1aju-m5.bpsyou get 1aju-m5.bps, with the following content:

1aju-m5.pdb
1aju-m5.out
    2         # duplex
   13         # number of base-pairs
    1    1    # explicit bp numbering/hetero atoms
    1   30  0 #    1 | ...5>A:..16_:[..G]G-----C[..C]:..46_:A<...5  1.26  0.86 43.33  8.60  0.14
    2   29  0 #    2 | ...5>A:..17_:[..G]G-----C[..C]:..45_:A<...5  1.05  0.14 21.15  8.79 -2.62
    3   28  0 #    3 | ...5>A:..18_:[..C]C-----G[..G]:..44_:A<...5  0.47  0.27 13.69  9.09 -3.30
    4   27  0 #    4 | ...5>A:..19_:[..C]C-----G[..G]:..43_:A<...5  0.55  0.43 20.29  9.06 -2.56
    5   26  0 #    5 | ...5>A:..20_:[..A]A-----U[..U]:..42_:A<...5  1.04  1.00 16.36  8.68 -1.15
    6   25  0 #    6 | ...5>A:..21_:[..G]G-----C[..C]:..41_:A<...5  1.01  0.44  9.82  8.78 -2.61
    7   24  0 #    7 | ...5>A:..22_:[..A]A-----U[..U]:..40_:A<...5  0.88  0.75 23.30  8.87 -1.45
   10   23  0 #    8 | ...5>A:..26_:[..G]G-----C[..C]:..39_:A<...5  1.16  0.44 20.37  8.79 -1.94
   11   22  0 #    9 | ...5>A:..27_:[..A]A-----U[..U]:..38_:A<...5  1.09  1.03 16.74  8.87 -1.00
   12   21  0 #   10 | ...5>A:..28_:[..G]G-----C[..C]:..37_:A<...5  0.94  0.83 22.27  8.99 -1.29
   13   20  9 #   11 x ...5>A:..29_:[..C]C-----G[..G]:..36_:A<...5  1.14  0.55 24.72  8.76 -1.53
   15   18  1 #   12 + ...5>A:..31_:[..U]U-**--G[..G]:..34_:A<...5  4.82  2.03 40.01  7.97  7.88
   16   17  1 #   13 + ...5>A:..32_:[..G]G-**+-G[..G]:..33_:A<...5  6.66  0.32 62.30  6.72  9.42
##### Base-pair criteria used:     4.00     0.00    15.00     2.50    65.00     4.50     7.50 [ O N]
##### 2 non-Watson-Crick base-pairs, and 3 helices (2 isolated bps)
##### Helix #1 (11): 1 - 11  ***broken O3'(i) to P(i+1) linkage***
##### Helix #2 (1): 12
##### Helix #3 (1): 13

The helix continues up to base pair (bp) "A:..29_:[..C]C-----G[..G]:..36_:A" (#11). The next two bps are isolated, i.e., not part of a continuous helix formed by bps from 1 to 11. Please see the attached blocview-image showing nucleotides 28 to 37, with green for G, cyan for U, red for A, and yellow for C.

Regarding your question,

When bp is represented with bigger number first (like 20-9) does it mean anything?

As shown above, the numerical values for bps (the left two columns) from find_pair are nucleotide sequential numbers as they appear in the input PDB file. What do you mean "does it mean anything?". As always, please be specific, using an example to illustrate your point.

HTH,

Xiang-Jun

1228

General discussions (Q&As) / Re: Helices and Isolates in output of find_pair

« on: July 13, 2012, 11:09:37 am »

Thanks for using 3DNA. In 'find_pair' output, '+' means isolated base-pair (bp), i.e., a bp not in a helical context. '|' means the bp is part of a helix, and 'x' means helix breaks at the bp.

It would help if you provide an example -- then our discussion would be more specific.

Xiang-Jun

1229

General discussions (Q&As) / Re: How to bend DNA in a protein-DNA complex

« on: July 12, 2012, 07:03:50 pm »

is there any way to incorporate protein information in the bp_step.par file such that the whole complex undergoes bend.

No. The rebuilding process in 3DNA is purely geometric, and it does not handle protein explicitly. If you have a DNA-protein complex to start with, bending DNA will most likely cause steric clashes.

Xiang-Jun

1230

General discussions (Q&As) / Re: How to bend DNA in a protein-DNA complex

« on: July 12, 2012, 05:39:38 pm »

Could you please make your point specific by using a concreate example? What do your mean "it is easy to make that bend DNA using 3DNA"?

Xiang-Jun

1231

General discussions (Q&As) / Re: create bases?

« on: July 12, 2012, 11:49:04 am »

The output file generated by analyze shows only 18 base pairs and does not include the first two TT in Y chain.

The first two TTs on chain Y are not paired to AAs in 3dfv: 'find_pair' identifies all 18 bps available and 'analyze' outputs only parameters for those 18 bps. Everything is as expected.

As for your first question, i.e., pairing the two TTs in chain Y with two AAs in chain Z, have you checked if the two ends are pseudo-continuous in crystal packing? If so, write the full coordinates in a PDB file, and then 3DNA 'find_pair/analyze' will work accordingly. If not, you need to model the pairing with certain assumption/approximations. 3DNA has no direct facility for the job, but may be tailored for the purpose. On the other hand, please have a check of Coot, NAB, PyMol etc tools which may fit the job better. Please report back how it goes, and I will consider adapting 3DNA for your requirement if no other practical approach is available.

Xiang-Jun

1232

General discussions (Q&As) / Re: A way to regenerate experimental coordinates from the reference coordinates?

« on: July 09, 2012, 01:11:45 pm »

Updated to 2012jul09 -- have a look and report back how it works.

Xiang-Jun

1233

General discussions (Q&As) / Re: A way to regenerate experimental coordinates from the reference coordinates?

« on: July 09, 2012, 11:26:31 am »

There are two aspects to your question:

• You want the original coordinates of the base pairs (bp) instead of those reoriented w.r.t. bp reference frames.
• You are concerned about the speed of transformations or extracting from PDB files.

Using Python or any other scripting language, you do not need to parse hundreds of PDBs, but only two: one is the the original PDB file, and the other is 'allpairs.pdb'. By scanning the later, you have a list of all bps, then you can extract one-by-one from the same original PDB file. Have a try and report back how it goes -- I do not think speed is an issue here.

That said, the most efficient way would be to add an option to 'find_pair', presumably -original_coordinate, so that instead of transforming to bp reference frame, the original atomic coordinates are written directly to 'allpairs.pdb'. I will update the 3DNA v2.1beta distribution soon, so stay tuned.

Xiang-Jun

1234

General discussions (Q&As) / Re: A way to regenerate experimental coordinates from the reference coordinates?

« on: July 07, 2012, 06:26:57 pm »

Thanks for using 3DNA and your kind words about it! Over the years, user feedback/encouragement has been the driving force to move the project forward.

As you noticed, 'allpairs.pdb' has each of its base-pair (bp) reoriented in the local bp reference frame. If you want the all-atom bp coordinates in the native PDB, you can write a simple Python script to extract them from the original PDB file -- certainly no "complex matrix transformation" required. To make the point clear, let's use '6tna' as an example.

Code: [Select]

find_pair -p 6tna.pdb 6tna.bps
    # This generates 'allpairs.pdb', where each bp is delineated by a MODEL/ENDMDL pair
head allpairs.pdb
        # The first 2 lines are as below:
    # MODEL        1
    # REMARK    Section #0001 ....>A:...1_:[..G]G-----C[..C]:..72_:A<....

For the first bp, you can then simply extract nucleotides G1 on chain A (A.G1) and A.C72 from '6tna.pdb'. Check $X3DNA/perl_scripts/pdb_frag for a rudimentary implementation in Perl. By looping through 'allpairs.pdb' and checking for pattern "REMARK    Section #", you can convert all the bps to their native PDB coordinates.

HTH,

Xiang-Jun

1235

General discussions (Q&As) / Re: which parameter shall I change to produce bend DNA

« on: July 05, 2012, 06:23:21 pm »

No idea if AMBER or CHARMM is parametrized for (strongly) bend DNA. Large DNA bending angle is normally found in protein-DNA complexes, e.g. IHF or CAP.

You will get more pertinent advice on this question in the AMBER or CHARMM mailing list.

Xiang-Jun

1236

General discussions (Q&As) / Re: which parameter shall I change to produce bend DNA

« on: July 05, 2012, 04:53:22 pm »

So, my question is what is the basis of choosing roll parameters for a specific DNA bending angle?

Good question. However, that's what 3DNA cannot answer directly. As is made clear in the manual you referred to and in the 2008 3DNA Nature Protocols (NP) paper, the formulae for roll-introduced DNA curvature were based on the work of Calladine & Drew.

3DNA's usefulness in this area is described in the 2008 NP paper:

The complicated three-dimensional nature of local bending makes it difficult, even for a seasoned scientist, to visualize how the variation in roll at different dinucleotide steps leads to global curvature. With 3DNA, one simply prepares a data file with any prescribed set of parameters and builds the structure to see what it looks like (Fig. 3). The matrix-based scheme adopted in the 3DNA analysis/rebuilding programs makes this a completely reversible and rigorous process.


HTH,

Xiang-Jun

1237

General discussions (Q&As) / Re: which parameter shall I change to produce bend DNA

« on: July 05, 2012, 03:51:01 pm »

Please explain figure 2 in the documentation.

Are you referring to recipe #2 of the 2008 3DNA Nature Protocols paper, "command-line script to create a 22 base-pair long schematic duplex structure with a 45° curvature per helical turn"? It was Figure 3, instead of 2.

All the (step-by-step) details about how to generate Roll-introduce DNA curvature are presented there. Just try to reproduce recipe #2, as another user recently went through. If you have any technical problems, please post back to the forum.

Xiang-Jun

1238

General discussions (Q&As) / Re: Problem with installing 3DNA on Mac OSX-Intel 10.4

« on: July 02, 2012, 04:54:19 pm »

Following my previous response, I asked for help from SBGrid on compiling 3DNA for Mac OS X Intel 10.4. Ben Eisenbraun told me the OS is on longer supported by SBGrid, and suggested two alternatives (see his message below).

I tried to compile a 3DNA universal binary for Mac OS X 10.4 ppc and intel without luck. Compiling a 10.4/Intel compatible binary on the 10.5/Intel machine went through, so I have created a tarball for you to test. Please let us know if it works.

Xiang-Jun

Hi Xiang-Jun,

> I recently received a report from a 3DNA user that has "Mac OSX
> version 10.4.11, with a 1.83 GHz Intel Core Duo." Neither of the
> compiled versions of 3DNA with "sbgrid-dev-flex, OS X 10.5,
> x86/x86_64" or "sbgrid-dev-cotterpin, OS X 10.4, PowerPC" works for
> this architecture.

We no longer have a OS X Intel 10.4 machine. I have two ideas for you
though:

- cross-compile a 10.4/Intel binary on the 10.4/PPC machine. In the gcc
  manpage:

       -arch arch
           Compile for the specified target architecture arch.  The allowable
           values are i386, ppc and ppc64.  Multiple options work, and direct
           the compiler to produce ``universal'' binaries including object
           code for each architecture specified with -arch.  This option only
           works if assembler and libraries are available for each architec-
           ture specified.  (APPLE ONLY)

- compile a 10.4/Intel compatible binary on the 10.5/Intel machine using:

export MACOSX_DEPLOYMENT_TARGET=10.4
export LDFLAGS="-mmacosx-version-min=10.4 -Wl,-headerpad_max_install_names"

Those are probably enough. You might need to get into sysroot arguments to
gcc if you are using an OS X framework.

-ben

--
| Ben Eisenbraun
| SBGrid Consortium                          | http://sbgrid.org       |
| Harvard Medical School                     | http://hms.harvard.edu  |

1239

General discussions (Q&As) / Re: Recipe 4 of 3DNA Nature paper: Questions

« on: July 01, 2012, 09:22:27 am »

The 1st line is a comment, while the next two lines define just the resolution of the Raster3D render-ed image. Check .r3d format for details.

In the $X3DNA/config/ directory, there are two files, my_header.r3d (default) and my_header_hres.r3d. Simply copy my_header_hres.r3d to my_header.r3d in the $X3DNA/config/ directory or to your working directory to use the high resolution settings. Alternatively, you can manually edit the .r3d file directly. Moreover, when a .r3d file is loaded into PyMol, the three lines have no influence at all.

Thanks for your posts -- I'm happy to see that you are able to fully verify our reported results.

HTH,

Xiang-Jun

PS: In "3DNA Nature Protocols Paper [vol.3, no.7 (2008), 1213-1227]" dated September 27, 2008, I wrote:

Importantly, in the NP_Recipes subdirectory distributed with 3DNA v2.0,  I have included all scripts, original data files and generated images, so that qualified researchers should be able to reproduce accurately our results without difficulty. Of course, I am more than willing and would be quick to address any reproducibility issues you may have. Repeatability is one of the basic requirements of a published scientific work, yet in this "high-throughput" / "big science" age reproducibility is sort of becoming a luxury.

In 3DNA v2.1, I've updated the scripts to ensure continuous reproducibility of our 2008 Nature Protocols paper.

1240

General discussions (Q&As) / Re: Recipe 4 of 3DNA Nature paper: Questions

« on: June 30, 2012, 07:08:26 am »

Hi Ignacio,

Thanks for your detailed questions regarding recipes #4 in our 2008 3DNA Nature Protocols paper. I am glad to know that you can reproduce recipes #1-3 and 5 without any problem. Check "What's New" item dated 2012-04-25 for switching from Perl to Ruby as the scripting language in 3DNA v2.1.

As mentioned at the very top of "script_h1x_h3y" for recipe #4:

# This script is a bit long, but it is actually quite simple.
# Try to understand exactly how it works, you would qualify as
# an expert 3DNA user!

Recipe #4 should be reproducible as the other ones. The best way to understand the procedures is to duplicate the whole directory to a new location, repeat and check each step as you move along.

How should I open the .r3d file to edit it? Is there a particular command or with a text editor like vi should be enough?

The .r3d file is in plain text, so you can view or edit it any way you like, e.g., using vi/emacs. Check Raster3D homepage for details about the .r3d format.

Is this blocview.r3d file the t.r3d file that I should've obtained?

The new Ruby version of 'blocview' generates the file 'blocview.r3d' instead of 't.r3d'. The final composite .r3d file is named '1egk_ok.r3d', which can be loaded directly into PyMOL. Note that the original Perl scripts are still available under $X3DNA/perl_scripts/.

All the scripts are distributed with 3DNA; reading through/between the lines is the most effective way to fully understand what's going on.

HTH,

Xiang-Jun

1241

General discussions (Q&As) / Re: side_view.dat rotate_mol NO rotation

« on: June 29, 2012, 07:27:30 pm »

Hi Ignacio,

I am glad to hear that your problem has been solved  .

The reason: what you copied from .pdf file has hidden characters in it. On my MacBook Air running OS X 10.7.4 (Lion), I have the following:

more side_view.dat
by rotation y <96>30
by rotation x 20

Notice the extra characters <96>? Program vi shows the same info, while emacs displays \226. I do not know what the chars mean exactly, but 'rotate_mol' certainly do not like them, and outputs sensible error message:

wrong <by rotation> format

Thanks for using 3DNA. Keeping asking if anything is unclear or needs to be improved -- it's an ever-learning experience for all of us; through the process, we make 3DNA a better tool to serve the community.

HTH,

Xiang-Jun

1242

General discussions (Q&As) / Re: mutate_bases problem

« on: June 27, 2012, 06:12:21 pm »

In addition to Mauricio's suggestions, please note the following:

• You do not need to run w3DNA -- the stand-alone version of 3DNA has all you need to perform your task. Specifically, mutate_bases is a new addition to 3DNA v2.1, not available from w3DNA yet.
• The mutate_bases program can mutate a single base or any number of bases in a given structure. It just does what you ask it to do -- no more, no less. In particular, it does not check to maintain a Watson-Crick pair if you mutate only one the two bases.
• The program can be run directly on a DNA-protein complex -- no need to first extract the DNA component.

If I understand you correctly, the following steps should explain and solve your puzzle:

Code: [Select]

# Download 2r5y from PDB. Let's call the file 2r5y.pdb
find_pair 2r5y.pdb stdout
    # you will see the Watson-Crick pair: C:...5_:[.DT]T-----A[.DA]:..37_:D
mutate_bases 'c=c s=5 m=DG' 2r5y.pdb 2r5y_c5_T2G.pdb
    # mutate only T5 on chain C (C.T5) to G, as specified. However, it does not mutate D.A37 to C
find_pair 2r5y_c5_T2G.pdb stdout
    # now you'd see: C:...5_:[.DG]G-**--A[.DA]:..37_:D  --- i.e., a G-A mispair
mutate_bases 'c=c s=5 m=DG; c=d s=37 m=DC' 2r5y.pdb 2r5y_c5_T2G_d37_A2C.pdb
    # here we explicitly mutate C.T5 --> G and D.A37 --> C
find_pair 2r5y_c5_T2G_d37_A2C.pdb stdout
    # now you have: C:...5_:[.DG]G-----C[.DC]:..37_:D

HTH,

Xiang-Jun

1243

General discussions (Q&As) / Re: Problem with installing 3DNA on Mac OSX-Intel 10.4

« on: June 27, 2012, 05:41:28 pm »

Thanks for your feedback. I am glad that by VirtualBox + Linux, you now have 3DNA up and running. As always, if you have any 3DNA-related questions, please do not hesitate to post on the 3DNA Forum.

I will still keep an eye on the Mac OS X 10.4.11 Intel (x86) architecture. If I could have access to such a machine, I will compile a native 3DNA distribution for users like you -- I will post back here if I make any progress.

Xiang-Jun

1244

General discussions (Q&As) / Re: Problem with installing 3DNA on Mac OSX-Intel 10.4

« on: June 26, 2012, 10:52:55 pm »

I'm running Mac OSX version 10.4.11, with a 1.83 GHz Intel Core Duo.

Following my previous reply, I've checked the various Mac OS X systems available from SBGrid Developer Support. So I recompiled 3DNA on "OS X 10.4 PowerPC", and "OS X 10.5 Intel". I believe one of the latest 3DNA 2.1beta (2012jun26) distribution, presumably PPC, at the download page should work on your system.

Please have a try and report back how it goes. Also, let me know the output (verbatim) of running "sw_vers" on your Mac OS X.

HTH,

Xiang-Jun

1245

General discussions (Q&As) / Re: Problem with installing 3DNA on Mac OSX-Intel 10.4

« on: June 26, 2012, 05:51:40 pm »

Hi CWashburn,

Thanks for your interest in using 3DNA. I believe your problem is not related to installing 3DNA on Mac OS X. Instead, it appears to be due to 3DNA binary incompatibility with your Mac OS X 10.4.11.

I compiled the Mac OS X version of the currently distributed 3DNA v2.1beta on 10.7.4 (Lion) and verified that the binary works on 10.6.x (Snow Leopard). However, that does not explain why you receive the same error message "Bad CPU type in executable" with previous versions of 3DNA (v2.0 and v1.5). Since you have an Intel Core Duo, the error is unlikely an Intel vs PPC architecture issue either.

Without a Mac OS X 10.4 machine at hand, it is difficult to figure out where the problem is or to recompile 3DNA specifically for your settings. However, we can do at least the followings:

• Do you have access to a Mac with OS X 10.6 (Snow Leopard) or 10.7 (Lion)? Mac users are pretty quick in upgrading their OS, so presumably you could have a try on a newer OS X system and report back how it goes.
• You can try the Linux or Windows version of 3DNA. For example, you could install VirtualBox on your Mac and then set up Linux on top of it.
• I will see if I can find a Mac OS X 10.4 machine to test/compile 3DNA. Alternatively, you may well consider upgrade your hardware/software. In my understanding, Mac OS X 10.4 seems to be little used nowadays.

HTH,

Xiang-Jun

1246

General discussions (Q&As) / Re: mutate_bases problem

« on: June 26, 2012, 01:31:04 pm »

Could you be more specific, showing a (minimum) reproducible example of the problem you are experiencing? Unless others know exactly what you are talking about, they won't be able to help solve your problem.

Xiang-Jun

1247

General discussions (Q&As) / Re: O1P_O2P still needed ?

« on: June 20, 2012, 01:11:19 pm »

Hi Pascal,

I've just updated 3DNA v2.1beta to 2012jun20. There are currently separate columns for chi and A/S, e-z and BI/BII, as you suggested. Moreover, the -pdbv3 option is now on by default, so you do not have to bother with adding it in every 3DNA program. The previous behavior is still available by setting explicitly -pdbv3=no.

As always, let me know if you have any problems or suggestions.

Xiang-Jun

1248

General discussions (Q&As) / Re: O1P_O2P still needed ?

« on: June 20, 2012, 10:00:38 am »

Cannot think about something better than "Anti/Syn" or eventually "A/S" and "BI/BII".

Advice taken and appreciated!

Xiang-Jun

1249

General discussions (Q&As) / Re: O1P_O2P still needed ?

« on: June 20, 2012, 07:43:33 am »

Hi Pascal,

I am glad you found the current version of 3DNA v2.1beta works for your purpose.

BTW, I discovered the -torsion option for analyze that is really cool although it needs to run analyze twice to get all the outputs.

Yes, the -torsion was designed to be a handy tool for calculating the commonly used DNA/RNA backbone torsion angles. Since 3DNA is a command-line driven toolset and is efficient, I hope running analyze twice is not that a hassle. As mentioned previously, I'd like to reorganize/consolidate the various 3DNA components in future v3.x series. I welcome user feedback in any aspect, including how to name the programs consistently and logically.

A small comment, in order to parse efficiently the output, it would be nice to have a separate column for BI/BII.
Same for Syn/anti.

Message heard. Will update x3dna_ensemble shortly -- so stay tuned!

What would you suggest the header for the BI/BII and syn/anti columns called?

Best regards,

Xiang-Jun

1250

MD simulations / Re: fiber and gromacs

« on: June 20, 2012, 07:22:58 am »

> get_part 355d.pdb 355d-only-dna.pdb

> pdb2gmx -f 355d-only-dna.pdb -o prova.gro

I still get a fatal error in converting like the following:

Fatal error:
Atom C5M in residue DT 7 was not found in rtp entry DT with 32 atoms
while sorting atoms.

Oops, here I forgot to add the -pdbv3 option: instead of as " C7 ", the 5-methyl group of DT was labelled as " C5M" which pdb2gmx obviously does not like. Unless I am still missing something else, I believe the following should work:

Code: [Select]

get_part -pdbv3 355d.pdb 355d-only-dna.pdb
The last point in my previous reply still holds, i.e., more familiarity with the nuances of proper usage of Gromacs/pdb2gmx would certainly help. If you could post back your effort and progress in that aspect, it'd be great.

Xiang-Jun