 |
Collaborative Computational Project No. 4 |
 |
|---|
|
|
Collaborative Computational Project No. 4 |
|
|---|
| Home | About CCP4 | CCP4 Projects | Downloads | Documentation | Courses | Developers | CCP4 people | WG1/WG2 | Privacy |
|---|
Note that there are several independent documents linked here covering different platforms, different versions of CCP4 and different components of CCP4. If you can't find your problem here, please email us.
A list of more general version-unspecific problems can be found on the General Problems Page as well as descriptions of various operating system-specific eccentricities.
There are also a number of platform-specific pages:
Warning for Linux users: if you are running CCP4 compiled with gcc 2.96 may be unreliable.. This has been seen with RedHat 7.0 and Mandrake 8.1.
A list of general and version-independent problems with CCP4i can be found here:
The program extends is not found when installing the suite (either building from source or using precompiled binaries). This is because the Makefile in $CCP4/unsupported/src was not updated to install the program after it was built.
If building from source then the easiest solution is to go to the $CCP4/unsupported/src/ directory, issue the command
> make extendsand then manually copy extends to the $CBIN directory. Otherwise the $CCP4/unsupported/src/Makefile.in can be fixed with the following patch:
There are currently no plans to update the precompiled binaries; please contact CCP4 if you need a precompiled version of extends.
For situations were the rotation axis lies parallel to the z-axis, LSQKAB may generate incorrect values for the direction cosines. However the Euler angles and spherical polars should still be correct.
The problem can be fixed with the following patch:
(Thanks Phil Evans for identifying the problem)
The DMMULTI program uses multiple spacegroups, which can conflict with the libraries in CCP4 version 5.0 and above. As a result, unless all crystals have the same Laue group, the behaviour of the program is unpredictable.
The fix is a workaround which incorporates a pre-5.0 subroutine into the DMMULTI code. Patches are required to the files $CPROG/dmmulti_/dmmulti.f and $CPROG/dmmulti_/dmmulti_dmlib.f:
(Thanks to Kevin Cowtan)
abs may enter a very long (runtime may be several hours) loop complaining about
IS_MAGIC: Obsolete internal routine: you should not be calling this!This is a symptom of the wrong MNF/illegal value test routine being called. The results are therefore suspect.
The problem can be fixed with the following replacement:
contact and other programs which use the FROM RESIDUE .. CHAIN.. selection lines will fail if the Chain ID is E as this is misinterpreted as an exponential number
WARNING: Chain name should be a single character
The problem can be fixed with the following patch:
or by renaming the Chain ID to a value other than E.
maprot crashes on Linux systems, but is OK on IRIX at least. This might occur for example when running Map Cutting interface in ccp4i
A fixed maprot.f is available here:
Map Cutting task in ccp4i fails in mapmask with:
Spacegroup information obtained from library file: Logical Name: SYMINFO Filename: /user/xtal/ccp4/lib/data/syminfo.lib >>>>>> CCP4 library signal library_file:Cannot open file (Error) raised in ccp4_file_open <<<<<< >>>>>> CCP4 library signal ccp4_map:Cannot open file (Error) raised in ccp4_cmap_open <<<<<< >>>>>> CCP4 library signal ccp4_map:Cannot open file (Error) raised in MRDHDS <<<<<< mapmask: Error in opening input map file.
A fixed mapmask.f is available here:
On some platforms at least, TOPP fails with
*************************************************************************** The program run with command: topp has failed with error message open: Temporary file name (TMPDIR?) too long apparent state: unit 12 (unnamed) lately writing sequential formatted external IO ***************************************************************************
The problem is reportedly solved if you set TMPDIR to something beforehand.
For a more robust solution, a fixed autosnd.f is available here:
Refmac may fail with an error message of the form:
Open failed: Unit: 7, File: /scratch/rb84480/refmac5_temp1.36145_new.crd (logical: /scratch/rb84480/refmac5_temp1.36145_new.crd) Last system error message: No such file or directory Refmac_5.2.0005: Open failed: File: /scratch/rb84480/refmac5_temp1.36145_new.crdThis can happen when the input PDB file doesn't contain cell or spacegroup information - this information is now compulsory and should be supplied on the CRYST1 line in the PDB file.
To confirm whether this is the case check the Refmac output for a line of the form:
===> Warning: Input coordinate file does not have CRYST cardIf so then the workaround is to make sure that you add the cell and spacegroup information into the file. In future versions of Refmac the absence of this information will be a fatal error.
DM can use program column labels FDM and PHIDM for both LABIN and LABOUT, where they refer to different actual columns. This confuses the 5.0.2 library, and the effect is to re-label the input column while leaving the contents unchanged. This occurs for instance in the auto-SHARP package.
There is a fix to the library source file $CLIBS/cmtzlib_f.c :
This includes the 2 other fixes to cmtzlib_f.c referred to on this page.(Thanks to Clemens Vonrhein)
The CELL keyword used to update the MTZ file cell parameters. However, now that the file cell parameters have been made obsolete by the dataset cell parameters, this keyword has no effect. MTZUTILS has been updated so that the CELL keyword changes all the dataset cell parameters in the output MTZ file. This is clearly quite drastic, and is intended only for simple files with no or minimal dataset information. For more sophisticated editing, please use CAD or the CCP4i interface "Edit MTZ Datasets".
There is a fix to the program source file $CPROG/mtzutils.f, available as a patch file or as full source :
The SET CELL keyword used to update the MTZ file cell parameters. However, now that the file cell parameters have been made obsolete by the dataset cell parameters, this keyword has no effect. SFTOOLS has been updated to have LIST/SET DCELL keywords to list or update the dataset cell parameters. For more sophisticated editing, please use CAD or the CCP4i interface "Edit MTZ Datasets".
There is a fix to the program source file $CPROG/sftools_/sftools.f, available as a patch file or as full source (this contains other changes):
When running Refmac5 in rigid body refinement mode, the interface may produce the message:
One or more rigid domains is not properly defined. Check the rigid domain definitions before rerunning this job.and then refuse to run. While it is possible that one or domains may not be properly defined (most likely because a range of residues contains a blank), there is a bug which means that this message always occurs if the rigid domain definition contains more than one range of residues.
The fix is to apply the following patch to the file $CCP4/ccp4i/tasks/refmac5.tcl:
Selection of cycle with arp_waters will cause the refmac5 task to fail when information such as spacegroup or crystal name is missing from the mtzfile. An example message:
#CCP4I TERMINATION STATUS 0 Error from script /usr/local/ccp4/share/ccp4i/scripts/refmac5.script: can't read "MTZ_file_data(XNAMES)": no such element in array #CCP4I TERMINATION TIME 23 Aug 2004 15:29:07 #CCP4I MESSAGE Task failedThis error results from the use of mtzdump to fill in information for the job.
The fix is to apply the following patch to the file $CCP4/ccp4i/src/CCP4_utils.tcl:
The Edit Restraints task produces LINK records which are 81 characters long. When read back into Edit Restraints task, the last character is truncated. Also, refmac5 can't read these.
The fix is to update the file $CCP4/ccp4i/utils/pdb_utils.tcl from:
This contains a 1-line fix to a format statement.Using the "Edit/Rotate Map & Mask" item under "Map & Mask Utilities" in ccp4i. When choosing "Extend a map/mask file", then under the Extend File section choosing "cover all atoms in molecule". This generates the following script:
mapmask MAPIN MIRdata_mlphare1.map XYZIN toxd_prot.pdb MAPOUT extended.map SYMMETRY 19 XYZLIM BORDER 5
This fails with the message:
Data line--- XYZLIM mapmask: You have no parameters for the XYZLIM keyword
The fix is to update the file $CCP4/ccp4i/templates/mapmask.com:
*** mapmask.com 26 Jan 2004 11:27:54 -0000 1.3
--- mapmask.com 4 Oct 2004 16:41:28 -0000 1.4
***************
*** 12,18 ****
$IFXYZLIM xyzlim $XYZLIM_1 $XYZLIM_2 $XYZLIM_3 $XYZLIM_4 $XYZLIM_5 $XYZLIM_6
$IFASU XYZLIM ASU
! {[IfSet XYZLIM_MODE]} XYZLIM $XYZLIM_MODE
$IFBORDER BORDER $BORDER
{ ![StringSame $EXTEND_MODE DEFAULT] } EXTEND $EXTEND_MODE
--- 12,18 ----
$IFXYZLIM xyzlim $XYZLIM_1 $XYZLIM_2 $XYZLIM_3 $XYZLIM_4 $XYZLIM_5 $XYZLIM_6
$IFASU XYZLIM ASU
! {[IfSet $XYZLIM_MODE]} XYZLIM $XYZLIM_MODE
$IFBORDER BORDER $BORDER
{ ![StringSame $EXTEND_MODE DEFAULT] } EXTEND $EXTEND_MODE
This task, with output option TNT, fails in CAD.
A fix will be provided shortly, or contact DL team.
This task, with initial phases, fails after CAD with
can't read "TMPPDB": no such variable
while executing
"set CURRENT_PDB $TMPPDB"
The fix is to apply the following patch to the file $CCP4/ccp4i/scripts/ncsref.scripts:
In the "Convert Intensities to SFs" (Truncate) interface, if "intensities with anomalous data" is chosen as input then the interface presents fields to give Imean, I(+), I(-) and associated sigmas. However the keyworded script that is generated lacks the information for the anomalous pairs in the LABIN command.
There are updates to the interface files to address this problem. The fixes are available as patches to be applied to the appropriate files in $CCP4/ccp4i/tasks (truncate.tcl and truncate.def) and $CCP4/ccp4i/templates (truncate.com):
(Thanks to Randy Read for reporting this problem)
The parameters VDW radius, ionic radius and shrink area used for the solvent mask calculation are not passed from the GUI to the program script. The "use experimental sigmas" parameter is also not passed.
There is an update to the refmac5.com interface file to address this problem. The fix is available as a patch to be applied to the appropriate file in $CCP4/ccp4i/templates (refmac5.com):
(Thanks to Jose Caaveiro for reporting this problem)
There is an update to the local.tclfile to address this problem. The fix is available as a patch to be applied to the appropriate file in $CCP4/ccp4i/src (local.tcl):
There are two bugs in the subroutine LRSEEK, in the Fortran API to the CMTZ libraries (cmtzlib_f.c), which mean that the first reflection is always skipped and that the data array that is returned is misaligned with respect to the columns in the file.
Currently only the unsupported program postref uses LRSEEK so this is not expected to be a problem for most users of CCP4. A patch to cmtzlib_f.c is available here:
(Thanks to Clemens Vonrhein for identifying and fixing the problem)
If a PDB file contains just a single ATOM line, then this atom is not read. Different programs fail in different ways, depending on how they handle a file with apparently zero atoms.
A simple workaround is to add an END card at the end of the PDB file.
This bug is fixed in the latest version of MMDB, which can be picked up from http://www.ebi.ac.uk/~keb/cldoc/
After running SCALA (and possibly others) the sort order information in the MTZ file header is reset to 0 0 0 0 0 (even though the sort order may be unchanged).
This is due to a bug in the CMTZ libraries, which fails to transfer the sort information across from the input to the output file. A patch to cmtzlib_f.c is available here:
(Thanks to Ana Gonzales and Irimpan Mathews for reporting this problem)
The command line switch -c should be used for specifying the column label, rather than -s.
(Thanks to Pierre Rizkallah)
The control of printed output has been further refined. Print 2 will print out symmetry operations and score statistics for each section during a scan. Print 3 will, in addition, print out real to vector space transformations.
(Thanks to Pete Dunten)
Sun, Alpha and Intel compilers may complain about \' to write quote in line 179 of mtztona4.f. I believe '''' is the correct Fortranic way of doing it (this is used extensively in refmac). \' is probably a widely-accepted extension.
Change both instances of '\'' to '''' (4 quotes) in line 179 of mtztona4.f
Or get an updated ftp://ftp.ccp4.ac.uk/ccp4/5.0.1/patches/mtztona4.f-09July2004
xplot84driver does not recognise plt files.
Change the paswrd[9] term in plot84_file.h line 31 to paswrd[8].
Or get an updated ftp://ftp.ccp4.ac.uk/ccp4/5.0.1/patches/plot84_file.h-09July2004
(Thanks to Bill Scott)
fft incorrectly calculates Patterson maps when it uses Spacegroup 10 P2/m. This is corrected by the following patch, or use of fftbig
*** /y/people/ccp4/cadd/junk/fft.f 2004-07-19 12:08:05.000000000 +0100
--- /y/programs/xtal/ccp4-5.0.1/src/fft.f 2004-07-07 10:48:07.000000000 +0100
***************
*** 9753,9761 ****
C -- Not a patterson
IF (ISQ.GT.0) THEN
C These pattersons can be set. No others..
! C IF(NLAFFT.EQ.4) NSPFFT = 10
! C fft10 has a bug - disable it altogether..
! IF(NLAFFT.EQ.4) NSPFFT = 2
IF(NLAFFT.EQ.6) NSPFFT = 47
C -- Set to P1 (from P1bar) because permution of axes permitted
IF(NLAFFT.EQ.3) NSPFFT = 1
--- 9753,9759 ----
C -- Not a patterson
IF (ISQ.GT.0) THEN
C These pattersons can be set. No others..
! IF(NLAFFT.EQ.4) NSPFFT = 10
IF(NLAFFT.EQ.6) NSPFFT = 47
C -- Set to P1 (from P1bar) because permution of axes permitted
IF(NLAFFT.EQ.3) NSPFFT = 1
Or get an updated ftp://ftp.ccp4.ac.uk/ccp4/5.0.1/patches/fft.f-19July2004
(Thanks to Eleanor Dodson)
xdlmapman core dumps on writing CCP4-format map. It will read in a map OK, and start writing the CCP4 map, but then core dump.
This is a bug in the CCP4 library (it assumes an input CCP4 map file is present). There is a fixed cmaplib_f.c file. This needs to be copied to $CCP4/lib/src and the library re-compiled and reinstalled.
If you don't want to re-build the CCP4 library, it is sufficient to comment out line 2854 of $CCP4/x-windows/xdlgjk/xdlmapman_subs.f
call mttcpy (myline)
and recompile and reinstall xdlmapman. This writes a title line to the map
header, so you don't lose anything!
There is a problem with sfall that the identification of systematic absences and centric reflections is that appropriate to the FFT spacegroup rather than the true spacegroup. So in I4 for instance, the FFT spacegroup is P1, and all reflections are output including the systematic absences.
This is most noticeable for MODE XYZIN when sfall constructs the reflection list and checks for sys. abs. For MODE XYZIN HKLIN, the reflection list is taken from the hopefully correct HKLIN. However, the check for restricted values of centric phases is still wrong. I.e. you get phases of 179.56 when properly sfall shifts this to 180
There is a fix, but involves changes to the library. This will be included in CCP4 5.0.2 Meanwhile, a workaround is to pass the output from sfall through CAD to weed out the systematic absences (as well as putting reflections into proper a.s.u.) However, this doesn't fix the centric phases.
(Thanks to Filipe Maia for reporting this.)
When running the program to 'Extract additional information for deposition' and in the mode to 'Generate a complete mmCIF file for deposition', if all steps are not filled in then the program will attempt to generate information in the output mmCIF file which cannot be extracted. For example, if only structure refinement files are used for input, the program will attempt to generate a complete mmCIF file for all steps in structure solution.
The fix is to update $CCP4I_TOP/scripts/dhm_tool.script and then restart the CCP4I interface. Also, the mode to 'Generate a complete mmCIF file for deposition' should really only be used if log and harvest files from more than one step are available. There are modes present in the interface which can extract information from individual steps, eg: Data Scaling, Molecular Replacement, Structure Refinement. The updated file is available here:
(Thanks to Peter Briggs and Huanwang Yang)
When running FFFEAR using the ccp4i selecting a theoretical 5 turn helix actually selects a 5 residue strand, and selecting a theoretical 10 residue strand results in a 10 turn helix being selected.
There is a misordering in a menu in the file fffear.tcl:
143,144c143,144 < theor-helix-5 \ < theor-strand-10 \ --- > theor-strand-5 \ > theor-helix-10 \
Or get an updated ftp://ftp.ccp4.ac.uk/ccp4/5.0.1/patches/fffear.tcl-09July2004
Two problems have been reported:
These problems are addressed by the updated interface files $CCP4/ccp4i/tasks/mosflm.def and $CCP4/ccp4i/tasks/mosflm.tcl which are available from the CCP4 ftp server:
(Thanks to Jianghai Zhu)
There is a memory leak in the MTZ library associated with reading reflections, introduced between 5.0 and 5.0.1 This is particularly noticeable with Scala which reads large unmerged MTZ files, and reads them once for each scaling cycle. In extreme cases, the program will die with the error "Cannot allocate memory".
The core library needs to be patched. Get the updated file ftp://ftp.ccp4.ac.uk/ccp4/5.0.1/patches/cmtzlib.c-27July2004 Replace the file $CCP4/lib/src/cmtzlib.c with it. Recompile the library. If you compiled statically, you will need to recompile the affected programs as well, e.g. Scala.
A variety of problems on a number of platforms have been reported when using the --non_shared option of configure. These range from problems with completing the "configure" step, through to building and running Mosflm during "make".
The problems appear to be due to the fact that a number of systems supply one or more of the system libraries as shared only, which is incompatible with the --non_shared option of configure.
As a result of these problems, use of the --non_shared option is deprecated, and the recommended remedy is to avoid its use. This problem will not be fixed, and it is anticipated that the option will be withdrawn in a future release.
There are a number of problems affecting Refmac5.2.0003 in CCP4 5.0:
clykin: neither label recognised: PHCOMB PHCOMB Refmac_5.2.0003: Error in label assignments in LABOUT
The fix is to update the file $CPROG/refmac5_/rcard_tor1.f and then rebuild Refmac. The updated file is available here:
(Thanks to Garib Murshudov)
A Refmac script which runs to completion with NCYCLES > 0 crashes when NCYCLES is set to zero.
The fix is to update the file $CPROG/refmac5_/hkon_secder_tch.f and then rebuild Refmac. The updated file is available here:
This fix is also available as a patch:(Thanks to Garib Murshudov)
When running the CETC/uniqueify script, the process may fail with the message
Failed to find spacegroup in SYMINFO! ASUSET: no spacegroup info! UNIQUE: Fatal error in ASUSET.This will happen if the file contains a spacegroup name which has spaces, for example 'P 21 21 21'. (You can check the spacegroup name by using mtzdmp to look at the MTZ header information, or by viewing the file in CCP4i.)
NB The use of spacegroup names with spaces in v5.0 brings CCP4 into line with other projects in the crystallographic community (e.g. the PDB).
The fix is to use the updated version of uniqueify. The updated file is available here:
(Thanks to Jeff Lerman, for reporting this problem.)
When running a program under windows, or a task using the CCP4 interface, the job may fail with the message "No translation for logical name "MMCIFDIC"". This is because during installation of the windows version of CCP4, the 'MMCIFDIC' environment variable has not been set. This needs to be set to the cif_mmdic.lib file which, under Windows, is located in the ccp4bin directory.
The fix is to set this environment variable manually. The way to set environment variables under Windows OS is as follows:
Click 'Start' in the bottom left-hand corner of the screen. Select 'Settings' then 'Control Panel' and open up the 'System' icon.
Click the 'Advanced' tab and then open up 'Environment Variables'. There are 2
sets of variables - User variables and System Variables. Under System
Variables, click 'New'. Enter 'MMCIFDIC' (in capital letters) for the 'Variable
Name' and enter the full path of the cif_mmdic.lib file for the 'Variable
Value'. Click 'OK' to finalise, then 'OK' again to set and leave the
environment variables menu.
When running a refinement job using phase and FOM, Refmac5.2.0003 fails with a message like:
clykin: neither label recognised: PHCOMB PHCOMB Refmac_5.2.0003: Error in label assignments in LABOUT
This is related to a reported problem for Refmac5.2.0003, see above for how to fix this.
(Thanks to Phil Evans)
When choosing "cycle with ARP_waters" in Refmac5 task, the task will fail if the spacegroup name has spaces in it (which it will if it is a recent MTZ file). The program arp_waters cannot handle names with spaces.
The ccp4i script has been changed to use the spacegroup number instead of the name. This is less general than using the name, but will work assuming you have conventional indexing.
The updated file is available here:
In the Modify / Merge MTZ Files task, select "Change spacegroup and/or reindex reflections". Changes to the menu "Apply reindex matrix" are not passed to the run command file. If an old job is re-run, then it works fine. There is a fix to the distributed sortmtz.def file.
The updated file is available here:
When choosing "cycle with ARP_waters" in Refmac5 task, the task will fail if the dataset corresponding to the selected MTZ columns has a different set of cell parameters to those stored "globally" in the MTZ file. (This is possible now that MTZ columns can belong to different crystals, which may be assigned different cell parameters according to the cells of the physical crystals from which diffraction data was collected).
In this case the script will fail with an error message from ARP_waters:
... ----- Difference in cell parameters detected ----- Cell from input card: 64.897 78.323 38.792 90.000 90.000 90.000 ----- Cell from PDB header: 64.850 78.560 39.510 90.000 90.000 90.000
The $CCP4/ccp4i/scripts/refmac5.script file has been updated to find and use the correct cell parameters from the MTZ file when running ARP_waters. This requires an updated version of $CCP4/ccp4i/src/CCP4_utils.tcl to work correctly.
The updated files are available here:
Note that refmac5.script-26May2004 also contains the previous fix for Refmac5 task fails when cycling with ARP_waters: spacegroup name contains spaces.
When running Refmac5 through the interface with high resolution data (at or above 0.7A) and cycling with Arp_waters, the procedure fails with a message from the Arp_waters step along the lines of:
Data line--- resolution 40.825 0.540 This Data Card in not understood RESOLUTION 40.825 0.540 Cannot accept field shown by arrows: RESOLUTION 40.825 ==>0.540<==
There is no fix for this problem. The workaround is to explicitly set the high resolution cut-off to be lower than 0.7A in the Refinement Parameters folder of the interface. (Later versions of the interface will trap for this and will not allow the task to run unless an appropriate high resolution cut-off is selected first.)
When running Refmac5 through the interface cycling with Arp_waters and writing hydrogens to the coordinate file (keyword MAKE HOUT), the procedure fails with a message from the Arp_waters step along the lines of:
> Illegal atom name: 1HG2ATHR A > ^^
This is a known bug for which there will be no fix. The workaround is to switch off the option to output hydrogens to the coordinate file in the Refinement Parameters folder of the interface, when cycling with Arp_waters. (Later versions of the interface will trap for this and will not allow the task to run.)
When inputting complicated NCS restraints, eg
Data line--- nonx nchains 6 chnid A B D E G H nspa 1 1 159 1 Data line--- nonx nchains 2 chnid A C nspa 2 1 49 1 51 159 1 Data line--- nonx nchains 2 chnid A F nspa 2 1 49 1 51 159 1 Data line--- nonx nchains 2 chnid A I nspa 6 1 4 1 13 47 1 55 77 1 86 125 1 127 154 1 157 159 1 Data line--- nonx nchains 2 chnid A J nspa 2 13 78 1 89 159 1the following is displayed in a pop-up window:
Error: can't read "array (NONX_SPANS_RES1_2_1)": no such variableThe fix is to apply the following correction to $CCP4/ccp4i/tasks/refmac5.tcl
diff -r1.32 refmac5.tcl
99c99
< if { $array([subst $var]_[subst $i]_$j) == "" } {
---
> if { $array([subst $var],[subst $i]_$j) == "" } {
105c105
< for { set j 1 } { $j <= $array(N_NONX_SPANS,$i) } { incr j } {
---
> for { set j 1 } { $j <= $array(N_NONX_CHN,$i) } { incr j } {
108c108
< if { $array([subst $var]_[subst $i]_$j) == "" } {
---
> if { $array([subst $var],[subst $i]_$j) == "" } {
The updated file is available here:
For some spacegroups (e.g. I 41) some programs (e.g. AMoRe) may fail when using the subroutine PGDEFN to fetch the point group, producing the message:
Failed to find spacegroup in SYMINFO! AMORE: Fatal error in PGDEFN Times: User: 1.8s System: 1.7s Elapsed: 0:03(or similar).
This occurs when the calling program only supplies a subset of the symmetry operations defining the full spacegroup.
A fix is available to the Fortran interface to the C level symmetry library (file $CLIBS/csymlib_f.c). The updated file is available here:
NB this replaces the 21/06/2004 version, which still had a bug in it -pjb.
