From: Roy Stogner <roystgnr@ic...>  20050627 22:08:07

On Mon, 27 Jun 2005, Coroian, Cristian wrote: > With regards to mapping a real space point back to computational space, > what do you think of this idea: > > In the PointLocatorStructure::init(), build an ndimentional container > where n is the dimension of the Point, containing Elem constant > refferences. For example, in a 2D case I would have > > E :: ndimensional container where references are stored > delta :: ndimensional container where cell size (a conversion factor) > is stored. > > for all elements > > E[floor(element.centroid(0)/delta(0))][floor(element.centroid(1)delta(1) > )] = &element; > > Then have the point locator operator() function would > > return E[floor(Point(0)/delta(0))][floor(Point(1)/delta(1))] > > which is the constant reference to the element. > > Outside of space inefficiency can you provide any suggestions as far as > this method is concerned? I can't think of a better way to provide a timeefficient point locator for a cartesian grid held in the current unstructured Mesh subclass. If you eventually make a new CartesianMesh subclass, though, just make sure your coarse elements are always created in a canonical order and never renumbered and you'll be able to get the correct element with an (i*N*M+j*N+k) type indexing without a lookup table. You could even retain adaptivity in such a class  just make sure the coarse elements aren't renumbered, have the lookup find the containing coarse element first, and iteratively descend down into child elements to find the correct containing active element.  Roy Stogner 