dolfin team mailing list archive

[Matthew Knepley <knepley@xxxxxxxxx>]

On Mon, Apr 6, 2009 at 10:13 AM, Anders Logg <logg@xxxxxxxxx> wrote:

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

This is impossible in parallel.

  Matt


> > 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
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAknaHAYACgkQTuwUCDsYZdFCKgCgkVH8LWChvkvV83uO3Sy1p1bi
> 02wAn1ciECz89yZHhdHKmvScPSpMI3lO
> =TstO
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev
>
>


-- 
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener