dolfin team mailing list archive

[Jed Brown <jed@xxxxxxxx>]

On Tue 2009-04-07 15:05, Murtazo Nazarov wrote:
> Jed Brown wrote:
> > On Mon 2009-04-06 07:42, 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
> >>
> >>   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.
> >>     
> >
> > I agree with all your points, but with caveats on 3.
> >
> > There are much bigger gains in cache performance by interlacing the dofs
> > so as to enable the use of inodes and blocked matrix formats (BAIJ).
> >
> > If we want to use blocked formats with slip boundary conditions, we need
> > to be able to leave the condition in.  A slip boundary condition imposes
> > a Dirichlet condition on the normal component and stress conditions on
> > the tangent components.  The global degrees of freedom can be written in
> > a rotated coordinate frame so that the Dirichlet condition can be
> > completely removed, but when using BAIJ we have to put something there.
> > This can be done, complete with "zeroing the column", but it requires
> > manipulations in function evaluation and when setting values in the
> > matrix.  In some of my experiments, the performance benefits of BAIJ
> > over AIJ+inodes justify this strategy.
> >
> > If you have Dirichlet conditions on all components, then removing these
> > dofs from the system really is better.  Also, if you are not using
> > blocked matrix formats, you might as well remove all Dirichlet dofs for
> > all the reasons Matt states.
> >
> > Jed
> >   
> 
> The slip boundary condition is implemented in unicorn now, as the way 
> you said:
> 
> http://www.nada.kth.se/cgi-bin/jjan/hgwebdir.cgi/unicorn-kth
> 
> The speed is almost the same as applying Dirichlet boundary condition. 
> Some matrix operations are used there.

I looked at lib/SlipBC.cpp in that repository, but it looks like it
manipulates an assembled matrix which is completely different from what
I described.

Jed

Attachment: pgpDTKlIMqdp_.pgp
Description: PGP signature