Until current release, molecular output files in the .oeb format had
MMFF aromaticity. In practice, such a situation lead to the visual
change between the input and output aromaticity of some molecules.
Starting from now OpenEye aromaticity model is used in the .oeb
A bug which occasionally caused errors in fixing a subset of atoms, was
When using PVM, Szybki now runs a mechanism for checking versions
used by master and slaves. This mechanism prevents the situation of
different versions of Szybki running on the master and slaves.
Molecules containing atoms for which MMFF types are not properly
typed are not processed. In previous versions attempts were made to
assign for such atom the closest MMFF type, however this procedure
almost always lead to errors. This situation occurred for example in
the case of bad pdb files. For proteins, better diagnostics
(residue name and number, atom name) are included as output.
Reading protein data in .oeb binary format containing additional
untagged information (FRED receptor files) is allowed. Until now
using such a file in pvm mode caused a fatal error.
The combination of options -complexif1 and -ligandsif2 run
in the pvm mode caused incorrect behavior in the case when the
preexisting ligand in the macromolecule (in the file if1)
overlapped with one or more ligands from the input file if2.
Run time license for the shape toolkit is added. It is required when the
combination of options -complexif1 and -ligandsif2 is used.
Redundant warnings generated upon -protein_elecnone and
-strip_water were removed.
Spelling in the log file was fixed.
Year 2008 was added to the Szybki banner.
In the documentation description for the -fix_smarts option an
example was added which illustrates the adjustment of hydrogen atom
Examples of log files generated upon ligand optimization in the
partially flexible protein followed by a single point PB
calculations are given.
Optimization using conjugate gradient method was added as an
alternative to the default quasi-Newton method with the BFGS
Hessian update scheme. In Szybki toolkit this is done by the usage
of a new function voidSetOptimizerType(unsignedinttype). In
Szybki application a flag -conj has been added for that
Default value of the protein dielectric constant is 1. Previous
default value for that parameter was 2, however it was not
consistent with the default value of MMFF94 force field.
Protein-electrostatic models in Szybki application are selected with
descriptive strings. Available options are:
None - no electrostatic potential used (default option)
A bug causing crash in the case of combined usage of partial protein
flexibility and protein electrostatic model
OEProteinElectrostatics::SolventPBForces was fixed.
A bug causing different behavior and/or occasional crash depending
of the order of calls: SetProtein(const OEChem::OEMolBase&),
SetRunType(unsigned int) and SetResidueFlexibility(double) has been
Modification of the potential function after the usage of coordinate
adaptors could occasionally result in crash, for example when
function FixAtoms() was followed by SetRemoveCoulombTerms(). This
bug was fixed.
Running in the pvm mode requires now setting the PVM_PATH variable,
which points at the directory where the Szybki script is
located. For example if Szybki was untarred in the directory
mydir, then using bash shell one can set the above variable
with: export PVM_PATH=mydir/openeye/bin
In the case when protein electrostatic model was set at
OEProteinElectrostatics::NoElectrostatics and partial protein
flexibility was allowed with the voidSetSideChainsFlexibility(double) or voidSetPolarHFlexibility(double) functions, Coulombic terms describing
the interaction between the ligand and flexible protein atoms were
included during optimization. This was inconsistent with the
meaning of NoElectrostatics, therefore those Coulombic terms were
eliminated in the current release
Using the function voidSetSideChainsFlexibility(double) resulted
occasionally in double counting of some residues. This bug was fixed.
Fixing atoms with a function boolFixAtoms(std::string) where the
passed string is SMARTS pattern, was based on MMFF aromaticity
types. Starting from the current release OE aromaticity model is