Option to store geometry at quadrature points
Reported by Jed Brown | November 21st, 2008 @ 08:33 PM
Recomputing the element Jacobian is dominated by evaluating the coordinate values at quadrature points. This accounts for almost 40% of runtime for the projection problem with no preconditioner. Storing the geometry puts more pressure on the memory bus, but should still speed things up.
Comments and changes to this ticket
-
Jed Brown November 24th, 2008 @ 11:34 AM
- State changed from “new” to “resolved”
ac45dfafe23bc082bfe8395a50ce3d3d8daa9277 mostly resolves this. The floating point performance of geometry computations is very high (2.5 GFLOPS) so the cost of recomputing geometry is now fairly small. This might change with higher order parametric maps, but I doubt that it is worthwhile. The geometry computations need to be overhauled when we do higher order parametric mapping (they might get simpler).
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
An implementation of the ``dual order hp'' version of the finite element method. This project targets parallel domain-decomposition methods for strongly coupled nonlinear problems with PDE constraints.
Jed Brown