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
>

Reply via email to