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 Manual · G-quadruplexes · DSSR-Jmol · DSSR-PyMOL · DSSR Licensing · Video Overview· RNA Covers

Messages - auffinger

Pages: 1 2 [3] 4
51
Feature requests / Re: chain continuation character in analyze
« on: August 08, 2012, 06:19:18 am »
Thanks Xiang-Jun,

Works fine, when no options for find_pairs are used. Yet, I am using following options
find_pair -s -pdbv3 -attach=off  -chain_markers='o|x+' ...
and would like to see these markers in the output of analyze

analyze -pdbv3 file.fp out

that is like

...
   3   (0.038) ....>A:...3_:[.DG]G-
   4   (0.030) ....>A:...4_:[.DG]G-
   5   (0.010) ....>A:...5_:[.DC]C-
   6   (0.043) ....>A:...6_:[.DG]G-
...

Sorry if I didn't explain myself well on this point.

Best,

Pascal

52
Feature requests / Re: BI/BII issue
« on: August 05, 2012, 01:13:02 pm »
OK, thanks for the link, I will look more into that and reply soon.

Pascal

53
Feature requests / Re: chain continuation character in analyze
« on: August 05, 2012, 01:06:10 pm »
Well, normally after a 'x' character a new chain starts, so this is easy. Yet putting a '+' instead of a '-' at these positions seems more informative to me although it looks like a detail. A '+' should then appear for the first residue of a structure. Hence, you would have a specific marker for all 3' and 5' residues.
Of course, an isolated residue can be found and you would have to chose between '+' and 'x' (I suggest '+').

  1   (0.012) ....>A:...1_:[..C]C-          <-- a '+' here instead of a '-'
   2   (0.019) ....>A:...2_:[.DC]C-
   3   (0.038) ....>A:...3_:[.DG]G-
   4   (0.030) ....>A:...4_:[.DG]G-
   5   (0.010) ....>A:...5_:[.DC]C-
   6   (0.043) ....>A:...6_:[.DG]G-
   7   (0.012) ....>A:...7_:[.DC]C-
   8   (0.013) ....>A:...8_:[.DC]C-
   9   (0.027) ....>A:...9_:[.DG]G-
  10   (0.027) ....>A:..10_:[..G]Gx
  11   (0.015) ....>B:..11_:[..C]C-       <-- a '+' here
  12   (0.009) ....>B:..12_:[.DC]C-

Pascal

54
Feature requests / BI/BII issue
« on: August 04, 2012, 02:34:45 pm »
Hi Xiang-Jun,

BI-BII feature is nice. however, the criteria e-z is probably not sufficient to define one or the other since, the way you do it, every nucleotide is either of the BI or BII type. Furthermore, I think that BI/BII is mainly used for B-DNA.

Best,

Pascal

55
Feature requests / chain continuation character in analyze
« on: August 04, 2012, 02:31:03 pm »
Hi Xiang-Jun,

Went just through a few options.
In the analyze file, you insert the '-' character when a strand is not broken and 'x' when its broken.
Then a new chain starts. May be you could add a third '+' character for these residues ?
This is a really minor point.

Also, for the same strand P...P and C1'...C1' distances, could you add two decimals instead of one?
This could be convenient for some applications.

Best,

Pascal

56
General discussions (Q&As) / Re: O1P_O2P still needed ?
« on: June 20, 2012, 09:31:38 am »
Cannot think about something better than "Anti/Syn" or eventually "A/S" and "BI/BII".

Hope it helps,

Pascal

57
General discussions (Q&As) / Re: O1P_O2P still needed ?
« on: June 20, 2012, 05:42:44 am »
Xiang-Jun,

Yes, the latest version works fine with the -pdbv3 option (find_pair and analyze)
BTW, I discovered the -torsion option for analyze that is really cool although it needs to run analyze twice to get all the outputs.

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.

Best,

Pascal

58
General discussions (Q&As) / Re: O1P_O2P still needed ?
« on: June 19, 2012, 01:36:49 pm »
Hi Xiang-Jun,

I tried several times to use the -pdbv3 option with the find_pair and analyze programs. Unfortunately, this option seem to work only with the O1P_O2P program. Is that because I am using a very early release of the 2.1 version of 3DNA ?

Best,

Pascal

59
General discussions (Q&As) / O1P_O2P still needed ?
« on: June 18, 2012, 04:39:07 am »
Hi Xiang_Jun,

Just wondering, is currently, with the new version of 3DNA, O1P_O2P still needed ?

Thanks for the reply,

Pascal

60
Yes, it does,

Thanks a lot,

Pascal

61
Xiang-Jun,

Thanks for your reply,

i tried following
find_pair -p -attach=off 437D.py.pdb out
followed by
analyze allpairs.ana

and got the file
437D.py.outp

in this file, I see for example

Local base-pair step parameters
    step       Shift     Slide      Rise      Tilt      Roll     Twist
   1 GG/GC      ----      ----      ----      ----      ----      ----
   2 GC/GG      ----      ----      ----      ----      ----      ----
   3 CC/GG      ----      ----      ----      ----      ----      ----
   4 CG/CG      ----      ----      ----      ----      ----      ----
   5 GG/AC      ----      ----      ----      ----      ----      ----
   6 GC/GA      ----      ----      ----      ----      ----      ----
   7 CG/CG      ----      ----      ----      ----      ----      ----
   8 GG/CC      ----      ----      ----      ----      ----      ----
   9 GG/AC      ----      ----      ----      ----      ----      ----
  10 GC/GA      ----      ----      ----      ----      ----      ----
  11 CC/CG      ----      ----      ----      ----      ----      ----
  12 CA/CC      ----      ----      ----      ----      ----      ----
  13 AC/GC      ----      ----      ----      ----      ----      ----
  14 CC/GG      ----      ----      ----      ----      ----      ----
  15 CC/AG      ----      ----      ----      ----      ----      ----
  16 CG/CA      ----      ----      ----      ----      ----      ----
  17 GC/AC      ----      ----      ----      ----      ----      ----
  18 CC/AA      ----      ----      ----      ----      ----      ----
  19 CG/GA      ----      ----      ----      ----      ----      ----
  20 GC/GG      ----      ----      ----      ----      ----      ----
  21 CC/GG      ----      ----      ----      ----      ----      ----
  22 CC/GG      ----      ----      ----      ----      ----      ----
****************************************************************************
Local base-pair helical parameters
    step       X-disp    Y-disp   h-Rise     Incl.       Tip   h-Twist
   1 GG/GC      ----      ----      ----      ----      ----      ----
   2 GC/GG      ----      ----      ----      ----      ----      ----
   3 CC/GG      ----      ----      ----      ----      ----      ----
   4 CG/CG      ----      ----      ----      ----      ----      ----
   5 GG/AC      ----      ----      ----      ----      ----      ----
   6 GC/GA      ----      ----      ----      ----      ----      ----
   7 CG/CG      ----      ----      ----      ----      ----      ----
   8 GG/CC      ----      ----      ----      ----      ----      ----
   9 GG/AC      ----      ----      ----      ----      ----      ----
  10 GC/GA      ----      ----      ----      ----      ----      ----
  11 CC/CG      ----      ----      ----      ----      ----      ----
  12 CA/CC      ----      ----      ----      ----      ----      ----
  13 AC/GC      ----      ----      ----      ----      ----      ----
  14 CC/GG      ----      ----      ----      ----      ----      ----
  15 CC/AG      ----      ----      ----      ----      ----      ----
  16 CG/CA      ----      ----      ----      ----      ----      ----
  17 GC/AC      ----      ----      ----      ----      ----      ----
  18 CC/AA      ----      ----      ----      ----      ----      ----
  19 CG/GA      ----      ----      ----      ----      ----      ----
  20 GC/GG      ----      ----      ----      ----      ----      ----
  21 CC/GG      ----      ----      ----      ----      ----      ----
  22 CC/GG      ----      ----      ----      ----      ----      ----
****************************************************************************

and

****************************************************************************
Same strand P--P and C1'--C1' virtual bond distances

                 Strand I                          Strand II
    step      P--P     C1'--C1'       step      P--P     C1'--C1'
   1 G/G       ---       ---         1 C/G       ---       ---
   2 G/C       ---       ---         2 G/G       ---       ---
   3 C/C       ---       ---         3 G/G       ---       ---
   4 C/G       ---       ---         4 G/C       ---       ---
   5 G/G       ---       ---         5 C/A       ---       ---
   6 G/C       ---       ---         6 A/G       ---       ---
   7 C/G       ---       ---         7 G/C       ---       ---
   8 G/G       ---       ---         8 C/C       ---       ---
   9 G/G       ---       ---         9 C/A       ---       ---
  10 G/C       ---       ---        10 A/G       ---       ---
  11 C/C       ---       ---        11 G/C       ---       ---
  12 C/A       ---       ---        12 C/C       ---       ---
  13 A/C       ---       ---        13 C/G       ---       ---
  14 C/C       ---       ---        14 G/G       ---       ---
  15 C/C       ---       ---        15 G/A       ---       ---
  16 C/G       ---       ---        16 A/C       ---       ---
  17 G/C       ---       ---        17 C/A       ---       ---
  18 C/C       ---       ---        18 A/A       ---       ---
  19 C/G       ---       ---        19 A/G       ---       ---
  20 G/C       ---       ---        20 G/G       ---       ---
  21 C/C       ---       ---        21 G/G       ---       ---
  22 C/C       ---       ---        22 G/G       ---       ---
****************************************************************************

How can I get these values.
Fixing this may be by changing the all pairs.ana file would be helpful to me.
or at least if you could tell me how to do that.

Pascal

62
Feature requests / find_pair and analyze outputs with option -pz
« on: May 18, 2012, 09:50:07 am »
Dear Xiang-Jun,

I asked you a while ago about getting a find_pair output that works as an input for analyze.
I was pleased to see that the *ana file (output from find_pair -pz) works.
Yet, it seems not to be sufficient for analyze to calculate, for example, locate base_pair parameters, or same strand P...P distances.

This would be a nice feature, if the *.ana output would allow to provide a complete output for analyze.

Is there any hidden option I am not aware off ?

Thanks for your reply,

Pascal

63
Bug reports / file format v2.1 and Kaisen
« on: February 16, 2012, 03:51:55 am »
Hi Xiang-Jun,

Really glad to hear about this update and will be glad to test it soon. 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. Also, have you an updated and detailed manual somewhere ? This is one of the very important and often missed feature of such important packages.

(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))

Best,

Pascal

64
General discussions (Q&As) / Re: O1P_O2P program
« on: November 15, 2010, 02:09:54 pm »
Hi again Xiang-Jun,

Read your most recent blog page and found it quite interesting. The question I am asking now is: given the recent PDB changes, is the O1P_O2P still interesting to use? I noted that this program still finds mislabelled O1P/O2P atoms and corrects them. Yet, after checking some of them, I noted that these changes occur mostly for terminal residues and I am not sure that everything is OK at this level (you could eventually like to check file 10MH). On my side, I will continue to check the files, it might well be that some modified residues are also mislabeled in original files. A bunch of O1P/O2P atoms can still be found in PDB files (HETATM lines; see 1RZR).

Best,

Pascal

65
General discussions (Q&As) / Re: O1P_O2P program
« on: November 09, 2010, 06:25:57 am »
Hi Xiang-Jun,

Thanks for your reply. Wrote a script for that purpose. It is just that at a first glance, I didn't realize that the header was shortened. This is a problem when one wants to generate symmetry related images. In fact, shortening the header is probably not very useful here and it would be nice to put at least a note in your program description for other eventual users  8)

Best,

Pascal

66
General discussions (Q&As) / O1P_O2P program
« on: November 08, 2010, 11:10:00 am »
Dear Xiang-Jun,

We are using the O1P_O2P program that s quite useful. Yet, this program removes part of the header and we would like to keep it as it is. Is there an option to keep the entire header or remove it entirely ?

Thanks for your reply,
best regards,

Pascal

67
General discussions (Q&As) / Re: rotate_mol ambiguous orientations
« on: July 09, 2010, 06:36:12 am »
Hi Xiang_Jun,

Another one, hope it will come to an end or do you have to write a patch for each specific base pair?

Pascal

68
General discussions (Q&As) / Re: rotate_mol ambiguous orientations
« on: July 09, 2010, 06:07:29 am »
Hi Xiang_Jun,

Here is another one. Thanks for taking care of it.

Pascal

69
General discussions (Q&As) / Re: rotate_mol ambiguous orientations
« on: July 08, 2010, 12:03:52 pm »
Thanks Xiang_Jun,

This part of the problem is solved. I will scan the other base pairs to see if everything is fine now.

Pascal

70
General discussions (Q&As) / Re: rotate_mol ambiguous orientations
« on: July 07, 2010, 07:22:14 am »
Hi Xiang_Jun,

Yes, it works fine for the AC cWCWC base pairs I sent you. Many thanks for that. Yet, unfortunately it"s not the end of the story. Here is another example with an ensemble of AC tHWC pairs, for which three orientations can be distinguished (see AC1, AC2, and AC42). Any clues ? Can rotate_mol provide a consistent orientation for all base pair types ? Again, many base pair types seem to be affected by this issue. Do you take into account the mass of the atoms and/or the C1' atoms with the base (-b) option ? Although this might not change a lot of things.

Best regards,

Pascal

[attachment=0:2t129ljn]AC.png[/attachment:2t129ljn]

71
General discussions (Q&As) / Re: rotate_mol ambiguous orientations
« on: July 04, 2010, 12:32:44 am »
Dear Xiang-Jun,

Thanks for your quick reply. Yet, I am not quite sure that its only a matter of positive and negative shear value. Here is another example for AC cWCWC pairs. AC1 and AC3 are oriented similarly, also they have positive and negative shear values while AC66 has a different orientation. Any clues since I do really not know how to solve this ? I join a pymol file that contains a superposition of about 150 similar AC cWCWC base pairs on which you can see some further ""misoriented"" base pairs.

Pascal

[attachment=0:1sowrmee]AC3_66.png[/attachment:1sowrmee]

72
General discussions (Q&As) / Re: rotate_mol ambiguous orientations
« on: July 03, 2010, 01:31:11 pm »
Hi Xiang-Jun,

Yes it works as you say. The fact that spurious characters were present in the files originated from the fact that I used MSW to edit them when I transfered them from a linux to a mac (sorry about that). The original files do not contain these characters. Although, using the -b option worked in the previous case, here is another example (which I should have sent you at the first) place of what is troubling me. Could you check this one ? Its an AA pair.

Pascal

73
General discussions (Q&As) / rotate_mol ambiguous orientations
« on: July 02, 2010, 12:44:51 pm »
Dear Xiang-Jun,

Recently we used rotate_mol in order to ovelay base pairs of a same class and originating from different PDB structures. As we understood, rotate_mol sets the input structure with respect of its principal moments of inertia. Also it works generally fine, in some instances we got contradictory results by using rotate_mol -ac  (see attached files and pictures). Did we miss some options ? How could we easely use rotate_mol for overlaying such structures.

Best regards,

Pascal

[attachment=0:q0e397s7]GA_12.png[/attachment:q0e397s7]

74
General discussions (Q&As) / non planar base pairs
« on: April 17, 2010, 01:19:28 pm »
Dear Xiang-Jun,

Another interrogation related to 3DNA. We came accross a strange base pair selected by find_pair, the base looks almost othogonal and this, although not frequent, is not a unique case (this base pair involves symmetry related residues). We used find_pair -p on a modified PDB file of the 1DC0 structure with following parameters:
Base-pair criteria used:   3.35   0.00  15.00   1.50  65.00   4.50   7.50 [ O N].

In which way should we change these parameters in order to eliminate such base pairs (thought stagger=1.5 would do)?

see attached files,

Best regards,

Pascal

75
General discussions (Q&As) / Re: find_pair and HETATM
« on: April 16, 2010, 05:55:35 am »
Hi Xiang-Jun,

I was a little bit quick on this. We had a selection issue with pymol that for unknown reasons takes sometimes connectity cards into cosideration leading to the picture I sent to the forum. Our scripts start to become quite complex,and even after the recent pdb file updates (cleaning), there are a lot of special issues to deal with that complicate our work. I can remove this and my preceding post from the file since it might not be too useful to the community. By curiosity, do you take into account connectivity cards in 3DNA? Anyway, your programs don't need to be modified.

Cheers,

Pascal

Pages: 1 2 [3] 4

Created and maintained by Dr. Xiang-Jun Lu [律祥俊] (xiangjun@x3dna.org)
The Bussemaker Laboratory at the Department of Biological Sciences, Columbia University.