dolfin team mailing list archive

[Robert Kirby <robert.c.kirby@xxxxxxxxx>]

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 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.

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.
>
> --
> Anders
>
> -----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
>
>