Need to interpret the phenyl ring protons without stereospecificity for distances and dihedral violation analysis

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Verify buguous reporting of phenyl ring proton distance violation:
http://nmr.cmbi.ru.nl/NRG-
CING/data/kn/2knr/2knr.cing/2knr/HTML/Restraints/distance_constraint_list.html#_
o9466

771 A PHE37 HD1 A LEU96 HA  1.8 5.0 4.3+-1.0    0.2+-0.8    3.7 1   
violMax: 3.67
violSd: 0.82

What is the expected output? What do you see instead?
The restraint from:
assign ( resid   37 and name HD1  )   ( resid   96 and name HA   )   4.00  2.20 
 1.00

Measured in Pymol to NOT violate in any model.

Please use labels and text to provide additional information.

Original issue reported on code.google.com by jurge...@gmail.com on 15 Mar 2010 at 1:41

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Also in AstexViewer, it doesn't violate.

Chris

Original comment by chris.pe...@gmail.com on 14 Apr 2010 at 3:21

[GoogleCodeExporter]

Issue 165 has been merged into this issue.

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

[GoogleCodeExporter]

Wim has worked on his code for doing this.
I'm checking ccpnmr.format.process.stereoAssignmentSwap

Before the check simply failed for entries
[AR3436ALyon3, AtT13Lyon3, AtT13Paris, CGR26AParis, CtR69ALyon,
CtR69ALyon2, CtR69AParis, ET109AredLyon, HR5537ALyon3, NeR103ALyon,
NeR103ALyon2, VpR247Lyon3]
but this is reportedly fixed.

Original comment by jurge...@gmail.com on 30 Apr 2010 at 5:16

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

AtT13Lyon3 runs thru fine.
The hi violations were reduced from:

rmsd     0.273 +- 0.025
violations <-0.1 A (lower-bound violations)  16
violations > 0.1 A   5553
violations > 0.3 A   4041
violations > 0.5 A   3299

to:
rmsd     0.061 +- 0.008
violations <-0.1 A (lower-bound violations)  18
violations > 0.1 A   1270
violations > 0.3 A   399
violations > 0.5 A   198

Some very hi violations remain that in my Wattos code would probably have been 
reduced because it would simply deassign them if they are this 
high:

#    ch1     ri1     rn1     at1     ch2     ri2     rn2     at2     low     upp     av  sd  min     max     vAv     
vSd  vMx     c1  c3  c5  Critique
851  
A   89  LEU QD2 A   99  LEU QD1 1.80    4.87    4.58    1.16    2.31    6.68    0.32    0.55    1.81    6   6   6   
violMax: 1.81
violSd: 0.55
2078     
A   52  LEU QD2 A   88  LEU QD1 1.80    4.03    3.67    1.07    2.11    5.83    0.26    0.62    1.80    3   3   3   
violMax: 1.80
violSd: 0.62
1055     
A   42  ARG HG2 A   52  LEU QD2 1.80    5.50    4.35    1.58    2.08    7.23    0.25    0.62    1.73    3   3   3   
violMax: 1.73
violSd: 0.62
1150     
A   30  LYS HD2 A   99  LEU QD2 1.80    4.48    4.55    0.85    2.93    6.00    0.36    0.50    1.52    11  5   5   
violMax: 1.52
violSd: 0.50

I need to check this further but a huge improvement already though.

Original comment by jurge...@gmail.com on 30 Apr 2010 at 5:30

• Changed state: Started

[GoogleCodeExporter]

Original comment by jurge...@gmail.com on 22 Sep 2010 at 2:52

• Removed labels: Milestone-Release-CASD-NMR

[GoogleCodeExporter]

This takes over from NRG:
http://code.google.com/p/nmrrestrntsgrid/issues/detail?id=162

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

[GoogleCodeExporter]

For entry 2knr, I have tried to solve this stereospecific assignment (SSA) 
issue with the FC code in:
from ccpnmr.format.process.stereoAssignmentSwap import 
StereoAssignmentSwapCheck (Working revision:    1.17.4.5)
It is deassinging:
771 A PHE37 HD1 A LEU96 HA
to QD.
But it's not doing it for all A PHE37 HD1, just for the violated restraint 
occurrences.
That makes the data kinda inconsistent which I would like to see resolved.

Another problem is the violation as in the attachment shown from Analysis.
2629.00  
A   17  PHE HD1 A   24  ALA HN  1.80    6.00    8.11        8.11    8.11    2.11        2.11    1   1   1   violMax: 
2.11
2629.01 A   17  PHE HE1 A   24  ALA HN  1.80    6.00    8.11        8.11    8.11    2.11        2.11    1   1   1   viol
Max: 2.11
The HD1 has been deassigned to HD1/HE1 whereas I would expect it to deassign to 
QD as above for PHE37.

Can we work on this Wim?
I'm going to get started on solving the dihedral angle violation issues for the 
PHE/TYR rings issue 259.

Original comment by jurge...@gmail.com on 24 Sep 2010 at 11:07

Attachments:

• [Picture 2.png](https://storage.googleapis.com/google-code-attachments/cing/issue-231/comment-9/Picture 2.png)

[GoogleCodeExporter]

Before I start to change anything I have to be sure that I'm not going to mess 
things up completely.... so what I do in my code now is:

1. Check whether prochirals/aromatics get 'better' by swapping. If so, swap 
'em. This works pretty well I think

2. Look at violated constraints, and deassign the prochiral/aromatic FOR THAT 
CONSTRAINT if it's violated by more than 1.0 angstrom in any structure or by 
more then 0.5 in half of structures.

-> So right now I'm only deassigning within the SINGLE CONSTRAINT if there is a 
problem. Do you want me to deassign ALL constraints for that prochiral/aromatic 
as soon as there is one constraint with a problem?

It's too long ago since I wrote this code, so I can't remember the original 
reasons for doing it this way, but I assume that's how it was meant to be at 
the time based on the pseudocode I got from you or Aart.

Original comment by wfvran...@gmail.com on 27 Jan 2011 at 3:24

[GoogleCodeExporter]

I understand the code you wrote. Indeed we think it's better to treat the 
assignments the same over all restraints. That way we get no inconsistencies in 
the peak assignments which result in inconsistent restraints. Kinda like CCPN 
treats resonances I guess. 

Is that something you like for NRG-CING? Alternatively, we could take FRED data 
instead of DOCR data for which this correction has already been performed.

Original comment by jurge...@gmail.com on 31 Jan 2011 at 9:13

[GoogleCodeExporter]

OK that makes sense, I can adapt the code, much easier to deal with it that way 
anyway. I'll make sure you keep the original option (only the restraints 
modified) or the new one (all related assignments modified).

Original comment by wfvran...@gmail.com on 31 Jan 2011 at 2:33

[GoogleCodeExporter]

Wim, would you be willing to look at my algorithm at:
http://nmr.cmbi.ru.nl/~jd/wattos/doc/Wattos/Soup/Constraint/AssignStereo.html#do
AssignStereo(float, float, float, float, float, float, java.lang.String) 

Perhaps you could implement it in CCPN? The main advantage would be to base the 
decision on all involved restraints and not just the one restraint and then 
propagate. This is Geerten's preference as well.

If you like we can skype about this.

Original comment by jurge...@gmail.com on 1 Feb 2011 at 1:35

[GoogleCodeExporter]

Also, we should generate some computer parsable output (e.g. xml) like:

http://restraintsgrid.bmrb.wisc.edu/NRG/MRGridServlet?db_username=wattos1&format
=distance&mrblock_id=379535&pdb_id=1hue&request_type=block&subtype=stereo+assign
ment&type=check

Original comment by jurge...@gmail.com on 1 Feb 2011 at 1:48

[GoogleCodeExporter]

OK but I'm not sure I'm completely following here. There are two issues:

1. Swapping prochiral assignments
2. Deassigning constraints

The link you sent me deals with the swapping as far as I can see, I can adapt 
my code to do it in the same order, but of course always a hassle in CCPN with 
the resonances and all that.

I've been changing my code today to do 2. for either:

- Just the violated constraints.
- All constraints involving the prochiral that needs to be deassigned.

Original comment by wfvran...@gmail.com on 2 Feb 2011 at 3:09

[GoogleCodeExporter]

About comment 14, I can write out an XML file... the only thing are the 
'energies' - is this the energy you'd get if you were using a square well type 
potential with a certain energy constant? If so, I'd like to discuss that some 
more, people use different settings of course, and we'll start to get 
structures with logNormal constraints, where this is completely not useful 
(neither is the concept of a clear violation of course, so that would be an 
issue anyway...).

Original comment by wfvran...@gmail.com on 2 Feb 2011 at 3:36

[GoogleCodeExporter]

wrt comment 15: The Wattos routine documentation also has a paragraph on the 
deassign:

Consecutively deassign the triplets if they meet the violation criteria set. If 
a single restraint in a single model is violated more than the parameter 
single_model_violation_deassign_criterium Angstrom, then all restraints 
involved with this triplet will be deassigned for the ambiguity in this 
triplet. If a single restraint violates more than parameter 
multi_model_rel_violation_deassign_criterium percent of the models more than 
multi_model_violation_deassign_criterium Angstrom then all restraints involved 
with this triplet will be deassigned for the ambiguity in this triplet.

wrt comment 16: Indeed the energy is the same as a SUM averaged square well but 
without a scaling energy constant. Hit me on Skype to discuss further. Great 
that we can have the XML output.

Original comment by jurge...@gmail.com on 3 Feb 2011 at 8:49

[GoogleCodeExporter]

Ah yes I didn't look at the running text, only the pseudocode.

So do you recalculate all violations after a deassign or swap? Or just do 
everything in the first iteration, then a second run with all changed 
deassign/swap?

Original comment by wfvran...@gmail.com on 3 Feb 2011 at 9:22

[GoogleCodeExporter]

I calculate the violations for each triplet when I deal with them. Technically 
that's not recalculating but it doesn't matter. I do not iterate. I tried but 
found no iterations necessary. 

Just to be clear. For triplet 2 I do take the corrected state for a triplet 1 
for all restraints involved.

Original comment by jurge...@gmail.com on 3 Feb 2011 at 9:31

[GoogleCodeExporter]

OK results for the 2knr project I have. I've compared it to the output you have 
on NRG for FRED, and it's generally similar but there are differences, I 
suspect in large part because my restraints are not 'filtered'. Anyway I've 
attached the output, but we need a better comparison point... also there might 
be an issue with the Phe/Tyr protons - it only really makes sense to deassign 
to the QR, no? I'm treating the HD/HE together for that purpose... .

Original comment by wfvran...@gmail.com on 23 Feb 2011 at 11:52

Attachments:

• 2knr.new.out

[GoogleCodeExporter]

Nice Wim

You're right about the deassignment of the Phe/Tyr protons. My report in NRG 
looks as if it was swapped but that's not important since it got deassigned 
anyway. In NRG only to a pseudo with 2 hydrogens but in FC to a pseudo with 4 
hydrogens which is fine.

FC lists 136 'triplets' whereas Wattos lists 142.There are 6 extra triplets in 
Wattos because of the 8 Phe/Tyr. The Phe 40 and 95 have no QE, did you deassign 
to QR anyway in these residues? Shouldn't be, can you improve reporting for 
them? Perhaps use NMR-STAR with similar tags as in NRG but you can also use xml 
if you prefer. I would like to make it part of the human readable output of FC 
so perhaps best to use NMR-STAR like you kinda have now. Also, you or I can add 
the overview we have in NRG like:

    _Stereo_assign_list.Triplet_count        142
    _Stereo_assign_list.Swap_count           2
    _Stereo_assign_list.Swap_percentage      1.4
etc.

I'm gonna run Wattos assignment routines on the DOCR files of on our regular 
bunch now so we can do exact comparisons ok?

Original comment by jurge...@gmail.com on 23 Feb 2011 at 1:57

[GoogleCodeExporter]

I do deassign stand-alone QE or QD to QR if required... what is the difference 
with the case where you have both QE and QD available?

I can certainly change the output, I will also tag objects inside the CCPN 
project to track what happened.

Original comment by wfvran...@gmail.com on 23 Feb 2011 at 2:15

[GoogleCodeExporter]

>I do deassign stand-alone QE or QD to QR if required... what is the difference 
with the case where you have both QE and QD available?
Let's discuss this on Skype.

Can you run on the CCPN XML project from DOCR on the same entries as I will for 
Wattos.
The list I got is:
1a24 1a4d 1afp 1ai0 1b4y 1brv 1bus 1c2n 1cjg 1d3z 1hue 1ieh 1iv6 1jwe 1kr8 2cka
2fws 2hgh 2jmx 2k0e 2kib 2knr 2kz0 2rop
The data is temporarily in:
http://nmr.cmbi.ru.nl/~jd/tmp/docr.zip

We can first focus on 2knr if you prefer.

Original comment by jurge...@gmail.com on 23 Feb 2011 at 2:29

[GoogleCodeExporter]

O, just realized something. 
> I suspect in large part because my restraints are not 'filtered'.
The DOCR restraints is what NRG uses for the stereo assignment check. So there 
should be no differences from our input. The only difference I can see are if 
the import of NMR-STAR into Wattos was not complete. This happens for a few 
entries.

I've checked in the log on grunt.bmrb.wisc.edu:
/raid/docr/NRG/assign/2knr/2knr.log
to see it reads the FC produced STAR directly:
Doing ReadEntryNMRSTAR with arguments: 
[file:/raid/docr/NRG/star/2knr/2knr_merge.str, null, true, true, true, true, 
true]

So it should have all 4062 restraints for this entry.
Funny that the file /raid/docr/NRG/star/2knr/2knr_merge.str contains 2 times a 
saveframe with those 4062 restraints.  One time: 
save_CNS/XPLOR_distance_constraints_3 and one time 
save_CNS/XPLOR_distance_constraints_3_1. Anyway, that's the STAR...

So can you compare again where the differences come from knowing that the input 
should have been the same?

Original comment by jurge...@gmail.com on 23 Feb 2011 at 2:51

[GoogleCodeExporter]

OK got the file, I'll run it on all these entries.

Original comment by wfvran...@gmail.com on 23 Feb 2011 at 2:51

[GoogleCodeExporter]

About 2knr, I'm not sure. The number of counted constraints for each triplet is 
already different, and I am sure that I did count those correctly. I have more 
than you, but if you look at the originally deposited file:

http://restraintsgrid.bmrb.wisc.edu/NRG/MRGridServlet?block_text_type=1-original
&db_username=wattos1&file_detail=1-original&format=simple&mrblock_id=275136&pdb_
id=2knr&request_type=block&subtype=NOE&type=distance

and count the number of constraints for 4 MET HB*, which in the file is:

resid    1 and name HB

I do count 7, as reported in my file.

I'm attaching an updated output for 2knr by the way, noticed some small 
problems.

Original comment by wfvran...@gmail.com on 23 Feb 2011 at 3:46

Attachments:

• 2knr.new2.out

[GoogleCodeExporter]

>I do count 7,
Wattos includes the ambis itself:
assign ( resid    1 and name HB*  )   ( resid    2 and name HN   )   4.00  2.20 
 1.00
assign ( resid    1 and name HB*  )   ( resid    2 and name HB*  )   4.00  2.20 
 2.00
assign ( resid    1 and name HB*  )   ( resid    3 and name HB2  )   4.00  2.20 
 2.00
assign ( resid    1 and name HB*  )   ( resid    3 and name HB1  )   4.00  2.20 
 2.00
assign ( resid    1 and name HB*  )   ( resid    3 and name HD*  )   4.00  2.20 
 1.00
which doesn't matter for the difference of the energies between the 2 states.

When comparing from your new log 
  A   11   Phe  HB*        False  100.0    7.502  23  20 False   0   0
with Wattos:
       1  11 PHE QB  35 no  100.0  99.8  6.351  6.361  0.010 23  6 no  0.185   0   0 

The energy difference is 7.502 in FC instead of 6.351 in Wattos.
We both count 23 restraints but Wattos classifies 6 and FC 3 (23-20) of them as 
ambi.

Checking manually, I think your FC is correct. I'll go and check my Wattos 
code! No clue how I would get to 6.

assign ( resid    8 and name HB2  )   ( resid    8 and name HD1  )   4.00  2.20 
 1.00
assign ( resid    5 and name HA   )   ( resid    8 and name HB1  )   4.00  2.20 
 1.00
assign ( resid    3 and name HD1* )   ( resid    8 and name HB2  )   4.00  2.20 
 1.00 # not ambi Leu6 MD1
assign ( resid    5 and name HA   )   ( resid    8 and name HB2  )   4.00  2.20 
 1.00
assign ( resid    3 and name HB2  )   ( resid    8 and name HB1  )   4.00  2.20 
 2.00
assign ( resid    8 and name HB1  )   ( resid   36 and name HB   )   4.00  2.20 
 2.00
assign ( resid    3 and name HB2  )   ( resid    8 and name HB2  )   4.00  2.20 
 1.00
assign ( resid    3 and name HB1  )   ( resid    8 and name HB2  )   4.00  2.20 
 2.00
assign ( resid    3 and name HD2* )   ( resid    8 and name HB2  )   4.00  2.20 
 1.00 # not ambi Leu6 MD2 
assign ( resid    8 and name HB2  )   ( resid   36 and name HD1* )   4.00  2.20 
 1.00 # not ambi Ile39 MD1
assign ( resid    8 and name HB1  )   ( resid   36 and name HD1* )   4.00  2.20 
 1.00 # not ambi Ile39 MD1
assign ( resid    5 and name HN   )   ( resid    8 and name HB1  )   4.00  2.20 
 2.00
assign ( resid    8 and name HB2  )   ( resid    9 and name HN   )   4.00  2.20 
 1.00
assign ( resid    8 and name HB1  )   ( resid    9 and name HN   )   4.00  2.20 
 1.00
assign ( resid    8 and name HN   )   ( resid    8 and name HB1  )   3.00  1.20 
 0.50
assign ( resid    8 and name HN   )   ( resid    8 and name HB2  )   3.00  1.20 
 0.50
assign ( resid    7 and name HN   )   ( resid    8 and name HB2  )   4.00  2.20 
 2.00
assign ( resid    3 and name HN   )   ( resid    8 and name HB2  )   4.00  2.20 
 1.00
assign ( resid    8 and name HB1  )   ( resid   10 and name HN   )   4.00  2.20 
 2.00
assign ( resid    6 and name HN   )   ( resid    8 and name HB1  )   4.00  2.20 
 2.00
assign ( resid    3 and name HD*  )   ( resid    8 and name HB1  )   4.00  2.20 
 1.00 # ambi Leu6 QD
assign ( resid    8 and name HB2  )   ( resid    9 and name HG*  )   4.00  2.20 
 1.00 # ambi Val12 QD
assign ( resid    8 and name HB1  )   ( resid    9 and name HG*  )   4.00  2.20 
 1.00 # ambi Val12 QD 

Do you use sum averaging as I suspect? Do you include lower bound violations to 
the energy term? I might have wanted to ignore those here.

Good exercise!

Original comment by jurge...@gmail.com on 23 Feb 2011 at 4:54

[GoogleCodeExporter]

Indeed good to be double-checking this... and yes I check for lower bound 
violations, shall I switch that off?

Original comment by wfvran...@gmail.com on 23 Feb 2011 at 7:57

[GoogleCodeExporter]

Here the results of all the entries... .

Original comment by wfvran...@gmail.com on 23 Feb 2011 at 8:32

Attachments:

• test1.tgz

[GoogleCodeExporter]

> yes I check for lower bound violations, shall I switch that off?
Wattos also does the lower bound violations so keep it on.

The energy differences depend on previous swap/deassigns so they might be off 
for that reason. This is the explanation for the inconsistency in comment 27.

Wattos reports the order in which they are processed with the tag 
_Stereo_assign.Num could you add that?

FC probably does this triplet first:
  A  115   Leu  HD*        False   90.0    0.000  80  34 False   0   0
since it has 80 involved restraints. However Wattos did that one fifth 
 1 115 LEU QD   5 no  100.0   0.0  0.000  0.127  0.127 38 12 no  0.423   0   0 
because it only counted 38 restraints total. Checking by hand in the original 
data I see FC is right again. 
Pfff, I found that Wattos does:

     * Remove all restraints from triplet that are ambi in the triplet because those types of restraints don't need to
     * be considered. E.g. for triplet VAL QG a restraint VAL QG <-> GLY H will be removed but a restraint VAL MG <->
     * GLY H will not.

Would this matter much? Only changes ordering slightly. Can you reorder on this 
easily?
Can you make your exact cutoffs the same as Wattos at least for comparing our 
algorithms for now?

Also Wattos routines try the whole list first for swapping first. Then and only 
then it will go over the list of triplets again to deassign. Is that what you 
do?

We do get differences like the 
  A    6   Leu  HB*        False   90.0    8.957  26  19 False   0   0
Wattos swaps:
       1   6 LEU QB  22 no   90.0  78.6  8.803 11.204  2.402 26 10 yes 2.200  11  11 
and gets rid of the 2.200 Ang. violation (nice to add to your table too?) that 
way.

Another important difference is:
  A   41   Val  HG*        False   90.0    0.000  76  30 True    2   0
which Wattos maintains the SSA
       1  41 VAL QG  11 no  100.0   0.0  0.000  0.020  0.020 30 14 no  0.202   0   0 
since there are no significant violations. Perhaps a round-off caused FC to 
deassign?

Thanks for going in detail here Wim!

Original comment by jurge...@gmail.com on 24 Feb 2011 at 10:07

[GoogleCodeExporter]

OK, I will modify and rerun. At the moment I do the deassigning while swapping, 
so I'll build in a second loop for deassigning... .

Original comment by wfvran...@gmail.com on 24 Feb 2011 at 11:21

[GoogleCodeExporter]

Attached a reworked list, for 2knr only at the moment. So this is with first 
doing swaps, then deassigns, and with priority changed as per previous 
discussion. There remain differences, some deassigns don't happen in my case... 
also note that I added the maximum violation, and that I count large violations 
(more than 2.0 angstrom) and small ones (between 1.0 and 2.0) separately.

As a sidenote - the number of ambiguous constraints I list are based on the 
original count, not the one after all the deassigning has been done. This can 
be changed of course if necessary, but I think the original data makes more 
sense (as this is what the swap/deassign was based on).

Original comment by wfvran...@gmail.com on 24 Feb 2011 at 12:53

Attachments:

• 2knr.new5.out

[GoogleCodeExporter]

>So this is with first doing swaps, then deassigns, and with priority changed 
as per previous discussion.
Nice!

>also note that I added the maximum violation,
Nice but they differ from Wattos. Wattos uses:
* 15 * Maximum unaveraged violation before deassignment (Ang.)

Do you list the post processing violation perhaps?

You get zero in:
  A    6   Leu  HD*         11 False   80.0    0.000  34   4 False   0.000   0   0
Wattos lists 1.651:
      1   6 LEU QD   8 no    5.0   0.0  0.000  1.649  1.649 34 14 yes 1.651  19  22 
Looking at the DOCR CCPN project with Analysis I do get violations but only 
ones that will be fixed by the SSA fixes.

Perhaps you averaged the violation over all models whereas I report the single 
highest one. Again, hard to compare then. Can you add the highest one as well 
just for our comparison?

I think that the code already looks very useful. Time to check in and let me 
know how I can call it. Is it still in:

$CINGROOT/python/cing/Scripts/FC/utils.py -> from 
ccpnmr.format.process.stereoAssignmentSwap import StereoAssignmentSwapCheck

I call that like:
        nmrConstraintStore = ccpnProject.findFirstNmrConstraintStore()
        structureEnsemble = ccpnProject.findFirstStructureEnsemble()
        numSwapCheckRuns = 3
        if nmrConstraintStore:
            if structureEnsemble:
                swapCheck(nmrConstraintStore, structureEnsemble, numSwapCheckRuns)
            else:
                NTmessage("Failed to find structureEnsemble; skipping swapCheck")
        else:
            NTmessage("Failed to find nmrConstraintStore; skipping swapCheck")
#        constraintsHandler.swapCheck(nmrConstraintStore, structureEnsemble, 
numSwapCheckRuns)

and

    swapCheck = StereoAssignmentSwapCheck(nmrConstraintStore,structureEnsemble,verbose = True)

#    violationCodes = {'xl': {'violation': 1.0, 'fraction': 0.00001},
#                      'l': {'violation': 0.5, 'fraction': 0.5}}
    # Use more restrictive cutoffs than the above defaults.
    violationCodes = {'xl': {'violation': 0.5, 'fraction': 0.00001},
                      'l': {'violation': 0.3, 'fraction': 0.5}}

    for _swapCheckRun in range(0,numSwapCheckRuns):
      swapCheck.checkSwapsAndClean(violationCodes = violationCodes)

Thanks Wim!

Original comment by jurge...@gmail.com on 24 Feb 2011 at 1:49

[GoogleCodeExporter]

The violation is post-swapping, pre-deassigning, and it should be the maximum 
one.

To run the new code:

from ccpnmr.format.process.stereoAssignmentSwap import StereoAssignmentCleanup

then use that instead of StereoAssignmentSwapCheck. Note that the top example 
the swapCheck call containing the numSwapCheckRuns is a different bit of code, 
just do the same there as in the bottom bit.

Original comment by wfvran...@gmail.com on 24 Feb 2011 at 2:29

[GoogleCodeExporter]

> The violation is post-swapping, pre-deassigning, and it should be the maximum 
one.
Could you make it pre-both?

> To run the new code:
Testing now.

Original comment by jurge...@gmail.com on 24 Feb 2011 at 2:48

[GoogleCodeExporter]

So this is the violation in the original restraint list with the original 
assignments, no swapping, correct? New list attached, most things match up but 
not all... we do something different for the aromatic rings for sure. Also, I'm 
only tracking violations larger than 1.0 angstrom, this I can also change if 
there is a point.

Original comment by wfvran...@gmail.com on 24 Feb 2011 at 4:51

Attachments:

• 2knr.new6.out

[GoogleCodeExporter]

>So this is the violation in the original restraint list with the original 
assignments, no swapping, correct? 
Yes, correcto.

>Also, I'm only tracking violations larger than 1.0 angstrom, this I can also 
change if there is a point.
Mmm, you don't include the smaller violations to the energy term? Can you 
include any violation even if it's just 0.01? My point would be that even 
violations below 1 Ang. are very important/strong in the structure calculation. 
In CING 0.5 is already considered 'bad'. We additionally score the >0.1 as well.

Original comment by jurge...@gmail.com on 24 Feb 2011 at 7:19

[GoogleCodeExporter]

No of course all violations are included in the energy, I'm just not listing 
them because the code looks for large violations for deassigning, no point in 
tracking everything from that point of view.

Original comment by wfvran...@gmail.com on 24 Feb 2011 at 7:42

[GoogleCodeExporter]

>code looks for large violations for deassigning,

Ah, but you also have criteria on the 'energy' setting like Wattos right? I 
guess I need to start to look at the code tomorrow. Thanks Wim!

Original comment by jurge...@gmail.com on 24 Feb 2011 at 7:49

[GoogleCodeExporter]

No criteria on the energy setting, all violations count in the way I set it up. 
Completely missed that part if we talked about it before!

Original comment by wfvran...@gmail.com on 25 Feb 2011 at 8:34

[GoogleCodeExporter]

Let me compare the results and look at your code. If the results are as good or 
better as for NRG then no need to make it more alike. If significantly worse 
violations result then we might want to add the other criteria I have in 
Wattos. 

Which version of the code should I be on for getting the results like you have 
shown in 2knr.new6.out?
I have today's:
   Repository revision: 1.1.2.4 /cvsroot/ccpn/ccpn/python/ccp/util/Validation.py,v
   Repository revision: 1.17.4.8    /cvsroot/ccpn/ccpn/python/ccpnmr/format/process/stereoAssignmentSwap.py,v

Thanks Wim

Original comment by jurge...@gmail.com on 25 Feb 2011 at 8:52

[GoogleCodeExporter]

Yep the latest revision of stereoAssignmentSwap.py, with changes in your code 
as listed before.

Original comment by wfvran...@gmail.com on 25 Feb 2011 at 9:00

[GoogleCodeExporter]

Great, I'm gonna embed that in my prep stages of the pipeline today.

Original comment by jurge...@gmail.com on 25 Feb 2011 at 9:11

[GoogleCodeExporter]

Wim, can I add the generation of an overview STAR file to your code in 
StereoAssignmentCleanup?
The embedding worked.

Original comment by jurge...@gmail.com on 25 Feb 2011 at 10:41

[GoogleCodeExporter]

Excellent, and yes, of course.

Original comment by wfvran...@gmail.com on 25 Feb 2011 at 10:48

[GoogleCodeExporter]

Apologies, Jurgen, I did forget to check in the version that reports the 
original maximum violations (above 1.0 angstrom) - now done!

Original comment by wfvran...@gmail.com on 25 Feb 2011 at 4:05

[GoogleCodeExporter]

ok, hold off on changing anything for this now. I'm close to finishing my 
iteration now.

Original comment by jurge...@gmail.com on 28 Feb 2011 at 12:19

[GoogleCodeExporter]

I'm making it close to Wattos output so I can compare. It's more difficult than 
I thought so I'm taking a little longer than expected.

Original comment by jurge...@gmail.com on 1 Mar 2011 at 3:24

[GoogleCodeExporter]

I suggest we skype about this but for reference here are my observations 
already.

Attached:
-1- FC code
Then find:
-2- http://nmr.cmbi.ru.nl/~jd/tmp/docrAssignWattos.tgz Wattos equivalent STAR 
result file to compare with line by line. I modified Wattos code to get it 
right.
-3- http://nmr.cmbi.ru.nl/~jd/tmp/docrAssignFc.tgz FC STAR results

Remarks:
-0- For 1brv the STAR results compare line by line!
-1- I get the same original max violations as in NRG now (mostly).
-2- I added sorting by atom for triplets when other 2 numbers are equal in both 
Wattos and FC. This makes it easier to compare.
-3- Reenable the Phe/Tyr and ambi counts by disabling compareWithWattos = 1 in 
code.

Questions

-1- ambi count off for 1brv A 19 CYS HB*. Wattos got 4 out of 22 you get 2:
       1 19 CYS QB 1 no 100.0 98.2 6.725 6.845 0.120 22 4 no 0.242 0 0 
Counting by hand I also get 4. Which do you exclude? I've excluded this column 
for easier comparison.
        73 1 19 CYS HB2 1 26 LEU HB3 4.568 . 4.568 4.607 4.586 4.633 0.065 34 0 "[    .    1    .    2    .    3    .    4    .   ]" 1 
        79 1 19 CYS HB3 1 22 ASN HB3 3.050 . 3.050 3.087 3.072 3.101 0.051 43 0 "[    .    1    .    2    .    3    .    4    .   ]" 1 
        82 1 19 CYS HB3 1 26 LEU HB2 4.778 . 4.778 3.997 3.941 4.051     .  0 0 "[    .    1    .    2    .    3    .    4    .   ]" 1 
        83 1 19 CYS HB3 1 26 LEU HB3 4.335 . 4.335 4.538 4.505 4.572 0.237 43 0 "[    .    1    .    2    .    3    .    4    .   ]" 1 
You find something different:
DEBUG: ambi in ('A', 19, <ccp.molecule.ChemComp.ChemAtomSet ['protein', 'Cys', 
'HB*', 1]>): 
Constraint [256]: [1.8] - [5.82]  [176.HB2] - 
[183.HD11,183.HD12,183.HD13,183.HD21,183.HD22,183.HD23]  [176.HB2] - 
[183.HD11,183.HD12,183.HD13,183.HD21,183.HD22,183.HD23]
Constraint [252]: [1.8] - [5.892]  [176.HB3] - 
[183.HD11,183.HD12,183.HD13,183.HD21,183.HD22,183.HD23]  [176.HB3] - 
[183.HD11,183.HD12,183.HD13,183.HD21,183.HD22,183.HD23]
Can you adjust this so we can include the ambi criteria for sorting again? It's 
disabled now.

-2- The max org violation 0.258 found by FC in 2knr differs from Wattos found 
0.093 Angstrom for:
  1   34   GLU QB          42 no    100.0    99.6    1.1    1.1    0.0  19 no      0.258   0   0
Wattos locates the highest violation in model 15 for this triplet in this 
restraint:
        164 1   7 LYS QE   1  34 GLU HB2  4.000 . 5.000 4.553 3.480 5.093 0.093 15 0 "[    .    1    .    2]" 1
When I measure in Yasara for this model: 5.362 and 6.352. Which is sum averaged 
5.093 like Wattos had. Normally FC has the exact same distances as Wattos so 
something special must be going on. This is before processing so that can't be 
it. I haven't taken the effort to print this one out from FC. The restraint 
doesn't seem to be listed when I did a quick scan.

-3- Can you add the other DNA/RNA triplets like in entry 1a4d. Currently I only 
see Q5's
-4- Can you split the Phe/Tyr QR like Wattos has them?

Bugs: see attached logs.

-A- For 1a24 (same for 1c2n)
ERROR: Traceback (most recent call last):
  File "/Users/jd/workspace35/cing/python/cing/Scripts/FC/utils.py", line 282, in <module>
    if fcProcessEntry( entry_code, ccpnTgzFile, outputCcpnTgzFile, functionToRun ):
  File "/Users/jd/workspace35/cing/python/cing/Scripts/FC/utils.py", line 195, in fcProcessEntry
    swapCheck(nmrConstraintStore, structureEnsemble)
  File "/Users/jd/workspace35/cing/python/cing/Scripts/FC/utils.py", line 125, in swapCheck
    swapCheck.checkSwapsAndClean()
  File "/Users/jd/workspace35/ccpn/python/ccpnmr/format/process/stereoAssignmentSwap.py", line 1405, in checkSwapsAndClean
    self.resetConstraintItems(allConstraintItems,prochiralResonances, prochiralKey,violationCode,fractionViolated,verbose=False)
  File "/Users/jd/workspace35/ccpn/python/ccpnmr/format/process/stereoAssignmentSwap.py", line 761, in resetConstraintItems
    otherProchiralResonance = prochiralResonances[not prochiralResonances.index(resonance)]
IndexError: list index out of range

-B- For 1d3z

ERROR: Traceback (most recent call last):
  File "/Users/jd/workspace35/cing/python/cing/Scripts/FC/utils.py", line 282, in <module>
    if fcProcessEntry( entry_code, ccpnTgzFile, outputCcpnTgzFile, functionToRun ):
  File "/Users/jd/workspace35/cing/python/cing/Scripts/FC/utils.py", line 195, in fcProcessEntry
    swapCheck(nmrConstraintStore, structureEnsemble)
  File "/Users/jd/workspace35/cing/python/cing/Scripts/FC/utils.py", line 125, in swapCheck
    swapCheck.checkSwapsAndClean()
  File "/Users/jd/workspace35/ccpn/python/ccpnmr/format/process/stereoAssignmentSwap.py", line 1057, in checkSwapsAndClean
    connectedConstraints.pop(connectedConstraints.index(constraint))
ValueError: list.index(x): x not in list

Original comment by jurge...@gmail.com on 3 Mar 2011 at 1:47

Attachments:

• stereoAssignmentSwap.py

[GoogleCodeExporter]

New version, all from above implemented/fixed except for the violation problem. 
You need to re-activate the Phe/Tyr stuff and ambi count though.

Original comment by wfvran...@gmail.com on 10 Mar 2011 at 3:18

Attachments:

• stereoAssignmentSwap.py