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 >> >>
