<div dir="ltr">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.<div>
<br></div><div>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:</div><div><br></div>
<div>1) Removing all arguments from KSPSolve and SNESSolve</div><div><br></div><div>  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.</div>
<div><br></div><div>2) Using templates for unstructured meshes</div><div><br></div><div>  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: <a href="http://arxiv.org/abs/1209.1711">http://arxiv.org/abs/1209.1711</a>. 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.</div>
<div><br></div><div>3) Nonlinear preconditioning</div><div><br></div><div>  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 :)</div>
<div><br></div><div>I guess I remember the ones where I was at least partly at fault the best.</div><div><br></div><div>    Matt</div><div><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener
</div></div>