[petsc-dev] Times we are spectacularly wrong

[Matthew Knepley]

I have just seen another time when we were really wrong about a high-level
interface. I remember many discussions about implementing multivectors. I
know we discussed the relative merits of interlaced vs. non-interlaced,
etc. However, our basic assumption was the we would alter the Vec interface
somehow. If you look at TAIJ, that we completely misguided. You keep Vec
the same, and introduce tensor (Kronecker product) structure into the
matrix and you get "multivectors" as a special case, AND this interoperates
correctly with VecGather/ScatterStride(). It is worth asking how we got it
so wrong for so long.

I think it would be good to keep a catalogue of these things. One good
thing about institutional memory is that it keeps you from making the same
mistake again. I can already think of a few:

1) Removing all arguments from KSPSolve and SNESSolve

  I don't know how we talked ourselves into this, but it was a disaster. We
had to make a special release just to undo it. The concomitant change
removing all arguments from *Create() was right on, but KSPSolve() is
supposed to embody the inverse operation, so we were actually moving away
from the math, and making the user type and remember more. It roundly fails
the Reduction of Cognitive Complexity test.

2) Using templates for unstructured meshes

  I was convinced that unstructured meshes were too complex for C, and we
needed the ability of templates to express generic algorithms. This
unfortunately turned out to be horseshit (from a large horse). Templates
clutter the code with a huge number of unnecessary types, increasingly the
cognitive complexity. The also made it all but impossible to interoperate
with the rest of PETSc. They were a maintenance and portability nightmare,
and debugging performance problems because a monumental endeavor. I had to
write an entire arXiv submission to try and figure out how it went so
wrong: http://arxiv.org/abs/1209.1711. It turned out that writing it was a
good exercise in that there was considerable interface development and I
think we have something workable now, but I could have saved myself years
of pain by doing this all as a series of C rewrites in the PETSc object
system.

3) Nonlinear preconditioning

  This was not so bad, but we did spend years puzzling it out, and made
many mistakes. I think we missed the essential division between single step
and multistep methods. This allowed us to see the difference between left
and right preconditioning, and make sense out of the existing methods like
ASPIN, which mixed nonlinear preconditioning with decomposition. I think
this shows that we have to keep trying to categorize things until we get
the right division. I am sure the Templates guys thought they had it right
too :)

I guess I remember the ones where I was at least partly at fault the best.

    Matt

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131030/2898952d/attachment.html>