From 508a07d57ae5a750bb12bd7449505be0334e4720 Mon Sep 17 00:00:00 2001 From: David Wells Date: Tue, 11 Oct 2016 15:34:51 -0400 Subject: [PATCH] Remove MGDoFHandler doc references. This class was removed in commit c3b628b913. --- examples/step-50/step-50.cc | 30 +++++++++++------------------- 1 file changed, 11 insertions(+), 19 deletions(-) diff --git a/examples/step-50/step-50.cc b/examples/step-50/step-50.cc index ea0ee6e034..d43bcc550d 100644 --- a/examples/step-50/step-50.cc +++ b/examples/step-50/step-50.cc @@ -542,8 +542,8 @@ namespace Step50 // need a right hand side, and more significantly (ii) we don't // just loop over all active cells, but in fact all cells, active // or not. Consequently, the correct iterator to use is - // MGDoFHandler::cell_iterator rather than - // MGDoFHandler::active_cell_iterator. Let's go about it: + // DoFHandler::cell_iterator rather than + // DoFHandler::active_cell_iterator. Let's go about it: typename DoFHandler::cell_iterator cell = mg_dof_handler.begin(), endc = mg_dof_handler.end(); @@ -679,7 +679,7 @@ namespace Step50 // spaces involved and can often be computed in a generic way // independent of the problem under consideration. In that case, we // can use the MGTransferPrebuilt class that, given the constraints - // on the global level and an MGDoFHandler object computes the + // on the global level and an DoFHandler object computes the // matrices corresponding to these transfer operators. // // The second part of the following lines deals with the coarse grid @@ -816,22 +816,14 @@ namespace Step50 // @sect4{Postprocessing} - // The following two functions postprocess a - // solution once it is computed. In - // particular, the first one refines the mesh - // at the beginning of each cycle while the - // second one outputs results at the end of - // each such cycle. The functions are almost - // unchanged from those in step-6, with the - // exception of two minor differences: The - // KellyErrorEstimator::estimate function - // wants an argument of type DoFHandler, not - // MGDoFHandler, and so we have to cast from - // derived to base class; and we generate - // output in VTK format, to use the more - // modern visualization programs available - // today compared to those that were - // available when step-6 was written. + // The following two functions postprocess a solution once it is + // computed. In particular, the first one refines the mesh at the beginning + // of each cycle while the second one outputs results at the end of each + // such cycle. The refine_grid() method is almost unchanged + // from step-6: the only substantial difference is that this method uses a + // distributed grid refinement function instead of a serial one. The + // output_results() method is quite different since each + // processor writes only part of the overall graphical output. template void LaplaceProblem::refine_grid () { -- 2.39.5