dolfin team mailing list archive

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

I'd forgotton about the symmetric enforcement being in place.If you just
order the dof so that the constrained ones come last, it's
easy to generate the matrix with them removed as well.  Not much
harder than taking the average diagonal for scaling.  At least, on one
processor :)

Rob

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