Adding dihedral angle violations

[GoogleCodeExporter]

What steps will reproduce the problem?
1. I've had some code laying around for this but it needed debugging for which 
I only now have time.

For entry 1brv with all 48 models I get the following inconsistent result below.
The maximum violation is listed as 7.17 even thought he angle avg, min, and max 
are 
-101.85 -100.16 -100.16
So the 3 numbers are inconsistent for sure.
The first matches the one found from Tim's Analysis.

Now lets find where the inconsistency is caused...

    loop_
       _TA_constraint_stats.Restraint_ID
       _TA_constraint_stats.Torsion_angle_name
       _TA_constraint_stats.Entity_assembly_ID_1
       _TA_constraint_stats.Comp_index_ID_1
       _TA_constraint_stats.Comp_ID_1
       _TA_constraint_stats.Atom_ID_1
       _TA_constraint_stats.Entity_assembly_ID_2
       _TA_constraint_stats.Comp_index_ID_2
       _TA_constraint_stats.Comp_ID_2
       _TA_constraint_stats.Atom_ID_2
       _TA_constraint_stats.Entity_assembly_ID_3
       _TA_constraint_stats.Comp_index_ID_3
       _TA_constraint_stats.Comp_ID_3
       _TA_constraint_stats.Atom_ID_3
       _TA_constraint_stats.Entity_assembly_ID_4
       _TA_constraint_stats.Comp_index_ID_4
       _TA_constraint_stats.Comp_ID_4
       _TA_constraint_stats.Atom_ID_4
       _TA_constraint_stats.Angle_lower_bound_val
       _TA_constraint_stats.Angle_upper_bound_val
       _TA_constraint_stats.Angle_average
       _TA_constraint_stats.Angle_minimum
       _TA_constraint_stats.Angle_maximum
       _TA_constraint_stats.Max_violation
       _TA_constraint_stats.Max_violation_model_number
       _TA_constraint_stats.Over_cutoff_violation_count
       _TA_constraint_stats.Over_cutoff_violation_per_model

        1 . 1 16 CYS N  1 16 CYS CA 1 16 CYS CB 1 16 CYS SG -100.00  -20.00 -101.85 -100.16 -100.16  7.17 12  5 "[    .    1-+ *.    2    .    3    .    *  * .   ]"

Original issue reported on code.google.com by jurge...@gmail.com on 21 Jan 2009 at 3:09

[GoogleCodeExporter]

Looks like the violations are:

Doing CalcDihConstraintViolation with arguments: [5.0, 1brv_dihed_viol.str]
DEBUG: Doing constr.scList.toSTAR for scListCount: 1
DEBUG: Calculating violations for cdihs numbering: 29 in models numbering: 48
DEBUG: **** Found upp, low: -19.99999941818584, -100.0000005060238
DEBUG: **** Found value, viol: -100.15644598896294, 0.15644548293914207
DEBUG: **** Found value, viol: -101.5255778986595, 1.5255773926357081
DEBUG: **** Found value, viol: -99.95711374822528, 0.0
DEBUG: **** Found value, viol: -100.20541161512276, 0.20541110909896348
DEBUG: **** Found value, viol: -100.68275304564744, 0.6827525396236446
DEBUG: **** Found value, viol: -100.30258471644453, 0.30258421042073486
DEBUG: **** Found value, viol: -101.0241668814997, 1.024166375475902
DEBUG: **** Found value, viol: -101.02959688188986, 1.029596375866062
DEBUG: **** Found value, viol: -102.83071776602222, 2.8307172599984245
DEBUG: **** Found value, viol: -102.04734970973512, 2.047349203711322
DEBUG: **** Found value, viol: -105.15083740442716, 5.150836898403376
DEBUG: **** Found value, viol: -107.17147373829458, 7.171473232270778

So the max viol of 7.17 is indeed present and caused in model 12. 

Therefore the min max numbers must be off.

Original comment by jurge...@gmail.com on 21 Jan 2009 at 3:10

[GoogleCodeExporter]

yep, needed a swap in the code of 1 character.
Result now is:
        1 . 1 16 CYS N  1 16 CYS CA 1 16 CYS CB 1 16 CYS SG -100.00  -20.00 -101.85 -107.17  -95.92  7.17 12  5 "[    .    1-+ *.    2    .    3    .    *  * .   ]"
Min/max: -107.17  -95.92

Committed in Wattos revision 99.

I will update the NRG setup to include it after Eldon reviews the file.

Eldon could you review it please?

Original comment by jurge...@gmail.com on 21 Jan 2009 at 3:50

Attachments:

• 1brv_dihed_viol.str

[GoogleCodeExporter]

The results match those in NRG-CING at:
http://nmr.cmbi.ru.nl/NRG-CING//data/br/1brv/1brv.cing/1brv/HTML/Restraints/dihe
dral_constraint_list.html
in spot checks.

Original comment by jurge...@gmail.com on 21 Jan 2009 at 4:00

[GoogleCodeExporter]

Original comment by jurge...@gmail.com on 27 Jan 2009 at 3:27

[GoogleCodeExporter]

Committed changes in revision 118.

Original comment by jurge...@gmail.com on 28 Jan 2009 at 11:05

• Changed state: Fixed

[GoogleCodeExporter]

Check violations as in:
http://restraintsgrid.bmrb.wisc.edu/NRG/MRGridServlet?
db_username=wattos1&mrblock_id=457307&pdb_id=2rq9&request_type=block

Original comment by jurge...@gmail.com on 18 Mar 2010 at 2:11

• Changed state: Started
• Added labels: Entry-2rq9

[GoogleCodeExporter]

Original comment by jurge...@gmail.com on 18 Mar 2010 at 2:14

[GoogleCodeExporter]

Hi viol (just first 2 models):
16 PSI 1  32 ARG N 1  32 ARG CA 1  32 ARG C  1  33 SER N  133.52  163.52  
-35.01  -38.06  -31.96 164.52 1 2  [+-]  
from:
     21   LEU  PSI   133.52     163.52
So for this entry it's just a misaligned conversion by FC.
Chris can you fix this entry's alignment?

I'll keep this issue open to look for other bugs.

Original comment by jurge...@gmail.com on 22 Mar 2010 at 12:46

[GoogleCodeExporter]

found hi viols for 333 entries in NRG:
1a60 1afo 1ah1 1aj4 1amb 1az6 1azh 1b2i 1bgz 1bjx 1bla 1bvm 1bwg 1chv 1ckr 1cqg 
1e10 1el2 1eln 1etf 1eza 1f7e 1f7m 1ffm 1go0 1go1 1hks 1hpk 1hry 1i8e 1i93 1i98 
1idg 1ihv 
1iio 1jsa 1juu 1k18 1la3 1lmv 1lvz 1mit 1mpe 1ne3 1noq 1ntq 1o8y 1o8z 1olg 1oq2 
1pt4 1q10 1q1v 1qze 1r4d 1r5s 1rfl 1rqv 1rvs 1snj 1ssn 1tk7 1tns 1tut 1u34 1uab 
1ufn 1ugk 1um7 
1uwo 1v9x 1vf9 1vkr 1vmc 1vsq 1wcr 1wf7 1wfk 1wjb 1wjd 1wje 1wvk 1x43 1x44 1x45 
1x5l 1x61 1x62 1x63 1x64 1x6c 1xdx 1xfn 1xhp 1yho 1yji 1yjj 1ysf 1yui 1z1v 1z31 
1zad 1zgw 
1zwv 2a55 2agm 2asy 2b8a 2cor 2cot 2cou 2cr0 2cr2 2cr6 2cr7 2cra 2crl 2crq 2cru 
2cs2 2cs4 2cs5 2d8h 2d8i 2d8j 2d8k 2d8m 2d8x 2d8y 2d8z 2d90 2d96 2d9c 2dav 2dks 
2dl3 2dl4 
2dl5 2dl7 2dl8 2dl9 2dlo 2dlp 2dm2 2dm3 2dm4 2dm7 2dmg 2dmh 2dmj 2dn0 2dun 2e2w 
2e5p 2e6o 2e6p 2e6q 2e7b 2e7c 2e7h 2e7k 2e7m 2e7n 2e7o 2e8d 2ebt 2ebu 2ebw 2ecd 
2edf 2edl 2edn 2edo 2edt 2edv 2eel 2ekx 2el8 2enj 2enm 2enn 2ens 2ent 2env 2eny 
2enz 2eo1 2eo9 2eoc 2eod 2ep4 2ep6 2ep8 2eqi 2eqp 2eqz 2exd 2eyv 2eza 2ezh 2ezl 
2ezm 2ezo 
2ezx 2ezy 2f40 2fhm 2gbh 2ge9 2glo 2gs0 2gut 2h67 2hho 2hlt 2hlu 2hsk 2hsr 2hss 
2htf 2hv4 2ifs 2ipa 2jm0 2jn0 2jnc 2jnz 2joz 2jp0 2jp2 2jpf 2jsg 2jt2 2jtq 2jtr 
2jts 2jug 2juh 2jv1 
2jva 2jvv 2jw8 2jxo 2jxx 2jzh 2jzi 2jzn 2jzo 2k1f 2k1i 2k25 2k2e 2k2i 2k2n 2k3f 
2k3m 2k43 2k4g 2k4k 2k4m 2k50 2k52 2k57 2k5v 2k5w 2k5z 2k60 2k62 2k6u 2k7v 2k9g 
2k9o 2k9p 
2ka4 2ka6 2kan 2kcv 2kdq 2ke0 2keb 2keg 2kg4 2kgb 2kgq 2khn 2kj1 2kli 2kmg 2kmj 
2knf 2knh 2koi 2kpm 2odc 2os6 2otk 2p3m 2p89 2pku 2pn9 2po8 2rlk 2rm4 2rmx 2rn5 
2rnn 
2rno 2ror 2rq8 2stt 2w1o 2wwv 2wy2 2yqi 2yr3 2yra 2yrb 2yrc 2yre 2yrg 2yrh 2yrj 
2yrl 2ysl 2ysm 2ysq 2yst 2ysx 2yty 3eza 3gb1 3phy 7hsc

Picking 2dav:
240 PSI   1  49 TRP N  1  49 TRP CA 1  49 TRP C   1  50 MET N    105.00 -175.00 
 -14.49  -33.83  -34.56 139.96 11 20  [**********+****-****]  
from:

  49 TRP   PHI    -175.0    75.0 5.00E-01
  49 TRP   PSI     -75.0   185.0 5.00E-01
  49 TRP   PHI    -255.0   -25.0 5.00E-01 OR
  49 TRP   PSI      25.0    55.0 5.00E-01
  49 TRP   PHI    -135.0    75.0 5.00E-01 OR
  49 TRP   PSI     105.0   185.0 5.00E-01

This is blocked on issue 5 for ambi dihedral handling in NRG. 

The 333 entries can't all be like this so I keep on this.

Original comment by jurge...@gmail.com on 22 Mar 2010 at 1:06

• Added labels: Entry-2dav
• Removed labels: Entry-2rq9

[GoogleCodeExporter]

Actually, it seems the one I check by hand are all from RIKEN. They might well 
be numbered 333. End of my 
action here. 

Original comment by jurge...@gmail.com on 22 Mar 2010 at 1:10

[GoogleCodeExporter]

The format isn't described at:
http://www.cyana.org/wiki/index.php/Torsion_angle_restraint_file

Wim, does the FC handle these ambies from CYANA fine? Could we use the FC to 
parse them to STAR and 
integrate with NRG's pipeline still somehow?

Original comment by jurge...@gmail.com on 22 Mar 2010 at 1:14

[GoogleCodeExporter]

So looking at the excerpt from the file, it's OR-ing the *combinations* of 
PHI/PSI
angles? That is odd, is it not? I can easily handle different angle ranges for a
particular set of atoms that form a dihedral (after slight modifications in my 
code),
but not sets like this I'm afraid. What is the logic behind them? Is this 
chemical
shift-based?

Original comment by wfvran...@gmail.com on 30 Mar 2010 at 9:57

[GoogleCodeExporter]

It's probably enforcing Ramachandran plot preferences. Based on residue type 
perhaps but indeed perhaps 
based on CS. 
Solution: rewrite parser, add to NMR-STAR, CCPN, and CING as an alternative 
restraint type: the 
dihedralComboAmbi or so. A lot of work and the reason I left it for a while now.

Other workaround is to mark it as unparsable for now. We do need to do 
something about it because it 
certainly messes up Kent's work.

How should we prioritize this?

Original comment by jurge...@gmail.com on 30 Mar 2010 at 11:14

[GoogleCodeExporter]

Getting this into CCPN will require a model change (or addition, at least). I 
can run
it by Rasmus, but they'll have to agree, plus it'll take a while before it's in 
(next
release, at the earliest).

Are there any references about this Ramachandran plot residue preference 
forcing by
the way? I'm not against knowledge based stuff per se, but this could be a 
problem if
you actually have unusual conformations in your protein.

Original comment by wfvran...@gmail.com on 30 Mar 2010 at 12:32

[GoogleCodeExporter]

I hereby volunteer to ask the CYANA authors.

Original comment by jurge...@gmail.com on 30 Mar 2010 at 12:37

[GoogleCodeExporter]

From Peter G. with permission:

these are ambiguous torsion angle restraints with a target function term of 
(F1(f1) * ... * Fn(fn))^(-1/n)  where F1(f1) is the target function term for 
the first restraint of a torsion angle f1, etc. In this way, 
the overall restraint is fulfilled whenever at least one of the individual 
restraints is fulfilled. Ambiguous torsion angle restraints are marked by "OR" 
at the end of the individual restraints 1, 2,..., n -1. The 
last line of an ambiguous torsion angle restraint looks like a normal 
restraint. To calculate the size of the restraint violation, it is sufficient 
to take the minimal violation of any of the individual restraints that 
are combined into an ambiguous torsion angle restraint.

In your example, ambiguous torsion angle restraints for phi/psi pairs are used 
to restrain the structure to favorable regions of the Ramachandran plot. In 
general, however, these restraints are applied only 
transiently during the cooling phase of the simulated annealing, and not at the 
end of the structure calculation. This is indicated by 'type=2' after thei 
weighting factor (5.00E-01 in the example). In this 
case, the restraints should not be taken into account when calculating the 
final restraint violations because they were not active when the structure was 
written.

Original comment by jurge...@gmail.com on 1 Apr 2010 at 9:20

[GoogleCodeExporter]

I suggest that Chris reclassifies them for now to:
##### BMRB adds: PROGRAM        DYANA/DIANA
##### BMRB adds: TYPE           dihedral combo
##### BMRB adds: SUBTYPE        ambi
##### BMRB adds: FORMAT         n/a
and we don't parse/handle them. This way the hi violations will disappear and 
we don't punish other hi violating 
restraints that were not enforced in the final refinement.

Original comment by jurge...@gmail.com on 1 Apr 2010 at 9:26

[GoogleCodeExporter]

Fine with me!

Original comment by wfvran...@gmail.com on 1 Apr 2010 at 12:14

[GoogleCodeExporter]

I like that too. Let me know when mrannotator can handle dihedral combo.

Original comment by schulte....@gmail.com on 1 Apr 2010 at 1:13

[GoogleCodeExporter]

Go ahead and update the csv file with that definition and commit it to Google 
Code.
Make sure to rebuild the jar file 'cause it needs to have that updated csv file.

Original comment by jurge...@gmail.com on 1 Apr 2010 at 1:20

[GoogleCodeExporter]

Unless there is a particular reason, I would suggest spelling out ambi as 
ambiguous.

Original comment by Eldon.Ul...@gmail.com on 1 Apr 2010 at 3:16

[GoogleCodeExporter]

Oops, Thought we were being asked to add terms to the enumerations for the tags 
for
type and subtype.

Just one point of clarification; these 'restraints' would be included in the 
NMR-STAR
outputs, but listed in a text block and not included in the actual restraints 
values?

Original comment by Eldon.Ul...@gmail.com on 1 Apr 2010 at 3:27

[GoogleCodeExporter]

Correct Eldon.
Thanks for updating the CSV file Chris!

I agreed with Chris to first get rid of the ambi dihedrals and then I will 
debug the violation reporting code.

Original comment by jurge...@gmail.com on 14 Apr 2010 at 2:18

[GoogleCodeExporter]

All the explicit ambi dihedrals that I could find were in diana format. In 
total, there were 129 of them. These 
have been converted to dihedral combo. The ambiguous angles were always phi and 
psi, and they were almost 
always followed by a block of unambiguous chi* angles.

 The converted:
2e7b 2ep6 1ufn 1v9x 1wfk 1x43 1x44 1x45 1x5l 1x61 1x62 1x63 1x64 1zwv
2asy 2cor 2cot 2cou 2cr0 2cr2 2cr6 2cr7 2cra 2crl 2crq 2cru 2cs2 2cs4
2cs5 2d8h 2d8i 2d8j 2d8k 2d8m 2d8x 2d8y 2d8z 2d90 2d96 2d9c 2dav 2dks
2dl3 2dl4 2dl5 2dl7 2dl8 2dl9 2dlo 2dlp 2dm2 2dm3 2dm4 2dm7 2dmg 2dmh
2dmj 2dn0 2dun 2e2w 2e6o 2e6p 2e6q 2e7c 2e7h 2e7k 2e7m 2e7n 2e7o 2ebt
2ebu 2ebw 2ecd 2edf 2edl 2edn 2edo 2edt 2edv 2eel 2ekx 2el8 2enj 2enm
2enn 2ens 2ent 2env 2eny 2enz 2eo1 2eo9 2eoc 2eod 2ep4 2ep8 2eqi 2eqz
2exd 2jpf 2juh 2jw8 2k4m 2k9g 2k9p 2kan 2ke0 2keg 2kg4 2kgb 2rlk 2rmx
2ror 2rq8 2yqi 2yr3 2yra 2yrb 2yrc 2yre 2yrg 2yrh 2yrj 2yrl 2ysl 2ysm
2ysq 2yst 2ysx

Original comment by schulte....@gmail.com on 15 Apr 2010 at 4:35

[GoogleCodeExporter]

Nice job, now I can continue debugging the remaining violations.

Original comment by jurge...@gmail.com on 22 Apr 2010 at 2:28

[GoogleCodeExporter]

This weeks entry 2kwb had one I should fix:
270 . 1 133 PHE CA 1 133 PHE CB 1 133 PHE CG  1 133 PHE CD1   60.00  100.00   
72.30  -84.10   87.32 144.10  
6 2 "[    .+   1    .  - 2]"

Original comment by jurge...@gmail.com on 29 Apr 2010 at 1:44

• Added labels: Entry-2kwb

[GoogleCodeExporter]

May I suggest we eliminate my buggy code for dihedral angle violations in NRG. 
I am working on getting it right in NRG-CING but don't have the time to do the 
same for NRG.

The problem with the ambi dihedral restraints can be fixed by updating the data 
models and parser code.

Original comment by jurge...@gmail.com on 20 Sep 2010 at 9:06

• Changed state: WontFix

[GoogleCodeExporter]

This is continued for NRG-CING at isssssue 231:
http://code.google.com/p/cing/issues/detail?id=231

Original comment by jurge...@gmail.com on 24 Sep 2010 at 8:14

[GoogleCodeExporter]

To remove them from the database in one blow use:

mysql -h localhost -u wattos1 -p4I4KMS wattos1

select * from mrblock where program = 'Wattos' and format = 'dihedral angle';
And then if you are comfortable enough etc. do the actual delete. This can not 
be undone!
delete from mrblock where program = 'Wattos' and format = 'dihedral angle';

Original comment by jurge...@gmail.com on 24 Sep 2010 at 8:33

[GoogleCodeExporter]

- Fixed in Wattos revvvvision 138 finally. Tested with 2kwb DOCR file included 
with the commit.
  Test with macro CalcDihConstrViolation.wcf from ant target for from Junit test in File31Test.java
  Now for any PHE/TYR chi-2 both violations are calculated and the dihedral with the smallest violation is picked.

Chris, regenerate the Wattos.jar after updating from Wattos svn repository. 
Then all entries should be rerun. Actually, only the Wattos violation 
calculation step needs to be redone of course.

Original comment by jurge...@gmail.com on 28 Sep 2010 at 12:51

• Changed state: Fixed

[GoogleCodeExporter]

Will do. Where is CalcDihConstrViolation.wcf? I don't see it in 
/raid/docr/workspace/nmrrestrntsgrid/scripts/wcf or 
/raid/docr/workspace/wattos/scripts.

Original comment by schulte....@gmail.com on 28 Sep 2010 at 1:51

[GoogleCodeExporter]

It's in this commit as well:
http://code.google.com/p/wattos/source/detail?r=138

Original comment by jurge...@gmail.com on 28 Sep 2010 at 2:31

[GoogleCodeExporter]

The "MACRO FILE EXECUTION" section in buildEclipse.xml causes buildMadison.xml 
to fail when it is added, but it doesn't seem to be necessary. I was able to 
run CalcDihConstrViolation.wcf and got a Viol_max of 7.84. I see 
CalcDihConstraintViolation is in the existing CalcConstrViolation.wcf. 

Original comment by schulte....@gmail.com on 28 Sep 2010 at 6:20

[GoogleCodeExporter]

I recalculated the violations of the ~300 bad dihedral angle violations. Many 
of these were fixed, but there are still ~250 entries with hi dihedral angle 
violations.

Original comment by schulte....@gmail.com on 4 Oct 2010 at 3:45

[GoogleCodeExporter]

Can you file a report on one of them here? Is it still the same problem then?

Original comment by jurge...@gmail.com on 4 Oct 2010 at 5:01

• Changed state: Started

[GoogleCodeExporter]

2joz - violation is in psi bond Tyr84-Pro85 
        96 . 1  84 TYR N 1  84 TYR CA 1  84 TYR C  1  85 PRO N  110.10  147.00 -170.57  166.51    2.64 146.65  1 20  [+**************-****]  
---

2h67 - Tyr14 - N-CA-CB-CG - Chi1? violation = 138.14
---
2jzi - I think this one is an unresolvable mapping issue! The original file has 
molecule A and molecule B, both of which would be mapped with ['a', ' ', 1, 0]. 
The numbers for the violations look like they are taking the restraints for 
molecule B and mapping them to molecule A.
---

2hac - ILE 18  N-CA-CB-CG: violation = 96.47. Phe13 violation = 96.06 

Original comment by schulte....@gmail.com on 4 Oct 2010 at 8:35

[GoogleCodeExporter]

Thanks for checking on these Chris

2joz - violation is in psi bond Tyr84-Pro85 
        96 . 1  84 TYR N 1  84 TYR CA 1  84 TYR C  1  85 PRO N  110.10  147.00 -170.57  166.51    2.64 146.65  1 20  [+**************-****]  
---
Original data:
assign ( resid   84 and name N    )   ( resid   84 and name CA   ) 
        (resid   84 and name C    )   ( resid   85 and name N    )  1  128.55   18.45 2
Seems to be fine.
Violation is same as in NRG-CING:
http://nmr.cmbi.ru.nl/NRG-CING/data/jo/2joz/2joz.cing/2joz/HTML/Restraints/dihed
ral_constraint_list.html#_top
No action needed.

2h67 - Tyr14 - N-CA-CB-CG - Chi1? violation = 138.14
Original data:
assign (resid 14 and name N) (resid 14 and name CA) 
       (resid 14 and name CB) (resid 14 and name CG) 1.0 180.0 40.0 2
Violation Wattos:
       37 . 1 14 TYR N  1 14 TYR CA 1 14 TYR CB  1 14 TYR CG   140.00 -140.00 -174.16  173.14    1.86 138.14  1  6 "[+*  .    *   -.*   *]" 
Violation is same as in NRG-CING:
http://nmr.cmbi.ru.nl/NRG-CING/data/h6/2h67/2h67.cing/2h67/HTML/Restraints/dihed
ral_constraint_list.html#_top
Also checking this one by hand (see attachement) shows we're correct here.

---
2jzi - I think this one is an unresolvable mapping issue! The original file has 
molecule A and molecule B, both of which would be mapped with ['a', ' ', 1, 0]. 
The numbers for the violations look like they are taking the restraints for 
molecule B and mapping them to molecule A.
---
E.g.:
        12 . 1   4 LEU N  1   4 LEU CA 1   4 LEU C  1   5 THR N    -52.60  -23.40  164.76  164.81  164.79 142.77  5 20  [****+********-******]  
Again the same in CING:
http://nmr.cmbi.ru.nl/NRG-CING/data/jz/2jzi/2jzi.cing/2jzi/HTML/Restraints/dihed
ral_constraint_list.html#_top
But you're right, the input is indistinguishable between the monomers. Wonder 
how the authors really fed this into the structure calculation program.

Could you check the last one in Pymol or so? If this one is ok then we consider 
this issue close.

Thanks Chris!

Original comment by jurge...@gmail.com on 5 Oct 2010 at 8:54

Attachments:

• [Picture 1.png](https://storage.googleapis.com/google-code-attachments/nmrrestrntsgrid/issue-162/comment-37/Picture 1.png)

[GoogleCodeExporter]

2jzi - I think this one is an unresolvable mapping issue! The original file has 
molecule A and molecule B, both of which would be mapped with ['a', ' ', 1, 0]. 
The numbers for the violations look like they are taking the restraints for 
molecule B and mapping them to molecule A.
---
E.g.:
        12 . 1   4 LEU N  1   4 LEU CA 1   4 LEU C  1   5 THR N    -52.60  -23.40  164.76  164.81  164.79 142.77  5 20  [****+********-******]  
Again the same in CING:
http://nmr.cmbi.ru.nl/NRG-CING/data/jz/2jzi/2jzi.cing/2jzi/HTML/Restraints/dihed
ral_constraint_list.html#_top
But you're right, the input is indistinguishable between the monomers. Wonder 
how the authors really fed this into the structure calculation program.

I'm guessing they processed these in two different files with different 
parameters set. I'll check a few more today to make sure a good random sampling 
shows that we're OK. 

I've been looking for documentation on XPLOR-CNS file formats, but all I find 
are manuals on setting up processing parameters. Does anyone have, or know 
where to get a good description?

Original comment by schulte....@gmail.com on 5 Oct 2010 at 12:57

[GoogleCodeExporter]

You can find many good things starting from the NOE distance restraint section 
at:
http://nmr.cit.nih.gov/xplor-nih/doc/current/xplor/node376.html
It's only 18 years old ;-)

Atom selections are examplified here:
http://nmr.cit.nih.gov/xplor-nih/doc/current/xplor/node40.html

Original comment by jurge...@gmail.com on 5 Oct 2010 at 1:20

[GoogleCodeExporter]

Thanks!

Original comment by schulte....@gmail.com on 5 Oct 2010 at 4:31

[GoogleCodeExporter]

Can we close this issue?

Original comment by jurge...@gmail.com on 11 Oct 2010 at 12:46

[GoogleCodeExporter]

I

Original comment by schulte....@gmail.com on 23 Feb 2011 at 3:50

• Changed state: Fixed