Hi All,
Notwithstanding the stimulating discussion about the B-factor, I'd like
to chime in with my $0.02 on the original question of to build or not to
build and what are the rules and standards... and sorry for the lengthy
e-mail - I was trying to respond to several comments at once.

I thought there was a very well-defined rule: models based on
experimental data should represent the experimental data correctly. If a
model has parts that are not substantiated by experimental data and are
based only on assumptions, it's no longer an experimental model. Based
on this, one should leave out the atoms for which there is no observable
electron density. And one need not say that "we were unable to build a
model of a missing side chains (or any other segments of the structure).
There is also no need to guess or fake "most probable" conformations of
the unobserved parts. Instead, it should be reported that the segment in
question was so flexible that it could not be described by just one or
two (and may be three) conformers. As such, this observation stands on
its own feet just like any other observation of "visible" segments and
there is no need to fake a model. If the work was done properly, a model
with missing parts is not intrinsically inferior to other, more complete
model. The fact that a side chain displays flexibility may be
biologically much more relevant than some well-defined Ile in the core
of the molecule. Omitting unobserved side chains from the model would
also help avoid assumptions as if we know for sure that the side chain
is there. Given side chain actually may not be there for some reason or
another. Sequence errors and radiation-induced damage come to mind, for
example. The latter is also often the reason that the side chain may not
be fully occupied in the structure derived from a specific data set
(i.e. the sum of occupancies of all its existing conformations may not
be 1, contrary to earlier suggestions in the thread). Back in the day I
personally spent large amounts of time and effort constructing and
refining multi-conformational models of some side chains because I was
sure they were there somewhere. Later on, as we learned more, I realized
that some of them have been sheered by radiation damage and actually
were not there. As knowledge advances, many of our assumptions may
crumble and that's why we ought to keep "experimentally visible" models
apart from those with assumed parts.

As for the downstream consumers of our models, we may not need to
confuse them with strange B factors or occupancies. We just need to give
them correct information. Namely, that the given part(s) of the molecule
could not be "seen" experimentally due to its flexibility (or, in some
cases, to radiation damage).  There was an interesting suggestion of two
models - one accurately describing the experimental observations and the
other for the downstream users. It would be a good way to separate Sci
from Fi but there may be a problem. When theories are derived further
downstream, it'll be impossible to keep track of what came from Sci and
what came from Fi versions.

Best regards,
N.


Ruslan Sanishvili (Nukri), Ph.D.

GM/CA-CAT
Biosciences Division, ANL
9700 S. Cass Ave.
Argonne, IL 60439

Tel: (630)252-0665
Fax: (630)252-0667
[log in to unmask]

-----Original Message-----
From: CCP4 bulletin board [mailto:[log in to unmask]] On Behalf Of
Dale Tronrud
Sent: Thursday, March 31, 2011 4:51 PM
To: [log in to unmask]
Subject: Re: [ccp4bb] what to do with disordered side chains

On 3/31/2011 12:52 PM, Jacob Keller wrote:
>> The only advantage of a large, positive, number is that it would
create
>> bugs that are more subtle.
>
> Although most of the users on this BB probably know more about the
> software coding, I am surprised that bugs--even subtle ones--would be
> introduced by residues flagged with 0 occupancy and b-factor = 500.
> Can you elaborate/enumerate?

    The principle problems with defining a particular value of the B
factor
as magical have already been listed in this thread.  B factors are
usually
restrained to the values of the atoms their atom is bonded to and
sometimes to other atoms they pack against.  You may set the B factor
equal to 500.00 but it will not stick.  At worst its presence will pull
up the B factors of nearby atoms that do have density.

    In addition, the only refinement program I know of that takes
occupancy
into account when restraining bond lengths and angles is CNX.  The
presence
of atoms with occ=0 will affect the location of atoms they share
geometry
restraints with.

    Of course you could modify the refinement programs, and every other
program that reads crystallographic models, to deal with your
redefinition
of _atom_site.B_iso_or_equiv.  In fact you would have to, just as you
would
have to when you change the definition of any of the parameters in our
models.  If we have to modify code, why not create a solution that is
explicit, clear, and as consistent with previous practices as possible?
>
> I think that the worst that could happen is that the unexperienced yet
> b-factor-savvy user would be astonished by the huge b-factors, even if
> he did not realize they were flags. At best, being surprised at the
> precise number 500, he would look into the pdb file and see occupancy
> = zero, google it, and learn something new about crystallography.
>
    How about positive difference map peaks on neighboring atoms?  How
about values for B factors that don't relate to the mean square motion
of the atom, despite that being the direct definition of the B factor?

    The concept of an "unexperienced yet b-factor-savvy user" is
amusing.
I'm not b-factor-savvy.  Atomic displacement values are easy, but I'm
learning new subtleties about B factors all the time.

>
>>    The fundamental problem with your solution is that you are trying
to
>> cram two pieces of information into a single number.  Such density
always
>> causes problems.  Each concept needs its own value.
>
> What two pieces of information into what single number? Occupancy = 0
> tells you that the atom cannot be modelled, and B=500 is merely a flag
> for same, and always goes with occ=0. What is so dense? On the
> contrary, I think the info is redundant if anything...

    To be honest I had forgotten that you were proposing that the
occupancy
be set to zero at the same time.  Besides putting two pieces of
information
in the B factor column (The B factor's value and a flag for
"imaginaryness".)
You do the same for occupancy (the occupancy's value and a flag for
"imaginaryness".)  This violates another rule of data structures - that
each concept be stored in one, and only one, place.  How do you
interpret
an atom with an occupancy of zero but a B factor of 250?  How about an
atom with a B factor of 500.00 and an occupancy of 1.00?  Now we have
the
confusing situation that the B factor can only be interpreted in the
context of the the value of the occupancy and vice versa.
Database-savvy
people (and I'm not one of them either) are not going to like this.

    If you want to calculate the average B factor for a model, certainly
those atoms with their B factor = 500 should not be included.  However,
I gather we do need to include those equal to 500 if their occupancy is
not equal to 0.0.  This is a mess.  In a database application we can't
simply SELECT the row with the B factors and average them.  We have to
SELECT both the B factor and occupancy rows and perform some really
weird "if" statements element by element - just to calculate an average!
What should be a simple task becomes very complex.  Will a graduate
student code the calculation correctly?  Probably not.  They will likely
not recall all the complicated interpretations of special values your
convention would require.

    Now consider this.  Refinement is running along and the occupancy
for
an atom happens to overshoot and, in the middle of refinement, assumes
a value of 0.00.  There is positive difference density the next cycle.
(I did say that it overshot.)  Should the refinement program interpret
that Occ=0.00 to mean that the atom is imaginary and should not be
considered as part of the crystallographic model?  Wouldn't it be bad
if the atom suddenly disappeared because of a fluctuation?  Or should
the refinement program use one definition of "occupancy" during
refinement, but write a PDB file occupancy that has a different
definition?
(It might be relevant to this line of thought to recall that the TNT
refinement package writes each intermediate coordinate file to disk and
reads it back in at the start of the next cycle.  There can be no
difference between the meaning of the parameters in memory and on disk.)

    A great deal of what we do with our models depends on the details of
the definitions of these parameters.  Adding extra meanings and special
cases causes all sorts of problems at all levels of use.
>
>
>> either.  You can't out-think someone who's not paying attention.  At
>> some point you have to assume that people being paid to perform
research
>> will learn the basics of the data they are using, even if you know
that
>> assumption is not 100% true.
>
> Well, the problem is not *should* but *do*. Should we print bilingual
> danger signs in the US? Shouldn't we assume that people know English?
> But there is danger, and we care about sparing lives. Here too, if we
> care about the truth being abused or missed, it seems we should go out
> of our way.
>
    I've not advocated doing nothing.  I've advocated that the solution
we choose should be clearly defined and that definition be consistent
with past definitions (as much as possible) and consistent with the
principles of data structures created by the people who study such
things.

    We *should* go out of our way to make a solution to this common
problem.
The solution we choose should be one that actually solves the problem
and not simply creates more confusion.

Dale Tronrud

P.S. I just Googled "occupancy zero".  The top hit is a letter from
Bernhard Rupp recommending that occupancies not be set to zero :-)