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
