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.7.3 (DSSR Manual) · Homepage

Messages - xiangjun

Pages: 1 ... 46 47 [48] 49 50 ... 66
1176
General discussions (Q&As) / Re: B-Factor values from PDB in output files?
« on: February 12, 2013, 08:48:25 pm »
The B-factor values are currently not included in 3DNA output file(s), and you are the first user to request such info. Where do you think is the appropriate place to put them? And in what format? How about atom occupancy?

Xiang-Jun

1177
Could you be specific on what you mean by adding "the helical axis as a dotted line in the 3dna-generated figures"? As always, a concrete example would help clarify your point.

Fig. 3 (recipe #2) of the 3DNA NP08 paper shows a dotted line contacting bp centers, but I sense that's not what you want. Does the thread "defining a local helix axis" help?

Xiang-Jun

1178
MD simulations / Re: Stacking of two neighboring non-base-paired bases
« on: January 28, 2013, 11:07:30 am »
Upon your request, I've removed "the image of the whole structure". I understand your concern, and good luck with your manuscript!

Xiang-Jun

1179
MD simulations / Re: Stacking of two neighboring non-base-paired bases
« on: January 27, 2013, 11:22:07 pm »
Thanks for providing a PDB file which helps clarify the issue.

The find_pair program is working as designed. For your RNA structure, it identifies two helical regions (see the attached figure below --- [Note added on 2013-01-28: image deleted upon request]):

Code: [Select]
pdb.00001
pdb.out
    2         # duplex
   30         # number of base-pairs
    1    1    # explicit bp numbering/hetero atoms
   31    8  0 #    1 | ....>-:..31_:[.RG]G-----C[.RC]:...8_:-<....  0.23  0.08 16.57  8.85 -3.78
   32    7  0 #    2 | ....>-:..32_:[.RC]C-----G[.RG]:...7_:-<....  0.50  0.23 11.02  8.87 -3.49
   33    6  0 #    3 | ....>-:..33_:[.RA]A-----U[.RU]:...6_:-<....  0.15  0.03  4.87  8.77 -4.55
   34    5  0 #    4 | ....>-:..34_:[.RA]A-----U[.RU]:...5_:-<....  0.14  0.09  6.89  8.85 -4.32
   35    4  0 #    5 | ....>-:..35_:[.RG]G-----C[.RC]:...4_:-<....  0.84  0.37  4.54  8.71 -3.19
   36    3  0 #    6 | ....>-:..36_:[.RC]C-----G[.RG]:...3_:-<....  0.84  0.79 15.85  8.75 -1.79
   37    2  0 #    7 | ....>-:..37_:[.RU]U-**--G[.RG]:...2_:-<....  3.01  0.85 17.27  8.99  2.57
   38   23  0 #    8 | ....>-:..38_:[.RG]G-----C[.RC]:..23_:-<....  0.45  0.30 12.77  8.96 -3.31
   39   22  0 #    9 | ....>-:..39_:[.RG]G-----C[.RC]:..22_:-<....  0.50  0.33 33.29  8.85 -2.19
   42   40  0 #   10 | ....>-:..42_:[.RA]A-**+-G[.RG]:..40_:-<....  7.23  1.99 47.35  7.57 10.57
   43   61  0 #   11 | ....>-:..43_:[.RA]A-**--G[.RG]:..61_:-<....  1.60  0.88 20.41 10.70  1.38
   44   60  0 #   12 | ....>-:..44_:[.RC]C-----G[.RG]:..60_:-<....  0.34  0.04 24.77  8.89 -3.35
   45   59  0 #   13 | ....>-:..45_:[.RA]A-----U[.RU]:..59_:-<....  0.13  0.06 17.54  8.79 -3.87
   46   58  0 #   14 | ....>-:..46_:[.RU]U-----A[.RA]:..58_:-<....  0.11  0.07 12.05  8.78 -4.15
   47   57  0 #   15 | ....>-:..47_:[.RU]U-----A[.RA]:..57_:-<....  0.36  0.34 10.79  8.72 -3.42
   48   55  0 #   16 | ....>-:..48_:[.RC]C-----G[.RG]:..55_:-<....  0.40  0.02 28.47  8.84 -3.15
   49   54  0 #   17 | ....>-:..49_:[.RC]C-----G[.RG]:..54_:-<....  0.53  0.38 22.85  8.85 -2.56
   50   53  9 #   18 x ....>-:..50_:[.RG]G-**--A[.RA]:..53_:-<....  9.64  0.99 16.65  8.51 11.45
   10   73  0 #   19 | ....>-:..10_:[RG5]g-----c[RC3]:..73_:-<....  0.37  0.20 12.89  8.98 -3.58
   11   72  0 #   20 | ....>-:..11_:[.RG]G-----C[.RC]:..72_:-<....  0.97  0.26 20.72  8.78 -2.48
   12   71  0 #   21 | ....>-:..12_:[.RU]U-----A[.RA]:..71_:-<....  0.17  0.04 22.04  9.00 -3.65
   13   70  0 #   22 | ....>-:..13_:[.RC]C-----G[.RG]:..70_:-<....  0.46  0.18 17.81  9.02 -3.30
   14   69  0 #   23 | ....>-:..14_:[.RC]C-----G[.RG]:..69_:-<....  0.52  0.46 10.86  9.01 -3.01
   15   68  0 #   24 | ....>-:..15_:[.RG]G-----C[.RC]:..68_:-<....  0.33  0.29 12.02  8.95 -3.50
   16   67  0 #   25 | ....>-:..16_:[.RC]C-----G[.RG]:..67_:-<....  0.36  0.30 11.63  8.96 -3.45
   17   66  0 #   26 | ....>-:..17_:[.RA]A-----U[.RU]:..66_:-<....  0.18  0.00  4.99  8.79 -4.57
   18   30  0 #   27 | ....>-:..18_:[.RG]G-----C[.RC]:..30_:-<....  0.35  0.07 24.12  8.82 -3.30
   19   29  0 #   28 | ....>-:..19_:[.RC]C-----G[.RG]:..29_:-<....  0.49  0.20 24.09  8.88 -2.91
   20   28  0 #   29 | ....>-:..20_:[.RC]C-----G[.RG]:..28_:-<....  0.73  0.69 13.00  9.01 -2.25
   21   26  0 #   30 | ....>-:..21_:[.RU]U-**+-G[.RG]:..26_:-<....  1.30  0.34 16.05  9.43 -0.22
##### Base-pair criteria used:     4.00     0.00    15.00     2.50    65.00     4.50     7.80 [ O N]
##### 5 non-Watson-Crick base-pairs, and 2 helices (0 isolated bps)
##### Helix #1 (18): 1 - 18  ***broken O3'[i] to P[i+1] linkage***
##### Helix #2 (12): 19 - 30  ***broken O3'[i] to P[i+1] linkage***

G1 and U24 are not paired according to the default criteria. Indeed, as shown below and as mentioned in your initial post, G1 and U24 are stacking instead of pairing.

Quote
I want to analyze two bases in a ribozyme, G1 and U24, neither of which are in any base pairs. I want to track the sliding interaction of these two bases across the total length of my trajectory, so that I can correlate the sliding to various other distances and angles that I measure across the length of the trajectory as well. I can see how one can extract the slide parameter for a base pair step, but I don't understand if and how one can extract the slide parameter for two unpaired bases.


If you insist on finding the relative geometry of G1 to U24, you could play the following trick:
Code: [Select]
find_pair -s pdb.00001 pdb.00001.datThe -s option means to output a list of all nucleotides in the given PDB file. Since you are interested in only G1 vs U24, you can manually edit the above output file pdb.00001.dat to have the following content:

Code: [Select]
pdb.00001
pdb.outs
    1      # single helix
    2      # number of bases
    1    1 # explicit bp numbering/hetero atoms
    1      #     1 ....>-:...1_:[RG5]g
   24      #    24 ....>-:..24_:[.RU]U

Running "analyze pdb.00001.dat", you get in file pdb.outs the following section:
Code: [Select]
****************************************************************************
Local base step parameters
    step       Shift     Slide      Rise      Tilt      Roll     Twist
   1  g/U      -1.95     -2.62      1.18    -29.34    146.33     78.47
****************************************************************************

Try a few frames (snapshots) along your MD simulation trajectories to decide for yourself if that make sense -- certainly this usage is beyond 3DNA's 'normal' application range.

Xiang-Jun


1180
MD simulations / Re: Stacking of two neighboring non-base-paired bases
« on: January 27, 2013, 09:00:49 am »
Thank for providing further details. However, for your example to be reproducible, you need to provide a PDB file -- that's the starting point of all the following steps.

Basically, you need to run find_pair first to get the pairing info in a file (as the one you attached); the file may need to be modified manually if some desired pair is missing, as is most likely in your case. Then one runs x3dna_ensemble analyze to get the various 3DNA parameters, followed by x3dna_ensemble extract to pick up the parameters one is interested in. The first step in analyzing an ensemble (MD or NMR), i.e, preparing a correct bp file, is identical to that for a single structure, and it is the most crucial.

In the coming 3DNA JoVE paper, there is a protocol to illustrate the whole procedure. In the meantime, you may want to try the examples distributed with 3DNA to get familiar on how to run x3dna_ensemble.

Xiang-Jun

1181
MD simulations / Re: Stacking of two neighboring non-base-paired bases
« on: January 26, 2013, 11:36:40 pm »
Welcome to join the 3DNA-user community!

Please note that the x3dna_md.rb and extract_par.rb pair has been replaced by the x3dna_ensemble script, which consolidates ensemble-processing functionality in 3DNA v2.1 under one umbrella. Please update your 3DNA installation to the latest version.

Regarding your specific question, could you provide a reproducible example? A single frame from your MD simulations can be used to illustrate your point. Show step-by-step what you want to achieve, what's missing from 3DNA, and we can start from there.

Xiang-Jun

1182
General discussions (Q&As) / Re: Analyzing some pdb files of bent DNA
« on: January 15, 2013, 12:15:40 pm »
The helix break is controlled by a parameter callled helix_break in file $X3DNA/config/misc_3dna.par:

Code: [Select]
#   distance criterion for helix break
<helix_break>7.5</helix_break>

It has a default value of 7.5 Å. Reset it to a larger value, e.g. 8.0 Å (see FAQs), will do the trick for all your cases.

HTH,

Xiang-Jun

1183
General discussions (Q&As) / Re: Analyzing some pdb files of bent DNA
« on: January 14, 2013, 04:22:19 pm »
Thanks for using w3DNA, a web-service hosted and supported by the Olson laboratory at Rutgers University. w3DNA aims to make commonly/routinely used 3DNA functionality easily available. To taking full advantage of 3DNA, the standard command-line version is the way to go. Also, w3DNA is still using 3DNA v2.0, while the the command-line version is v2.1.

The issue you experienced for PDB entries 2o8b and 2o8c, i.e., some step parameters are designated as "----", is due to the kink in the two structures. Thus, find_pair now takes each DNA as two helical regions instead of a continuous helix, see below:
find_pair 2o8b.pdb 2o8b.inp
# contents of 2o8b.inp
2o8b.pdb
2o8b.out
    2         # duplex
   15         # number of base-pairs
    1    1    # explicit bp numbering/hetero atoms
    1   30  0 #    1 | ....>E:...1_:[.DG]G-----C[.DC]:..30_:F<....  1.14  0.36 14.09  9.30 -0.44
    2   29  0 #    2 | ....>E:...2_:[.DA]A-----T[.DT]:..29_:F<....  0.89  0.82 26.82  9.09 -1.13
    3   28  0 #    3 | ....>E:...3_:[.DA]A-----T[.DT]:..28_:F<....  0.23  0.03 18.38  9.24 -3.78
    4   27  0 #    4 | ....>E:...4_:[.DC]C-----G[.DG]:..27_:F<....  0.78  0.19  8.59  8.93 -3.40
    5   26  0 #    5 | ....>E:...5_:[.DC]C-----G[.DG]:..26_:F<....  0.56  0.29 17.33  9.24 -3.00
    6   25  0 #    6 | ....>E:...6_:[.DG]G-----C[.DC]:..25_:F<....  0.29  0.27 19.28  9.01 -3.20
    7   24  9 #    7 x ....>E:...7_:[.DC]C-----G[.DG]:..24_:F<....  0.22  0.01 24.18  9.04 -3.55
    8   23  0 #    8 | ....>E:...8_:[.DG]G-**--T[.DT]:..23_:F<....  5.22  0.31 43.28  9.87  7.00
    9   22  0 #    9 | ....>E:...9_:[.DC]C-----G[.DG]:..22_:F<....  0.44  0.33 20.98  8.84 -2.85
   10   21  0 #   10 | ....>E:..10_:[.DG]G-----C[.DC]:..21_:F<....  0.41  0.39 10.80  9.05 -3.28
   11   20  0 #   11 | ....>E:..11_:[.DC]C-----G[.DG]:..20_:F<....  0.26  0.01 12.86  9.06 -4.07
   12   19  0 #   12 | ....>E:..12_:[.DT]T-----A[.DA]:..19_:F<....  0.85  0.47 11.88  8.95 -2.62
   13   18  0 #   13 | ....>E:..13_:[.DA]A-----T[.DT]:..18_:F<....  0.53  0.18  9.30  8.85 -3.65
   14   17  0 #   14 | ....>E:..14_:[.DG]G-----C[.DC]:..17_:F<....  1.17  0.94 21.28  8.97 -0.89
   15   16  0 #   15 | ....>E:..15_:[.DG]G-----C[.DC]:..16_:F<....  1.17  0.05 37.85  8.66 -1.83
##### Base-pair criteria used:     4.00     0.00    15.00     2.50    65.00     4.50     7.50 [ O N]
##### 1 non-Watson-Crick base-pair, and 2 helices (0 isolated bps)
##### Helix #1 (7 ): 1 - 7
##### Helix #2 (8 ): 8 - 15

You can fix the problem by either changing 9 for bp #7 to 0, or running analyze with the -c option:
Code: [Select]
analyze -c 2o8b.inp
In 3DNA, lower case a/c/g/t/u is used for modified bases of A/C/G/T/U respectively. For example, in 2o8c, 6OG is assigned as g.

HTH,

Xiang-Jun



1184
Hi Jane,

I do not quite get what you mean for your follow up question.

Regarding the local reference frame, please have a look of the 2003 3DNA paper, especially Figure 2 (below):


and Figure 1 of the base reference frame paper:


Specifically, the x-axis points from the minor-groove side to the major groove side. For the aligned A and T bases, it's horizontal, pointing to the right. It's a good exercise for you to work out where the x-axes for DT-104 and DA-105 point to. Then you should be able to figure out why one opening is positive, and another is negative.

Note that in 3DNA, the reference frame is defined purely based on the base atoms, not taking consideration of the syn/anti chi torsion angle. See my post "The chi (χ) torsion angle characterizes base/sugar relative orientation".

Xiang-Jun

1185
Thanks for providing an example that helps to illustrate the 'asymmetry' of the A-T vs T-A Hoogsteen pair when put in a structural context. The difference in opening can be understood in the same way as shear in G-U vs U-G wobble pair. See the figure below where the A and T on one strand are aligned on their base reference frames; note the different orientations of T and A.

In 3DNA, the Hoogsteen pair is of the M+N type; thus if the bases are swapped to N+M, all bp parameters change signs.
Code: [Select]
    3 T+A      -0.52      3.62      0.46     -6.35     10.24    -67.69
    4 A+T       0.60     -3.57     -0.56      6.51    -11.43     67.59

3DNA is unique in rigorously quantifying such differences using the six rigid-body bp parameters.

HTH,

Xiang-Jun

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

For B-DNA structures, some base-pair parameters (e.g., shear, opening) are normally quite small, so the difference between +/- values are not that obvious. For some extreme cases, however, the meaning in +/- is immediately obvious. For example, the famous U-G & G-U wobble pairs are distinguished by +/- shear -- see my post "Difference in shear of neighboring base pairs affects twist angle".

As for opening, if you could provide some concrete examples, I will help you work them through to see the difference.

HTH,

Xiang-Jun
 

1187
w3DNA -- web interface to 3DNA / Re: Structural quality
« on: January 11, 2013, 12:26:12 pm »
Hi Damien,

Please note that 3DNA works 'mechanically' -- it calculates a set of parameters for your input structure, without checking if it is reasonable at all. However, since an erroneous structure often gives some bizarre parameters, 3DNA can give a careful user some hint on possible issues.

A quick check using Jmol (or RasMol) shows one region of your model is displayed differently from the rest, signaling some problems. For a detailed report regarding the quality of your model, please try MolProbity (http://molprobity.biochem.duke.edu/).

Xiang-Jun

1188
General discussions (Q&As) / Re: Illegal instruction 4
« on: January 10, 2013, 12:02:14 pm »
Hi Susana,

Thanks for reporting the "Illegal instruction" error message when you ran 3DNA on your Mac OS X Lion 10.7.5 machine. It was due to a backward compatibility issue for the 3DNA binaries I compiled on a newer 10.8.x (Mountain Lion) Mac. I've recompiled 3DNA on a Mac OS X 10.6 (Snow Leopard) and now it should work for you; please download the 3DNA 2013jan10 version from the download page and report back how it goes.

I am using a MacBook Air as the primary machine to develop 3DNA, so a native Mac OS X version of the software should always be available.

HTH,

Xiang-Jun

1189
3DNA does not provide an automatic way to build a dsRNA with non-Watson-Crick base pairs, e.g., the G-U wobble pair. Nevertheless, it has the components that can could possibly be combined to get the job done, on a case-by-case basis. If you are specific about what you want to achieve, our discussions can be more concerete. Alternatively, you may try software tools developed from the laboratories of Eric Westhof or François Major, among other possible choices.

Xiang-Jun

1190
w3DNA -- web interface to 3DNA / Re: misshapen base ring
« on: January 08, 2013, 01:19:16 pm »
Hi Damien,

I've updated 3DNA v2.1 to 2013jan08, with an improved algorithm for nucleotide identification. Specifically, in its default setting, DT8 on chain F is no longer recognized as a nucleotide. For the record, in my yesterday's response with an attached image, I observed the missing pair issue via Jmol using the DT8 as a test case. However, I did not check carefully to notice that previous versions of 3DNA, by virtue of very general distance cutoffs, actually take it as a nucleotide! :-[

Note that the w3DNA web-server hosted at Rutgers is currently not yet updated to the latest version. So your best bet is to download the standard command-line version of 3DNA; it is the most efficient and convenient way to get your job done.

HTH,

Xiang-Jun

1191
w3DNA -- web interface to 3DNA / Re: misshapen base ring
« on: January 07, 2013, 01:34:38 pm »
Hi Damien,

Thanks for your follow-up. Yes, you can certainly use 3DNA to detect anomaly in a structure; that happened a (long) while ago at the NDB.

Thanks for pointing out the "bad" pair involving DT8 on chain F. The issue is due to the very 'generous' distance criteria used, which work well for 'reasonable' cases but apparently fail for your severely distorted structure. I'll fix the issue and update 3DNA shortly.

Xiang-Jun

1192
w3DNA -- web interface to 3DNA / Re: misshapen base ring
« on: January 07, 2013, 11:55:26 am »
Hi Damien,

Thanks for providing a sample PDB file that illustrates the problem you are facing; it helped me to identify the issue.

As shown by the attached image for DT8 on chain F, the base is distorted beyond recognition. For example, C5--C6 distance is only 0.42 Å -- far too short for a covalent bond, whereas N1--C6 = 1.97 Å and C4--C5 = 2.16 Å are far too long. So 3DNA won't recognize it as a DNA base T at all. Same issues exist for the other three nucleotides.

It does not makes much sense to change 3DNA to accommodate such erroneous cases; rather, the mistakes should be fixed in any tool you used to generate this structure in the first place.

HTH,

Xiang-Jun
 

1193
w3DNA -- web interface to 3DNA / Re: misshapen base ring
« on: January 07, 2013, 10:45:36 am »
Could you post (attach) an example structure to make your point concreate?

Xiang-Jun

1194
MD simulations / Re: Base stacking from x3dna_ensemble
« on: December 15, 2012, 12:14:16 pm »
The updated 3DNA v2.1 (2012dec15) should do the trick for you. In particular, I added the -ring option to 'analyze' and the corresponding 'x3dna_ensemble analyze' script. By default, the -ring option is not set for back compatibility. So other users won't notice any differences.

For example, in directory $X3DNA/examples/ensemble/md, you can run the following command:
Quote
x3dna_ensemble analyze -b bpfile.dat -e sample_md0.pdb -r
Note the -r option (short-hand form for -ring).

When you run x3dna_ensemble extract -l, you will find the new parameters are named as below:
Code: [Select]
[ 5] b1c_xyz             [ 6] b1n_vec             [ 7] b2c_xyz             [ 8] b2n_vec
Please verify and report back how it goes.

Xiang-Jun

1195
MD simulations / Re: Base stacking from x3dna_ensemble
« on: December 13, 2012, 11:03:57 am »
What do you mean exactly by "position of center of bases"? Geometric center of all base atoms, or just ring atoms? I may consider to add such info that can meet your needs and fit into other parts of 3DNA.

Xiang-Jun

1196
Hi Paul,

Thanks for posting back. In addtion to what I said in my previous reply, please note that 3DNA caluclates local step and helical parameters which could thus be strongly influenced by regional distortions. The same argument is true for the derived Xp/Yp/Zp parameters and their corresponding helical variants. The situation is especially noticeable for Z-DNA, as in your case, where the repeating unit is two base pairs but the structure is analyzed the 'normal' way (as in A- and B-DNA).

Other users of the forum may want to comment on your questions. Did you also post your questions on the CCP4 mailing list?

Xiang-Jun

1197
MD simulations / Re: Base stacking from x3dna_ensemble
« on: December 10, 2012, 01:17:01 pm »
Hi Ali,

Thanks for providing a sample AMBER MD trajectory file (actg3_md.pdb) which allow me to trace where the problem is.

A portion of PDB ATOM record from the file is as below:
Code: [Select]
         1         2         3         4         5         6         7         8
12345678901234567890123456789012345678901234567890123456789012345678901234567890
ATOM     11  N9  DA5     1       0.781  -4.705  -0.553  0.00  0.00             
ATOM     12  C8  DA5     1      -0.573  -5.051  -0.401  0.00  0.00             
ATOM     13  H8  DA5     1      -0.879  -6.079  -0.526  0.00  0.00             
ATOM     14  N7  DA5     1      -1.349  -3.982  -0.328  0.00  0.00             
ATOM     15  C5  DA5     1      -0.421  -2.977  -0.164  0.00  0.00             
ATOM     16  C6  DA5     1      -0.512  -1.582   0.086  0.00  0.00       

According to the PDB format specification, columns 55 to 60 [Real(6.2)] is for atom occupancy. Normally, it is 1.00 -- check one of PDB entries (e.g., 355d) for an example. Now, as you can see, AMBER puts 0.00 there. It happens that in the 2012dec09 release of 3DNA, I added checking for atom occupancy (see "What's new?" for details). It is in that release that atoms with zero occupancy are ignored -- so find_pair would judge that your MD trajectories contains no base pairs. That explains your observation:
Quote
By the previous release (2012Nov26) there is not any problem!

You raised an interesting question:
Quote
Is it not possible that 3DNA analyze directly the output trajectory file of famous MD codes such as Amber?

Surely I'll like to make 3DNA directly applicable to the output trajectory file of the famous AMBER package. So I have now made checking for -occupancy optional that can be turned on by user explicitly. Download the updated 3DNA v2.1 2012dec10 release, and it should have solved the problem.

Xiang-Jun

1198
MD simulations / Re: Base stacking from x3dna_ensemble
« on: December 10, 2012, 08:02:48 am »
Thanks for letting me know the new issues you experienced -- I will look not them and get back to you shortly.

Xiang-Jun

1199
MD simulations / Re: Base stacking from x3dna_ensemble
« on: December 09, 2012, 08:48:26 pm »
Hi Ali,

Thanks for clarifying your question and providing further details on what you aim to achieve.

Following my previous reply, I've revised the Ruby script associated with x3dna_ensemble to parse the section "Origin (Ox, Oy, Oz) and mean normal vector (Nx, Ny, Nz) of each base-pair in the coordinate system of the given structure". The two newly-added parameters to extract are: bpo_xyz and bpn_vec. Please download 3DNA v2.1(2012dec09) and let me know if that fits the bill.

Since you are interested in base stacking interactions, your may also want to check the section "Overlap area in Angstrom^2 between polygons defined by atoms on successive bases. Polygons projected in the mean plane of the designed base-pair step."

HTH,

Xiang-Jun


1200
MD simulations / Re: Base stacking from x3dna_ensemble
« on: December 08, 2012, 08:48:13 pm »
Hi Ali,

Thanks for using 3DNA and posting your questions on the forum. With feedbacks from users like you, 3DNA can only become more useful to the community.

I think I understand your question: the 3DNA analyze program includes a section as below:
****************************************************************************
Origin (Ox, Oy, Oz) and mean normal vector (Nx, Ny, Nz) of each base-pair in
   the coordinate system of the given structure

      bp        Ox        Oy        Oz        Nx        Ny        Nz
    1 C-G      17.13     25.96     25.88     -0.10     -0.44     -0.89
    2 G-C      16.56     24.81     22.95     -0.21     -0.33     -0.92
    3 C-G      16.16     23.97     19.28     -0.18     -0.48     -0.86
...........................................................................

However, the parameters herein are not in x3dna_ensemble output. Am I right?

That section is currently not parsed by the x3dna_ensemble script -- you are the first to make this request. I will consider to add the portion in x3dna_ensemble output in the next release of 3DNA v2.1(beta) in the near future. What format do you prefer?

Xiang-Jun

Pages: 1 ... 46 47 [48] 49 50 ... 66

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