dolfin team mailing list archive

[Evan Lezar <evanlezar@xxxxxxxxx>]

Just my two-cents worth.  For eigenvalue problems, the current method of
applying zero valued Dirichlet BCs leads to a number of unity eigenvalues.
 This is problematic when the desired eigenvalues of the system also lie
around unity.  If there is a way to get around this without removing the
DOFs then I would like to know what it is.
Thanks
Evan

On Tue, Apr 7, 2009 at 7:06 PM, Murtazo Nazarov <murtazo@xxxxxxxxxxx> wrote:

> Jed Brown wrote:
> > 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
> >
> Yes, you are right. It is similar to the existing Dirichlet bc
> implementation.
>
> /murtazo
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev
>