Collaborative Computational Project No. 4
Software for Macromolecular X-Ray Crystallography

Known General Problems

This page is intended to list frequently occurring problems which fall between being "bugs" and being "features". These include rather esoteric installation or set-up problems for specific systems.

List of problems

  1. General problems
  2. Problems with CCP4 under IRIX (separate page)
  3. Problems with CCP4 under OSF1/Tru64 Unix (Digital/Compaq)
  4. Problems with CCP4 under SunOS (separate page)
  5. Problems with CCP4 under Linux (separate page)
  6. General page for CCP4 on Windows (separate page)
  7. Problems with CCP4 on Macintosh (separate page)
  8. General problems with CCP4i graphical user interface (separate page)

General Problems

These are version/OS unspecific problems which you may encounter.

Running Acorn with PDB file from Arp/Warp

If you wish to run Acorn using the output PDB file from an Arp/Warp job you will need to remove the dummy atoms (DUM) from the PDB file first. Acorn is currently not able to handle these atom labels and will crash if they are included. You will see an error message similar to this one when this happens:

*** Warning(s): point code unit    function
***                 1 16576    1    MMDB_F_Atom
*** file   : /home/bloggs/CCP4_Work/308_warpNtrace.pdb
*** warning: atom serial number does not match position
*** position unavailable, serial number 1
*** warning: unknown form factor encountered
*** position unavailable, serial number 1
No match for atom ID   giving up!
ACORN:   No match for atom label(ATSORT)

[Back to top]

I get warnings when building rxdispencer

When configuring and building the rxdispencer regular expression package, the following warnings are sometimes observed:

cat: /home/software/xtal/ccp4-6/ccp4-5.99.4/lib/rxdispencer/*/PLUGIN/REQ: No such file or directory
cat: /home/software/xtal/ccp4-6/ccp4-5.99.4/lib/rxdispencer/*/PLUGIN/REQ: No such file or directory

As the plugins are optional and are not required by CCP4, this is not a problem and the warnings can be ignored.

*** Rx/Dispencer textual pattern matcher enabled.
=== WARNING: Missing suggested package: libguile
=== WARNING: Missing suggested package: guile

rxdispencer has an optional interface for guile but this is also not required by CCP4 and so this warning may also be ignored.

[Back to top]

Graphs in log files do not display in Mozilla

When trying to view html-ised log files in Mozilla, the graphs are not displayed, and a warning is given that there is no appropriate plug-in for type application/x-java-vm

First, you need the Java runtime environment package installing. But even if this is installed, you need to tell Mozilla about it. You need to create a soft-link in $HOME/.mozilla/plugins

   ln -s <j2re-path>/
and re-load the file. More hints are available at

[Back to top]

The display in Mathematica is messed up when I source ccp4.setup

An environment variable set in ccp4.setup can reportedly interfere with the proper display in Mathematica.

If the XUSERFILESEARCHPATH environment is not set, the Mathematica interface is fine. However, if it is set (even just to /usr/lib/X11/app-defaults) the fonts and the buttons in the Mathematica notebook interface are messed up.

A reported fix for this problem is to replace XUSERFILESEARCHPATH with XAPPLRESDIR, which works for xloggraph at least, and doesn't interfere with the proper functioning of Mathematica.

(Thanks to Randy Read)

[Back to top]

I am running NCSMASK / REINDEX / TPLOT / TRACER and get unexpected results

There are several known name conflicts with non-CCP4 programs:

and probably more. If these appear first on the PATH, then you will not be running the CCP4 program, and you will get unexpected results. The solution is to change the variable ccp4_first_in_path in the file ccp4.setup to be 1, and source it again. This will ensure that the CCP4 program takes priority.

Note that for the change to take full effect you may need to log off and on completely, and just sourcing the ccp4.setup again may not be sufficient.

[Back to top]

Some programs e.g. REFMAC5, MOLREP have poor performance across NFS

There is at least one report of very poor performance of some CCP4 programs when running with files accessed over NFS. The programs run okay, but spend most of their time accessing files rather than using the CPU, resulting in extended times for them to complete.

The problem has been traced back to the CCP4_SCR environment variable in ccp4.setup being set to a non-local (NFS) directory. By resetting the scratch area to be a local directory the performance is greatly improved.

(Thanks to Mikko Huhtala)

[Back to top] not generated/build fails in CCIF, fontpack/cifdic_to_symtab cannot find

This is two separate problems with similar suspected causes:

  1. Several reports have been received of the failure of fontpack to generate during a --with-shared-libs build of ccp4. This occurs during the make install phase of installation. The simplest solution is to rerun make install. Alternatively,

    cd $CCP4/lib/data
    cp font84.dat $CCP4/lib/font84.dat
  2. The make phase of installation may fail when trying to make the CCIF symbol table under the --with-shared-libs option of ccp4. The error message is of the form:

    ./cifdic_to_symtab: rld: Fatal Error:
    Cannot successfully map soname ' under any of the filenames ...
    The simplest solution is to rerun make. If this fails then try:
    cd $CCP4/lib/ccif
    cp $CCP4_LIB
    cd $CCP4 ; make

Currently there is no known reason for these failures. The best guess is that it arises from the hash table of libraries on LD_LIBRARY_PATH not being updated during the running of the make install script (a similar feature is sometimes found for the update of programs on the PATH).

[Back to top]

Each time I try to run one of the programs it fails with the message Error: cannot map

This may be a problem if the suite was built with the --with-shared-lib option. An error message of the form:

19391:/program/programs/ccp4-4.1.1/bin/hklview: /sbin/loader: Fatal
Error: cannot map
means that the program you're trying to run cannot find the shared library file in any of the places it would normally look.

The environment variable LD_LIBRARY_PATH is used to set the list of non-standard directories where programs will look for the libraries - this should be set by the relevant lines in your ccp4.setup file:

if ($?LD_LIBRARY_PATH) then
(This shouldn't be confused with the LD_PATH which appears nearby in the setup file but which is unrelated and which also uses a different syntax.)

Check that LD_LIBRARY_PATH is set correctly, e.g. do

(this should return something like /lib:/usr/lib:/usr/users/ccp4/ccp4/lib), and make sure that the $CLIB directory is included. If there is still a problem then check that has actually been installed in $CLIB directory.

[Back to top]

Some programs e.g. CAD run extremely slowly on one system compared to the same job on another

There is a peculiar problem with the binsort program (which is used to do binary sorting in programs like CAD) on some systems, whereby the sorting becomes more inefficient as the amount of memory allocated for the sorting is increased. Normally it is expected that the opposite behaviour would be observed.

binsort in CCP4 4.1.1 is compiled with default memory allocation set to 8MB, but this setting can be overridden by setting the environment variable BINSORT_MEM. Uncommenting and editing the line

#  setenv BINSORT_MEM     8388608               # edit this if necessary
in ccp4.setup should do the trick.

The optimal value seems to be around 2MB (2097152 bytes). We would welcome any feedback from people who have experienced this problem - mail to

(Thanks Phil Evans and Clemens Vonrhein)

[Back to top]

Calls to LAPACK routines crash at run-time on non-IEEE compliant machines

On non-IEEE compliant machines the LAPACK routines distributed with CCP4 4.1 onwards will compile successfully, but certain routines (e.g. DSYEVR) which call ILAENV may crash at run-time.

ILAENV needs to be altered for non-IEEE compliant machines; apply the following patch to the file $CCP4/lib/lapack/src/ilaenv.f:

diff ilaenv-dist.f ilaenv-non-ieee.f 
< C     ILAENV = 0
<       ILAENV = 1
>       ILAENV = 0
> C     ILAENV = 1
< C     ILAENV = 0
<       ILAENV = 1
>       ILAENV = 0
> C     ILAENV = 1
and recompile.

Technically this is a bug within the CCP4 installation procedure, as the changes required are documented in the LAPACK working notes. In future the installation procedure should resolve this problem automatically, without the need for human intervention.

[Back to top]

Problems with insufficient memory when running MOSFLM/REFMAC5/...

Some of the larger programs in the suite may fail due to there being insufficient memory. On sum systems this may be reported as the problem, on others it may result in a segmentation violation or bus error. The failure will be immediate on the launch of the program

The solution is to increase the available memory, either RAM or swap space, or alternatively:

MOSFLM: change all occurrences of

(mosflm_all_ip_inc.for) to lower values (4000 is sufficient for most cases).

REFMAC5: set QQDEN (pls_incl.fh) to a smaller value, eg 10,000,000, (for medium sized crystals QQDEN around 8000000 should be enough), and correspondingly reduce MAXATOM and MAXRESIDUE (eg 15000 and 7000).

After making these changes the programs must be recompiled and moved to the CBIN directory.

[Back to top]

Problems when trying to deposit coordinates

There have been some problems reported when trying to deposit coordinates - in these cases, all ATOM records in the pdb file are rejected due to atom numbers (rather than names) appearing in columns at the end of the ATOM records.

At present it is not clear which package has written out these numbers, but to fix the file simply run PDBSET with an empty script - this will clear the numbers and write out a correctly formatted pdb file, e.g.:

pdbset XYZIN origfile.pdb XYZOUT newfile.pdb << /dev/null

[Back to top]

Regular expression package

The libccif library used to read/write mmCIF files requires a regular expression ("rx") package to reside on the system. Most modern systems have a good enough native rx package, but some older system may not. To cover this eventuality, the CCP4 distribution includes source code for a version of one from Henry Spencer / Tom Lord which should work on most older systems. This package is built by the --with-rxdispencer configure switch. However, this package is known not to compile on some newer systems. Thus, you should assume a native rx package to begin with, and only if this fails try the distributed rxdispencer.

Details for specific systems follow:

IRIX 32-bit
Native rx should be fine with IRIX 6.* For IRIX5.3, rxdispencer is apparently OK.
IRIX 64-bit
rxdispencer has not been ported to 64-bit architectures and does not work. Problems have been discovered with IRIX6.2 native rx (although it is believed that there are OS patches which fix these), but IRIX6.5 appears to be fine. The moral is that if you are determined to use 64-bit (or n32) objects, then you need to upgrade to 6.5

[Back to top]

After sourcing ccp4.setup, man will find CCP4 man pages but system man pages are no longer available

Before sourcing ccp4.setup, check whether the MANPATH environment variable exists (use echo $MANPATH). If no MANPATH is set then under IRIX man searches a built-in set of paths; you must edit ccp4.setup to include these paths explicitly, e.g. use

    if (${?MANPATH} == 0) then
      setenv MANPATH \
      # edit this if necessary
      setenv MANPATH $CCP4/man:/usr/man:$MANPATH
      # IRIX (and others?) may use /usr/catman or /usr/share/catman
      # rather than /usr/man.  It *probably* doesn't do any harm to
      # append those anyhow.

Other systems may have slightly different default search paths, e.g. OSF1/Digital Unix has /usr/share/man:/usr/dt/share/man:/usr/local/man, Solaris/Sun has /usr/share/man. Check man locally to see what these are.

[Back to top]

I get the following error when running xloggraph: Error: xloggraph -- Tom's font file not specified

The X-windows programs XLOGGRAPH and XPLOT84DRIVER need a number of "X-windows resources" defaults setting, e.g. to find Tom's font or set the colours when drawing lines.

CCP4 supply the file $CCP4/x-windows/XCCPJIFFY/XCCPJiffy.AppDefaults, which contains default settings for most of these resources - upon "making" the X-jiffy software a couple more site-specific resources are appended to make a file XCCPJiffy (in the same directory). Upon "make install" XCCPJiffy should be installed automatically in the directory $CCP4_LIB/X11/app-defaults

The user can then access these defaults automatically provided that this directory is one of those to set in the XUSERFILESEARCHPATH variable in your ccp4.setup (the default is $CCP4_LIB/X11/app-defaults/)

What can go wrong?

Try the following checks, in order:

  1. Try "echo $XUSERFILESEARCHPATH" - in ccp4.setup this should default to include $CCP4_LIB/X11/app-defaults, then
  2. Check that $CCP4_LIB/X11/app-defaults exists. Go there and check that it contains the file XCCPJiffy, then
  3. Check the contents of the XCCPJiffy file (use e.g. more) - somewhere it should have a line like XCCPJiffy*tomFontPath: /ccpdisk/ccp4/lib/nice_font.bin, then
  4. Check that nice_font.bin is actually there e.g. do ls -l /ccpdisk/ccp4/lib/nice_font.bin (or whatever the path is in XCCPJiffy).
Any one of these steps could show something has gone wrong.

Other things could go wrong ...

... things that we don't know about or understand! For instance, maybe there is some peculiarity in the local system (e.g. one user couldn't source ccp4.setup successfully from .login unless he commented out the lines setting XUSERFILESEARCHPATH). In these cases you could try the following.

Adding the Defaults to your .Xdefaults file

The ~/.Xdefaults file holds the user preferences for X applications, and can be used to override the systems defaults.

Adding the Defaults to the X-database using xrdb

You can add the defaults directly to the x-database using the xrdb command:
xrdb -merge XCCPJiffy
should add them; use
xrdb -query
to see that they have been set correctly. I'm not sure if this has been done each time you login, or only once, ever (in which case you will only need to do it again if you move the installation at any time).

[Back to top]

Problems with CCP4 under OSF1/Tru64 Unix (Digital/Compaq)

These are specific problems with the CCP4 suite when installed on Digital/Compaq systems running OSF1/Tru64 Unix.

Some programs (e.g. scala) fail to run, with error message "datasize exceeds process limits"

This problem seems to be associated with Digital workstations, and is due to insufficient system resources being set as default.

(The following advice is lifted almost verbatim from the MOSFLM problems page - thanks to Harry Powell)

Follow this procedure and check at each stage if the program will run successfully. Type:


and check that the datasize is at least as large as your installed RAM, and stacksize is 32768 bytes. If not, type


and check again. If there has been no change to those parameters, contact your system manager and get her/him to set the following parameter values using dxkerneltuner; the system will have to be rebooted so that the new values can be used.

     run dxkerneltuner

     (a window pops up)

     select 'proc' - fifth from the bottom on the list. Press 
     the 'select subsystem' button.

     (a second window pops up)

     Change the third item down 'per-proc-stack-size' from 
     2097152 to 33554432 (=1024*32768) (i.e. equal to the 
     value in the box just below).

     Change the 'per-proc-data-size' parameter from
     134217728 to 1073741824 (or your available memory????).

     press 'apply' then 'ok'

     You will probably get a warning about how dangerous 
     this is...

     exit from dxkerneltuner.


[Back to top]

Problems compiling some programs (e.g.refmac5) using f90 compilers on V4.0, f77/f90 on V5.*

As of OSF1/Tru64 Unix V5.0, using the "f77" command actually invokes the Compaq Fortran 90 compiler, which differs from the old Fortran 77 compiler present on V4.0 of the operating system. To get the behaviour of the older compiler on the newer systems it is necessary to use f77 -old_f77.

In practice this should not be a problem - the CCP4 configure under V5.* should set the Makefiles up so that the f90 default compiler will work okay. However, on V5.1 (and possibly also other versions where f77 is an alias for f90), compilation of some programs (e.g. refmac5) may fail with a message of the form

Fatal:  Insufficient virtual memory to continue compilation.
It's not clear that this has anything to do with the compiler version, in fact it is a similar problem to insufficient system resources being set as default.

The limits can be set to the highest value allowed by using the unlimit command in csh/tcsh, and then attempting the compilation again. If it still doesn't work then run the sys_check program (as root) and follow the tuning suggestions.

Alternatively: to force compilation of the suite using the older compiler, set the Fortran compiler in config.status as follows

FC="f77 -old_f77"
then start the installation again by running config.status and then make. This should work without needing to reset the resource limits.

(To explicitly use the Fortran 90 compiler in the installation, set

FC="f90" FOPTIM="-O1"
in config.status. Clemens Vonrhein notes that "for f90 the default optimisation is actually -O4. Using 'only' -O1 is a bit depressing, but as far as I can remember some programs won't run correctly when compiled with higher optimisations. My first guess would be that there are problems with these programs - in my experience the Compaq/Digital compilers are of very high quality (although probably a bit picky about standard conformance).")

(Thanks to David Schuller and Clemens Vonrhein)

As of release 4.2.1 -__V40_OBJ_COMPAT -nointrinsics has been removed from the XCFLAGS option in configure. This is required for V5 executables to run under V4.0, so may be required for this case.

[Back to top]

Environment setting sometimes causing a syntax problem with /bin/sh

This problems appears when trying to use the ccp4.setup-bash where a syntax like
export X=something
will cause the shell to complains the syntax is incorrect.

The way to solve this problem is to change the

at the top of the file into
which would not complain about this syntax.

some programs (e.g. CAD) run incredibly slowly even on fast machines running OSF1 V5.0

It appears there is a problem with the system sorting utility (which is used in CCP4 programs when sorting and merging MTZ files) on some OSF1 systems. The sort runs more slowly when more memory is allocated to it, which is the opposite of the expected behaviour.

In these cases it seems that reducing the memory by resetting the BINSORTMEM variable in ccp4.setup greatly improves the performance. A value of 2097152 (2MB) seems optimal in these cases (current CCP4 default is 8MB).

(Thanks to Clemens Vonrhein)

More ... (from Frank Vondelft):

I took another look at the problem documented in the link above, because even with the BINSORT_MEM value suggested there I found cad running time to be ridiculous (1.5 minutes for a piddly little cell at 2.3A). Turns out BINSORT_MEM should be more like 100000 (rather than 2M that Clemens suggested), then it runs acceptably. Above 1M, the time goes up exponentially.

BINSORT_MEM             |       Time(s)                 
                        |       17,686  |       136,582   (no. reflections)
                        |               |  osf1    |    linux
1000                    |       ["out of internal or external memory"]
10000                   |       2.413     18.17         9.05
100000                  |       2.431     18.20         8.98
1000000                 |       3.858     18.18         8.85
10000000                |       38.439    18.47         8.64
100000000               |       -       1700.79         8.49

Keeping it small does not affect runtime on linux, I couldn't test it on IRIX. ... Oh, we have an ESV40 running OSF1 v5.1, but it's the same on v5.0.

[Back to top]

`ipdisp -md' etc fails under Tru64 with error message "*** Can't open SPDFIL:"

There is a problem with the ipdisp script running under Tru64 which results in the above error. This turns out to be because "$@" doesn't expand to nothing when there are no parameters.

It can be cured by using /bin/ksh instead of /bin/sh. Alternatively, setting BIN_SH=svr4 in the environment (e.g. via the system init files) fixes the problem.

(Thanks to Dave Love)

[Back to top]

CCP4 Main Page UP