Check in some log files to the test data and confirm geometry extraction from them. Examples should be available as documentation even for systems that don't have all back ends installed.

Common test class, e.g. EnergyTest, subclassed by MethodEnergyTest (e.g. Semiempirical, DFT...), further subclassed by adapter (e.g. GAMESS, MOPAC7...)

Also MethodEnergyComparison, MethodOptComparison, etc.

This should get rid of code redundancy and make it easier to cross-validate adapters.

The cross-package comparison code should actually be part of the application instead of the test.

Also need a way to automatically skip runs if the back end is not installed, and report it.

Also need a way to automatically skip runs if the back end does not support the method, and report it.

At some point I will want to add a handler to automatically attempt to fix failed SCF convergence. First we need a failed SCF convergence test case that exercises detection mechanisms, though.

Reading the code, it appears that NWChem in its default compile may support a maximum of 7 basis sets assigned in one system. Add test case to check this. Also see if we can discover basis sets limits for the other adapters.

Add support and tests for goal=saddle. Partial dependency on hessian calculations (for verification).

At some point I'll want the capability to automatically retry difficult geometry optimizations. First we need a detection mechanism and corresponding test case for optimization failures.

It should be possible to augment a basis set definition with diffuse/polarization functions.

Investigate this: can we further simplify data extraction by having a single extract_matches method that takes parameters line_scanner, start=None, end=None? Do it as a generator.

When start and end are None, line_scanner would try to match patterns from every line like the line_to_geometry method does inside extract_geometry. When start is None and end is a string, the scanner would run until it encounters the end-string or until it runs out of data. When start is a string and end is None, the scanner would only try to match lines after it encounters the start-string in input. When start and end are both strings, the scanner would enter active mode only between start and end pairs, to e.g. extract blocks of data.

A higher level generator on top of this generator can manage transitions to group data in blocks. This simplifies structure extraction for geometry.