On Mon, 30 Mar 2009, Kirk, Benjamin (JSC-EG311) wrote: >>>> The has_affine_map seems like a big payoff to avoid repeating the >>>> flops to determine it... >> >> I'd say we might want to profile that before we make too big a deal >> out of calling it a lot. For Quad4's it's two point subtractions and >> one equality test, for Hex8's it's at most 6 point subtractions and 4 >> equality tests, some of which may short-circuit if the element is not >> affine. > > Well, take a look at the Hex27, which would be the element for the CH > application I believe...
Hex8, unless they want to do p refinement. I know, you wouldn't expect a cubic FE to be representable on a first order element, but satisfying C1 continuity ends up moving every DoF to a node in this case. It's also worth pointing out that for Cahn-Hilliard (to do it properly, with a realistic free energy functional) you'll have element integrations that end up overwhelming anything has_affine_map might do. On a Hex8: 8 bases times 8 test functions times enough quadrature points to integrate them all accurately, with a lot of flops (including divisions) per quadrature point... I once got a notable speedup by looping over just the upper triangular jacobian while calculating the lower triangular entries at the same time, but I don't think you'll see too much from just getting rid of has_affine_map. Remember that the whole reason has_affine_map is there is because it turned out to be much cheaper than fully reinitializing an FE object. John's got the right idea. Profile first, see if has_affine_map really is a significant expense, then if it is we can worry about optimizing it. --- Roy ------------------------------------------------------------------------------ _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
