00001
01174 triangulation.set_boundary (0);
01175 GridTools::transform (&warp<spacedim>, triangulation);
01176 std::ofstream x("x"), y("y");
01177 GridOut().write_gnuplot (volume_mesh, x);
01178 GridOut().write_gnuplot (triangulation, y);
01179 }
01180
01181 std::cout << "Surface mesh has " << triangulation.n_active_cells()
01182 << " cells."
01183 << std::endl;
01184
01185 ...
01186 @endcode
01187
01188 Note that the only essential addition has been the three lines marked with
01189 asterisks. It is worth pointing out one other thing here, though: because we
01190 un-attach the manifold description from the surface mesh, whenever we use a
01191 mapping object in the rest of the program, it has no curves boundary
01192 description to go on any more. Rather, it will have to use the implicit,
01193 StraightBoundary class that is used on all parts of the boundary not
01194 explicitly assigned a different mannifold object. Consequently, whether we use
01195 MappingQ(2), MappingQ(15) or MappingQ1, each cell of our mesh will be mapped
01196 using a bilinear approximation.
01197
01198 All these drawbacks aside, the resulting pictures are still pretty. The only
01199 other differences to what's in @ref step_38 "step-38" is that we changed the right hand side
01200 to @f$f(\mathbf x)=\sin x_3@f$ and the boundary values (through the
01201 <code>Solution</code> class) to @f$u(\mathbf x)|_{\partial\Omega}=\cos x_3@f$. Of
01202 course, we now non longer know the exact solution, so the computation of the
01203 error at the end of <code>LaplaceBeltrami::run</code> will yield a meaningless
01204 number.
01205
01206 <a name="PlainProg"></a>
01207 <h1> The plain program</h1>
01208 @include "step-38.cc"
01209 */
01210