dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Apr 25, 2007 at 10:34:20AM +0200, Garth N. Wells wrote:
> 
> 
> Anders Logg wrote:
> > On Tue, Apr 24, 2007 at 06:40:08PM +0200, Garth N. Wells wrote:
> >>
> >> Anders Logg wrote:
> >>> On Tue, Apr 24, 2007 at 05:28:46PM +0200, Garth N. Wells wrote:
> >>>> Anders Logg wrote:
> >>>>> On Tue, Apr 24, 2007 at 04:37:13PM +0200, Garth N. Wells wrote:
> >>>>>> I've done some rough timings for assembly of the elasticity demo with 
> >>>>>> the mesh refined once. For assembly, things are much faster (almost a 
> >>>>>> factor 3), but the application of Dirichlet boundary conditions has 
> >>>>>> become very expensive. Both the creation of sub-domains and the 
> >>>>>> application of the boundary conditions appears to be quite costly. Of 
> >>>>>> the time required for mesh initialisation, refinement, assembly and 
> >>>>>> application of boundary conditions, more the 50% of the runtime involves 
> >>>>>> the application of the boundary conditions. In version 0.64, the 
> >>>>>> application of boundary conditions involves almost zero overhead.
> >>>>>>
> >>>>>> Garth
> >>>>> Strange... There are are a few differences in how the bcs are handled
> >>>>> compared to 0.6.4 but I didn't think these would introduce any
> >>>>> overhead. Here are the major differences:
> >>>>>
> >>>>> 1. We loop over the whole domain, not just the boundary
> >>>>>
> >>>>> This means we can set Dirichlet conditions in the interior as well as
> >>>>> on the boundary. The overhead should be small, since before we always
> >>>>> created a BoundaryMesh before iterating over the boundary and that
> >>>>> creation involves an iteration over the entire mesh, as well as
> >>>>> creating the new data for the boundary mesh. 
> >>>>>
> >>>>> 2. We create the mesh functions for the sub domains
> >>>>>
> >>>>> This is only done when a mesh function has not been supplied. If you
> >>>>> have a mesh function that specifies the sub domains, then this step is
> >>>>> not needed. Perhaps we could do some optimization in the
> >>>>> BoundaryCondition constructor.
> >>>>>
> >>>> Creating the sub-domains is very expensive: 11.1 / 24 s. Application of 
> >>>> the boundary conditions (bc.apply(. . .)) requires 3.41 / 24 s, which 
> >>>> still seems like quite a lot.
> >>>>
> >>>> Garth
> >>> ok, so we need to look into that. I'm working on getting the Stokes
> >>> demo working (setting bcs for sub systems) but I can take a closer
> >>> look when I'm done (if you don't find a solution before then).
> >>>
> >>> Creating the sub domains should be just as expensive as creating the
> >>> BoundaryMesh in the old code.
> >>>
> >> The expense is in initialising the connectivity (mesh.init(...) ). It is 
> >> dominating the creation of a the BoundaryCondition as this is when it is 
> >> first called.
> >>
> >> Garth
> > 
> > ok, that sounds good in the sense that we do the same initialization
> > in the old code when creating the BoundaryMesh. Is the initialization
> > done more than once? The second time it gets called it should realize
> > that the entities are already there and don't need to be generated.
> >
> 
> It's only done once.
> 
> Garth

But then it should be just as fast/slow as before. Do you see a
difference in the time spent inside mesh.init() for the old and the
new code?

When I think of it, we should actually be faster now since no
unnecessary initialization is done. (The old did some overkill since
it didn't know what was needed for higher order elements but the new
code asks needs_mesh_entities() for this and should get away with less
initialization.)

/Anders