Difference between revisions of "Version 3.0 Projects"

From Open Babel
Jump to: navigation, search
Line 59: Line 59:
* Consistent units:
* Consistent units:
** GetTorsion returns degrees while SetTorsion takes radians
** GetTorsion returns degrees while SetTorsion takes radians
* Callbacks:
** simple callback functions
** or type-safe signals (boost::signal or libcsig++)
== Design ==
== Design ==

Revision as of 13:53, 9 August 2008

This page itemizes some projects for version 3.0, targeted for a release date of (???)

Everything here is intended as a proposal to be edited, revised, removed, added, etc. Please make suggestions and critiques!

Key Frameworks (proposed)

The release will include several types of key chemical "frameworks."

  • Formats (including molecules, reactions, grids/cubes, trajectories/animations)
  • Fingerprints // Filtering (SMARTS, Descriptors, etc.)
  • Fragments // Force Fields (building, depiction)
  • Flexibility (scripting languages, 3rd party development, open source)

Each of these frameworks is already available in Open Babel 2.1, but are not always easily approachable. Documentation and tutorials continue to improve, but in some cases, continuing development requires some backwards-incompatible changes.

General projects

This list includes general ideas and goals for the 3.0 effort. The main push should be to refactor code to eliminate duplication and provide for a more logical class hierarchy. Some classes and methods have been deprecated and will be removed.

  • Atom indexing from 0 (i.e., all data finally indexed from 0)
    • This will require considerable time to stabilize the code after this change
  • Stereochemistry updates
  • Valence model updates
    • Retain any and all formal charges
    • Valence and aromaticity models for different formats (e.g., SMILES is different from Tripos Mol2)
  • Consider using base libraries
    • Boost
    • Eigen
    • GMM
    • GNU Science Library (GSL)
  • Header reorganization
    • Eliminate iostream from public headers (use iosfwd, etc.) to minimize compile and performance hit
    • Minimize ABI / API breaking via opaque pointers
    • Use minimal #include statements in public headers (and class stubs as needed)
  • Revisit and refactor classes, methods (eliminate deprecated methods, migrate some methods to/from base classes)
    • Continuing Software Archeology
    • Generalization of OBBond class
      • Support for ionic bonds, hydrogen bonds, multi-center bonds, etc.
    • Generalization of queries and filters (beyond just SMARTS matching)
  • Performance improvements
    • SMARTS performance
    • Graph symmetry
    • Atom typing
    • Minimize use of SSSR (smallest ring size already determined by FindRingAtomsAndBonds)
  • Plugin module improvements
    • Fingerprints, force fields, formats
    • Descriptors, filters
    • Load only as needed
  • Support for chemical data types:
    • QM data support
      • Vibrational modes, etc.
      • Orbital energies (eigenvalues, eigenvectors)
      • Cube files, grids, etc.
    • Point group and space group symmetry perception
    • Existing PDB, CML, SDF properties and metadata
    • Keywords, author, references, etc.
  • Consistent units:
    • GetTorsion returns degrees while SetTorsion takes radians
  • Callbacks:
    • simple callback functions
    • or type-safe signals (boost::signal or libcsig++)




All plugins inherit from OBPlugin, this class has public GetType(), GetName() and GetDescription() methods and a protected SetInfo() method which can be called by friend class OBPluginFactory. OBPlugin doesn't have any other uses at the moment and no OBPlugin methods have to be re-implemented or called when creating plugins.

Real plugins inherit from an OBPluginInterface, which itself inherits from OBPlugin. These interfaces are the types of plugins, they have pure virtual functions to be implemented in the derived plugin class. OBMoleculeFormat, OBDescriptor, OBFingerprint, ... are all plugins interfaces. In the future, perception models will also be plugins with matching interfaces. (Note: there is no OBPluginInterface class, this is just to make the diagram more generic.)

A plugin will need to use the MAKE_FACTORY(Class, ClassFactory) macro to create a derived OBPluginFactory. The plugin will also need to declare a static instance of the derived OBPluginFactory with the type, name and description as parameters:

#include <openbabel/descriptor.h>

class MyDescriptor : public OBDescriptor
    double Predict (...) 
      return ...;

MAKE_FACTORY(MyDescriptor, MyDescriptorFactory)
MyDescriptorFactory myDescriptionFactory(OBPlugin::DescriptorType, "MyDescriptor", "description...")

Improvements compared to 2.2:

  • OBPluginManager is now a facade/interface and the implementation details are hidden.
  • OBPluginManager provides all needed plugin iterators, the client never sees how the plugins are stored internally, ...
  • The plugin type, name and des<cription is in one single place (at the bottom of the plugin file)
  • static instance of the plugin replaced by much smaller factory


  • have both a MAKE_FACTORY and MAKE_SINGLETON_FACTORY to create multiple or a single instance (<-- using a shared_ptr?)
  • create interface(s) for perception models

Specific Developer Projects

  • Geoff
    • Atom and other objects indexed from 0
    • Header reorganization to improve compile time
    • Use of opaque data pointers to minimize API and ABI breaks
    • Modified ring detection to minimize FindSSSR in aromaticity detection, etc.
    • All-around help
  • Joerg
    • Moving algorithms from JOELib to OpenBabel
      • features
        • Atom pairs (fast, creating fast index? algorithm for indexing?)
        • Radial Basis Function, BCUT?
        • Optimal Assignment kernel (slow, but very fancy)
      • Clique detection
  • Tim
    • Force fields
      • Port to eigen2
      • Make memory usage for large molecules more linear (for non-bonded interactions, store only one OBFFCalculation for each unique A-B combination, ::Compute(...) will take positions as input. E_VDW and E_ELE iterate over all pairs or the neighbor list when cut-off are used.)
      • Group-based cut-offs (avoid cut-off problems)
      • Periodic boundary conditions (box)
      • more generic way to read and specify parameter files (all AMBER ffs (GAFF), MMFF94/MMFF94s)
      • Add AMBER force field
  • Chris
    • Change implementation of plugin classes so types (like fingerprints, forcefields) are themselves plugins which allows generalized commandline listing.
    • Add OBDescriptor plugin type as a wrapper for logP etc. and for existing properties like MW, (and others from JOELLib?).
    • Add --filter option using descriptors and --desc (?) for adding as SDF-like properties (OBPairData)
    • Eventually, move OBFormat to this plugin framework.
    • Make proposal for cleaning up stereochemical representation.
    • New OBReaction