On Fri, 27 Mar 2009, Kirk, Benjamin (JSC-EG311) wrote: > What do you think about adding some bitfields (or bitsets) to Elem > to track things like has_affine_map, on_processor_boundary, > on_material_interface, etc...? > > The has_affine_map seems like a big payoff to avoid repeating the > flops to determine it...
Hmm... it does, but it also seems like a bug waiting to happen. Calculate and cache has_affine_map... but then the user decides to smooth the mesh / run an ALE timestep / snap boundary nodes to new positions / etc. and the cache has been invalidated and the next FE::reinit() silently gives incorrect results. It's dangerous to cache data about an element that isn't encapsulated by the Elem class; in this case data that can be changed just by moving Points the Elem points to. Also: I'm all for making libMesh faster, but I'm lazy enough to want the effort focused on my current application. That's why I wrote the affine_map stuff when I was doing Cahn-Hilliard on rectilinear grids, and why I can't seem to make myself enthusiastic about further affine speedups now that I'm running compressible Navier-Stokes on meshes full of skewed quads and hexes. If you're looking for something to optimize, next on my plate is to change the FE::shape* interfaces to take arguments in vector form. It won't save many flops, but FE::reinit is slow enough that we can't be keeping the FPU queue full anyway, and I suspect just moving some for loops inside function calls will save a lot of cycles. Maybe I'm wrong; I'll forward this on to libmesh-devel for third opinions. Or maybe I'm just being myopic. Derek tells me there's INL people interested in doing Cahn-Hilliard stuff in his framework, who would be using affine grids, and who are referencing my CH talks. Speeding that up might help move that along, and I would enjoy describing my applications work as "cited in the nuclear engineering literature" rather than just "cited by a couple others from my department"... --- Roy ------------------------------------------------------------------------------ _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
