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 · Homepage · DSSR · Web-DSSR · DSSR Manual · Reproduce DSSR · DSSR-Jmol · DSSR-PyMOL · Web-SNAP

Messages - xiangjun

Pages: [1] 2 3 ... 85
1
General discussions (Q&As) / Re: treating abasic site and THF with 3DNA
« on: January 18, 2019, 10:46:39 am »
Hi Xia,

Thanks for using 3DNA and DSSR, and for posting your questions on the Forum. Your description and the two attached PDB files help clarify the issue. Overall, 3DNA and DSSR are behaving as designed.

Quote
I screened through the forum and I found out that the option --abasic is only applicable for DSSR, can you tell me if the option is also avalaible in 3DNA? If yes, how can I include it in the find_pair and analyze command?

The DSSR --abasic option takes abasic sites in the assignment of loops and the summary output. For example, DAP1030 in your test_dna_DAP.pdb file is classified as a bugle:

Code: [Select]
List of 1 bulge
   1 bulge: nts=5; [0,1]; linked by [#1,#2]
     summary: [2] 0 1 [X.797 X.1031 X.798 X.1029] 7 8
     nts=5 AAT?T X.DA797,X.DA798,X.DT1029,X.DAP1030,X.DT1031
       nts=0
       nts=1 ? X.DAP1030

And MOL885 in test_dna_THF.pdb is part of an internal loop:

Code: [Select]
List of 1 internal loop
   1 symmetric internal loop: nts=6; [1,1]; linked by [#1,#2]
     summary: [2] 1 1 [X.884 X.943 X.886 X.941] 8 7
     nts=6 T?TAAA X.DT884,X.MOL885,X.DT886,X.DA941,X.DA942,X.DA943
       nts=1 ? X.MOL885
       nts=1 A X.DA942

Since no base atoms are available, no base-pair parameters can be calculated.

Note that as of v1.7.3-2017dec26, the --abasic option is set by default in DSSR. So users no longer need to specify it explicitly. On the other hand, one can use --abasic=no to see how DSSR behaves by not taking abasic sites into considerations.

Quote
Otherwise, I saw in a post that we can modified manually the find_pair output so that 3DNA can identified these two residues that don't have base atoms. Can you tell me what does the last five columns mean and how can I get these numbers correctly?

There is no --abasic option in 3DNA (v2.x and before). It is not meaningful to manually add an abasic site to the find_pair output and then feed it into analyze. No magic here: without base atoms, the base reference frame cannot be defined, so no base-pair parameters are available.

The last five columns of the find_pair output are some parameters related to the identified pairs. They represent "d, dv, angle, dNN, dsum" -- check the source code for details. Users do not need to manipulate (or care about) them: they are for information only and is ignored by analyze.

HTH,

Xiang-Jun

2
You're welcome. As mentioned on the Forum and in the manual, DSSR contains many undocumented 'features'. User questions on subtle/technical aspects in DSSR are always gladly received.

As a side note, by including isPairs in loops by default, it is possible to filter DSSR output as users see fit. For example, by parsing for the negative index (#-49), or no. of pairs in a stem (1), users can easily remove the 3-way junction.

Quote
1 3-way junction: nts=11; [2,1,2]; linked by [#63,#64,#-49]
     summary: [3] 2 1 2 [i2.1225 i2.1641 i2.1228 i2.1530 i2.1532 i2.1638] 5 3 1

Along the line, it is also feasible to select junction loops with a stem length of e.g. 3 or more canonical pairs.

Best regards,

Xiang-Jun

3
Hi Jun Li,

Thanks for using DSSR and for posting your questions on the 3DNA Forum.

I understand that the inclusion of isolated canonical pairs (icPairs, those with negative index numbers) in delineating loops may lead to 'spurious' (junction) loops. I am so glad that this issue has been finally brought up on the Forum.

As far as I know, no consensus exists as to whether icPairs should be (always) included in the delineation of loops. Without taking them into consideration, however, the widely documented GUAA tetraloop in PDB entry 1msy (see figure below) cannot be logically identified. That's why DSSR counts icPairs in loops, by default.


While undocumented, DSSR has an option to exclude icPairs from loops, i.e. (--loop-exclude-icpair). Run DSSR with this option on your example PDB entry 5vyc, you'd find that the 3-way junction you reported is gone.


In a similar way, it is also debatable if a non-canonical base pair in an otherwise 'regular' double helix should be taken as part of a stem or as an internal loop. As noted in the 2015 DSSR paper in NAR:
Quote
Following standard conventions (13,35–36), DSSR by default uses only canonical pairs to identify stems and to characterize pseudoknots. Nevertheless, the program contains provisions for including noncanonical pairs in an extended definition of stems

It is my hope that DSSR would help 'standardize' the field, probably in the long run.

Best regards,

Xiang-Jun

4
As a follow-up of the initial request "Mutate_Bases: Option to mutate all residues of the same type to another". In 3DNA v3, I've added a new program named x3dna-mutate which can do this and much more, by incorporating the DSSR annotations. Some examples:

Code: [Select]
x3dna-mutate --mutation='to=A' -i=1ehz.pdb -o=1ehz-allA.pdb
x3dna-mutate --mutation='name=A to=G' -i=1ehz.pdb -o=1ehz-A2G.pdb
x3dna-mutate -m='to=A cond=hairpin' -i=1ehz.pdb -o=1ehz-hairpinsA.pdb
x3dna-mutate --m='name=A negate to=G' -i=1ehz.pdb -o=1ehz-nonA2G.pdb
x3dna-mutate --m='chain=A num=12 to=DT' -i=355d.pdb -o=355d_G12T.pdb
x3dna-mutate --m='num=12 to=DT; num=13 to=DA' -i=355d.pdb -o=355d_TA.pdb

Xiang-Jun

5
Hi Manish,

Thanks for your detailed responses to my follow-up questions. Presumably, such a back-and-forth conversational style should be the norm on an online forum. In practice, as one can see by browsing the 3DNA Forum, that is normally not the case. I sense users may just want a quick and straight answer to their questions, which are frequently not well defined. I then ask for clarifications, but oftentimes receive no responses.

Quote
I am not sure if there are any available software tools for sugar mutations. However, please let me know if you find/are aware of any such tools for sugar mutations. It would be of great help to me.


I'm aware of the paper "Using internal and collective variables in Monte Carlo simulations of nucleic acid structures: Chain breakage/closure algorithm and associated Jacobians" by Heinz Sklenar et al. which may be relevant to the topic here.

Quote
' Do you have a concrete example of such mutations? '- Yes, there are many examples of such mutations in literature. Please go through either of these links to have a rough idea of what I am trying to study:
1- https://onlinelibrary.wiley.com/doi/full/10.1002/cbic.201600385
2- https://pubs.acs.org/doi/10.1021/bi201710q

I will follow these two links and see what I can get. Since your request in on sugar mutations which is not covered by the 'mutate_bases' program in 3DNA v2.x, please start a new thread for future communications.

Best regards,

Xiang-Jun

6
Hi Manish,

Thanks for trying out the new web 3DNA 2.0. As the name mutate_bases hints, the program mutates bases only while keeping the backbone untouched. So it is (currently) not possible to change the sugar from deoxyribose to ribose.

In 3DNA v3.0 (where DSSR and SNAP are two representatives), I will consider adding more modeling features based on users' requests, on a case-by-case basis. In this specific case, aren't there other software tools available for sugar mutations? Cannot you do it manually? How do you consider the sugar conformations (C3'-endo vs C2'-endo) after adding O2'? Do you have a concrete example of such mutations?

Best regards,

Xiang-Jun

7
RNA structures (DSSR) / Re: Stacking parameters
« on: December 27, 2018, 02:08:45 pm »
Hi Simón,

Thanks for using DSSR and for posting your questions on the Forum.

You've touched a subtle, technical point. In DSSR, stacking is decided by no-zero overlapping area of (extended) base-rings projected on the mean plane of the two base normals. The two bases may be (nearly) parallel and stack well, or they are offset, and at a big angle. So being 'stacked' are not equal, as reflected by the different overlap areas and the angles. Users can filter the DSSR-derived stacks based on these two parameters.

These are just general comments. If you provide some specific examples, we can discuss in more detail.

Best regards,

Xiang-Jun

8
FAQs / Re: How to set up 3DNA on Windows
« on: December 27, 2018, 09:13:08 am »
You do not need 'license.txt' to get 3DNA v2.4.0 (or v2.3.4) up and running.

What do you mean that you "install the software successfully"? Please provide details, better with screenshots to show the problem you face unambiguously.

Best regards,

Xiang-Jun

9
w3DNA -- web interface to 3DNA / Re: Notes on w3DNA v2
« on: December 07, 2018, 10:47:08 am »
Hi Shuxiang,

Good catch. The issue you noticed is due to a bug that shows up only in special cases like TNT, and with the analyze -t option. It has been fixed. I'll release an update of 3DNA v2.3 next week, along with several other minor revisions, after we finish (mostly) the web 3DNA v2.0.

Best regards,

Xiang-Jun

10
Hi Pedro,

Thanks for using (web) 3DNA and for posting your questions on the Forum.

I guess the issue you met is related to PDB format. By default, 3DNA fiber and x3dna_mutate generate PDB files that follow PDBV3, which use DA, DG etc for DNA nucleotides, and OP1/OP2 instead O1P/O2P for atom names.

To verify, could you please try PDB id 355d from RCSB (or PDBe) and see if it is recognized by AMBER?

Please attached a PDB file from NAB that does work with AMBER. Since both NAB and AMBER are maintained by the same group, it is not a surprise they work happily together.

Best regards,

Xiang-Jun


11
Hi Doris,

Please be specific with your question so others can reproduce it.

What URL did you use for w3DNA? What feature did you try, with what sequence (parameters), and got what result (PDB file)?

Best regards,

Xiang-Jun

12
w3DNA -- web interface to 3DNA / Re: Notes on w3DNA v2
« on: December 03, 2018, 02:53:08 pm »
Hi Shuxiang,

Thanks for the update. Using high-resolution PNG files for the stacking diagrams is fine with me.

Best regards,

Xiang-Jun

13
RNA structures (DSSR) / Re: Non canonical RNA pairs in bpseq format
« on: December 01, 2018, 09:59:40 am »
Quote
Is there any possible way to get to both canonical and  non canonical pairs of  RNA in bpseq format using DSSR software as .bpseq and .ct output file do not contains non canonical pairs?

The .bpseq and .ct file formats are for RNA secondary structure, which is defined by canonical pairs. I'm not convinced that it is a good idea to extend DSSR-derived output files of .bpseq and .ct with non-canonical pairs included. With the pairing information from DSSR, you could (easily) write a utility program/script for your particular needs. You're welcome to contribute back your software so other users may benefit from your effort.

Quote
but the output file that I got for '1hr2' RNA, nt index is off-set by some number. In the output file for this RNA index of first pair is A.U106 and A.G215. Here first two notation are fine. But notation third is 106 and 215 is off-set by some number.

I am confused by this part of your questions. The shorthand A.U106 notation means U 106 on chain A. Here 106 is the sequence number as defined in the input PDB or mmCIF file. The first pair in your attached file is between A.U106 and A.G215 (see the attached image). There is no ambiguity here, as far as I'm concerned.

Best regards,

Xiang-Jun


14
FAQs / How to draw a helical axis
« on: November 29, 2018, 12:45:17 pm »
While experimentally-determined DNA/RNA double helices (as deposited in the PDB) are never strictly linear, oligonucleotides or fragments of large nucleic acid molecules may be approximately straight. In such cases, it is informative to draw a helical axis to visualize them in a 3D molecular viewer (such as PyMOL or Jmol). Moreover, helical axes from two different fragments can be used to determine the "bending angle" between them. 3DNA and DSSR provide this info, as illustrated below using PDB id 355d as an example.
  • Running 3DNA (v2.3) find_pair 355d.pdb | analyze, the output file 355d.out contains the following segment:
    Global linear helical axis defined by equivalent C1' and RN9/YN1 atom pairs
    Deviation from regular linear helix: 3.30(0.52)
    Helix:    -0.1269   -0.2753   -0.9530
    HETATM 9998  XS    X X 999      17.536  25.713  25.665
    HETATM 9999  XE    X X 999      12.911  15.677  -9.080
    Average and standard deviation of helix radius:
          P: 9.42(0.82), O4': 6.37(0.85),  C1': 5.85(0.86)
    The two HETATM records can be copy-and-pasted into the original PDB file. The line can be easily drawn between them, which is the helical axis.

  • Running DSSR: x3dna-dssr -i=355d.pdb --more, the output contains the following segment:
      helix#1[1] bps=12
          strand-1 5'-CGCGAATTCGCG-3'
           bp-type    ||||||||||||
          strand-2 3'-GCGCTTAAGCGC-5'
          helix-form  BBBBBBBBBBB
        helical-rise:   3.30(0.52)
        helical-radius: 9.42(0.82)
        helical-axis:   -0.127    -0.275    -0.953
           point-one:   17.536    25.713    25.665
           point-two:   12.911    15.677    -9.080
    With the --helical-axis option, as in x3dna-dssr -i=355d.pdb --more --helical-axis, DSSR also generates a file named dssr-helicalAxes.pdb with the following content:
    REMARK-DSSR: helix#1
    ATOM      1  P1   DC A   1      17.536  25.713  25.665  1.00 10.97      H1   P
    REMARK-DSSR: helix#1
    ATOM      2  P2   DG A  12      12.911  15.677  -9.080  1.00 18.40      H1   P
    CONECT    1    2
    CONECT    2    1
    Loading both 355d.pdb and dssr-helicalAxes.pdb into PyMOL, one can get an image as attached.

15
Bug reports / Re: JSON output should escape backslashes
« on: November 29, 2018, 11:14:45 am »
I've updated DSSR to v1.8.5-2018nov29. The bug of not escaping backslash (or double quote) in DSSR JSON output has been fixed.

Please have a try and report back how it goes.

Best regards,

Xiang-Jun

Pages: [1] 2 3 ... 85

Created and maintained by Dr. Xiang-Jun Lu [律祥俊], Principal Investigator of the NIH grant R01GM096889
Dr. Lu is currently affiliated with the Bussemaker Laboratory at the Department of Biological Sciences, Columbia University.