I would also like this capability! It is something that often shows up
in inverse/optimal control problems.
Written in FFC/UFL your first equation reads:
dot(u,v)*dx - p*div(v)*dx + lmbda*dot(v,n)*ds
where u, p, lmbda are trial functions.
You could form one system or create a block matrix. Anyhow
the term
lmbda*dot(v,n)*ds
would lead to a matrix with a very big kernel since you are not able to
restrict the dofs of lmbda only to the boundary.
What you can currently do is to restrict the functionspace for lmbda to
all the cells
associated with the boundary.
Using restricted functionspaces (in a simpler fashion) can be found in
demo/function/restriction.
The restriction does only work on cells for now.
We could discuss Uzawa and/or block matrices for this problem but I think
the simplest start is to create one system to begin with.
Whether it makes sense that lmbda lives on the whole cell associated with
the boundary, I don't know.
Kent
On Thu, Apr 16, 2009 at 02:57:07PM -0400, Shawn Walker wrote:
Oh really? And then I could call a direct solver on it? Is there a
demo
somewhere that shows this?
I could also use an Uzawa method. But concatenating matrices would be
fine for me.
- Shawn
No, I don't expect direct solvers will work, but it should be possible
to use with a Krylov solver. Kent knows about this.
When I look at it now, BlockMatrix does not inherit from any of the
KrylovMatrix base classes so it won't work with any of the solvers.
Kent has his own GMRES/CG implementation in Python which uses the
mult() operator provided by BlockMatrix. Maybe Kent can elaborate on
this (and the code)?
Moving this to dolfin-dev.
--
Anders
_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@xxxxxxxxxx
http://www.fenics.org/mailman/listinfo/dolfin-dev
_______________________________________________
FFC-dev mailing list
FFC-dev@xxxxxxxxxx
http://www.fenics.org/mailman/listinfo/ffc-dev
