Release Notes

Release Highlights 2020.0

OpenEye Toolkits and Applications have been integrated into a single release cycle. This will provide more consistency among our products and enable a more robust and efficient development cycle. This integration reduces release process management overehead, freeing developer time for new features and bug-fix releases for critical issues.

OMEGA: GPU-OMEGA - GPU-accelerated torsion driving

The 2020.0 release introduces GPU-OMEGA to the OMEGA application suite to provide accelerated torsion driving. It is integrated into the existing OMEGA application; no additional user actions are required to make use of this new feature. GPU-OMEGA detects any supported Nvidia GPU on Linux platforms and accelerates performance unless explicitly suppressed by using the option -useGPU false. GPU-OMEGA is available with all sampling modes except macrocycle, which does not use the torsion driving method for conformer generation. For more details on GPU-OMEGA, including prerequisites and additional requirements for using dense mode, please see GPU-OMEGA.

GPU-OMEGA performs at the same high level of accuracy as Omega TK, as shown below using a filtered subset of the Platinum dataset [Friedrich-2017] [Hawkins-2020]:

../../_images/CPU_v_GPU_scatter_rmsd.png

Comparison of the minimum RMSDs of CPU- and GPU-generated conformers against the experimental coordinates of a filtered subset of the Platinum dataset

GPU-OMEGA was benchmarked against the CPU on AWS to demonstrate the achievable performance on a P3 instance, which houses a single Nvidia Tesla V100 GPU. GPU-OMEGA was benchmarked with all supported sampling modes (classic, dense, pose, rocs, and fastrocs) using a subset of ~6000 molecules from the GSK TCAMs dataset [Gamo-2010]. The most impressive speed-up is seen with the dense sampling mode, with a reduction in time from 120 hours to less than 4 hours.

../../_images/GPU_Omega_Modes_V100_perf_apps.png

Elapsed time comparison between Omega and GPU-OMEGA on an AWS P3 instance when sampling a subset of the GSK-TCAMS dataset with classic, rocs, fastrocs, pose, and dense modes

SPRUCE: Protein Loop Modeling

The 2020.0 release adds protein loop modeling to the SPRUCE application. This approach relies on a template database derived from structures in the public RCSB Protein Data Bank. The database, which has been built for modeling loops that are 4-20 residues long by default, is available for download in a platform-independent format. A separate application, LoopDB_Builder, allows appending additional structures to the existing database. For example, proprietary in-house structures can be added, or the database can be completely rebuilt with different options.

This approach has been validated on a public dataset from Rossi et al. [Rossi-2007]. The results shown below were generated by building the excised loops back into the dataset, where the specific structures themselves were not part of the template database, and used the same success criterion as in the paper (<2.5A backbone RMSD). The results are generally good and the median RMSD is 0.6-0.7A (blue dots), irrespective of the length of the modeled loop. The mean RMSD (green dots) may be higher as unsuccessful cases (gray bar) can deviate significantly from the expected result. Only in a one case (out of ~200 loops), was a result not produced (red bar), i.e. did not survive the search and filtering steps.

../../_images/RossiLoops.png

Performance assessment building loops ranging from 4-12 residues in length

SZYBKI: Custom SMIRNOFF

The abilities of SZYBKI and FreeForm to use force fields based on SMIRNOFF (SMIRks Native Open Force Field) specifications has been extended to use custom versions of such force fields. The -ff parameter in both SZYBKI and FreeForm now accepts XML files with SMIRNOFF specifications in addition to the predefined names for built-in force fields.

The coverage of built-in force fields has also been extended by incorporating Parsley_OpenFF1.1.1 from the Open Force Field Initiative.

General Notices

  • All applications, including GUI applications, are now available in the RHEL8 application bundle except for GPU-OMEGA, the CUDA-enabled feature of OMEGA. GPU-OMEGA will be supported in the next release when the toolkits have been upgraded to support CUDA 10.
  • The application bundle for macOS is now notarized and can be run on macOS Catalina 10.15. Apple notarization gives users of our software more confidence that the Developer ID-signed software has been checked by Apple for malicious components.
  • This is the last release to support Ubuntu16.04. Support for Ubuntu20.04 will be added in the next release.
  • MacOS 10.12 is no longer supported.

Detailed Release Notes

AFITT 2.5.1

Spring 2020

  • This version of AFITT has been built using OEToolkits 2020.0.
  • The AFITT GUI is not available as part of the 2020.0 release.

BROOD 3.1.3

Spring 2020

  • This version of BROOD has been built using OEToolkits 2020.0.

Minor bug fixes

  • BROOD no longer fails when stereos are not specified for query fragments.
  • BROOD’s warning messages about invalid query fragments are now clearer.
  • Clicking Show on Disk in vBrood on macOS no longer uses Apple Script. This avoids OS-generated log messages in the terminal window.
  • vBrood no longer generates libpng warning messages upon startup.
  • Clicking Run after creating a query no longer uses the deprecated OEFileRandomName function. This avoids warning messages in the terminal window.

EON 2.3.3

Spring 2020

  • This version of EON has been built using OEToolkits 2020.0.

OEDocking 3.5.0

Spring 2020

  • This version of OEDocking has been built using OEToolkits 2020.0.

Minor bug fixes

  • The Windows version of Make Receptor now displays the user’s home directory when File Open is first clicked.
  • Make Receptor file filters have been simplified to only include Molecules, Receptors, and All Supported Formats. The Molecules filter now includes CIF and CIF.gz file extensions.
  • Users can now browse to find their license file.

Documentation changes

  • The utilities section has been updated with accurate information on supported applications and their usage.

OMEGA 4.0.0

Spring 2020

  • This version of OMEGA has been built using OEToolkits 2020.0.

New Features

  • GPU-OMEGA, a GPU-accelerated implementation of the torsion driving algorithm, is now available. GPU-OMEGA can make use of any suitable Nvidia GPU on supported Linux platforms by default for classic mode runs. Users are advised to read the GPU-OMEGA section of the documentation to ensure that their systems meet all the prerequisites and that the availability for the different sampling modes is understood. GPU-OMEGA will be disabled and fall back to the CPU on systems not meeting the requirements.
  • OMEGA in the macrocycle mode has been rewritten to take advantage of the newly extended corresponding functionality in the 2020.0 release of Omega TK. With this update, some of the previous application-specific functionality, including duplicate removal and overlaying of the generated conformers, are now directly taken care of by the underlying toolkit functionality. From a performance point of view, OMEGA macrocycle is now more efficient for finding new conformers during conformer generation.

PICTO 4.5.0

Spring 2020

  • This version of PICTO has been built using OEToolkits 2020.0.
  • This is the first release of PICTO as an independent application suite and as part of the OpenEye Applications bundle. Previously, PICTO was an integral part of VIDA.

pKa-Prospector 1.1.3

Spring 2020

  • This version of pKa-Prospector has been built using OEToolkits 2020.0.

QUACPAC 2.1.0

Spring 2020

  • This version of QUACPAC has been built using OEToolkits 2020.0.

ROCS 3.4.0

Spring 2020

  • This version of ROCS has been built using OEToolkits 2020.0.

Major bug fixes

  • Shape queries with the file extension SQ no longer give incorrect shape Tanimoto scores.

Minor bug fixes

  • ScaledColor and ComboScore are no longer available as options for the -rankby parameter. Accordingly, those quantities are also no longer reported in the output results files. Users are encouraged to use ColorTanimoto and TanimotoCombo instead.
  • Images in the RocsReport documentation have been updated.

SPRUCE 1.1.0

Spring 2020

This version of SPRUCE has been built using OEToolkits 2020.0.

New Features

With this release we now support loop modeling in proteins structures. The database, which has been built for modeling loops that are 4-20 residues long by default, is available for download in a platform-independent format.

This release contains two new applications:

  • LoopDB_Builder uses existing structures to build a dictionary of known loops that can be used in loop modeling of unresolved gaps in protein structures.
  • du2pdb converts the entire content of an OEDesignUnit to a PDB file.

Major bug fixes

  • The GetStructure application has been enhanced to prevent partial downloads. Retries and timeouts have been improved.

Minor bug fixes

  • The prefix input behavior has been standardized across all SPRUCE applications.
  • The input option --restrict_to_refsite is now being respected for both SPRUCE and EnumSites.
  • The -site_residue input option to EnumSites now performs correctly.
  • The GetStructure application now checks that the input PDB code contains 4 characters.
  • SPRUCE now fails if an MTZ file is specified but is not present or is unreadable.
  • The documentation around the -site_residue option used for APO structures has been simplified.

SZMAP 1.6.0

Spring 2020

  • This version of SZMAP has been built using OEToolkits 2020.0.

Major bug fixes

  • Using an OEDesignUnit as an input for stabilizing calculations now properly performs all 3 calculation stages.

Minor bug fixes

  • SzmapReport warning messages have been cleaned up.

SZYBKI 2.2.0

Spring 2020

  • This version of SZYBKI has been built using OEToolkits 2020.0.
  • As part of the integration of OEToolkits and OEApplications into a single release, the version number of SZYBKI has been upgraded to 2.2.0 to make it consistent with that of Szybki TK.

New features

  • SZYBKI applications can now use SMIRNOFF force fields with the built-in parameters parsley_1.0.0 and parsley_1.1.1. In addition, the applications can now use custom OpenFF parameters from an XML file.

Major bug fixes

  • An issue with Freeform results that occurred when the output was in sd format combined with the option -track has been fixed.