Version 3.0 Projects

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 Goals

The version 3.0 release will not be backwards-compatible with version 2.x releases. For this reason, there may be a further 2.3 release to add some features to the 2.x release series before developers migrate to 3.0.

• Faster compilation
• Easier development
• More modular library, flexible use of plugins

Design

Many design project proposals have been pushed into separate wiki pages.

• Improved Code Quality
• Improved Plugin Framework
• Indexing from 0, not 1
• Online slot games

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.
  • Atom indexing always goes from 0 to numAtoms-1, even when you delete, add, ... atoms. The function of an atom index is to provide an index which can be used to access a data field in a std::vector for example.
• Unique Atom indexes will not go from 0 to numAtoms-1, they can be used to identify atoms for undo/redo purposes etc. Unique indexes are not reused
  • OB3: Atom Indexing & Unique IDs?
  • Re: OB3: Atom Indexing & Unique IDs? (part 1)
  • Re: OB3: Atom Indexing & Unique IDs? (part 2)
• Stereochemistry updates
  • OB3: Stereochemistry
  • Current status
• Valence model updates
  • Retain any and all formal charges
  • Valence and aromaticity models for different formats (e.g., SMILES is different from Tripos Mol2)
• Fix some problems with scripting bindings
  • SetData and scripting bindings
• Consider using base libraries
  • Boost
  • Eigen
• 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++)

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
      • Product graph

• 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