dolfin team mailing list archive

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

Ah... so preconditioners handle the corruption of the spectrum associated
with linear solves, but perhaps eigensolvers do not fare as well.
One work-around would be to do boundary conditions weakly via Nitsche's
method.  It is probably known what effect these BC have on the eigenvalue
problem, but not by me.  There are no artificial modifications of the
matrix, though, which bodes well.



On Tue, Apr 7, 2009 at 6:28 PM, Evan Lezar <evanlezar@xxxxxxxxx> wrote:

> 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
>>
>
>
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev
>
>