 |
Collaborative Computational Project No. 4 |
 |
|---|
|
|
Collaborative Computational Project No. 4 |
|
|---|
| Home | About CCP4 | CCP4 Projects | Downloads | Documentation | Courses | Developers | CCP4 people | WG1/WG2 | Privacy |
|---|
These are version/OS unspecific problems which you may encounter.
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)
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.
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>/libjavaplugin_oji.so libjavaplugin_oji.soand re-load the file. More hints are available at http://plugindoc.mozdev.org
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)
There are several known name conflicts with non-CCP4 programs:
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.
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)
This is two separate problems with similar suspected causes:
Several reports have been received of the failure of fontpack to generate font84.data 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 ./fontpack cp font84.dat $CCP4/lib/font84.dat
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 'libccif.so under any of the filenames ...The simplest solution is to rerun make. If this fails then try:
cd $CCP4/lib/ccif cp libccif.so $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).
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 libccp4.someans that the program you're trying to run cannot find the shared library file libccp4.so 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
setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:$CLIB
else
setenv LD_LIBRARY_PATH $CLIB
endif
(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
> echo $LD_LIBRARY_PATH(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 libccp4.so has actually been installed in $CLIB directory.
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 necessaryin 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 ccp4@ccp4.ac.uk.
(Thanks Phil Evans and Clemens Vonrhein)
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 527,528c527,528 < C ILAENV = 0 < ILAENV = 1 --- > ILAENV = 0 > C ILAENV = 1 538,539c538,539 < C ILAENV = 0 < ILAENV = 1 --- > ILAENV = 0 > C ILAENV = 1and 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.
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
PARAMETER (IXWDTH=8000)
PARAMETER (IYLENGTH=8000)
(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.
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
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:
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 \
/usr/share/catman:/usr/share/man:/usr/catman:/usr/man:$CCP4/man:/usr/man
else
# 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.
endif
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.
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:
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:These are specific problems with the CCP4 suite when installed on Digital/Compaq systems running OSF1/Tru64 Unix.
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:
limit
and check that the datasize is at least as large as your installed RAM, and stacksize is 32768 bytes. If not, type
unlimit
limit
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.
reboot.
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.
export X=somethingwill cause the shell to complains the syntax is incorrect.
The way to solve this problem is to change the
#!/bin/shat the top of the file into
#!/usr/bin/posix/shwhich would not complain about this syntax.
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.
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)
