Remove MGDoFHandler doc references.

This class was removed in commit c3b628b913.

diff --git a/examples/step-50/step-50.cc b/examples/step-50/step-50.cc
index ea0ee6e03426378ce2e19840790f497fe66d93ec..d43bcc550d5387ae22f2e27af9a709f21223e6bb 100644 (file)
--- 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<dim>::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 <code>refine_grid()</code> 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
+  // <code>output_results()</code> method is quite different since each
+  // processor writes only part of the overall graphical output.
   template <int dim>
   void LaplaceProblem<dim>::refine_grid ()
   {