Messages

1276

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

1277

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

1278

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

1279

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

1280

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

1281

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

1282

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]

1283

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

1284

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
 

1285

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

1286

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

1287

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
 

1288

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

1289

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

1290

MD simulations / Re: pdb files created using v 1.5 and v 2.1 beta

« on: May 29, 2012, 09:03:44 pm »

To be clearer and more specific, please attach two PDB files you generated with 3DNA v1.5 and v2.1. What's your concern regarding the two PDB files? Overall, the v2.1 version is supposed to be more standard compliant, but the xyz coordinates should be the same.

Xiang-Jun

1291

General discussions (Q&As) / Re: ssdna binding protein, again

« on: May 25, 2012, 05:50:26 pm »

No, as discussed previously in the forum.

Xiang-Jun

1292

General discussions (Q&As) / Re: ssdna binding protein, again

« on: May 25, 2012, 10:53:01 am »

Thanks for posting your question on the forum and sending me the data. Your PDB file is an NMR ensemble consisting of 20 models. As you mentioned, the ssDNA is split into two parts, without a connecting loop.

You can run 'find_pair' with the -s option following by 'analyze', as shown below:

Code: [Select]

find_pair -s complex_ENSW_2.pdb ssDNA-protein.inp
analyze ssDNA-protein.inp
The list of nucleotides in your structure is in file 'ssDNA-protein.inp', with content:

complex_ENSW_2.pdb
complex_ENSW_2.outs
    1      # single helix
   14      # number of bases
    1    1 # explicit bp numbering/hetero atoms
  149      # ...1>B:..99_:[THY]T
  150      # ...1>B:.100_:[THY]T
  151      # ...1>B:.101_:[THY]T
  152      # ...1>B:.102_:[THY]T
  153      # ...1>B:.103_:[THY]T
  154      # ...1>B:.104_:[THY]T
  155      # ...1>B:.105_:[THY]T
  156      # ...1>B:.299_:[THY]T
  157      # ...1>B:.300_:[THY]T
  158      # ...1>B:.301_:[THY]T
  159      # ...1>B:.302_:[THY]T
  160      # ...1>B:.303_:[THY]T
  161      # ...1>B:.304_:[THY]T
  162      # ...1>B:.305_:[THY]T

The parameters for the first model in your ensemble is in file "complex_ENSW_2.outs".

Please note the follows:

• Since your ssDNA is not in a helical conformation, the twist/rise/roll etc step parameters may not be useful; the backbone torsions have the normal meaning.
• Since you have an ensemble, you may want to analyze all of the 20 models to see variations along the chain. Currently, the Ruby script 'x3dna_ensemble analyze' applies only to duplexes. If needed, I will consider extending the script to ssDNA as well.
• Since you are studying a ssDNA-protein complex, the most interesting part maybe to know how ssDNA interacts with protein. Currently, 3DNA's analysis is nucleic-acid centered, i.e., without caring about the protein part. I am planning to extend 3DNA's functionality to the analysis of DNA-protein complexes from a more balanced point of view. As always, I welcome user feedback to make the forthcoming tool most relavant to real-world application.

HTH,

Xiang-Jun

1293

General discussions (Q&As) / Re: This structure has broken O3' to P[i+1] linkages

« on: May 24, 2012, 02:17:04 pm »

Thanks for using 3DNA. Regarding 1le5, if you display 1le5.pdb (downloaded from PDB) in Jmol/PyMOL/RasMol, you will immediately notice that the structure in its asymmetric unit contains two copies of DNA duplexes. The two 'fragments' are not covalently connected, thus the message "This structure has broken O3' to P[i+1] linkages." -- it is for information only, not an error.

For the benefit of other viewers, here is what it looks like:

find_pair 1le5.pdb 1le5.inp
File '1le5.inp' has the following content:
1le5.pdb
1le5.out
    2         # duplex
   22         # number of base-pairs
    1    1    # explicit bp numbering/hetero atoms
    2   24  0 #    1 | ....>C:...2_:[GUA]G-----C[CYT]:..24_:D<....  0.61  0.60 14.96  9.14 -2.43
    3   23  0 #    2 | ....>C:...3_:[GUA]G-----C[CYT]:..23_:D<....  1.51  1.46 20.49  8.77  0.45
    4   22  0 #    3 | ....>C:...4_:[GUA]G-----C[CYT]:..22_:D<....  0.22  0.16 15.16  9.16 -3.69
    5   21  0 #    4 | ....>C:...5_:[ADE]A-----T[THY]:..21_:D<....  0.62  0.47 31.07  9.04 -1.89
    6   20  0 #    5 | ....>C:...6_:[ADE]A-----T[THY]:..20_:D<....  0.29  0.26  5.82  8.99 -3.91
    7   19  0 #    6 | ....>C:...7_:[ADE]A-----T[THY]:..19_:D<....  0.33  0.28 13.21  8.86 -3.45
    8   18  0 #    7 | ....>C:...8_:[THY]T-----A[ADE]:..18_:D<....  0.38  0.31 21.55  8.63 -2.92
    9   17  0 #    8 | ....>C:...9_:[THY]T-----A[ADE]:..17_:D<....  1.06  1.02 10.85  8.99 -1.37
   10   16  0 #    9 | ....>C:..10_:[CYT]C-----G[GUA]:..16_:D<....  1.03  1.00  4.76  9.04 -1.73
   11   15  0 #   10 | ....>C:..11_:[CYT]C-----G[GUA]:..15_:D<....  0.56  0.51 11.05  9.05 -2.87
   12   14  9 #   11 x ....>C:..12_:[THY]T-----A[ADE]:..14_:D<....  0.55  0.50 30.25  8.91 -1.94
   26   48  0 #   12 | ....>G:...2_:[GUA]G-----C[CYT]:..24_:H<....  0.88  0.72  5.00  8.59 -2.43
   27   47  0 #   13 | ....>G:...3_:[GUA]G-----C[CYT]:..23_:H<....  1.08  0.96 14.49  8.78 -1.27
   28   46  0 #   14 | ....>G:...4_:[GUA]G-----C[CYT]:..22_:H<....  0.40  0.24 12.49  8.79 -3.50
   29   45  0 #   15 | ....>G:...5_:[ADE]A-----T[THY]:..21_:H<....  0.41  0.30 13.27  8.63 -3.33
   30   44  0 #   16 | ....>G:...6_:[ADE]A-----T[THY]:..20_:H<....  0.95  0.80 21.23  8.37 -1.38
   31   43  0 #   17 | ....>G:...7_:[ADE]A-----T[THY]:..19_:H<....  0.86  0.81 19.69  8.59  0.46
   32   42  0 #   18 | ....>G:...8_:[THY]T-----A[ADE]:..18_:H<....  0.88  0.80 21.14  8.77 -1.45
   33   41  0 #   19 | ....>G:...9_:[THY]T-----A[ADE]:..17_:H<....  0.88  0.29 20.88  8.50 -2.50
   34   40  0 #   20 | ....>G:..10_:[CYT]C-----G[GUA]:..16_:H<....  0.70  0.34 11.58  8.42 -0.03
   35   39  0 #   21 | ....>G:..11_:[CYT]C-----G[GUA]:..15_:H<....  0.82  0.56  5.73  8.42  0.22
   36   38  0 #   22 | ....>G:..12_:[THY]T-----A[ADE]:..14_:H<....  1.18  0.85  5.25  8.14  0.13
##### Base-pair criteria used:     4.00     0.00    15.00     2.50    65.00     4.50     7.50 [ O N]
##### 0 non-Watson-Crick base-pairs, and 2 helices (0 isolated bps)
##### Helix #1 (11): 1 - 11
##### Helix #2 (11): 12 - 22

[/color]
The output from running "analyze 1le5.inp" contains parameters in file '1le5.out'. For groove widths, you just need to consider one section:

                  Minor Groove        Major Groove
                 P-P     Refined     P-P     Refined
   1 GG/CC       ---       ---       ---       ---
   2 GG/CC       ---       ---       ---       ---
   3 GA/TC      10.2       ---      20.6       ---
   4 AA/TT       8.1       8.1      18.2      18.1
   5 AA/TT       9.2       9.2      16.6      16.1
   6 AT/AT      10.5      10.5      17.1      17.0
   7 TT/AA       9.6       9.5      18.9      18.8
   8 TC/GA      10.9       ---      22.6       ---
   9 CC/GG       ---       ---       ---       ---
  10 CT/AG       ---       ---       ---       ---
  11 TG/CA       ---       ---       ---       ---

Alternatively, you may manually extract only chains C and D, and repeat the above procedure.

HTH,

Xiang-Jun

1294

Feature requests / Re: find_pair and analyze outputs with option -pz

« on: May 18, 2012, 10:58:59 am »

How about:

Code: [Select]

find_pair -p 437d.pdb 437d.all
analyze -c allpairs.ana
I used the PDB entry 437d. Note the -c option of 'analyze'. Does it fit the bill?

Xiang-Jun

1295

Feature requests / Re: find_pair and analyze outputs with option -pz

« on: May 18, 2012, 10:10:17 am »

Hi Pascal,

First to clarify, in 'find_pair', the -z option does not combine with -p; try for example 355d with -pz and -p only, you will get the same output file. The -z option is for detailed output of base-pair parameters of duplex structures (mainly for debugging without running 'analyze'). The -p option is for detection of all base pairs without regarding whether they are in double helices and its output is not to be fed into 'analyze'. This option had existed even before v1.5 and it formed the basis of BPS and RNAView. However, I did not have an opportunity to document this feature until v2.0 to accompany the 2008 3DNA Nature Protocols paper -- such thing won't happen again.

Second, and more important, please be specific with an example on what do you want to get (with -p). I will see if your request fits in core 3DNA or better served with a script.

Xiang-Jun

1296

General discussions (Q&As) / Re: 3DNA with twist and rise calculated w.r.t c1'

« on: May 18, 2012, 07:12:26 am »

Thanks for clarifying your question. The info you asked for is still available in 3DNA output from 'analyze' as shown below for 355d/bdl084:

****************************************************************************
Global linear helical axis defined by equivalent C1' and RN9/YN1 atom pairs
Deviation from regular linear helix: 3.30(0.52)
Helix:    -0.127  -0.275  -0.953
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)

Global parameters based on C1'-C1' vectors:

disp.: displacement of the middle C1'-C1' point from the helix
angle: inclination between C1'-C1' vector and helix (subtracted from 90)
twist: helical twist angle between consecutive C1'-C1' vectors
rise:  helical rise by projection of the vector connecting consecutive
       C1'-C1' middle points onto the helical axis

     bp       disp.    angle     twist      rise
   1 C-G      1.95      5.18     36.25      3.50
   2 G-C      2.04      4.65     40.52      2.43
   3 C-G      2.26      4.02     28.36      4.27
   4 G-C      3.04     -0.22     36.02      3.07
   5 A-T      3.53     -5.05     36.82      3.14
   6 A-T      3.32     -5.83     32.80      3.09
   7 T-A      2.98     -6.44     34.14      3.23
   8 T-A      2.99     -7.13     39.93      2.82
   9 C-G      2.88     -4.95     29.46      4.19
  10 G-C      2.34     -6.66     39.85      2.81
  11 C-G      2.37    -10.68     35.99      3.90
  12 G-C      1.85     -4.90      ---       --- 

Xiang-Jun

1297

General discussions (Q&As) / Re: 3DNA with twist and rise calculated w.r.t c1'

« on: May 17, 2012, 12:30:41 pm »

Try 'cehs' instead of 'analyze'. Does it provide what you want?

Xiang-Jun

1298

General discussions (Q&As) / Re: Base Stacking analysis

« on: May 02, 2012, 11:19:00 am »

Hi Ju,

Thanks for your interest in 3DNA. Regarding base-stacking analysis, 'analyze' in 3DNA does the job: for double helical structures, the program projects base atoms onto the "mean" base-pair plane and then calculates the overlap area, if the two base-pairs in a dinucleotide step are not too far away. It does a similar job for single-stranded structures, on neighboring nucleotides as defined in the input file.

Note that in its current setting, the 'analyze' program does not perform an exhaustive stacking analysis of all possible nucleotide bases in three-dimensional space. For that purpose, you may try FR3D from the Leontis laboratory.

I am also quite interested in extending 3DNA's functionality for RNA structure analysis, and I greatly appreciate user's feedback.

Xiang-Jun

1299

General discussions (Q&As) / Re: Calculating groove width- calladine algorithm

« on: April 30, 2012, 11:00:44 am »

As you know, 3DNA employs the El Hassan and Calladine algorithm to calculate major- and minor-groove widths. More specially, the appendix of the 1998 J. Mol. Biol. paper "Two Distinct Modes of Protein-induced Bending in DNA" was the sole reference based on which I implemented the groove-width algorithm. I am going to document the technical details, with an example, in the near future. However, if you really want to get to the bottom of the method, there is no substitute for reading carefully the original reference; after all, the appendix is only less than three pages long.

Also it will be nice to know of any other algorithm/ work that talks about groove width calculation that is accepted  by Nucleic acid community. their advantages n disadvantages. esp with respected irregular deformed helices.

This is not a light topic, which certainly cannot be fully addressed in a forum post, at least in my understanding. However, I assume that you are (or should be) aware of Curves/Curves+ which "provides a full analysis of groove widths and depths".

Given your deep interest in groove calculation, have you surveyed the literature? Do you know of other references than those two mentioned above? It would be helpful if you could share such information with us -- I'll consider to add the groove depth parameter if it fits in with 3DNA.

Xiang-Jun

1300

MD simulations / Re: No matching entry in atomlist.dat

« on: April 29, 2012, 08:23:33 pm »

In the default 'atomlist.dat' file, there is an entry, [.OW.   O]. Presumably, yours should be added as: [..OW   O].

DG3 and DC5 have already been included in 'baselist.dat' (as 'g' and 'c' respectively). What specific message does 'find_pair' output for your structure? Did you know that, as of 3DNA v2.1, you do not have to modify 'baselist.dat'?  Nevertheless, it is a good idea to be explicit about each mapping.

Attaching a sample PDB file would clarify the issues.

Xiang-Jun