On Mon, Apr 6, 2009 at 10:13 AM, Anders Logg <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 > > [email protected] > > http://www.fenics.org/mailman/listinfo/dolfin-dev > > > > > > > > > _______________________________________________ > > DOLFIN-dev mailing list > > [email protected] > > 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 > [email protected] > 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
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
