On Fri, Jun 13, 2008 at 10:43:12AM +0200, Johan Hake wrote: > On Friday 13 June 2008 10:17:20 Anders Logg wrote: > > On Fri, Jun 13, 2008 at 10:08:31AM +0200, Johan Hake wrote: > > > On Thursday 12 June 2008 22:05:43 Anders Logg wrote: > > > > On Wed, Jun 11, 2008 at 08:27:14AM +0200, Johan Hake wrote: > > > > > On Tuesday 10 June 2008 14:52:52 Anders Logg wrote: > > > > > > On Tue, Jun 10, 2008 at 02:28:51PM +0200, Johan Hake wrote: > > > > > > > On Tuesday 10 June 2008 13:23:45 Anders Logg wrote: > > > > > > > > On Tue, Jun 10, 2008 at 09:55:51AM +0200, Martin Sandve Alnæs > wrote: > > > > > > > > > 2008/6/9 DOLFIN <[EMAIL PROTECTED]>: > > > > > > > > > > One or more new changesets pushed to the primary dolfin > > > > > > > > > > repository. A short summary of the last three changesets is > > > > > > > > > > included below. > > > > > > > > > > > > > > > > > > > > changeset: 4282:5f6759a7460d81435abf4d67911667e3e628e164 > > > > > > > > > > tag: tip > > > > > > > > > > user: Anders Logg <[EMAIL PROTECTED]> > > > > > > > > > > date: Mon Jun 09 23:06:51 2008 +0200 > > > > > > > > > > files: dolfin/fem/Assembler.cpp dolfin/fem/UFC.cpp > > > > > > > > > > dolfin/fem/UFC.h description: > > > > > > > > > > Reset local tensor A^K before call to tabulate_tensor() > > > > > > > > > > > > > > > > > > Why? This is the job of tabulate_tensor, which can do it much > > > > > > > > > more efficiently? > > > > > > > > > > > > > > > > I added this for convenience. It is used when assembling forms > > > > > > > > over subdomains and the form compiler needs to generate code > > > > > > > > for zero contributions from other domains, for example when > > > > > > > > integrating > > > > > > > > > > > > > > > > M = f*ds(5) > > > > > > > > > > > > > > > > Then the compiler needs to add zero integrals for ds([0-4]). > > > > > > > > Then this code just needs to be empty. > > > > > > > > > > > > > > It would be great to be able to integrate the above mentioned > > > > > > > form. It took me some time to realise that you could only > > > > > > > assemble subdomains that was contiguously numbered from 0 and up. > > > > > > > > > > > > That's not needed anymore. It should be possible now to integrate > > > > > > the form above without adding any additional terms. > > > > > > > > > > Nice! > > > > > > > > > > > > But is this implementation the most logical? What if I think it > > > > > > > is natural to mark a subdomain with "100"? Then 100 empty > > > > > > > integrals would be created? Is it possible to store the integrals > > > > > > > in a map, with markers as keys. Or store the integrals in a > > > > > > > contiguous array, and then map these to markers? > > > > > > > > > > > > Yes, this can be done. It's related to building a mapping from > > > > > > subdomains to cells that's been discussed before. Now we only have > > > > > > the inverse, the mapping from cells to subdomains. I don't know > > > > > > when this will happen. It's something I'd like to have but it's not > > > > > > critical. > > > > > > > > > > OK > > > > > > > > > > > > This would add flexibility for assigning a form integral an > > > > > > > arbitrary number, but it also introduce a map lookup overhead > > > > > > > that would slow down the assembly. The latter could be solved > > > > > > > with an inverse MeshFunction, which map values to cells/facets. > > > > > > > > > > > > Don't think it needs to slow down assembly. > > > > > > > > > > OK > > > > > > > > > > > > It would also be nice to separate a facet MeshFunction in one > > > > > > > only for interior facets and one only for the exterior ones. This > > > > > > > would fit nicely in to the above mentioned procedure. I do not > > > > > > > know how to do this nicely though... > > > > > > > > > > > > Yes. > > > > > > > > > > > > > A note related to this issue: > > > > > > > A typical small mesh I generate have 23K vertices, and 86K > > > > > > > tetrahedrons, it takes ~0.3 s to load. The boundary mesh have 35K > > > > > > > facets but the whole mesh have 190K facets, including the > > > > > > > interior facets. This takes ~5s to load, almost 20 times more > > > > > > > time than the mesh, and it loads information about 160K facets > > > > > > > that is not needed. > > > > > > > > > > > > I guess you need this for boundary conditions? If that is the case, > > > > > > then the internal facets never need to be generated if you use the > > > > > > new mesh file format (which VTK uses) where all the boundary > > > > > > information is included in the mesh file. > > > > > > > > > > ? > > > > > > > > > > Maybee I was unclear? I need a MeshFunction to define my boundary > > > > > subdomains, to send to assemble. Do you say that I can store this > > > > > subdomain meshfunction in the new mesh format, by only storing the > > > > > information of the exterior facets? I thought a Meshfunction was tied > > > > > to the same entities in the mesh, and needed to be of the same > > > > > length, i.e., a facet meshfunction need to include information of all > > > > > facets in the mesh. > > > > > > > > Yes, that's true, but in the "new" (extended) mesh format, we store > > > > Arrays, not MeshFunctions. These don't have to have the same length. > > > > > > > > Take a look at data/meshes/aneurysm.xml.gz. > > > > > > > > Only DirichletBC can currently handle this data. Assembler still > > > > relies on a MeshFunction for the subdomains. > > > > > > Ok, this MeshData can take an arbitrary number of MeshFunctions and > > > Arrays. But three arrays with name "boundary facet cells", "boundary > > > facet numbers" and "boundary indicators" are treated specially in the > > > function DirichleBC(). > > > > Correct. > > > > > I do not really understand what these name stand for. Shouldn't it be > > > enough to use two arrays? One for the global facet number of the facets > > > laying on the boundary, and one for the markers? > > > > No, it's not enough. It would be enough if everyone numbered the > > facets in the same way as DOLFIN, but that is not the case, in > > particular since the way DOLFIN numbers the facets depends on the > > particular algorithm implemented in DOLFIN for generating the facets > > for a mesh. So we need to store the markers based on the *cells* > > rather than the *facets*. So we basically store a list of the cells > > adjacent to the facets on the boundary, the local numbering of the > > facets relative to those cells, and the markers for the facets. > > OK! > > > > I still can't figure out why a mesh takes ~20 times logner to load? First > > > I thought that a MeshFunction stores more information, but 20 times, and > > > the file is actually much smaller than the mesh file. Could the > > > implementation of XMLMeshFunction be to blame? > > > > I think the problem is that when you load markers on the facets of a > > mesh, then DOLFIN first needs to compute the facets and that may take > > some time. (Only the vertices and cells are present in the XML file.) > > Jepp, you are correct here! > > mesh.init(2) took 55 s and loading the mesh function after this took 2s... :P
Good. (But actually not that good. Looks like we might need to do something to improve the speed of mesh.init().) -- Anders
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
