dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Apr 06, 2009 at 10:01:24AM -0500, Robert Kirby wrote:
> I see two reasons why to do symmetric BC if you can.
> 1.) If CG is applicable, it will almost always work better than GMRES, both in
> terms of convergence rate and memory usage (no Hessenberg matrix).  A simple
> way to check this without any substantial code development is to do Nitsche BC
> for Poisson and compare CG and GMRES

Symmetric applications of BCs is already in place:

  A, b = assemble_system(a, L, bc)

The dofs are kept (not eliminated) but the BC is applied to ensure
that A remains symmetric (if symmetric).

> 2.) In 2d, say for Poisson, it's not a big
> deal -- a simple argument shows the diagonal terms are all O(1), so you don't
> introduce any weird scaling by setting the diagonal to 1, zeroing the row, etc.
>  In either 1d or 3d, however, the diagonal terms are not O(1).  This can affect
> the spectrum of the matrix and hence the convergence properties of the method.

We could always scale what we insert on the diagonal (in both LHS and
RHS) by looking at something like the average of the diagonal entries.

I'm not opposed to eliminating dofs. It's just what we have now works
and if we should spend time implementing something else it must be
worth the effort.

-- 
Anders


> On Mon, Apr 6, 2009 at 8:11 AM, Anders Logg <logg@xxxxxxxxx> wrote:
> 
>     On Mon, Apr 06, 2009 at 07:42:47AM -0500, Matthew Knepley wrote:
>     > On Mon, Apr 6, 2009 at 1:09 AM, Anders Logg <logg@xxxxxxxxx> wrote:
>     >
>     >     On Sun, Apr 05, 2009 at 05:11:51PM -0500, Matthew Knepley wrote:
>     >     > On Sun, Apr 5, 2009 at 2:54 PM, Anders Logg <logg@xxxxxxxxx> wrote:
>     >     >
>     >     >     Dirichlet BC would need to be added in/after each
>     multiplication and
>     >     >     it should be possible to build it into the mult() operator and
>     make
>     >     it
>     >     >     efficient.
>     >     >
>     >     >
>     >     > I still think the best way to handle this is to eliminate them, as
>     I
>     >     talked
>     >     > about
>     >     > last time at Simula.
>     >     >
>     >     >   Matt
>     >
>     >     I think we're in position to do that now with the new FunctionSpace
>     >     class. One could allow restrictions to be imposed, for example
>     >
>     >      V.restrict(bc);
>     >
>     >     But I haven't seen any good numbers to indicate it's worth the
>     effort.
>     >     How much better is it to eliminate, condition numbers etc for letting
>     >     the constrained dofs just sit along?
>     >
>     >
>     > Its not about performance, so much as
>     >
>     >   1) Programming ease, ESPECIALLY with nonlinear problems
> 
>     We have already implemented the functionality for non-elimination of
>     constrained dofs so the question is what the benefit is of *also*
>     implementing elimination as an extra option.
> 
>     >   2) Separation of storage organization from traversal organization
>     >
>     >   3) Cache performance
>     >
>     >   4) Interaction with external packages
>     >
>     > I think I must have done a terrible job explaining this. I have always
>     coded
>     > both ways and always found that elimination is better.
>     >
>     >    Matt
> 
>     I remember doing elimination 10 years ago when I still programmed in
>     MATLAB and that it was a pain: first removing dofs before solve,
>     then putting them back again to plot the solution.
> 
>     The reason we don't do it (yet) in DOLFIN is we (at least I) find it
>     easier to just modify the linear system.
> 
> 
>     -----BEGIN PGP SIGNATURE-----
>     Version: GnuPG v1.4.9 (GNU/Linux)
> 
>     iEYEARECAAYFAknZ/28ACgkQTuwUCDsYZdGueQCff2K3PEcJbv847DWuBhRAcbZq
>     Ea8An3SUcrax2ANUzgTapzc0tWMnFzrh
>     =zirv
>     -----END PGP SIGNATURE-----
> 
>     _______________________________________________
>     DOLFIN-dev mailing list
>     DOLFIN-dev@xxxxxxxxxx
>     http://www.fenics.org/mailman/listinfo/dolfin-dev
> 
> 
> 

> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev

Attachment: signature.asc
Description: Digital signature