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 <[email protected]> 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 <[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 > >>>> > >>>> 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 > [email protected] > http://www.fenics.org/mailman/listinfo/dolfin-dev >
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
