Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Netiquette · Download · News · Gallery · G-quadruplexes · DSSR-Jmol · DSSR-PyMOL · Video Overview · DSSR v2.5.4 (DSSR Manual) · Homepage

Messages - xiangjun

Pages: 1 ... 52 53 [54] 55 56 ... 65
1326
Thanks, that's helpful -- not only to your own understanding, but also to those who want to know the details.

Xiang-Jun

1327
For reference, here is a note about .par file from SNAP.
>> Following our Monday meeting, I have updated the SNAP program to do what we 
>> have discussed. Specifically,
>>
>> [1] I have added a command line option -frame=NUMBER. By default, it now
>>    uses the CA-CB-N based reference frame for AA as used by Pabo and
>>    Siggers/Honig. The ls-fitting scheme applies equally well to GLYCINE
>>    since FOUR atoms (N/CA/C/CB) are used by default. For glycine, where
>>    CB is missing, the other three are used.
>>
>>    With -frame=1, the previous peptide based reference frame is used.
>>
>> [2] When deciding the contacts, only heavy atoms (i.e., non-Hs) are
>>    considered.
>>
>> [3] SNAP now ouputs 4 types of AA-bp interactions, controlled by the new
>>    command line option -type=NUMBER, as follows:
>>        0: with any atom -- EITHER base OR backbone atom
>>        1: with base atom (could also contact backbone, default)
>>        2: with backbone atom (could also contact base)
>>        3: must contact BOTH base AND backbone atom
>>    The output files are now named like
>>        AT-ALA_1.par, AT-ALA_1.pdb etc for type=1, i.e., contacting base
>>        for -type=2, it would be AT-ALA_2.par etc, and so on.
>>    Note the interaction type info is now in the file name, and is NOT
>>        included in the .par file (see below).
>>
>> [4] The format of the .par file is now as follows:
>>
>> C4.A-D19.T:A55.ALA 1a73.pdb +     8.6310  -99.8367
>> # identifier, PDB file name, '+' or '-' as defined by dot(dz1, dz2)
>> # followed by "translational distance" and "rotational distance", as in #
>> Pabo, except that "translational distance" is NEGATIVE if it is below # the
>> base-pair mean plane. "rotational distance" is within [-180 to +180]
>>
>>   -3.6380    7.5388    2.1037    0.2592   38.5504  -93.9814
>> # six rigid body parameters: tx, ty, tz, rx, ry, rz
>>
>>    3.6415    7.1395    3.2034  # AA frame origin
>>   -0.1708   -0.8874   -0.4282  # x-axis
>>    0.8903    0.0471   -0.4529  # y-axis
>>    0.4220   -0.4586    0.7821  # z-axis
>> # The above 4 lines define the AA reference frame w.r.t. the bp frame, and
>> # can be *rigorously* deduced from the 6 rigid parameters. They are #
>> redundant, and can be safely ignored. They are included here for info #
>> purpose only.
>>
>>    3.6277    7.1391    3.1907  # CA atom coordinates
>>
>> [5] In processing all the PDB files in batch mode, you need to first run
>>    "snap -c" to initialize all the files. Then each run will "append" to
>>    the corresponding files to get the compilation of the whole set.
>>

1328
Please follow my last reply.

Xiang-Jun

1329
General discussions (Q&As) / Re: haddock compatible pdb
« on: March 01, 2012, 09:54:08 am »
Hi,

Thanks for the two example PDB files, which helped clarify the issue. Please download the updated 3DNA v2.1beta version I compiled on 2012-02-29, which should fix the problem, i.e., the revised fiber output PDB should be directly useable with HADDOCK.

Please have a try and report back how it goes.

Xiang-Jun

1330
General discussions (Q&As) / Re: haddock compatible pdb
« on: February 29, 2012, 08:20:10 am »
Hi Sumedha,

Thanks for posting at the 3DNA forum. Could you please show us, by a specific example, where the problem is? What is the required HADDOCK compatible PDB file? Since 3D-DART is 3DNA-driven, so what is needed may just be a simple conversion between fiber-generated PDB and the one required by HADDOCK. I need more detailed information.

Please help us to help you.

Xiang-Jun

1331
MD simulations / Re: Interpretation of Analysis data from 3DNA
« on: February 27, 2012, 05:38:36 pm »
Your two attached PDB files helped me trace and fix the bug -- it was the non-DNA/RNA chain that caused the problem. The bug can be traced way back to SCHNAaP, on which analyze in 3DNA is based. I've updated v2.1beta in the download page. Please have a try and report back how it goes.

For reference, I have also attached the output files that correspond to the two PDB files.

Xiang-Jun

1332
MD simulations / Re: Interpretation of Analysis data from 3DNA
« on: February 25, 2012, 01:51:59 pm »
What you attached are just input files generated from find_pair. Please provide .pdb files and output files to illustrate more clearly the problems you have, then others may help you more concretely.

Xiang-Jun


1333
Site announcements / Download instructions
« on: February 25, 2012, 12:48:38 am »
DSSR has completely superseded 3DNA with more advanced features and greatly improved usability. Please visit the Columbia Technology Ventures (CTV) website for obtaining the latest version of DSSR.

To download 3DNA v2.4, users must first register in the 3DNA Forum using their work email. After verification and activation, users can then login to see the Downloads section (see the screenshot below). Click links on that page to download 3DNA and other programs (listed below). Note that command-line tools such as wget and curl are blocked on purpose.




DSSR v1.9.10-2020apr23 --- This version corresponds to the paper "DSSR-enabled innovative schematics of 3D nucleic acid structures with PyMOL" (2020) in Nucleic Acids Research. From version 2.0 (released around the summer of 2020), DSSR has been licensed by the Columbia Technology Ventures (CTV), who manages the free DSSR Academic licenses as well as paid DSSR Pro licenses for both academic and commercial users. I've lately learned of academic users from certain countries having trouble in getting DSSR Academic licenses. This pre-licensed version is provided (as is) here to fill the gap: it is slightly outdated but still works well. Whenever possible, however, users should obtain the latest version of DSSR through CTV --- it is free for academic uses and fully supported by the NIH R24GM153869 grant.


3DNA v2.4.8-2023nov10 (with C source code, distributed under the CC-BY-NC-4.0 license; obsoleted by DSSR!) -- What's new?. Follow the instructions on "How to install 3DNA on Linux (macOS) and Windows?" and post back any questions you may have.

SCHNAaP/SCHNArP (with C source code, distributed under the CC-BY-NC-4.0 license) -- this package is a bit aged in applicability, but the algorithms implemented there are straightforward, easy to understand, and still valid.

1334
Feature requests / Request for new features
« on: February 24, 2012, 03:00:30 pm »
Hi all,

Over the years, new features in 3DNA have largely been driven by requests from the user community. As a concrete example, the mutate_bases utility program in v2.1 has been created to meet the needs of applying 3DNA to modeling studies of DNA-protein interactions. Similarly, the x3dna_ensemble Ruby module was written in response to a common need of analyzing trajectories of molecular dynamics (MD) simulations.

I aim to give each and every feature request a careful consideration, but will only consider to implement or incorporate into 3DNA the ones that I can fully understand. Additionally and importantly, the new features must make sense to me (I can be more easily convinced with specific examples), and should be of at least potential general interest. I'd like to make it clear that feature-rich is not a priority or major goal of 3DNA; what I strive for is a coherent suite of programs that are robust and efficient, practical for real world applications and adaptable to new environments.

As always, I greatly appreciated your suggestions and comments.

Xiang-Jun

1335
Bug reports / Report 3DNA bugs
« on: February 24, 2012, 02:15:31 pm »
Hi all,

Over the years, it is the constructive interactions with the user community that has driven 3DNA to its current prominent status. Please do not hesitate to report bugs -- the more, the merrier. I strive to fix any identified bugs as soon as possible.

The following is a list of known bugs in the current release of 3DNA v2.0 that have all been fixed in v2.1:
  • The fiber utility fails to local model directory. This is a very subtle bug that has existed from the very beginning, but is known to show up only in Fedora 14 64-bit Linux machine. Fixed in v2.1beta as of 2012-02-23. Thanks to esguerra!
  • Parameter std_curved not working. This bug was first reported by slaw in the thread "Global Helical Axis Information Missing", and was recently rediscovered by esguerra. For the current v2.0 users who need this feature, the workaround is to modify file 'misc_3dna.par' as follows:
    <std_curved >0.6</std_curved >   # add a space in the end of the tag!

1336
Hurrying for a meeting this morning, I did not notice the new set of 4 structures you attached when I posted my previous reply. Now things are becoming quite interesting. My arguments with regard to the first set of four structures you provided (Srini_PP.pdb, Srini_MM.pdb, Srini_PM.pdb and Srini_MP.pdb) still hold, i.e., PP=MM, and PM≈MP. There is no such things as "four distinctly different structures" there.

The new set of four structures (Srini_pp1.pdb, Srini_mm1.pdb, Srini_pm1.pdb, Srini_mp1.pdb), hereafter referred as PP1, MM1, PM1 and MP1, are completely different from the first set. 3DNA has no problem in identifying the four distinct forms, based on exactly the same algorithm as described in the 1997 JMB SCHNAaP paper. For example, for MM1, the output from 3DNA is as below:

Code: [Select]
****************************************************************************
Structure classification:

This is a right-handed unknown R-form structure
****************************************************************************

More specifically, Figure 7 of the SCHNAaP paper answers this question:


Quote
Figure 7. A representation of four possible arrangements for antiparallel nucleic acid duplexes. Left-handed W and Z-DNA are shown on the left (the characteristic zig-zag backbone pattern is not represented for simplicity). Right-handed A/B and hypothetical R-DNA are shown on the right. The Twist free ladder forms are shown in the middle column. In the top row, the minor groove faces the viewer, while in the bottom row, the major groove faces the viewer. The SCHNAaP coordinate system is also shown. These structures were generated using SCHNArP (see accompanying paper) with Twist= ±36° (0° for the ladder forms), Rise=3.34 Å, and all other step parameters are set to zero. Color scheme: the minor groove side, dark green; the major groove side, light green; and the backbone, red.

In connection with the new set of 4 structures, they correspond to the four forms classified in 3DNA (SCHNAaP) as below:
  • PM1: W-form, left-handed
  • MP1: Z-form, left-handed
  • PP1: A/B-form, right-handed
  • MM1: R-form, right-handed
Also as in SCHNAaP, right-handed structures (PP1/MM1) have positive Twist, and left-handed structures (PM1/MP1) have negative Twist. Moreover, they all have positive Rise.

I am really pleased to see the model structures representing the 4 possible distinct forms of double helices. I will consider to include them in future releases of the 3DNA distribution.

Xiang-Jun

1337
Bug reports / Re: Problems using fiber in version 2.1 -- 2012
« on: February 23, 2012, 03:42:32 pm »
Hi Mauricio,

Quote
Problem fixed with fiber-2

Thanks for your feedback -- I am glad to hear that the problem has been solved. You are so great :) in helping me identify and fix this very subtle bug that can be traced back to v1.5! The tricky part is that it normally does not show up -- not on CentOS 5, Scientific Linux 6, Debian 5, Debian 6, Ubuntu 10.10 and OpenSuSE 11.3. Even if I compile 3DNA directly on Fedora 14 64bit, everything runs smoothly.

This is an excellent example to show that a software program can never be claimed bug-free, and why user's feedback is always appreciated in my support of 3DNA. Please do not be shy to report back any issue you experience that can potentially help made 3DNA better.

As a side note with the fiber application, it's an old dog with new tricks in 3DAN v2.1. For example, to generate a single stranded RNA with sequence "aaauuuggc", it can now be conveniently done as below:
Code: [Select]
fiber -s -r -seq="aaauuuggc" rna_model.pdb
Thanks again for your help in fixing this bug!

Xiang-Jun

1338
In the .par file, the so-called "R matrix" is actually the amino-acid-side-chain expressed when the corresponding base-pair reference frame is at [1 0 0; 0 1 0; 0 0 1] after coordinate transformation.

To verify, simply find the corresponding .pdb for a .par entry, and extract the xyz coordinates of both Cα and Cβ atoms. Then the unit vector of Cα→Cβ corresponds, approximately, to the x-axis (the first row of the "R-matrix"). Please post back an example.

Xiang-Jun

1339
Then we may have different understanding as to what it means to be of the same structure: to me, since PP and MM have an RMSD of 0, they are IDENTICAL. Naturally, 3DNA should output the SAME parameters, as it does. As mentioned in my previous post, the case of PM vs MP follows the same argument.

Ask Sriri to show here in details most possible, how and why PP and MM are different.

Xiang-Jun

1340
Hi Wilma,

Thanks for bringing up this "issue". As always, the four concrete PDB files helped clarify everything. In short, 3DNA is behaving properly: because PP and MM are IDENTICAL (RMSD=0 Å), so are PM and MP (RMSD=0.0174364 Å). There are only two structures; the PP/MM pair is right-handed with Rise=+3.4Å, and Twist=+36°, whilst the PM/MP pair is left-handed Rise=+3.4Å, and Twist=–36°.

Now let's get into details to see why PP=MM, and PM=MP.
  • The PP vs MM case is clear-cut:
    head Srini_PP.pdb Srini_MM.pdb
    ==> Srini_PP.pdb <==
    ATOM      1  P     A A   1      -0.299   9.399  -1.529
    ATOM      2  O1P   A A   1      -0.377  10.734  -2.162
    ATOM      3  O2P   A A   1       0.714   9.245  -0.460
    ATOM      4  O5'   A A   1      -1.738   8.985  -0.968
    ATOM      5  C5'   A A   1      -2.674   8.343  -1.855
    ATOM      6  C4'   A A   1      -3.346   7.182  -1.148
    ATOM      7  O4'   A A   1      -2.596   5.941  -1.284
    ATOM      8  C3'   A A   1      -3.530   7.338   0.361
    ATOM      9  O3'   A A   1      -4.771   6.752   0.737

    ==> Srini_MM.pdb <==
    ATOM      1  P     A A   1       0.299   9.399   1.529
    ATOM      2  O1P   A A   1       0.377  10.734   2.162
    ATOM      3  O2P   A A   1      -0.714   9.245   0.460
    ATOM      4  O5'   A A   1       1.738   8.985   0.968
    ATOM      5  C5'   A A   1       2.674   8.343   1.855
    ATOM      6  C4'   A A   1       3.346   7.182   1.148
    ATOM      7  O4'   A A   1       2.596   5.941   1.284
    ATOM      8  C3'   A A   1       3.530   7.338  -0.361
    ATOM      9  O3'   A A   1       4.771   6.752  -0.737
    The simple head Unix command shows clearly PP and MM are related by a rotation about y-axis by 180°. Thus, the two structures have identical y-coordinates, but opposite x- and z-coordinates. Naturally, the RMSD between them is perfectly 0.
  • The case for PM vs MP is similar, as shown below.
    head Srini_PM.pdb Srini_MP.pdb
    ==> Srini_PM.pdb <==
    ATOM      2  O5*   A A   1       1.736   9.011  -0.504   1.0   0.0           O
    ATOM      3  C5*   A A   1       2.715   8.816   0.515   1.0   0.0           C
    ATOM      6  C4*   A A   1       3.299   7.393   0.557   1.0   0.0           C
    ATOM      8  O4*   A A   1       2.287   6.447   0.872   1.0   0.0           O
    ATOM      9  C1*   A A   1       2.480   5.346   0.001   1.0   0.0           C
    ATOM     11  N9    A A   1       1.290   4.498   0.000   1.0   0.0           N
    ATOM     12  C8    A A   1      -0.023   4.897   0.000   1.0   0.0           C
    ATOM     14  N7    A A   1      -0.878   3.903   0.000   1.0   0.0           N
    ATOM     15  C5    A A   1      -0.071   2.772   0.000   1.0   0.0           C

    ==> Srini_MP.pdb <==
    ATOM      2  O5*   A A   1      -1.747   9.015   0.517   1.0   0.0           O
    ATOM      3  C5*   A A   1      -2.723   8.818  -0.506   1.0   0.0           C
    ATOM      6  C4*   A A   1      -3.301   7.393  -0.552   1.0   0.0           C
    ATOM      8  O4*   A A   1      -2.286   6.450  -0.867   1.0   0.0           O
    ATOM      9  C1*   A A   1      -2.480   5.346  -0.001   1.0   0.0           C
    ATOM     11  N9    A A   1      -1.290   4.498   0.000   1.0   0.0           N
    ATOM     12  C8    A A   1       0.023   4.897   0.000   1.0   0.0           C
    ATOM     14  N7    A A   1       0.878   3.903   0.000   1.0   0.0           N
    ATOM     15  C5    A A   1       0.071   2.772   0.000   1.0   0.0           C

    The two structures have an RMSD of only 0.0174364 Å, which can be taken as zero in practical sense. For verification purpose, please download the superimposed PDB coordinates of PM onto MP (Srini-PM2MP.pdb), and its combination with the original MP in a MODEL/ENDMDL delineated PDB file (Srini-MP-PM-aligned.pdb).

    You can use Jmol or PyMOL to easily view the aligned structure file Srini-MP-PM-aligned.pdb to see for yourself how they overlap. Given below is the "nmr_ensemble" generated image based on Srini-MP-PM-aligned.pdb. Obviously, the two structures align virtually perfectly, in agreement with an RMSD of less than 0.02 Å.


I do not quite understand how Srini and you come to the conclusion that 3DNA is in error here. Unless I am missing something obvious, it is hard for me to imagine that simply rotate a DNA structure by 180 degrees about the y-axis should reverse its Rise and Twist. Maybe Srini can shed more light on his thought?

Xiang-Jun

1341
Bug reports / Re: Problems using fiber in version 2.1 -- 2012
« on: February 22, 2012, 08:18:22 pm »
Hi Mauricio,

You may have helped trace a subtle bug that only shows up in specific OS (here, fedora 14 64bit). Download the following two modified versions of fiber, named fiber-1 and fiber-2. Copy them into $X3DNA/bin, and then run the following, and report back verbatim what you see from screen (as I did in my first reply).

Code: [Select]
fiber-1 -a -seq="aattgg" fa-1.pdb
fiber-2 -a -seq="aattgg" fa-2.pdb

If I have fixed the bug, then the second version (fiber-2) should run successfully, and fiber-1 should provide further information about the source of the bug.

Please let me know how it goes.

Xiang-Jun

1342
Bug reports / Re: Problems using fiber in version 2.1 -- 2012
« on: February 22, 2012, 10:29:55 am »
Hi Mauricio,

Thanks for providing further information. I'll dig the issue further to see if I can reproduce the problem in machines I have access to, and then get back to you ...

Best regards,

Xiang-Jun

1343
Bug reports / Re: Problems using fiber in version 2.1 -- 2012
« on: February 22, 2012, 08:12:27 am »
Quote
open_file <str01/A.rpt> failed: No such file or directory
Weird -- that certainly should not happen! What do the following output?

Code: [Select]
echo $X3DNA
ls $X3DNA/fiber

I've just tried on my machine. As the screen output shows below, the program is working as expected:
Code: [Select]
tmp [510] fiber -a ADNA.pdb
Fiber data in directory: /Users/xiangjun/X3DNA/x3dna-v2.1beta/fiber/

 ...... /Users/xiangjun/X3DNA/x3dna-v2.1beta/config/ ......
 ...... reading file: misc_3dna.par ......
Structure #1; Twist: 32.7 (degrees); Rise: 2.548 (Angstrom)

Input your base sequence with only ACGT:
1. From a data file (complete sequence)
2. From keyboard (enter only the repeating sequence)
Your choice (1 or 2, Dft: 2):

Repeating unit (Dft: A):
Repeating unit: A
Number of repeats (Dft: 10):

Xiang-Jun

1344
The six parameters are just as "shear/stretch/stagger/buckle/propeller/opening" for base-pair parameters, and "shift/slide/rise/tilt/roll/twist" for the dinucleotide steps -- they quantify the spatial relationship rigorously between the side-chain reference frame and the base-pair reference frame. The technical details part (section #5) in the 3DNA manual contains a worked example on how to calculate step parameters. If you really want to get to the bottom of the matter, it's well worthwhile to repeat the example and try to understand every detail.

Quote
In the Siggers (2005) paper, they only used delta a and delta theta  describing the rotation angle.
Mathematically, to rigorously quantify the rotational relationship between two rigid bodies, three angular parameters are required. The Siggers method is a just an approximation, which may be sufficient for its purpose. To understand how the Siggers method works, you may need to dig into the source code -- simply reading the paper is not enough for the algorithmic details.

In light of this topic, you may want to pay more attention to the following quote:

Quote from: Siggers 2005 JMB paper
The approach used here is similar to that described by Pabo & Nekludova, but with two important differences. (1) Three geometric parameters [instead of two] are used in the comparison of residue-base-pairs, a feature that we found to increase the sensitivity of our analysis. ...

Xiang-Jun

1345
General discussions (Q&As) / Re: building a custom dna triplex
« on: February 16, 2012, 04:00:59 pm »
Hi George,

Thanks for posting at the new 3DNA forum!

One way to build a standard DNA triplex with a mixture of TAT and CGC(+) triples would be first to build a Poly (U) : poly (A) : poly(U) triplex, using fiber model #32, or another one as you see fit. Run fiber -l for a list of possible fiber models available from 3DNA, and read the 3DNA 2003 NAR paper for details.

Next, you can use mutate_bases to mutate A/U to the bases you need. See the documentation for details -- currently mutate_bases is the only program I have documented.

Third, you need to download 3DNA v2.1beta which has mutate_bases incorporated as an integral part of the new distribution.

Note that 3DNA v2.1 is only in beta test version. If you notice any issues, please report back.

Best regards,

Xiang-Jun



1346
Bug reports / Re: file format v2.1 and Kaisen
« on: February 16, 2012, 08:34:33 am »
Quote
But please, let me first know if you changed any of the output file format. It is crucial for me to know if, where and which changes have been made.
The file format has not changed in v2.1. That's one of the fundamental considerations I've in mind. Of course, if you notice anything otherwise, I will fix it.

Quote
Also, have you an updated and detailed manual somewhere ? This is one of the very important and often missed feature of such important packages.
Documentation is the next priority now that the v2.1beta is ready for outside testing. You are welcome to point out any areas that I should make clearer and/or document more deeply.

Quote
(your link to "kaisen" searches for kaisen" and thus does not find the correct page)
((this is my tiny contribution to this bug report section))
Fixed. Just remember that no contribution is tiny! The forum is migrated from the original phpBB3, and many links and content should be corrected. I make them available now simply because the forum is functioning, and I would like to hear more feedback from users and earlier. I welcome each and every contribution from the user community.

Xiang-Jun


1347
General discussions (Q&As) / mutate_bases
« on: February 11, 2012, 06:47:28 pm »
Note added on 2020-05-12: mutate_bases is now obsoleted by DSSR 2.0.

See also:

The utility program mutate_bases can be used to mutate bases in nucleic-acid-containing structures (DNA, RNA, and their complexes with ligands and proteins). It has two key and unique features: (1) the sugar-phosphate backbone conformation is untouched; (2) the base reference frame (position and orientation) is conserved, i.e., the mutated structure shares the same base-pair/step parameters as those of the native structure.

The mutate_bases program was created in response to repeated requests from 3DNA users over the years. Written as a standalone ANSI C program, it is on a par with other major 3DNA components (e.g., find_pair, analyze, rebuild and fiber). The program was first released as a supplement to 3DNA v2.0, and then became an essential part of the v2.1 release.

Overall, mutate_bases has been designed to solve the in silico base mutation problem in a practical sense: robust and efficient, getting its job done and then out of the way. The program can have many possible applications: in addition to perform base-pair mutations in DNA-protein complexes, it should also prove handy in RNA modeling and in providing initial structures for QM/MM/MD energy calculations, and in DNA/RNA modeling studies.

The standard command line help (mutate_bases -h) is as below:
NAME
        mutate_bases -- mutate bases, with backbone conformation unchanged
SYNOPSIS
        mutate_bases [OPTIONS] mutinfo pdbfile outfile
DESCRIPTION
        perform in silico base mutations of 3-dimensional nucleic acid
        structures, with two key and unique features: (1) the sugar-
        phosphate backbone conformation is untouched; (2) the base
        reference frame (position and orientation) is reserved, i.e.,
        the mutated structure shares the same base-pair/step
        parameters as the original one.
        -e    enumeration of all bases in the structure
        -l    name of file, containing list of mutations
        'mutinfo' can contain upto 5 fields for each mutation
                  [name=residue_name] [icode=insertion_code]
                  chain=chain_id seqnum=residue_number
                  mutation=residue_name
            The five fields per mutation can be in any order or CaSe.
            Each field can be abbreviated to its first character.
            Multiple mutations specified per line are separated by ';'.
            Fields in [] (i.e., name and icode) are optional.
            Mutation info should be QUOTED to be taken as one entry.
INPUT
        Nucleic-acid-containing structure file in PDB format
EXAMPLES
            # mutate G2 in chain A of B-DNA 355d to Adenine
        mutate_bases "c=a s=2 m=DA" 355d.pdb 355d_G2A.pdb
            # mutate the second base-pair G-C to A-T in 355d
        mutate_bases "c=a s=2 m=DA; c=B s=23 m=DT" 355d.pdb 355d_GC2AT.pdb
            # the above also generates file 'mutations.dat'
            # and the following command gives the same results
        mutate_bases -l mutations.dat 355d.pdb 355d_GC2AT_v2.pdb
            # mutate C74 in chain A of tRNA 1evv to U       
        mutate_bases "c=A s=74 m=U" 1evv.pdb 1evv_C74U.pdb
            # list all bases to be tailored for mutation
        mutate_bases -e 355d.pdb stdout
OUTPUT
        mutated structure in PDB format, sharing the same backbone
        conformation and base pair parameters as the original one.
SEE ALSO
        analyze, find_pair, rebuild
AUTHOR
        3DNA v2.1 (c) 2012 Dr. Xiang-Jun Lu (http://x3dna.org)


Now let's take advantage of the web to illustrate the key features of mutate_bases using a set of worked examples. The scripts and corresponding data files & images are attached, so you can repeat the procedures in order to have a better understanding of how the program works.

In our GpU dinucleotide platform paper, we reported a previously unnoticed intra-dinucleotide sugar-phosphate H-bond that is unique to the GpU platform. This O2′(G)···O2P(U) H-bond readily rationalizes the over 60% occurrence of GpU over other platforms (e.g., ApA and UpC). Moreover, this H-bond has recently been validated by state-of-the-art quantum-chemical techniques.

In this section, we will use mutate_bases to answer the questions of (1) why GpU, not GpT? i.e., why the GpU platform is RNA-specific? (2) why no UpG platforms observed? i.e., why the GpU platform is directional? The GpU platform (1msy_gu.pdb) is derived from PDB entry 1msy. The figure below shows the identity of the two nucleotides (G2655 and U2656 on chain A) and names of the base atoms.

"GpU platform" title="GpU platform"

  • Why no GpT platform?
    mutate_bases "c=a s=2656 m=t" 1msy_gu.pdb 1msy_gt.pdb
    With the above command, we mutate U (which is residue #2656 on chain A) to T (see figure below). Clearly, the methyl group of T protrudes into the pocket, causing steric clash. Thus GpT is incompatible with the platform conformation.

    "GpT platform?" title="GpT platform?"

  • Why no UpG platform?
    mutate_bases "c=a s=2655 m=u; c=a s=2656 m=g" 1msy_gu.pdb 1msy_ug.pdb
    Using the above command, we mutate G (which is residue #2655 on chain A) to U, and U to G simultaneously. That's what the plural 's' in mutate_bases stands for. From the figure below, one can see clearly that no intra-base H-bond is now possible, consistent with the fact that no UpG platform has been observed.

    "no UpG platform!" title="no UpG platform!"

    Note that the above command also generates a file named 'mutations.dat', which has the following content:
    c=a s=2655 m=u
    c=a s=2656 m=g
    You can then use the -l option of mutate_bases as such:
    mutate_bases -l mutations.dat 1msy_gu.pdb 1msy_ug2.pdb.
    The two mutated PDB files, 1msy_ug.pdb and 1msy_ug2.pdb, are identical.
You can run find_pair and analyze to the raw and mutated PDB files and verify that they indeed have the same base-pair parameters and backbone conformation.

To summarize, here is the command-script:
Code: [Select]
mutate_bases "c=a s=2656 m=t" 1msy_gu.pdb 1msy_gt.pdb
mutate_bases "c=a s=2655 m=u; c=a s=2656 m=g" 1msy_gu.pdb 1msy_ug.pdb
mutate_bases -l mutations.dat 1msy_gu.pdb 1msy_ug2.pdb

The PDB files referred:

Note all the images used in this post were generated using Jmol. As much I like RasMol (v2.6.4), I am now gradually switching to Jmol and PyMOL.


Note added on Monday, July 17, 2017:

Single quotes in mutate_bases command-line option have been replaced by double quotes so that the program also works in native Windows. See follow-up messages below.

1348
General discussions (Q&As) / find_pair
« on: February 11, 2012, 06:44:09 pm »
find_pair now contains -c+ option to generate input for Curves+.

1349
Feature requests / Re: Align multi-model (NMR) structures
« on: February 01, 2012, 12:41:35 pm »
Hi Andrew,

That's certainly possible. I will get this functionality added shortly so you can try it. I am consolidating the ensemble-related scripts into one, named 'x3dna_ensemble' with sub-commands such as 'analyze', 'extract', 'reorient', and more. So the new way to run the command would be "x3dna_ensemble reorient" plus options.

Xiang-Jun


Added on 2012-Feb-15: the current 3DNA v2.1beta can be downloaded from: http://x3dna.org/download/

1350
FAQs / How do I cite 3DNA?
« on: January 25, 2012, 06:11:55 pm »
Please use at least one of the following literature references:
The current citation list to 3DNA can be found in Google scholar.

Pages: 1 ... 52 53 [54] 55 56 ... 65

Funded by the NIH R24GM153869 grant on X3DNA-DSSR, an NIGMS National Resource for Structural Bioinformatics of Nucleic Acids

Created and maintained by Dr. Xiang-Jun Lu, Department of Biological Sciences, Columbia University