Messages

1276

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

1277

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

1278

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

1279

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

1280

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

1281

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

1282

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

1283

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

1284

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

1285

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

1286

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

« on: June 19, 2012, 01:50:01 pm »

Then install the latest release dated 2012jun06 and have a try again. Report back how it goes.

Xiang-Jun

1287

MD simulations / Re: fiber and gromacs

« on: June 19, 2012, 09:01:46 am »

Thanks for posting back your findings. I am glad to see that you are making progress!

Now I can reasonably guess what's happening:

• The program pdb2gmx seems to follow PDB format v3. So it takes residue name such as "  A" as RNA instead of DNA (" DA"). That's why the -pdbv3 option helps.
• Furthermore, for the HARMM27 force field, pdb2gmx does not like the 5'-phosphate group (atoms P, OP1, and OP2):
  

  ATOM      1  P    DG A   1      -0.356   9.218   1.848  1.00  1.00           P  
  ATOM      2  OP1  DG A   1      -0.311  10.489   2.605  1.00  1.00           O  
  ATOM      3  OP2  DG A   1      -1.334   9.156   0.740  1.00  1.00           O
  ------------------------------------------------------------------------------
  ATOM    124  P    DG B   7       0.356   9.218 -18.723  1.00  1.00           P  
  ATOM    125  OP1  DG B   7       0.311  10.489 -19.480  1.00  1.00           O  
  ATOM    126  OP2  DG B   7       1.334   9.156 -17.615  1.00  1.00           O  

  If you manually delete the two 5' phosphate fragments, I sense pdb2gmx should work for the AMBER forcce field.
  
  To verify the above line of thinking, extract only the two DNA chains in 355d as below:
  

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

  Now pdb2gmx should be happy with file '355d-only-dna.pdb' for both AMBER and CHARMM force fields.
• I performed a quick google search on pdb2gmx. It appears to me that users need to provide force-field specific residue types for "uncommon" cases. Dig deeper into Gromacs/pdb2gmx documentation, and post your question into the Gromacs mailing list -- gmx-users would help -- it is more of a Gromacs-related problem than 3DNA fiber-generated PDB files (with the -pdbv3 option).

HTH,

Xiang-Jun

1288

MD simulations / Re: fiber and gromacs

« on: June 18, 2012, 10:21:09 am »

Hi Cristiano,

Welcome to join the 3DNA user community! Posting your question on the 3DNA forum is the right step to solve any 3DNA-related problems.

Regarding your issue of 3DNA fiber-generated PDB file, it is likely to be due to a 'special' (customized) PDB format adopted by Gromacs, based on the following error message:

Atom P in residue A 1 was not found in rtp entry RA5 with 31 atoms while sorting atoms.

It seems Gromacs gets stuck in the first residue -- it is expecting RA5 (presumably for adenine of RNA, on the 5' end?) while 3DNA provides simply "  A" for DNA adenine.

Please try as instructed below, report back what you get, and we will move on from there:

• Download 355d, the classic Dickerson B-DNA dodecamer, and repeat your procedure.
• Regenerate your fiber model with option -pdbv3 (to have residue names like " DA"),  and repeat your procedure.
• Check for the documentation of the specifics of the Gromacs PDB format.

HTH

Xiang-Jun

1289

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

« on: June 18, 2012, 07:51:05 am »

Hi Pascal,

As you know, o1p_o2p is a tiny utility program to check if O1P and O2P atoms of a phosphate group are labelled properly. The program is as useful as before, so still distributed as part of 3DNA v2.1. In my experience, whenever I check a feature consistently throughout nucleic acid containing structures in wwPDB, I (nearly) always find some inconsistency. As a test, you may run o1p_o2p on all entries of the current NDB, and see what you get.

I am sure you are aware that O1P/O2P have been labelled OP1/OP2 respectively as of PDB format v3. The o1p_o2p program recognizes the new naming convention internally, and the output can be written accordingly with option -pdbv3.

In the v2.x series, I've been trying to keep 3DNA backward compatible, with added features/programs and improved functionality for each new release. It is imaginable that in 3DNA v3.x (in the not-too-distant future), among other things, I will reorganize/consolidate program structure, unify command-line options and configuration file formats. At that time, I am sure o1p_o2p as a stand-alone program will be gone, but its functionality would be integrated into a more versatile program.

HTH,

Xiang-Jun

1290

General discussions (Q&As) / Re: Download link for 3DNA v2.1beta

« on: June 17, 2012, 12:37:06 pm »

Thanks for sharing your experience with the issue of downloading 3DNA and how you solved it. I've just checked the x3dna.bio.columbia.edu server hosting the download files; neither of the IP addresses you used is blocked. So I still cannot figure out where the problem could be, but I am glad that you reported it. Any similar problems for other users?

Anyway, I am glad that you've now successfully downloaded 3DNA. If you meet any problem in using the software, please do not hesitate to post back on the forum.

Xiang-Jun

1291

General discussions (Q&As) / Re: Download link for 3DNA v2.1beta

« on: June 17, 2012, 09:27:30 am »

Hi Yuan,

Thanks for your interest in 3DNA. This is the first time I hear of any download issue since the new mechanism was established in March 2012. To double check, I've just login as an ordinary user and clicked the five download links for the v2.1beta version without any problem.

In the "Download instructions", I originally wrote "Note that you must register and login to see the download section." Maybe it is still not that clear, but the system is set up such that users must click the links at URL http://forum.x3dna.org/downloads/3dna-download/ to download. To avoid possible ambiguity, I've just refined the publicly accessible download instruction accordingly.

Have a try, please let me know how it goes.

Xiang-Jun

1292

Users' contributions / Re: build dna bulges and extend dna duplex at both terminals via 3dna

« on: June 06, 2012, 08:59:42 am »

Thanks for posting this recipe! Note that the whole procedure can be easily automated into a script to ensure reproducibility.

3DNA has more to offer than commonly assumed, especially for applications related to DNA-protein complexes and RNA structures. Your case serves as yet another example illustrating 3DNA's effectiveness and versatility in real world applications.

Thanks again for your effort in putting together the recipe!

Xiang-Jun

1293

General discussions (Q&As) / Re: extend dna duplex at both terminals?

« on: June 03, 2012, 12:07:16 pm »

it worked like a charm! thanks a lot.

Glad to hear. Could you please summarize the procedure in detail from a user's perspective and post it at the section "Users' contributions"? That'd benefit the whole 3DNA community, including yourself.

what it really means in ref_frames.dat for each base pair?

As you quoted, I said "The point is: one should use the 'ref_frames.dat' file corresponding to the structure to be reoriented." The fix-named file 'ref_frames.dat' is derived from a specific structure, thus it makes no sense to use it to reorient a bp in another structure.

Xiang-Jun

Indeed, Randy Bin Lin posted the recipe "build dna bulges and extend dna duplex at both terminals via 3dna", as requested -- thanks! [Noted added on Monday, 2012-06-11]

1294

General discussions (Q&As) / Re: extend dna duplex at both terminals?

« on: June 03, 2012, 06:42:24 am »

I think the superimposition could be closer.

You are absolutely right.

To get what you'd expect, run "find_pair" immediately after your fiber model, as below:

fiber -b -seq=ctc ctc.pdb
find_pair ctc.pdb ctc.bps
frame_mol -3 ref_frames.dat ctc.pdb ctc-frame-3.pdb

The point is: one should use the 'ref_frames.dat' file corresponding to the structure to be reoriented.

Try the process again and report back how it goes.

Xiang-Jun

1295

General discussions (Q&As) / Re: extend dna duplex at both terminals?

« on: June 02, 2012, 10:00:28 pm »

That's understandable and case-specific. Please attach data files and images to make your point unambiguous.

Xiang-Jun
 

1296

General discussions (Q&As) / Re: extend dna duplex at both terminals?

« on: June 02, 2012, 09:05:12 pm »

For the fiber model (CGC), re-orient it using its 3'-terminal C, i.e., use -3 instead of -1 for 'frame_mol'.

Does this help?

Xiang-Jun

1297

General discussions (Q&As) / Re: extend dna duplex at both terminals?

« on: June 02, 2012, 05:56:59 pm »

Okay, "analyze" your DNA duplex the normal way. You will get a file named 'ref_frames.dat'. Then run 'frame_mol' to reorient your duplex to the reference frame of one terminal pair (say the right-side C). Build a fiber B-DNA model of your preferred sequence (e.g., CAC), and then reset it to its 1st base-pair reference frame. Since two structures have a common reference frame, you can extract the "extended" part of the fiber model to the original structure. Repeat the same procedure for the other end, you should get what you want.

The above text description may sound a bit abstract, but the basic idea is very simple and generally applicable. If you work through a concrete example step-by-step, and meet any technical problem, please post back.

Xiang-Jun

1298

General discussions (Q&As) / Re: extend dna duplex at both terminals?

« on: June 02, 2012, 08:27:34 am »

3DNA should be applicable here, at least in principle. As always, please use a concrete example to illustrate exactly what you want to achieve, then I may offer more specific help.

Xiang-Jun
 

1299

MD simulations / Re: Naming Conventions in x3dna_md output

« on: June 01, 2012, 11:16:59 pm »

Hi Gavin,

Thanks for using the 'x3dna_ensemble' Ruby script. I am glad you ask "about the naming conventions" of the output parameters. To address your question, it helps to know how the script works -- it calls 'analyze' for each model/snapshot and then extract the corresponding parameters of double helical structures.

Simply run 'analyze' on a single structure, you'd notice the following section at the very beginning of the .out file:

Code: [Select]

1. The list of the parameters given below correspond to the 5' to 3' direction
   of strand I and 3' to 5' direction of strand II.

2. All angular parameters, except for the phase angle of sugar pseudo-
   rotation, are measured in degrees in the range of [-180, +180], and all
   displacements are measured in Angstrom units.Listing strand II parameters in the 3'->5' direction makes its base numbering consistent with base-pairs in a duplex.

So you are right in assuming "that puckering1 refers to the pucker data from strand1 and puckering2 refers to data from strand2.  I also assume that column 1 generated by extracting puckering1 refers to base 1 in the 5'->3' direction". However, as noted above, the puckering2 etc parameters are listed in 3'->5' direction.

As a general rule, whenever in doubt with any 3DNA-related issue, check with a concrete example, and do not hesitate to ask on the forum.

Xiang-Jun

1300

General discussions (Q&As) / Re: build dna bulge via 3dna?

« on: May 31, 2012, 10:35:53 am »

Thanks for using 3DNA. As to your question "to build a DNA duplex with bulges with -1, -2 up to -3 deletion, such as in PDB 1AX6 (-2 deletion)", I do not think 3DNA can do the magic automatically in a general sense -- there are so many possible variabilities to introduce bulges with -1, -2 or -3 deletions. Nevertheless, some components of 3DNA can help to some extent in the modeling process:

• Starting from a known structure, e.g. 1ax6, you can use "mutate_bases" to change the bases to your desired DNA sequence while preserving the backbone conformation and base orientation.
• By using "find_pair -s your.pdb stdout | analyze stdin", (manually) editing the generated file "bp_step.par" and then running "rebuild -atomic", you can build any DNA structure with your prescribed sequence and step parameters, but only approximate sugar-phosphate backbone.

HTH,

Xiang-Jun