Re: [ccp4bb] sfall bug?
Eleanor, Thanks for the suggestion. I changed atom numbers to 1 and 2 and residue numbers to 1 and 2. The behavior is identical. Thanks! Jens On Tue, 2015-07-07 at 06:48 +0100, Eleanor Dodson wrote: I wonder if this is due to the late residue number. Could you try again reducing that to something smaller. I seem to remember SFALL stores a flag to recall which residue contributed to which density and there could be a limit on its size. Will test when I get near a working system Eleanor On 6 July 2015 at 22:53, Jens Kaiser kai...@caltech.edu wrote: All, We seem to have stumbled upon a problem in sfall. The two attached pdb files are nearly identical, except the coordinates and b-factors for the two atoms are swapped. When calculating Fs with sfall, we get drastically different mtz files. Upon calculating the corresponding Fcalc maps, it seems that the second atom in a.pdb gets ignored, whereas both atoms in b.pdb are included. There is nothing obvious in the log files to hint to what is happening (i.e. both files state Number of atoms input= 2 Number of atoms in sort = 2 Number in density generation = 2 Number completely within fft box = 2 Minimum B = 5.91 Maximum B = 5.97 Average B = 5.94 We observed this behavior on mac and on Linux. Cheers, Jens
Re: [ccp4bb] sfall bug?
Maybe something to do with the SCALE tag? Minglei On Jul 6, 2015, at 11:02 PM, Jens Kaiser kai...@caltech.edu wrote: Eleanor, Thanks for the suggestion. I changed atom numbers to 1 and 2 and residue numbers to 1 and 2. The behavior is identical. Thanks! Jens On Tue, 2015-07-07 at 06:48 +0100, Eleanor Dodson wrote: I wonder if this is due to the late residue number. Could you try again reducing that to something smaller. I seem to remember SFALL stores a flag to recall which residue contributed to which density and there could be a limit on its size. Will test when I get near a working system Eleanor On 6 July 2015 at 22:53, Jens Kaiser kai...@caltech.edu wrote: All, We seem to have stumbled upon a problem in sfall. The two attached pdb files are nearly identical, except the coordinates and b-factors for the two atoms are swapped. When calculating Fs with sfall, we get drastically different mtz files. Upon calculating the corresponding Fcalc maps, it seems that the second atom in a.pdb gets ignored, whereas both atoms in b.pdb are included. There is nothing obvious in the log files to hint to what is happening (i.e. both files state Number of atoms input= 2 Number of atoms in sort = 2 Number in density generation = 2 Number completely within fft box = 2 Minimum B = 5.91 Maximum B = 5.97 Average B = 5.94 We observed this behavior on mac and on Linux. Cheers, Jens
Re: [ccp4bb] sfall bug?
Hi Jens, I do get the same results when running sfall xyzin a.pdb hklout a.mtz mapout a.map EOF MODE SFCAL XYZIN ATMMAP RESO 100 2 SFSG P1 SYMM P21 NOSC END ie. enforcing P1 for the structure-factor calculation. The density map (on MAPOUT) is on top of the atoms as expected. Unfortunately, the output MTZ file then has a hemisphere of data (P1) ... which is probably not what you want. If I remove the SFSG P1 card (ie let SFALL decide on the SG for SF-calculation itself): the ATMMAP generated for a.pdb is just wrong - it is missing density for the 35.753 7.581 -12.182 1.00 5.91 atom. As Kay says: maybe an issue with atom sorting ... or in the PDB reading via MMDB? It would be interesting to see if this issue is only for SFSG P21 or also for other non-P1 cases, eg. P212121. Cheers Clemens -- *** * Clemens Vonrhein, Ph.D. vonrhein AT GlobalPhasing DOT com * * Global Phasing Ltd. * Sheraton House, Castle Park * Cambridge CB3 0AX, UK *-- * BUSTER Development Group (http://www.globalphasing.com) ***
Re: [ccp4bb] sfall bug?
Just a few observations: I ran echo MODE SFCALC XYZIN\\n SYMM P21\\n RESO 30 3 | sfall xyzin a.pdb hklout temp.mtz a.log and echo MODE SFCALC XYZIN\\n SYMM P21\\n RESO 30 3 | sfall xyzin b.pdb hklout temp.mtz b.log and looked at a.log and b.log They differ only as follows: a.log has First 10 atoms of atsort - orthog coordinates 16204FE1 ICS 6496 10.0180 -7.5680 56.1090 1.005.976 fractional coordinates 0.38411-0.05791 0.55929 First 10 atoms of atsort - orthog coordinates 16289FE1 ICS 7496 35.7530 7.5810-12.1820 1.005.916 fractional coordinates 0.38376 0.05800-0.12143 First 10 atoms of sorted file in asym unit - 20.61588 0.44071 0.44209105.97 1.00 6 ***ZZZ END 10.38376 0.87857 0.05800205.91 1.00 6 ***ZZZ END First atom of sorted file in atsort 20.61588 0.44071 0.44209105.97131.00 ***ZZZ END whereas b.log has First 10 atoms of atsort - orthog coordinates 16204FE1 ICS 6496 35.7530 7.5810-12.1820 1.005.916 fractional coordinates 0.38376 0.05800-0.12143 First 10 atoms of atsort - orthog coordinates 16289FE1 ICS 7496 10.0180 -7.5680 56.1090 1.005.976 fractional coordinates 0.38411-0.05791 0.55929 First 10 atoms of sorted file in asym unit - 10.38376 0.87857 0.05800105.91 1.00 6 ***ZZZ END 20.61588 0.44071 0.44209205.97 1.00 6 ***ZZZ END First atom of sorted file in atsort 10.38376 0.87857 0.05800105.91131.00 ***ZZZ END What I don't understand is why the sorted lists are different? Sorting should make the resulting lists look the same, to my limited understanding. What is peculiar about the coordinates of these atoms is that there x coordinate in fractional units is almost the same, and their y coordinate is mirrored at the origin.Maybe that could play a role. Kay
[ccp4bb] sfall bug?
All, We seem to have stumbled upon a problem in sfall. The two attached pdb files are nearly identical, except the coordinates and b-factors for the two atoms are swapped. When calculating Fs with sfall, we get drastically different mtz files. Upon calculating the corresponding Fcalc maps, it seems that the second atom in a.pdb gets ignored, whereas both atoms in b.pdb are included. There is nothing obvious in the log files to hint to what is happening (i.e. both files state Number of atoms input= 2 Number of atoms in sort = 2 Number in density generation = 2 Number completely within fft box = 2 Minimum B = 5.91 Maximum B = 5.97 Average B = 5.94 We observed this behavior on mac and on Linux. Cheers, Jens a.pdb Description: application/aportisdoc b.pdb Description: application/aportisdoc
Re: [ccp4bb] sfall bug?
I wonder if this is due to the late residue number. Could you try again reducing that to something smaller. I seem to remember SFALL stores a flag to recall which residue contributed to which density and there could be a limit on its size. Will test when I get near a working system Eleanor On 6 July 2015 at 22:53, Jens Kaiser kai...@caltech.edu wrote: All, We seem to have stumbled upon a problem in sfall. The two attached pdb files are nearly identical, except the coordinates and b-factors for the two atoms are swapped. When calculating Fs with sfall, we get drastically different mtz files. Upon calculating the corresponding Fcalc maps, it seems that the second atom in a.pdb gets ignored, whereas both atoms in b.pdb are included. There is nothing obvious in the log files to hint to what is happening (i.e. both files state Number of atoms input= 2 Number of atoms in sort = 2 Number in density generation = 2 Number completely within fft box = 2 Minimum B = 5.91 Maximum B = 5.97 Average B = 5.94 We observed this behavior on mac and on Linux. Cheers, Jens
