JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for CCP4BB Archives


CCP4BB Archives

CCP4BB Archives


CCP4BB@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

CCP4BB Home

CCP4BB Home

CCP4BB  May 2018

CCP4BB May 2018

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: Calculating sigma value

From:

Dale Tronrud <[log in to unmask]>

Reply-To:

Dale Tronrud <[log in to unmask]>

Date:

Tue, 1 May 2018 15:55:22 -0700

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (368 lines)

Dear Ian,

   Clearly you have a passion for the SI.  After our last discussion of
this topic on the CCP4BB I downloaded "The International System of
Units: NIST Special Publication 330" and actually read it.
(https://dx.doi.org/10.6028/NIST.SP.330e2008)  The SI is a fine system
of units and this document is well written and easy to follow.

   I don't believe that you and I have any serious disagreements about
"units".  I agree with pretty much everything you have written in your
letter.

   We do seem to have a difference of opinion about the style of writing
appropriate for an informal venue such as the CCP4BB.

   While the SI units of a "quantity density" would be "inverse cubic
nanometers" the actual value would remain meaningless if the nature of
the "quantity" was left unspecified.  The document mentioned above makes
this clear (page 22) and I'm sure you agree as well.

   I think you believe that just saying "the map value is electron
density" is sufficient to lead the reader to understand that the
"quantity" with  SI'ish units of "/Angstrom^3" is, indeed, "number of
electrons", but I disagree.  After all, people commonly refer to the rms
normalized maps as "electron density" maps as well, so the term
"electron density" has been overloaded with several meanings and is now
ambiguous.  In a forum where people routinely use abbreviations such as
"IMHO", and "A" instead of "Angstrom", it seems to me ridiculous to say
"the number density of electrons in SI units of per Angstrom cubed" when
I could simply say "electrons/A^3" knowing that most readers would
understand my intent.

   In your post you defined electron density (in quotes) as "... or the
number of electrons per unit volume".  Those are pretty much exactly the
words the little voice in my head utters when I read the symbols
"electrons/A^3".  I never said that "electrons" is an SI unit, or that I
was even trying to obey the formality of the SI conventions.

   I will argue with you about the idea that electron density and proton
density are commensurate.  I don't really know of an application where
the sum of electron density and proton density makes any sense, much
less the sum of electron and rabbit density.  Any class library I would
write would throw an exception if you attempted to calculate such a thing.

   I presume your calculation is stepping toward the calculation of
charge density.  I would first calculate the charge density due to the
electron density, using the knowledge that there is one quantum of
negative charge for each electron, then calculate the charge density due
to the proton density, using knowledge of the charge of a proton, and
then sum the two charge densities, which are not only commensurate but
identical.  My code would then be ready should I run into a Xi baryon
with +2 charge whereas your code would have to be completely refactored. ;-)

Dale Tronrud

 P.S. Before the United States Department of Commerce comes knocking on
my door, I expect they would prosecute the RCSB.  Do you realize that
this criminal organization uses taxpayer money to store and distribute
files containing calculated structure factors represented as the number
of electrons per unit cell?!


On 4/30/2018 3:28 AM, Ian Tickle wrote:
> 
> Dale,
> 
> On 19 April 2018 at 17:36, Dale Tronrud <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
> 
>        The meaning of the term "e/A^3" as used in Coot has nothing to do
>     with the charge of an electron.  The intention of its authors is to
>     indicate that the value being represented by the map is the density of
>     electrons.  It is the number of electrons per cubic Anstrom at that
>     point in space.
> 
> 
> My intention was certainly not to imply that the unit designated 'e' in
> the units of electron density used by Coot should be taken to mean
> charge (in fact quite the opposite!), even though 'e' would normally be
> interpreted here as the atomic unit of charge
> (see https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication811e2008.pdf,
> Table 8). 
> 
>        I, generally, find it useless to say that a number is a density
>     (units of "per volume") without saying density of what.  This is not a
>     density of charge, not a density of mass, not a density of rabbits.  It
>     is a density of electrons.
> 
> 
> First, note that (SI Guide cited above, section 7), quote: "The value of
> a quantity is its magnitude expressed as the product of a number and a
> unit, and the number multiplying the unit is the numerical value of the
> quantity expressed in that unit".  So by stating that the electron
> density is X electrons/A^3, you are claiming that the number in the
> above recipe is X and that the unit is 'electrons/A^3', correct?  I just
> want to be sure we are talking about the same thing when referring to a
> 'unit'.
> 
> There are numerous reasons why this terminology is inconsistent,
> semantically illogical, unconventional or impermissible under the
> universally accepted SI system of units(Système international d'unités),
> as well as possibly unlawful in the US!  For starters, the object
> 'electron' to which we are referring here is already very clear from the
> definition, so it's quite unnecessary to repeat that object as a
> component of its units.  Here is the definition of 'electron density':
> 
> "Electron density is the volume number density of electrons, or the
> number of electrons per unit volume".  For the definition of 'number
> density' see: https://en.wikipedia.org/wiki/Number_density,
> quote: "Volume number density is the number of specified objects per
> unit volume <https://en.wikipedia.org/wiki/Volume>: n={\frac
> {N}{V}}, where /N/ is the total number of objects in a volume /V/. 
> In SI
> <https://en.wikipedia.org/wiki/International_System_of_Units> units,
> number density is measured in m^−3 , although cm^−3  is often used."
> 
> There is of course also line number density and area number density,
> such as population density, i.e. the number of people per unit area, or
> area number density of people. 
> See https://en.wikipedia.org/wiki/Population_density, quote: "Therefore,
> the worldwide human population density is around 7,500,000,000 ÷
> 510,000,000 = 14.7 per km^2  (38 per sq. mi). If only the Earth's land
> area of 150,000,000 km^2  (58,000,000 sq. mi.) is taken into account,
> then human population density increases to 50 per km^2  (129 per sq.
> mile)." (note that the unit 'sq. mi' is not permitted under SI !). 
> Seems pretty clear from this what the units of area number density are,
> and by analogy the units of volume number density.
> 
> There doesn't seem to be any ambiguity here that what is being described
> is the number density of people, and for anyone who doesn't think
> Wikipedia has got it right, for an 'official' example of usage of number
> density, please refer to section 6.2.6 in the SI Guide cited above,
> quote:  "6.2.6 ... Example: the number density of Pb atoms is 5 ×106 /m3
> but not: the number density of Pb atoms is 5 M/m3."
> 
> Furthermore, are you saying that, for example, the statement "the mass
> of an electron is 9.10938356(11)×10^−31 kg" is not sufficiently clear
> and that it should be "9.10938356(11)×10^−31 kg/electron" instead?  That
> would follow logically from your claim above.  The problem with this is
> that this usage is clearly not permitted under the SI system, to which
> all modern scientific institutions and journals are signed up to using,
> without exception.  Please see the above-mentioned SI Guide document,
> under 'Check List for Reviewing Manuscripts', item 6: "Information is
> not mixed with unit symbols (or names). For example, the form 'the water
> content is 20 mL/kg' is used and not '20 mL H2O/kg' or '20 mL of
> water/kg.' (See Sec. 7.5.)."  So mixing the object 'electron' with the
> other units (A^-3 or kg) is absolutely not permissible in SI.  Note that
> an 'electron' is like 'H2O' in the sense that both are instances of the
> class 'Matter', and so neither can possibly be units (i.e. instances of
> the class 'Units').  This makes perfect sense for several reasons:
> 
> First, the identical unit applied to different objects is
> 'commensurable', i.e. it can be compared, subtracted or added.  So if
> the number density of electrons is 5 A^-3 and the number density of
> protons is 10 A^-3 we can just add number densities and get the total
> number density of particles or matter objects (electrons or protons, or
> yes even rabbit volume density can be added to electron density!)
> =  15 A^-3.  Different units are 'incommensurable', i.e. can't be
> compared or equated.  Even if there were such units as 'electron',
> 'proton' or 'rabbit' and if the units of number density really were
> 'electrons/A^3' or 'protons/A^3' or rabbits/m^3 then these are clearly
> different units so are incommensurable.  It would therefore not be
> possible to calculate the total number density of matter objects - you
> may as well ask what is the sum of 5 kg and 10 meters!
> 
> Second, if you insist that every object has its own collection of units
> associated with it, a vast plethora of potential units would spring into
> existence!  Surely the whole point of units is to make things simple and
> keep the number of units to a minimum, not to make things vastly more
> complicated: the same unit can be applied to many different objects.  Or
> are you saying that this exception to the rule only applies to number
> densities, in which case what's the justification for making it a
> special case?
> 
> Third, we can talk about, 'length', 'mass' etc. as abstract objects
> divorced from any particular hunks of matter.
> 
> As you are located in the US, take note also that SI has the force of
> law, quote from SI Guide: "In January 1991, the Department of Commerce
> issued an addition to the Code of Federal Regulations entitled 'Metric
> Conversion Policy for Federal Agencies,' 15 CFR 1170, which removes the
> voluntary aspect of the conversion to the SI for Federal agencies and
> gives in detail the policy for that conversion. Executive Order 12770,
> issued in July 1991, reinforces that policy by providing Presidential
> authority and direction for the use of the metric system of measurement
> by Federal agencies and departments".  The important phrase here is
> 'removes the voluntary aspect', which I would say means that you can't
> make up your own units such as 'electron'.  So for Federal agencies and
> departments it is actually unlawful to use units such as 'electron' that
> are not permitted under the SI system!  Actually it's worse than that
> since 'electron' is not even a unit, SI or otherwise!  Comparing or
> equating different units, or worse, using something which isn't even a
> unit where a unit is expected, is called a 'category mistake'
> (https://en.wikipedia.org/wiki/Category_mistake
> <https://en.wikipedia.org/wiki/Category_mistake)>), or in common
> parlance 'comparing apples with oranges'.
> 
> The concept of 'category mistake' will be familiar to programmers of
> classed-based object-oriented languages, such as C++ and Java.  Here
> 'category' = 'class', and it's a semantic error (trapped by the
> compiler) to compare or equate an object instantiated from one class
> with an object from a different non-inherited class, simply because it's
> not semantically meaningful to do so.  It's also a category mistake to
> equate the property of an object (or any part of an object) to the
> object itself, and to attempt to apply a method of one class to objects
> instantiated from another non-inherited class.
> 
> The SI system (see the Guide, sections 4 & 5) consists of several tiers:
> 
> 1. The 7 SI base units: metre, kilogram, second and 4 others.
> 2. SI derived units: combinations of the base units, such as metre/second.
> 3. SI coherent derived units: units such as radian with special names
> and symbols.
> 4. Decimal multiples and sub-multiples of all the above, such as nanometre.
> 
> Then outside the SI system, but still acceptable for use in scientific
> publications, there are:
> 
> 5. Non-SI units accepted for use with the SI: non-SI units that are
> acceptable owing to common usage, such as hour, degree, litre.
> 6. Non-SI units accepted by the International Committee for Weights and
> Measures, and therefore accepted into SI, such as electronvolt and dalton.
> 7. Non-SI units that are part of other international standards, such as
> the electronic charge 'e', being the atomic unit of charge, and the
> electron rest mass m_e.
> 8. Other non-SI units also accepted because of common usage in
> specialised fields, such as Angstrom, rad, barn.
> 
> Finally we have units that are not permissible in any scientific
> publication:
> 
> 9. CGS units, such as erg, dyne.
> 10. Other obsolete units, such as torr, micron, inch, foot, yard, chain,
> furlong, mile, pound, poundal, rod, perch, peck, bushel, etc. etc.
> 
> Notice that the supposedly 'electron' ( or 'proton' or 'rabbit' or
> anything composed of matter) units, don't even make it into the list of
> impermissible units - simply because they are not even units!  The
> closest units to 'electron' in the list are electronic charge 'e' and
> electronvolt 'eV' (unit of energy), but as discussed above, they have
> nothing to do with electron density.
> 
> A requirement of SI is that if you use a non-SI unit for some quantity
> you are _required_ to state the value of that quantity in SI units, or
> the conversion factor.  See above-cited Check List for Reviewing
> Manuscripts, item 2, quote: "Only SI units and those units recognized
> for use with the SI are used to express the values of quantities. 
> Equivalent values in other units are given in parentheses following
> values in acceptable units only when deemed necessary for the intended
> audience. (See Chapter 2.)".  Therefore if you believe that 'electron'
> is a unit, please state the value of the 'electron' unit in the
> equivalent SI units.  If you have trouble with that, try stating the
> value of 1 rabbit or 1 person (for the supposed population density of
> rabbits or people that incorporates 'rabbit' or 'person' in the unit
> itself) in their equivalent SI units, or in any units for that matter! 
> Of course this is all semantic nonsense because it's plainly a category
> mistake to attempt to apply the method unitConversion in class Units to
> an object instantiated from the non-inherited class Matter (e.g.
> electron, proton, person, rabbit etc.).
> 
> Let's make it simpler and drop the units of volume, and talk instead
> about form factors (or structure factors), so the unit of electron
> density is whatever is the unit of the form factor divided by volume (by
> the usual equation for electron density).  Now a form factor is defined
> as the _ratio_ of the amplitude of scattering of the specified atom at
> some specified scattering angle divided by the scattering of a single
> electron (for which the angle is irrelevant).  Being a ratio of two
> quantities with identical dimensions, it can only be a pure
> dimensionless and unitless number (just like the unitless refractive
> index, being the ratio of two speeds).  It follows logically from your
> claim above that the units of electron density are 'electrons/A^3', that
> the units of form factors would have to be 'electrons', but this is
> impossible if form factors are unitless pure numbers (and anyway
> electrons are not units!).
> 
> A 'reductio ad absurdum' (reduce to absurdity) argument can be used
> here: the form factor at zero scattering angle is of course the number
> of electrons in the atom or ion, so do you say 'the number of electrons
> in a carbon atom is 6 electrons', or 'the number of electrons is 6'? 
> The former follows logically if the units of electron density are
> 'electrons/A^3', because then the units of a form factor would be
> 'electrons'.  However that is a clear category mistake: it equates a
> property of the 'electrons' object ('number of electrons'), which is
> obviously an instance of the 'Number' class, with the object itself ('6
> electrons') a blatant commission of a category mistake.  The second
> statement above is the only semantically valid one: we must equate
> 'number of electrons' (a Number class variable) with '6' (a Number class
> constant).  Doing anything else is 'comparing apples with oranges'!
> 
> 
>        Now the calculations are pretty simple.  When the refinement program
>     produces a model one of its parameters is a scale factor which relates
>     the relative values of the observed intensity to those calculated from
>     the model.  This scale factor, which is usually not written out in an
>     obvious place since its value is not very interesting, is just a simple
>     number, not a function of resolution or anything like that.  It's value
>     is also sensitive to a number of assumptions (like you are modeling
>     everything in your unit cell) so it is not particularly reliable.  This
>     means you shouldn't take the density values of your map terribly
>     seriously.  The differences in density from place to place is much more
>     reliable.
> 
>        This has led to the practice of converting the density values to
>     normalized values.  Here you calculate the rms value of the points in
>     the map and divide all the density points by that number.  "rms" is
>     simply what is says "Root of the Mean of the Squares".  Again this is
>     just a number, nothing fancy.
> 
>        The only trick is deciding what region of space to sum.  The crystal
>     is composed of regions which are occupied by ordered molecules (One
>     hopes this includs the molecule you are interested in!) and regions of
>     bulk solvent.  You could reasonably conclude that the rms's of these
>     regions should be considered different properties of the map.  I'm not
>     aware of any software that actually tries to calculate an rms for just
>     the region of the map that contains ordered structure.
> 
>        What was done in the past was to simply calculate the sum over the
>     region of the map presented to the program, and this was usually a
>     rectangular box inscribed over the molecule.  The corners of that box
>     would cover some amount of bulk solvent (and symmetry related molecules)
>     which depends on a lot of factors which shouldn't be affecting your
>     choice of contour levels.  This method is inconsistent and causes
>     confusion.
> 
>        The conventional method today is to calculate the rms by summing
>     over the entire asymmetric unit.  This, at least, creates consistency,
>     and can be calculated from the Fourier coefficients making it an easy
>     number to come up with.  Many programs now use this method, including
>     Coot (As I understand).  It does have the drawback that a crystal with a
>     large amount of solvent will have a lower rms than one that is very dry,
>     even if the variation within the ordered structure is the same.  You
>     need to be aware of this when interpreting maps whose contours are based
>     on the rms.  Showing the contour level both as rms and electrons/A^3 is
>     an attempt to provide a fuller description.
> 
>        Ian is certainly right -- the rms of a function is not a "sigma".
>     This confusion is a problem that is endemic in our field!  "sigma" is
>     shorthand for standard deviation which is a measure of the uncertainty
>     in our knowledge about a value.   The rms is not a measure in any way of
>     uncertainty -- It is simply a description of how variable the values of
>     the function are.  James Holton has written a very nice paper on this
>     topic, but I don't have the reference on hand.
> 
>        The excuse for this confabulation is that people believe, in a Fo-Fc
>     style map, most of the values should represent factors other than errors
>     in the structural model and therefore one can estimate the uncertainty
>     of the map by calculating the rms over the map.  This assumption is
>     highly questionable and unreliable.  The major problem then arises when
>     the same logic is extrapolated to a 2Fo-Fc style map.  In these maps the
>     variability in the ordered region of the crystal is all "signal" so
>     calculating an rms really has nothing to do with uncertainty.
> 
>        Describing your contours or peaks in an Fo-Fc style map by rms can
>     sort-of, kind-of, be justified, but it makes no sense for a 2Fo-Fc style
>     map.  If I want to be really serious about deciding if a peak in a map
>     may be missing atoms, I will leave some known atoms out of the model and
>     see how the heights of their difference peaks compare to the heights of
>     the mysterious peaks.  This method is fairly insensitive to the
>     systematic problems that affect both rms and electrons/A^2.
> 
> 
> On all your remaining points above we are thankfully in complete agreement!
> 
> Cheers
> 
> -- Ian
> 

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2024
March 2024
February 2024
January 2024
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
December 2022
November 2022
October 2022
September 2022
August 2022
July 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

For help and support help@jisc.ac.uk

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager