BUSTER frequently-asked questions

See also:

      "buster-discuss" site:globalphasing.com




How can I check my BUSTER is correctly installed? How fast is it supposed to run?

A good start is to always run

  checkdeps -n

to exercise various programs from the BUSTER package and check some basic functionality.

We also distribute a test script refine_test.sh (in $BDG_home/samples/autobuster directory) which runs a small refinement, using the options that we would recommend for regularising a structure and generating a new map after you've done a bit of rebuilding in coot. Further information on how to run it and on how long it takes to run on several machines we have tested it on can be found on the the BusterShortRefineTest page.

What BUSTER output should I look at?

Please see the dedicated page on interpreting BUSTER output.

When should I start using TLS?

For relatively high-resolution X-ray data, the use of TLS can make difference density clearer at the end of a refinement. Once modelling (to take account of difference density) is starting to become frustrating, running BUSTER with -M TLSbasic sometimes improves the density and helps during model adjustments. Once you've started using TLS, it's probably best to keep using it for the rest of the refinement.

For low-resolution data and models where there is a well-understood domain structure, TLS may well be useful from the early stages.

Why does BUSTER use one B-factor per atom even at low(ish) resolution?

The BUSTER geometry function incorporates a very strong BCORREL term which restrains the B-factor difference between bonded atoms, so neighbouring atoms are restrained to having similar B-factors. This type of restraint seems to work well even at resolution ranges where one would have used grouped B-factors refinement previously.

At very high resolutions you may want to consider using individual ADP refinement via the -M ADP macro.

In visualise-geometry-coot, what is an "Unhappy atom"?

The "unhappy atom" category uses the information from the analysis of restraint outliers (so-called geometry screen output), that sums the geometry function contribution of each atom for each restraint (bond, angle, torsion, contact term etc). The sorted list of those atoms contributing the most to the overall geometry function value provide the basis for this "unhappy atom" classification.

The list of these atoms can serve as an indication of problematic hotspots that would require some visual inspection against the 2mFo-DFc and mFo-DFc (difference) maps.

Why do the Rfree and Rfact values change abruptly at the start of the final cycle of a BUSTER refinement?

If the parameter AnalyseVoids is set to 'yes' (which is the default) the bulk solvent correction in the final cycle attempts to account for hydrophobic voids, i.e. regions within the model that are neither occupied by atoms nor by bulk solvent. We have found that this is often useful in removing patches of negative difference density from, for example, the interior of helix bundles. If you find that the change is for the worse on one of your structures, try running with refine AnalyseVoids=no ....

How should I run a BUSTER refinement after some model rebuilding with coot?

We provide some macros specifically for short BUSTER refinements after some model rebuilding with coot: see AutoBusterShortRunMacros page for details.

What is an easy way to get started with occupancy refinement?

We provide a simple tool to generate appropriate commands (in Gelly-syntax) describing the most common classes of occupancy refinement:

The analysis is based on some basic assumptions, like

Running e.g.

% pdb2occ -p your.pdb -o occref.gelly
% refine -p your.pdb -Gelly occref.gelly ...

will first analyse the existing PDB file (creating the text file occref.gelly), which is subsequently used in refinement. The text file can also be used as a starting template for defining more complicated situations. For further information and a full example please see AutoBusterLigandAndOccRef.

How do I specify the value used to select the set of reflections used for computing R-free?

You can use the parameter BusterFreeFlagValue to select an explicit test-set flag:

% refine BusterFreeFlagValue=0 ...

It defaults to '0' to follow the usual CCP4 selection - see also AutoBusterFreeRFlag.

What exactly do all those columns in the output MTZ file mean?

The MTZcolumns page aims to explain what each column means and how they could/should be used.

Please note that for PDB deposition we provide PDBx/mmCIF files that should be used directly as-is: the use of conversoin or extraction tools (like PDB_EXTRACT, SF_CONVERT etc) should be avoided if at all possible!

Handling LINKs and covalent ligands in BUSTER

How do I set up a disulfide bond to a symmetry-related CYS?

This can be done by adding a SSBOND card before the CRYST1 line in the input PDB file. The card must have correct column spacing.

SSBOND   1 CYS A  429    CYS A  476                          1555   4445  2.04
key:           c nnnn        d mmmm                               oooooo
change 'c' and 'nnnn' to the chain id residue number of the identity copy CYS
       'd' and 'mmmm' to the chain id residue number of the symmetry related CYS
leave  'oooooo' alone (provided it is not 1555 BUSTER will work out the correct symmetry operator).

PDB entry 4J0U provides an example with correct column spacing and a pretty disulfide across a symmetry contact:

Is there anything I can do with Grade if all I have as input is a PDB file with no hydrogens as source for restraint generation?

If that's all you have, then the general answer is no; it's entirely possible for a PDB file arising from a sufficiently badly driven refinement process to lack critical information about the chemistry of the ligand. But if you also have a good idea as to what the chemistry is, have a look at HydrogenatePDBwithOpenBabel

What is the order and the priorities for setting specific options?

The order in which settings can be changed from the defaults when running BUSTER:

1. installation-wide

This means a .autoBUSTER file in the same directory as the command (e.g. 'refine'). Or in more practical terms, these files should be located in

    % dir=`which refine`
    % ls -l `dirname $dir`/.autoBUSTER
    % set dir=`which refine`
    % ls -l `dirname $dir`/.autoBUSTER

2. user-wide

A file in the users home directory, i.e.


3. directory-wide

A file in the current directory (where the command, eg. 'refine' is being issued):


4. environment

Setting environemental variables in the usual shell-dependent way, eg.

    % MyParameter="XYZ"
    % export MyParameter
    % refine ...
    % setenv MyParameter "XYZ"
    % refine ...              

5. command-line

% refine MyParameter="XYZ" ...


% refine -M MyMacro ...

where a file MyMacro.macro contains something like

# my fancy stuff

and the directory containing that MyMacro.macro file being specified in the autoBUSTER_MacroDirs environmental variable.

Remember, the command-line is read in order, so

% refine MyParameter="ABC" -M MyMacro ...

will have a different effect to

% refine -M MyMacro MyParameter="ABC" ...

There is a big advantage of just using command-line arguments of the form par="value": the complete command-line is written into the header of the final refine.pdb file - so you always know exactly how it was run.

What is the optimal number of processors to use with BUSTER?

Please see the dedicated page Optimal number of processors for BUSTER.

How can I specify a specific Perl version/binary for use with BUSTER?

You should be able to set a specific Perl binary at installation time via

% env BDG_perl=/where/ever/bin/perl ./GPhL_BUSTER_snapshot_20210224_install.sh

to have this binary set within the BUSTER installation (instead of taking the location of "perl" from the PATH at installation time).

If you need to use another Perl version than the one found when BUSTER was installed, you can do the following:

      % env BDG_perl=/opt/myperl/bin/perl KeepFromEnv_BDG_perl=yes hydrogenate ...

If this works, you could add the following lines to your $BDG_home/setup_local.(c)sh files:

# setup_local.csh
setenv BDG_perl /opt/myperl/bin/perl
setenv KeepFromEnv_BDG_perl yes


# setup_local.sh
export BDG_perl=/opt/myperl/bin/perl
export KeepFromEnv_BDG_perl=yes

Remember to re-source the setup file again via

% source $BDG_home/setup_local.csh    # tcsh/csh
  - or -
% . $BDG_home/setup_local.sh          # sh/bash/zsh/ksh/dash

I get an error message 'OMP abort...'

The core refinement part of BUSTER is a fairly complicated multi-threaded program, and as such needs rather a lot of stack space. If you get error messages of the form

OMP abort: Unable to set worker thread stack size to 4194304 bytes

you can try some of these solutions:

A MakeTNT application does not run.

If any MakeTNT application (MakeTNT, PDB2TNT, MDL2TNT, MOL22TNT, EditTNT, EditREFMAC or MakeLINK) fails to run please see MakeTNT applications do not run page for advice.

I get a 'server: bind: Operation not supported' message from refine

BUSTER requires that the file system it's running on supports the creation of UNIX sockets - the Linux and Darwin local filesystems and NFS do this, but AFS does not. If you see this message, try running BUSTER in a directory on a local filesystem.

BusterFAQ page. Please address problems, corrections and clarifications to buster-develop@globalphasing.com