dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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

Attachment: signature.asc
Description: Digital signature