[Libmesh-devel] Fwd: libMesh with SNESVI

[Gaston, D. <der...@in...>]

Guys... Dmitry at Argonne is working on some advanced PETSc / libMesh
linkages... here is some of his work so you can see what he's up to and
comment if you wish.

Derek

---------- Forwarded message ----------
From: Dmitry Karpeev <ka...@mc...>
Date: Fri, Feb 24, 2012 at 12:04 AM
Subject: libMesh with SNESVI
To: Derek Gaston <der...@in...>, Michael Tonks <
mic...@in...>, Jungho Lee <ju...@mc...>, Barry Smith <
bs...@mc...>


Guys,
I've hooked up libMesh to the latest SNESVI functionality through a new
solver class petsc_dm_nonlinear_solver in libMesh.
It passes the usual SNES callbacks through a newly created,
libMesh-specific, DM implementation.
This is also how SNESVI gets its bounds on the solution.
I'm attaching a libMesh patch for this.  The problem is I'm not sure what
revision it should be applied to.
It applies cleanly against this (oldish) commit of our git-svn
mirror: 51fe6de55b8c32a048ce90315829ee6763b7f18a
I'm not sure it has a universal meaning like the usual git SHA1.
At any rate, I think it will apply just fine against the HEAD, but we'll
see :-)

I'm also attaching a test -- a libMesh reimplementation of our "biharmonic"
example.
It solves the biharmonic heat equation discretized with Hermit elements and
a Crank-Nicholson scheme in time,
plus it's supposed to to Cahn-Hilliard with various options, but I haven't
really tested that.
The biharmonic heat equation seems to work fine (using the eyeball norm) in
1D,2D and 3D with and without inequality constraints.

There is still much more work to be done to make this universally useful,
but this is an important start, in my opinion,
since now we can go in different directions from here:
 - pass the interface all the way up to MOOSE
 - generalize to other kinds of inequality constraints
 - pass field splits from MOOSE/libMesh to PETSc through the DM object
 - likewise for subdomains defined in terms of libMesh subsystems and mesh
blocks (good for PETSc's DD-style preconditioners)
 - DM will eventually pass the necessary info (refinement, coarsening,
restriction, interpolation) to MG
 - contact -- something I'm looking into right now, since Jason Hales asked
me to chase a weird behavior with petsc-3.1 (which is absent in petsc-2.3).

Let me know what the best way might be to work this patch into the libMesh
source tree.
Cheers,

Dmitry.