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 >