Hello again,
I am currently looking into the implementation FEValues. Here is my
understanding
1. FEValues takes some Mapping, FiniteElement, and Quadrature to
evaluate and store the values with the required UpdateFlags.
2. FEValues::initialize through the FiniteElement::get_data will then
pre-compute all the required data that are possibly computable on the
reference cell.
3. FEValues::reinit will then compute/fetch the data on a physical cell,
using the Jacobian information by calling the various fill_fe_values()
functions.
I see that most of the examples use implicit methods to solve the various
problems. Therefore, the cost of initialize() and reinit() on each cell is
quite low compared to solving the actual system at every step. However, for
explicit methods such as RK, we wouldn't want to re-compute the Jacobian or
reference gradients (\nabla_{physical} \phi = J^{-T} \nabla _{reference}
\phi) at every time step. Therefore, the FEValues declaration would be
outside the "assemble_system()" seen in most tutorials, and passed as an
argument as "assemble_system(FEValues fe_v)". Unfortunately, I am getting
lost in the code where things values are pre-computed versus fetching them.
My question is: What is being re-computed every time I call
FEValues::reinit(cell)?
I am mainly worried about it re-computing Jacobians (its determinant and
its inverse) and evaluating its product with the reference gradients
(\nabla_{reference} phi) every time reinit(cell) is called. Otherwise, the
solution will be to pre-compute and store those outside in some other
container and avoid using FEValues.
Doug
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
