volume gaussian bfactor off by factor of 3

[Tristan Croll]

The following bug report has been submitted:
Platform:        Linux-3.10.0-1160.25.1.el7.x86_64-x86_64-with-glibc2.17
ChimeraX Version: 1.3.dev202107150116 (2021-07-15 01:16:24 UTC)
Description
(I suspect this is my fault, from when I suggested this option): there's a factor of three missing in the "volume gaussian bfactor" command. Line https://github.com/RBVI/ChimeraX/blob/b7447d87e7021d67dba0c18b11ce29f48bb24b92/src/bundles/map_filter/src/vopcommand.py#L621 should be:

sd = sqrt(abs(bfactor)*3/(8*pi**2))

See https://en.wikipedia.org/wiki/Debye%E2%80%93Waller_factor.

OpenGL version: 3.3.0 NVIDIA 465.19.01
OpenGL renderer: NVIDIA TITAN Xp/PCIe/SSE2
OpenGL vendor: NVIDIA Corporation
Manufacturer: Dell Inc.
Model: Precision T5600
OS: CentOS Linux 7 Core
Architecture: 64bit ELF
Virutal Machine: none
CPU: 32 Intel(R) Xeon(R) CPU E5-2687W 0 @ 3.10GHz
Cache Size: 20480 KB
Memory:
	              total        used        free      shared  buff/cache   available
	Mem:            62G        6.1G         45G        223M         11G         55G
	Swap:          4.9G          0B        4.9G

Graphics:
	03:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP102 [TITAN Xp] [10de:1b02] (rev a1)	
	Subsystem: NVIDIA Corporation Device [10de:11df]	
	Kernel driver in use: nvidia
Locale: ('en_GB', 'UTF-8')
PyQt5 5.15.2, Qt 5.15.2
Installed Packages:
    alabaster: 0.7.12
    appdirs: 1.4.4
    Babel: 2.9.1
    backcall: 0.2.0
    blockdiag: 2.0.1
    certifi: 2021.5.30
    cftime: 1.5.0
    chardet: 4.0.0
    ChimeraX-AddCharge: 1.1.4
    ChimeraX-AddH: 2.1.10
    ChimeraX-AlignmentAlgorithms: 2.0
    ChimeraX-AlignmentHdrs: 3.2
    ChimeraX-AlignmentMatrices: 2.0
    ChimeraX-Alignments: 2.1
    ChimeraX-AltlocExplorer: 1.0
    ChimeraX-AmberInfo: 1.0
    ChimeraX-Arrays: 1.0
    ChimeraX-Atomic: 1.26
    ChimeraX-AtomicLibrary: 3.3
    ChimeraX-AtomSearch: 2.0
    ChimeraX-AtomSearchLibrary: 1.0
    ChimeraX-AxesPlanes: 2.0
    ChimeraX-BasicActions: 1.1
    ChimeraX-BILD: 1.0
    ChimeraX-BlastProtein: 1.1.1
    ChimeraX-BondRot: 2.0
    ChimeraX-BugReporter: 1.0
    ChimeraX-BuildStructure: 2.5.2
    ChimeraX-Bumps: 1.0
    ChimeraX-BundleBuilder: 1.1
    ChimeraX-ButtonPanel: 1.0
    ChimeraX-CageBuilder: 1.0
    ChimeraX-CellPack: 1.0
    ChimeraX-Centroids: 1.1
    ChimeraX-ChemGroup: 2.0
    ChimeraX-Clashes: 2.1
    ChimeraX-Clipper: 0.17.0
    ChimeraX-ColorActions: 1.0
    ChimeraX-ColorGlobe: 1.0
    ChimeraX-ColorKey: 1.3.2
    ChimeraX-CommandLine: 1.1.4
    ChimeraX-ConnectStructure: 2.0
    ChimeraX-Contacts: 1.0
    ChimeraX-Core: 1.3.dev202107150116
    ChimeraX-CoreFormats: 1.0
    ChimeraX-coulombic: 1.3
    ChimeraX-Crosslinks: 1.0
    ChimeraX-Crystal: 1.0
    ChimeraX-CrystalContacts: 1.0
    ChimeraX-DataFormats: 1.2
    ChimeraX-Dicom: 1.0
    ChimeraX-DistMonitor: 1.1.4
    ChimeraX-DistUI: 1.0
    ChimeraX-Dssp: 2.0
    ChimeraX-EMDB-SFF: 1.0
    ChimeraX-ExperimentalCommands: 1.0
    ChimeraX-FileHistory: 1.0
    ChimeraX-FunctionKey: 1.0
    ChimeraX-Geometry: 1.1
    ChimeraX-gltf: 1.0
    ChimeraX-Graphics: 1.1
    ChimeraX-Hbonds: 2.1
    ChimeraX-Help: 1.1
    ChimeraX-HKCage: 1.3
    ChimeraX-IHM: 1.1
    ChimeraX-ImageFormats: 1.1
    ChimeraX-IMOD: 1.0
    ChimeraX-IO: 1.0.1
    ChimeraX-ISOLDE: 1.3.dev32
    ChimeraX-ItemsInspection: 1.0
    ChimeraX-Label: 1.1
    ChimeraX-LinuxSupport: 1.0
    ChimeraX-ListInfo: 1.1.1
    ChimeraX-Log: 1.1.4
    ChimeraX-LookingGlass: 1.1
    ChimeraX-Maestro: 1.8.1
    ChimeraX-Map: 1.1
    ChimeraX-MapData: 2.0
    ChimeraX-MapEraser: 1.0
    ChimeraX-MapFilter: 2.0
    ChimeraX-MapFit: 2.0
    ChimeraX-MapSeries: 2.1
    ChimeraX-Markers: 1.0
    ChimeraX-Mask: 1.0
    ChimeraX-MatchMaker: 1.2.1
    ChimeraX-MDcrds: 2.4
    ChimeraX-MedicalToolbar: 1.0.1
    ChimeraX-Meeting: 1.0
    ChimeraX-MLP: 1.1
    ChimeraX-mmCIF: 2.3
    ChimeraX-MMTF: 2.1
    ChimeraX-Modeller: 1.0.2
    ChimeraX-ModelPanel: 1.1
    ChimeraX-ModelSeries: 1.0
    ChimeraX-Mol2: 2.0
    ChimeraX-Morph: 1.0
    ChimeraX-MouseModes: 1.1
    ChimeraX-Movie: 1.0
    ChimeraX-Neuron: 1.0
    ChimeraX-Nucleotides: 2.0.2
    ChimeraX-OpenCommand: 1.6.2
    ChimeraX-PDB: 2.4.4
    ChimeraX-PDBBio: 1.0
    ChimeraX-PDBLibrary: 1.0.1
    ChimeraX-PDBMatrices: 1.0
    ChimeraX-Phenix: 0.3
    ChimeraX-PickBlobs: 1.0
    ChimeraX-Positions: 1.0
    ChimeraX-PresetMgr: 1.0.1
    ChimeraX-PubChem: 2.1
    ChimeraX-ReadPbonds: 1.0
    ChimeraX-Registration: 1.1
    ChimeraX-RemoteControl: 1.0
    ChimeraX-ResidueFit: 1.0
    ChimeraX-RestServer: 1.1
    ChimeraX-RNALayout: 1.0
    ChimeraX-RotamerLibMgr: 2.0
    ChimeraX-RotamerLibsDunbrack: 2.0
    ChimeraX-RotamerLibsDynameomics: 2.0
    ChimeraX-RotamerLibsRichardson: 2.0
    ChimeraX-Sample: 0.1
    ChimeraX-SaveCommand: 1.4.1
    ChimeraX-SchemeMgr: 1.0
    ChimeraX-SDF: 2.0
    ChimeraX-Segger: 1.0
    ChimeraX-Segment: 1.0
    ChimeraX-SelInspector: 1.0
    ChimeraX-SeqView: 2.4.1
    ChimeraX-Shape: 1.0.1
    ChimeraX-Shell: 1.0
    ChimeraX-Shortcuts: 1.1
    ChimeraX-ShowAttr: 1.0
    ChimeraX-ShowSequences: 1.0
    ChimeraX-SideView: 1.0
    ChimeraX-Smiles: 2.1
    ChimeraX-SmoothLines: 1.0
    ChimeraX-SpaceNavigator: 1.0
    ChimeraX-StdCommands: 1.6
    ChimeraX-STL: 1.0
    ChimeraX-Storm: 1.0
    ChimeraX-Struts: 1.0
    ChimeraX-Surface: 1.0
    ChimeraX-SwapAA: 2.0
    ChimeraX-SwapRes: 2.1
    ChimeraX-TapeMeasure: 1.0
    ChimeraX-Test: 1.0
    ChimeraX-Toolbar: 1.1
    ChimeraX-ToolshedUtils: 1.2
    ChimeraX-Tug: 1.0
    ChimeraX-UI: 1.10.1
    ChimeraX-uniprot: 2.1
    ChimeraX-UnitCell: 1.0
    ChimeraX-ViewDockX: 1.0.1
    ChimeraX-Vive: 1.1
    ChimeraX-VolumeMenu: 1.0
    ChimeraX-Voyager: 0.1
    ChimeraX-VTK: 1.0
    ChimeraX-WavefrontOBJ: 1.0
    ChimeraX-WebCam: 1.0
    ChimeraX-WebServices: 1.0
    ChimeraX-Zone: 1.0
    colorama: 0.4.4
    comtypes: 1.1.10
    cxservices: 1.0
    cycler: 0.10.0
    Cython: 0.29.23
    decorator: 4.4.2
    distlib: 0.3.1
    distro: 1.5.0
    docutils: 0.17.1
    filelock: 3.0.12
    funcparserlib: 0.3.6
    grako: 3.16.5
    h5py: 3.3.0
    html2text: 2020.1.16
    idna: 2.10
    ihm: 0.20
    imagecodecs: 2021.4.28
    imagesize: 1.2.0
    ipykernel: 5.5.5
    ipython: 7.23.1
    ipython-genutils: 0.2.0
    jedi: 0.18.0
    Jinja2: 2.11.3
    jupyter-client: 6.1.12
    jupyter-core: 4.7.1
    kiwisolver: 1.3.1
    line-profiler: 3.3.0
    lxml: 4.6.3
    lz4: 3.1.3
    MarkupSafe: 1.1.1
    matplotlib: 3.4.2
    matplotlib-inline: 0.1.2
    msgpack: 1.0.2
    netCDF4: 1.5.6
    networkx: 2.5.1
    numexpr: 2.7.3
    numpy: 1.20.3
    numpydoc: 1.1.0
    OpenMM: 7.6.0
    openvr: 1.16.801
    packaging: 21.0
    ParmEd: 3.2.0
    parso: 0.8.2
    pexpect: 4.8.0
    pickleshare: 0.7.5
    Pillow: 8.2.0
    pip: 21.1.1
    pkginfo: 1.7.0
    prompt-toolkit: 3.0.19
    psutil: 5.8.0
    ptyprocess: 0.7.0
    pycollada: 0.7.1
    pydicom: 2.1.2
    Pygments: 2.9.0
    PyOpenGL: 3.1.5
    PyOpenGL-accelerate: 3.1.5
    pyparsing: 2.4.7
    PyQt5-commercial: 5.15.2
    PyQt5-sip: 12.8.1
    PyQtWebEngine-commercial: 5.15.2
    python-dateutil: 2.8.1
    pytz: 2021.1
    pyzmq: 22.1.0
    qtconsole: 5.1.0
    QtPy: 1.9.0
    RandomWords: 0.3.0
    requests: 2.25.1
    scipy: 1.6.3
    setuptools: 57.0.0
    sfftk-rw: 0.7.0.post1
    six: 1.16.0
    snowballstemmer: 2.1.0
    sortedcontainers: 2.4.0
    Sphinx: 4.0.1
    sphinxcontrib-applehelp: 1.0.2
    sphinxcontrib-blockdiag: 2.0.0
    sphinxcontrib-devhelp: 1.0.2
    sphinxcontrib-htmlhelp: 2.0.0
    sphinxcontrib-jsmath: 1.0.1
    sphinxcontrib-qthelp: 1.0.3
    sphinxcontrib-serializinghtml: 1.1.5
    suds-jurko: 0.6
    tables: 3.6.1
    tifffile: 2021.4.8
    tinyarray: 1.2.3
    tornado: 6.1
    traitlets: 5.0.5
    urllib3: 1.26.6
    wcwidth: 0.2.5
    webcolors: 1.11.1
    wheel: 0.36.2
    wheel-filename: 1.3.0

[Zach Pearson]

On Jul 26, 2021, at 10:06 AM, zjp@… wrote:
Hi Tom,

I want to claim this ticket because the fix seems simple and I'll gain some experience with trac: ​https://www.rbvi.ucsf.edu/trac/ChimeraX/ticket/4948

I made the fix Tristan suggested; if I were to push it, it'd show up in tonight's build right?

Thanks,

-- Zach

On July 26, 2021 11:12 AM, "Tom Goddard" <goddard@…> wrote:
Hi Zach,
That is fine. But I think Tristan is wrong and the current code is correct. So the difficulty with this bug report will be figuring out what is correct. The reason I think the current code is correct is because B = (8*pi*pi/3)<u*u> from Wikipedia (​https://en.wikipedia.org/wiki/Debye–Waller_factor) has u as a vector. In the ChimeraX code in vopcommand.py B = 8*pi*pi*<u_x*u_x>. The standard deviation sd = sqrt(<u_x*u_x>) in the code is for 1 dimension, and <u*u> = <u_x*u_x + u_y*u_y + u_z*u_z> = 3*<u_x*u_x> for isotropic motions. But I would want to know if Tristan has other reasons for thinking the bfactor scaling is wrong.
Tom

On Jul 26, 2021, at 12:06 PM, zjp@… wrote:
Hi Tom,

I think that makes sense but me check my understanding:

The code as written right now is like a reduced fraction; we don't need the 1/3 factor since we have 3 somewhere in the numerator (here from <u*u>).

Rearranging the equation from Wikipedia:

<u**2> = 3B / 8 * (pi ** 2)

<u**2> = 3(u_x*u_x)

3(u_x*u_x) = 3B / 8 * (pi ** 2)

(u_x*u_x) = B / 8 * (pi ** 2)

--

Maybe it'd be good to ask if he's run the code and seen it spit out a wrong number?

-- Zach

[Zach Pearson]

Hi Tristan, can you review the email chain that was just sent to you and let me know if you think it's sufficient justification for the current code? Have you run this code and gotten a wrong answer from it?

-- Zach

[Tristan Croll]

Hmm... Tom’s argument does make sense. The reason I looked was that a user said she’d tried applying a sharpening B-factor recommended by CryoSPARC (around 100 Å^2) to her map, and it blew out the high-resolution noise to values ~10k higher than the original mean.

I had a related conversation with Randy a couple of months back. I’d taken a model with predicted RMSD in the B-factor column and converted to actual B-factors using B=8 pi^2 (RMSD)^2... he told me I’d forgotten the factor of 3. 

Tomorrow I’ll try comparing results from a few different packages to double-check.

[Zach Pearson]

CC'ing Tom

[Tristan Croll]

emd_10452 sharpened with B=-100 by REFMAC (transparent green) vs. B=-33.33 by ChimeraX (solid)

[Tristan Croll]

emd_10452 sharpened with B=-100 by ChimeraX (values blown out ~10-million fold)

[Tristan Croll]

Comparing against sharpening by Refmac, it's pretty clear that the factor of three should be in there. Looks like the Wikipedia entry is wrong - see equations 5 and 6 at ​https://www3.cmbi.umcn.nl/bdb/theory/. Will discuss that in this morning's group meeting.

A side note: the B=-33.33 map sharpened by ChimeraX has some weird noise running through it that isn't in the Refmac one (the small jagged spots - they're quite high intensity and scattered in groups throughout the map). Something a bit funky about the Numpy FFT?

[Tristan Croll]

... and the more I read that, the more I'm confused as to who's wrong. But wrong or not, that's how everyone seems to define it (all the major packages seem to agree on what a B=-100 sharpening value means).

[Tristan Croll]

The high-resolution noise in the B=-33.33 map is probably not a bug, but rather lack of a feature. Not absolutely sure about Refmac (but CCP4 and Phenix tend to follow each other pretty closely), but the documentation for the equivalent in Phenix, phenix.auto_sharpen (​https://phenix-online.org/documentation/reference/auto_sharpen.html) says that it only applies the sharpening out to the "headline" resolution of the map (as specified by the user). By default everything past that point is blurred with a B-factor of 200 (if that option is turned off it's left as-is - i.e. still not sharpened). Makes sense - most cryo-EM maps are quite heavily over-sampled, making a lot of very low-intensity, high-res "information" that you don't want to magnify.

[Tom Goddard]

Ok, so Wikipedia differs by a factor of 3 from ​https://www3.cmbi.umcn.nl/bdb/theory/ and if the latter source is correct that would mean ChimeraX sharpening 3 times to much when B-factor is specified. Given your comparison to Refmac that appears to be the situation and is easy to fix. Zach can do that, and make a comment in the code as to the url to the B-factor equation being used.

The not sharpening beyond the map resolution makes sense -- usually the maps are oversampled by a factor of 3x. So when ChimeraX sharpens all the way out to the full oversampled resolution it is going to produce lots of nasty noise. I'd be surprised if the simply truncate the sharpening abruptly, ie have a discontinuous jump in the Fourier space scaling at a certain radius. I think that is likely to cause artifacts and I would suspect there is actually some roll-off in the transition. We may need to look at the Phenix code to see exactly what it is doing. We could add another option to specify the sharpening cutoff if we know how to transition the Fourier space scaling.

[Tristan Croll]

Relevant code used by phenix.auto_sharpen is at https://github.com/cctbx/cctbx_project/blob/fcff45919ee0b5cdf9f12cc9ea9d2f9efa9a0681/cctbx/maptbx/segment_and_split_map.py#L2810. Description of the k_sharpen parameter is at https://phenix-online.org/documentation/reference/auto_sharpen.html:

Steepness of transition between sharpening (up to resolution ) and not sharpening (d < resolution). Note: for blurring, all data are blurred (regardless of resolution), while for sharpening, only data with d about resolution or lower are sharpened. This prevents making very high-resolution data too strong. Note 2: if k_sharpen is zero or None, then no transition is applied and all data is sharpened or blurred.

If in doubt: this was all written by Tom Terwilliger (tterwilliger@newmexicoconsortium.org).
[https://phenix-online.org/documentation/reference/%22https://i.ytimg.com/vi/S56rYoZWxnM/sddefault.jpg%22]<https://phenix-online.org/documentation/reference/auto_sharpen.html>
Auto-sharpening cryo-EM or crystallographic maps with auto_sharpen - Phenix<https://phenix-online.org/documentation/reference/auto_sharpen.html>
Specific limitations and problems: Maps produced with the extract-unique option of map_box should not be sharpened with auto-sharpen. These maps are closely masked around the density of a single molecule and are set to zero in much of the map, so the information about noise in the map that normally is available is missing and auto-sharpen does not work properly.
phenix-online.org



________________________________
From: ChimeraX <ChimeraX-bugs-admin@cgl.ucsf.edu>
Sent: 27 July 2021 16:59
Cc: goddard@sonic.net <goddard@sonic.net>; Tristan Croll <tic20@cam.ac.uk>; zach.pearson@ucsf.edu <zach.pearson@ucsf.edu>
Subject: Re: [ChimeraX] #4948: volume gaussian bfactor off by factor of 3

#4948: volume gaussian bfactor off by factor of 3
------------------------------------+--------------------------
          Reporter:  Tristan Croll  |      Owner:  Zach Pearson
              Type:  defect         |     Status:  accepted
          Priority:  normal         |  Milestone:
         Component:  Volume Data    |    Version:
        Resolution:                 |   Keywords:
        Blocked By:                 |   Blocking:
Notify when closed:                 |   Platform:  all
           Project:  ChimeraX       |
------------------------------------+--------------------------

Comment (by Tom Goddard):

 Ok, so Wikipedia differs by a factor of 3 from
 https://www3.cmbi.umcn.nl/bdb/theory/ and if the latter source is correct
 that would mean ChimeraX sharpening 3 times to much when B-factor is
 specified.  Given your comparison to Refmac that appears to be the
 situation and is easy to fix.  Zach can do that, and make a comment in the
 code as to the url to the B-factor equation being used.

 The not sharpening beyond the map resolution makes sense -- usually the
 maps are oversampled by a factor of 3x.  So when ChimeraX sharpens all the
 way out to the full oversampled resolution it is going to produce lots of
 nasty noise.  I'd be surprised if the simply truncate the sharpening
 abruptly, ie have a discontinuous jump in the Fourier space scaling at a
 certain radius.  I think that is likely to cause artifacts and I would
 suspect there is actually some roll-off in the transition.  We may need to
 look at the Phenix code to see exactly what it is doing.  We could add
 another option to specify the sharpening cutoff if we know how to
 transition the Fourier space scaling.

--
Ticket URL: <https://www.rbvi.ucsf.edu/trac/ChimeraX/ticket/4948#comment:12>
ChimeraX <https://www.rbvi.ucsf.edu/chimerax/>
ChimeraX Issue Tracker

[Zach Pearson]

I have pushed the code suggested at the top of the ticket, so that fix should show up in the nightly build. I'm not sure whether to open a new ticket for the sharpening issues or to keep working on this ticket. Tom?

[goddard@…]

Thanks!  Make a new ticket for reducing bfactor sharpening noise, enhancement request, copy and paste Tristan's discussion.

[Tristan Croll]

Urgh. Sorry to do this, but I think I got the correction wrong (the applied B-factor comes out 3x too large, not 3x too small). So rather than

sd = sqrt(abs(bfactor)*3/(8*pi**2))

it should be

sd = sqrt(abs(bfactor)/(3*8*pi**2))

... or am I just over-tired?

[Zach Pearson]

I'm confused; in a previous comment comparing REFMAC and ChimeraX, ChimeraX's B-factor was 1/3 of REFMAC's (33.3 vs 100), so we added 3 in the numerator to equalize them. If it's 3x too large now, is it 300?

[Zach Pearson]

Maybe 3 in the denominator is right; looks like CX and REFMAC overlap pretty well with REFMAC at 100 and CX at 33.3.

[goddard@…]

Zach's code change looks right to me.  New code has "sd = sqrt(abs(bfactor)*3/(8*pi**2))".  The added factor of 3 make standard deviation sd larger which is what is needed since sharpening by specifying negative bfactor divides by this Gaussian in Fourier.  So a broad Gaussian does less sharpening.

[Tristan Croll]

I tried it out by hot-patching my ChimeraX installation:

        sd = sqrt(abs(bfactor)/(3*8*pi**2))

... is what comes out right. Attached two maps are a box cut from emdb_10452 with a B-factor of -100 applied either by phenix.auto_sharpen or by ChimeraX (after making the above change). While there are some subtle differences (auto_sharpen rescales the map to SD=1, does some correction for anisotropy, and avoids sharpening beyond the map resolution), they're pretty close to equivalent. In the image, the ChimeraX map is in wireframe and Phenix one is surface (contours of 0.0184 and 6.75 respectively). Still not quite sure why the math comes out this way, but that seems to be it.
________________________________
From: ChimeraX <ChimeraX-bugs-admin@cgl.ucsf.edu>
Sent: 28 July 2021 02:11
To: zach.pearson@ucsf.edu <zach.pearson@ucsf.edu>; Tristan Croll <tic20@cam.ac.uk>
Cc: goddard@sonic.net <goddard@sonic.net>
Subject: Re: [ChimeraX] #4948: volume gaussian bfactor off by factor of 3

#4948: volume gaussian bfactor off by factor of 3
------------------------------------+--------------------------
          Reporter:  Tristan Croll  |      Owner:  Zach Pearson
              Type:  defect         |     Status:  reopened
          Priority:  normal         |  Milestone:
         Component:  Volume Data    |    Version:
        Resolution:                 |   Keywords:
        Blocked By:                 |   Blocking:
Notify when closed:                 |   Platform:  all
           Project:  ChimeraX       |
------------------------------------+--------------------------

Comment (by goddard@…):

 {{{
 Zach's code change looks right to me.  New code has "sd =
 sqrt(abs(bfactor)*3/(8*pi**2))".  The added factor of 3 make standard
 deviation sd larger which is what is needed since sharpening by specifying
 negative bfactor divides by this Gaussian in Fourier.  So a broad Gaussian
 does less sharpening.

 }}}

--
Ticket URL: <https://www.rbvi.ucsf.edu/trac/ChimeraX/ticket/4948#comment:20>
ChimeraX <https://www.rbvi.ucsf.edu/chimerax/>
ChimeraX Issue Tracker

sharpen_comparison.tar.gz​

map_comparison.jpg​

[Tristan Croll]

Added by email2trac

[Tristan Croll]

Added by email2trac

[goddard@…]

You are right Tristan.  It is always good to look at it 3 ways.  Since we wanted the older ChimeraX bfactor of 33 to act like the new ChimeraX bfactor of 100 we of course need to divide by 3 in the new code.  My former reasoning was wrong because the Gaussian convolution in Fourier space is not with a Gaussian of width sd, it is with the Fourier transform of that Gaussian which has width proportional to 1/sd in Fourier space.

Zach, could you change the code to put the 3 in the denominator?

[Zach Pearson]

Fixed in tonight's build.