[petsc-dev] ML interface

[Barry Smith]

    If ML is being replaced why waste any time on it? Why not become a  
beta tester of the rewrite and make an interface for that? (You would  
possibly be able to influence bad decisions they are going to make).

    PETSc already defined CCXX even when using the C compiler. You  
could introduce SOURCECXX in the makefiles and possibly make mixing in  
some C++ code relatively easily. BUT why not just build PETSc with C+ 
+, what is the downside to that?

     Barry

On Apr 20, 2010, at 11:53 AM, Jed Brown wrote:

> 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