orderings

Hi Al.

On Sat, Nov 03, 2018 at 11:19:22AM +0100, Felix Salfelder wrote:
> a good ordering could be computed (pretty quickly) from the incidence
> graph and a loaded matrix. but if it is done only after load, then the
> matrix rebuild will take some extra time.

did something in that direction.

some ordering is pluggable in the plug_order branch. with this, a
static odering can be computed from the incidence graph.

when the incidence graph is not constructed (forward, reverse), there is
some overhead in the virtual iwant calls. i can't measure it.  (but
that's it).

i wrote plugins that intercept and store the incidence graph, then pass
it to algorithms shipped with boost. i have uploaded test diffs for
reverse cuthill mckee [1]. perhaps interesting

- the density gets better in most cases, eq*fg2.ckt is the notable
  exception, all others are not too bad.
- the extra running time is still negligible, even without much
  tweaking. solving time drops a bit, perhaps compensating for order
  computation.
- the numerical quality increases. it's not visible in many places, but
  some numerical zeroes are closer to zero, and sometimes the number of
  iterations goes down. it never goes up. my incmode example also seems
  to work with rcmk.

have fun.
felix

[1] https://www.boost.org/doc/libs/1_68_0/libs/graph/doc/cuthill_mckee_ordering.html