We've had reports of long execution times for previous releases of BUSTER (or Pipedream) on CentOS8 due to our distributed Gnuplot binary taking a very long time. We can partly reproduce this (although not quite to the same extent), but hope that the binary distributed with this release will on CentOS8 behave similar to other Linux distributions.
If you still experience problems, we would recommend the installation of an OS-specific version of Gnuplot on those systems.
As root, run
yum install gnuplot
and as software installer run
echo "setenv BDG_TOOL_GNUPLOT \"/usr/bin/gnuplot\"" >> $BDG_home/setup_local.csh echo "export BDG_TOOL_GNUPLOT=\"/usr/bin/gnuplot\"" >> $BDG_home/setup_local.sh
The setting of the environment variable BDG_TOOL_GNUPLOT will ensure the use of the newly installed OS-version of "gnuplot".
Remember that CentOS8 reached end-of-life on December 31, 2021, while CentOS7 is still supported til June 30th, 2024!
We've had reports about problems running BUSTER through the Coot helper menu (when using e.g. "visualise-geometry-coot") on CentOS stream when using the CCP4 7.1 provided Coot binary. This is most likely due to the setting of LD_LIBRARY_PATH as part of the "coot" wrapper script - resulting in incompatible shared libraries from CCP4 being loaded by normal OS utilities. We are investigating possible workarounds (Thanks to Kevin Battaile for reporting).
The required removal of incorrectly added hydrogens for non-standard amino-acids is not working as expected in aB_hydrogenate for multi-chain models. Those are added because the compound information from a restraint dictionary is usually for a non-bonded version and would therefore contain 3 hydrogens on the N-terminal amine group. A fix will be available in the next release - in the meantime, please remove those additional atoms (usually called "H2", "H3" or "HN2") manually. Thanks to Steven Sheriff for reporting and discussing that problem.
There is an issue running pipedream under CCP4 8.0: the location of the coot-mini-rsr command has changed (from $CCP4/bin/coot-mini-rsr to $CCP4/coot_py2/bin/coot-mini-rsr) and is therefore not found by the program. This will make the program fail even if neither SideAide nor PepFlip is being called.
One solution is to modify the Pipedream program itself by changing line 2449 in $BDG_home/lib/perl5/BDG/Pipedream.pm from
$minirsrexe = IPCcmdcanrun( ccp_version("coot-mini-rsr") );
to
$minirsrexe = IPCcmdcanrun( ccp_version("../coot_py2/bin/coot-mini-rsr") );
Alternatively, you could create a simple wrapper script in $CCP4/bin/coot-mini-rsr containing the two lines
#!/bin/sh $CCP4/coot_py2/bin/coot-mini-rsr "$@"
(and running chmod +x $CCP4/bin/coot-mini-rsr on it). Please let us know if this works for you (or doesn't).
We are currently preparing a new release of our software that will contain a generic fix to this problem.
The CPC4 8.0 binary seemingly gets confused by certain (or all?) REMARK records in the input PDB file. The following patch should fix that:
--- Sideaide.pm 2022-04-04 11:17:54.771678208 +0100 +++ Sideaide.pm 2021-07-13 14:32:27.000000000 +0100 @@ -111,9 +111,7 @@ # now run dssp - system("grep -v REMARK $xyzin > $root/fordssp.pdb"); - - my $dsspcommand = "$::dsspexe $root/fordssp.pdb $root/$prefix.dssp"; + my $dsspcommand = "$::dsspexe $xyzin $root/$prefix.dssp"; my ( $success, $errormessage, $fullbuf, $stdoutbuf, $stderrbuf ) = IPCcmdrun( $dsspcommand, 0 ); @@ -383,7 +381,7 @@ unlink( "$root/mini-rsr.out", "$root/$prefix\_pepflip.msg", "$root/$prefix\_pepflip.xml", "$root/$prefix\_pepflip.pdb", "$root/$prefix\_fit.pdb", "$root/masked.map"); } - unlink( "$root/fordssp.pdb", "$root/$prefix.dssp", "$root/$prefix\_scbuild.msg", "$root/$prefix\_scbuild.xml"); + unlink( "$root/$prefix.dssp", "$root/$prefix\_scbuild.msg", "$root/$prefix\_scbuild.xml"); return ($xyzout, $hbflip, $ndrota, $ctflip, $tcflip, $pepfix, $pepdis, $pepflips, $waterrem);