A list of known bugs and fixes for the current CCP4i version can be found via the CCP4 Problems Pages.
For help or to report new problems, please send mail to
ccp4gui@ccp4.ac.uk.
Please include as much as information as you can - see
here for details
about reporting problems.
There is also a list of problems with Tcl/Tk and BLT which may be relevant.
March 2010: The ccp4iwish executable link was removed after version 6.1.1 and this error occurs if a user has a configure.def file in their .CCP4 folder in the user home area dating from version 6.1.1. The fix is to replace the "ccp4iwish" reference in "System Administration" -> "Configure Interface" -> "Command to run iMosflm" with the path of the MOSFLM_WISH environment variable, that is:
[GetEnvPath MOSFLM_WISH]
July 2008: There are a number of issues with using CCP4i with Tcl/Tk version 8.5, since it has some significant differences from Tcl/Tk 8.4 (the current recommended version for running CCP4i).
Starting CCP4i using Tcl/Tk 8.5
The most important difference is that at the time of writing there isn't a version of the BLT module that is compatible with Tcl/Tk 8.5, which means that there is no bltwish interpreter (which is normally used by CCP4i) for this version.
On UNIX/Linux it is still possible to launch CCP4i with Tcl/Tk 8.5, by editing the $CCP4/ccp4i/bin/ccp4i file to use wish rather than bltwish.
The lack of BLT means that loggraph and the monomer library sketcher will be unavailable. Some task interfaces may also fail to start or crash when an attempt is made to launch them.
Check buttons/toggle buttons
In addition Tcl/Tk 8.5 renders many aspects of CCP4i in a different way to Tcl/Tk 8.4 (for example by using different font settings), so CCP4i may look quite different - for example, the controls in the main window may be misaligned and some buttons may look different.
In most cases this should not make any difference when using the interfaces, however check buttons under 8.5 may appear to be permanently "checked". This is due to the tickmark being almost the same colour as the button background - however the buttons should still function. This issue will should be addressed in CCP4 6.1 and later.
Try "ssh -Y" instead. This enables trusted X11 forwarding which are not subjected to the X11 SECURITY extension controls.
Also, the speed of X forwarding can be increased significantly by turning on compression using the -C flag to ssh. Other alternatives include NX/FreeNX and VNC.
This problem has been reported on Windows but could conceivably be observed on any platform where one of the utilities such as MapSlicer or Loggraph is run before CCP4i has been started for the first time.
In these cases a stream of warning messages are generated:
11:51:09 Running auto-configure for configure Creating new configure parameters file C:/ccp4- 6.0/ccp4i/etc/windows/configure.def 11:51:09 ERROR no type for FONT_SET in configure 11:51:09 Parameter FONT_SET not of defined type 11:51:09 ERROR no type for FONT_REGULAR in configure 11:51:09 Parameter FONT_REGULAR not of defined type ...
While annoying, you should be able to ignore these messages - the functionality of the utilities and of CCP4i should not be affected, and the warnings should not reoccur on subsequent runs.
(26/4/2006)
This error usually occurs when a user attempts to run a ccp4i job on Windows where there are spaces in the path names of the input files. For example, if a user has their PROJECT directory under the "My Documents" directory they will encounter this problem.
To avoid this problem, the PROJECT directory should be created somewhere without any spaces in its full path name. A user should also ensure that they do not introduce any additional spaces in the names of any files or subdirectories contained within the PROJECT directory.
(13/1/2006)
When trying to install a new task using the System Admin->Install Task function, the installer may fail claiming that the archive file is not a valid CCP4i archive, and is unable to unzip and untar it (even if these operations are possible from the command line, and the contents are fine).
This problem seems to be associated with the setting of the CCP4i TEMPORARY directory (see the Directories&ProjectDir window). Check that TEMPORARY is set to a valid directory, and that it is an absolute rather than a relative path.
(16/8/2004)
CCP4i is no fully longer compatible with Tcl/Tk 8.0, and you may see errors such as:
Error:bad index 'end-2' must be integer or 'end'
It is recommended that you upgrade the version of Tcl/Tk used by CCP4i to 8.3 or better.
(25/3/2004)
This is usually because you didn't create a project directory when you first started the interface, so CCP4i has nowhere to write the parameter files to.
The solution is to start up the main interface, and set up a project using the Project and Directories window (available from the right-hand side of the main CCP4i window), before trying to run the jobs again.
23/3/2004: As of CCP4 v5.0 the interface should explicitly warn you if the project database directory doesn't exist, and what action to take in this instance. (PJX)
This can happen if the temporary ``scratch'' directory is unset, full, or doesn't exist.
Check that you have sourced $CCP4/include/ccp4.setup before running the interface (you probably need to source this file to be able to run the interface at all unless your local setup is a bit unconventional). Then before starting ccp4i, try entering on the command line:
> echo $CCP4_SCR
which should return the path name of the temporary directory. Check that it exists and it is not full.
If this is not the problem then try:
> which mtzdump
You should get the path name for the mtzdump executable - if this command returns Command not found then this suggests there is a more fundamental problem with your setup (for example, mtzdump isn't installed).
There are several known problems which cause this to happen:
On Windows systems, this may be a symptom of having spaces in directory or file names. Having spaces causes a variety of problems, and is best avoided.
In older versions of the gui (pre CCP4 4.1) the communication between the two processes used the Tcl/Tk command send which didn't not work in Tcl/Tk built with the default options. As of CCP4 4.1 send is no longer used so this problem shouldn't arise.
Check your version of CCP4 and upgrade, if necessary.
When running jobs, CCP4i needs to be able to find the tclsh command in the directory pointed to by the CCP4I_TCLTK environment variable. For Unix/Linux systems this is set when you source the ccp4.setup file. If tclsh is not present then jobs may start but never actually run.
Check that $CCP4I_TCLTK/tclsh exists, and edit your ccp4.setup file to point to the correct directory if it doesn't.
This problem will also be observed if localhost is not defined in the system /etc/hosts. In this case a number of other symptoms will also be observed, for example 1) a warning message about running scripts being unable to connect to the server port; 2) neither the Run and view com file nor the Kill job options work.
The fix is to make sure that localhost is defined in the /etc/hosts file.
(Thanks Paulo Godoi)
#CCP4I TERMINATION STATUS 0 ROTAPREP: Error in label assignments
#CCP4I TERMINATION TIME 22 Dec 1999 12:18:14
#CCP4I MESSAGE Task failed
In this case the program has stopped cleanly with a helpful error message - try checking the log file output for the last run program for some more information on the problem.
or
Program crashes...
The log file ends with something like:
#CCP4I TERMINATION STATUS 0 child killed: segmentation violation
#CCP4I TERMINATION TIME 06 Mar 2000 22:49:07
#CCP4I MESSAGE Task failed
In this case the program has crashed - check if the log file is giving you any warnings about problems and, if you can work out what the program was doing when it crashed, then it might indicate which aspects of your program input should be checked.
Bug in CCP4i script...
Alternatively there may be a bug in the CCP4i script which runs the
task then at the end of the log file:
#CCP4I TERMINATION STATUS 0 CCP4I script error
#CCP4I TERMINATION TIME 20 Jan 2000 11:56:57
#CCP4I MESSAGE Task failed
and there should be an error message, coloured red, in the log file something like:
***************************************************************************
* CCP4Interface output from script
***************************************************************************
ERROR in CCP4Interface script
can't read "DICTPROTN": no such variable
***************************************************************************
Failed jobs may persist as phantoms in the job database (centre of the main CCP4i window) with their status as STARTING or RUNNING, but the "Kill job" function is unable to kill or remove them. They may also prevent you running a new job.
In this case, highlight the phantom job and click on "Delete/Archive Files..", then select "Delete output files and remove from database". This should clean up the dead job, and allow you to run a new task.
CCP4i needs the tclsh program to run the task when you hit the "run" button, but the exact name is important. On a Unix system check the available versions of tclsh by doing
> ls $CCP4I_TCLTK/tclsh*
If there is no exact match to tclsh (for example you may only find tclsh8.0) then there are two options:
> ln -s tclsh8.0 tclsh
or
exec $CCP4I_TCLTK/tclsh "$0" -- ${1+"$@"}
to become
exec $CCP4I_TCLTK/tclsh8.0 "$0" -- ${1+"$@"}
There are a number of possible causes for this problem:
The jobs are run locally, but the executables, libraries etc, are stored on a different computer and the main graphical CCP4i process is closed by the user while the run script (which executes a job) is still running.
It is okay to do this for most tasks. The error message is raised when the running script attempts to open a socket to the main graphical CCP4i process (to send the message that the job has finished, or to report a new output file to be registered), and the 'server' process (i.e. the main graphical CCP4i process) is no longer there.
The jobs should still run okay however, and when you restart the main CCP4i it will automatically check the log file for any job that it believes are still running and figure out that they have finished. So the status of the jobs in the database window should look OK.
For CCP4i in CCP4 4.2.1 or earlier: if the running task tries to register additional output files, then these files will not be registered if the main process is shut down, and no record of them will appear in the list under ``View Files From Job'' (note that the files still exist!). (This is particularly a problem for tasks which rely heavily on this mechanism, notably ARP/wARP.) Post CCP4 4.2.1 this problem should not be observed.
The message will also be observed if localhost is not defined in the system /etc/hosts. In this case a number of other symptoms will also be observed, for example 1) jobs run but the job status never updates from STARTING; 2) neither the Run and view com file nor the Kill job options work.
The fix is to make sure that localhost is defined in the /etc/hosts file.
(Thanks Paulo Godoi)
This has been reported after upgrading from CCP4 4.0 to 4.1. The interface for a task can be opened and the parameters modified as normal, but when the user tries to run the task a message like:
CCP4I ERROR:DEF file does not exist CCP4_DATABASE/250_scalepack2mtz.defappears in the terminal window. The job status appears as STARTING in the main window but the job doesn't run.
This problem appears to have been the result of originally setting up the project in 4.0 without creating a database for it when asked by the interface at the time. The problem can be fixed by deleting the user's .CCP4 directory plus the files .CCP4_directories, .CCP4_session_log and .CCP4_status.
(Thanks to Olof Svensson)
Upgrade to Tcl/Tk version 8.3 or better - version 8.2 had many bugs, and can no longer be obtained from the official Tcl/Tk websites.
Information on obtaining the latest versions of Tcl/Tk/BLT can be found here.
You will see the following output in the log file when Arp_waters is cycled with Refmac:
***** ERROR ***** Data Card RESO is required in this mode
This should only happen for the very first run of Arp, and contrary to appearances is not an error in the script. CCP4i is simply running Arp to obtain the Arp asymmetric unit (asu) limits - this is necessary because in some spacegroups Arp uses different limits to those assumed in CCP4.
You should see this message in the logfile directly after the error message above:
*************************************************************************** * Information from CCP4Interface script *************************************************************************** ARP/wARP assymmetric unit 0.0 1.0 0.0 1.0 0.0 0.1667 FFT and mapmask will be used to generate maps for this region ***************************************************************************
This indicates that in fact the script is running normally and that you should ignore the message from Arp. (Errors in subsequent Arp output should be treated seriously however.)
When using the "Run remote" option to run a task on a remote machine, it possible that the scripts generated by CCP4i are different to those generated when running the same job on the local machine (e.g. through the "Run now" option).
This is most likely because the remote machine has a different version of CCP4i installed (or because patches or changes have been applied to either the local or remote installations which mean that the two versions are no longer in synch).
(Thanks to Phil Evans and Airlie McCoy)
There are two things to check:
There is a back-up of the database file held as <projectdir>/CCP4_DATABASE/tmp_database.def So the first thing to do, is check whether this file exists and is OK. Do this before doing anything via the GUI.
Otherwise, there is a script which can be used to reconstruct the database from the existing files (beware: not exhaustively tested). It cannot recover "manual" edits (performed through "Edit Job Data") to the database contents unfortunately. There are instructions for using this in the comments at the head of the file:
# Usage: recover_db.tcl <project_alias> # # Run from within the affected project directory - it will # create a new file "recovery.def", which should be used to # replace the corrupted CCP4_DATABASE/database.def file. # Restart CCP4i and change to the project that you have just # tried to recover.You will need to edit the first line of the script to use whichever is the appropriate version of the tclsh interpreter on your system, for example the version pointed to by the $CCP4I_TCLTK variable.
If neither of these options works, you will have to recreate the database.def manually. Use $CCP4/ccp4i/etc/database.def as a template.