| Thread Previous • Date Previous • Date Next • Thread Next |
Anders Logg wrote:
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: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.On Tue, Apr 24, 2007 at 05:28:46PM +0200, Garth N. Wells wrote:Anders Logg wrote: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.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.GarthStrange... 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 ascreating 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.Garthok, 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.Garthok, 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. GarthBut 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?
I didn't check.The new creation of boundary conditions appears slow as this is where mesh.init() is first called. Previously, mesh.init() was first called inside the assembly, which made the old assembly appear very slow.
Garth
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 _______________________________________________ DOLFIN-dev mailing list DOLFIN-dev@xxxxxxxxxx http://www.fenics.org/mailman/listinfo/dolfin-dev
| Thread Previous • Date Previous • Date Next • Thread Next |
