From: Roy Stogner <roystgnr@ic...>  20090330 15:40:29

On Mon, 30 Mar 2009, Kirk, Benjamin (JSCEG311) 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 shortcircuit 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 CahnHilliard (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 