the test limit is perhaps over-tight data eps/0.0001/
Phil On 2 Apr 2015, at 00:34, Dale Tronrud <de...@daletronrud.com> wrote: > I think you are on the right track - There are not enough decimal > points in your matrix elements to pass the orthonormal test. This test > checks that the length of each row (x^2+y^2+z^2) is equal to one and the > dot product of each row with every other row is equal to zero. If the > values on your NCS statement are in row order I calculate 0.999337 for > the length of the first row. If the program is testing if this is equal > to one to four decimal points you lose. > > You have to add more digits, but just adding zeros isn't going to > accomplish much. The best solution is to get your ncs program to report > its matrix with more digits -- three is pitiful. Failing that you could > calculate one element of each row from the other two to ensure the > length is equal to one at a higher level of precision and hope this > doesn't mess up the dot product test. You'll end up with one number in > each row having more than three decimal places. > > Dale Tronrud > > On 4/1/2015 2:52 PM, Shane Caldwell wrote: >> Hi ccp4bb, >> >> I'm trying to solve a problem I never quite figured out in the past. I'd >> like to use the *sortwater* utility to send my picked waters to various >> protein chains, and to give them the same residue number if they are >> NCS-equivalent, as the manual outlines. >> >> http://www.ccp4.ac.uk/html/sortwater.html >> >> The first part goes off perfectly, partitioning the waters into their >> respective chains. Where I run into problems is bringing in NCS. I can't >> get the program to recognize the transformation matrix. I can calculate >> the matrix using *superpose*, and manually input these (limited >> precision) values into my script, which looks like: >> >> NCS B C MATRIX 0.072 0.997 -0.012 0.991 -0.073 -0.113 -0.113 -0.004 >> -0.994 37.502 -35.283 81.276 >> >> and it returns >> >> WARNING: **** Matrix is not orthonormal **** >> >> >> My linear algebra is very limited, and I don't know exactly what this >> means in the context of this program, though I suspect it could be >> either linked to converting to fractional coordinates (I'm in a >> monoclinic system), or a product of the limited precision of the matrix >> values. >> >> Using the identity matrix, like so: >> >> NCS B C MATRIX 1.00000 0.00000 0.00000 0.00000 1.00000 0.00000 0.00000 >> 0.00000 1.00000 0.000 0.000 0.000 >> >> doesn't trigger the warning. These values have more digits, but adding >> extra zeroes to the original matrix as a very crude workaround still >> returns the error. >> >> So, I'm now stuck trying to parse what's going on. I know *sortwater* >> also takes O datablocks as matrix input, and that's something I could >> look into (especially if calculating in a different program might get me >> better precision). Although, I'm not sure the format is a factor given >> the identity matrix is accepted as a keyword input. >> >> Skimming the archives, I get the sense this isn't something that many >> users do any more. I have quite a few structures with hundreds of waters >> each and I'd like to get the waters organized, but doing it by hand will >> take a very long time. Any help getting this program running would be >> greatly appreciated! >> >> >> Shane Caldwell >> McGill University
