From 00b913e99a601e2294e61a6ae6cfd2cf6f8e230b Mon Sep 17 00:00:00 2001 From: Wolfgang Bangerth Date: Sat, 5 Feb 2011 06:35:30 +0000 Subject: [PATCH] Update a comment. git-svn-id: https://svn.dealii.org/trunk@23287 0785d39b-7218-0410-832d-ea1e28bc413d --- deal.II/examples/step-18/doc/intro.dox | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/deal.II/examples/step-18/doc/intro.dox b/deal.II/examples/step-18/doc/intro.dox index 9db57ad419..9f56d3a0a2 100644 --- a/deal.II/examples/step-18/doc/intro.dox +++ b/deal.II/examples/step-18/doc/intro.dox @@ -639,7 +639,14 @@ is only slightly messy in the sequential case; in fact, the functions FETools::get_projection_from_quadrature_points_matrix will do the projection, and the FiniteElement::get_restriction_matrix and FiniteElement::get_prolongation_matrix functions will do the -transfer between mother and child cells. However, it becomes complicated +transfer between mother and child cells. Alternatively, one can use +FETools::get_projection_from_quadrature_points_matrix to convert data only +defined in quadrature points to a finite element field, use the +SolutionTransfer class to move the field to a refined/coarsened version of the +mesh, and then use FETools::compute_interpolation_to_quadrature_points_matrix +to get the information back into the quadrature points of the new mesh. + +However, whichever way we do it, it becomes complicated once we run the program in parallel, since then each process only stores this data for the cells it owned on the old mesh, and it may need to know the values of the quadrature point data on other cells if the corresponding cells -- 2.39.5