I started updating this interface and I have run into some questions. 1. Many ML options are only present in the C++ interface, via this cool new API knows as "strings". These mostly end up just setting agg_object->named_options which we can do just as well from ml.c. Unfortunately, there is some nontrivial logic about mutually exclusive/non-orthogonal options (ML just ignores certain options if other options are given). We usually get segfaults if we set incompatible options. I think there are cases where the ML C++ interface will also let this through, but it certainly does a more complete job of ensuring preconditions than we can reasonable expect to reproduce. Is it actually worthwhile to use ML's C++ interface considering that ML is not really developed any more (the devs are working on a new thing that's a more-or-less complete rewrite)?
2. If we make PETSc's ML interface use C++, I do not want to have to build all of PETSc with a C++ compiler just to be able to use ML. Can we detect a C++ compiler and then just compile *.cc sources with it (I would also like this to facilitate users building C++ project against a plain C PETSc)? 3. ML calls exit() directly in many places, despite being an insane error "handling" mechanism, especially in parallel. Part of me wants PETSc to register with atexit() just to be able to provide a stack trace in this circumstance. Thoughts? 4. ML_Gen_MultiLevelHierarchy_UsingSmoothedAggr_ReuseExistingAgg() exists (undocumented of course), so there is a way to avoid rebuilding the hierarchy at every PCSetUp. Jed
