Calculus II
Lesson 5: Applications of Integration 3: Area of a Surface of Revolution
Area of a Surface of Revolution
Recall that a surface of revolution is generated when the graph of a function is revolved around the -axis:
> restart;
> f := x-> 1 + 4*x^2 - x^3;
> plot(f, -1..2);
> plot3d([x,f(x)*cos(t), f(x)*sin(t)], x=-1..2, t=0..2*Pi);
>
Question 1
Define a function by . What surface is generated when the graph of between and is revolved around the -axis? Confirm your answer by using plot3d to draw the surface. (Hint: cut-and-paste from the example above!)
Solution.
> g := x-> sqrt(9 - x^2) ;
The curve is the upper half of the circle , so it is a semi-circle of radius 3, centred at the origin. When it is revolved around the -axis, we should get a sphere of radius 3.
> plot3d([x,g(x)*cos(t), g(x)*sin(t)], x=-3..3, t=0..2*Pi, axes=boxed, lightmodel=light1);
How should we proceed in order to find the area of such a surface? Naturally, we begin by dividing the interval over which we are working into a certain number of subintervals, and finding an approximation to the area of the part of the surface corresponding to one subinterval. This is the most complicated approximation we have seen so far, and it cannot be done in one step, but the first step is to approximate on each subinterval by a line segment, exactly as we did when we computed arclengths. Here is the procedure from the arclength worksheet that returns a piecewise-linear approximation to :
> pl := proc(f,a,b,n)
> local u,v,k;
> k := 1 + floor(n*(x-a)/(b-a));
> u := a + (k-1)*(b-a)/n;
> v := a + k*(b-a)/n;
> unapply(f(u) + (f(v) - f(u))/(v-u)*(x-u), x);
> end:
Working with the function we defined above, we can plot the piecewise-linear approximations, and (with plot3d ) the surfaces we get by revolving these approximations.
> plot([f,pl(f,-1,2,5)], -1..2, thickness=2);
> plot3d([x,pl(f,-1,2,5)(x)*cos(t),pl(f,-1,2,5)(x)*sin(t)], x=-1..2, t=0..2*Pi, axes=boxed, lightmodel=light1);
Question 2
Experiment with different numbers of subintervals to see how the piecewise-linear surfaces approach the exact surface of revolution. Repeat with the function from Question 1.
Solution. Here are the piecewise-linear approximations for , with 3, 6, and 10 subintervals, revolved around the -axis:
> plot3d([x,pl(f,-1,2,3)(x)*cos(t),pl(f,-1,2,3)(x)*sin(t)], x=-1..2, t=0..2*Pi, axes=boxed, lightmodel=light1);
> plot3d([x,pl(f,-1,2,6)(x)*cos(t),pl(f,-1,2,6)(x)*sin(t)], x=-1..2, t=0..2*Pi, axes=boxed, lightmodel=light1);
> plot3d([x,pl(f,-1,2,10)(x)*cos(t),pl(f,-1,2,10)(x)*sin(t)], x=-1..2, t=0..2*Pi, axes=boxed, lightmodel=light1);
With 10 subintervals, it is already hard to tell the approximate surface apart from the exact one, except perhaps at the narrow neck. (In a moment, we will compute the relevant areas numerically and see how close they really are.)
Here are the same approximations for :
> plot3d([x,pl(g,-3,3,3)(x)*cos(t),pl(g,-3,3,3)(x)*sin(t)], x=-3..3, t=0..2*Pi, axes=boxed, lightmodel=light1);
> plot3d([x,pl(g,-3,3,6)(x)*cos(t),pl(g,-3,3,6)(x)*sin(t)], x=-3..3, t=0..2*Pi, axes=boxed, lightmodel=light1);
> plot3d([x,pl(g,-3,3,10)(x)*cos(t),pl(g,-3,3,10)(x)*sin(t)], x=-3..3, t=0..2*Pi, axes=boxed, lightmodel=light1);
Once again, 10 subintervals seems to give a very good approximation over most of the interval. In this case, the approximation is not so good near the endpoints, and .
Question. Suppose you wanted to find a good numerical approximation to the area of the sphere with as little compuatation as possible. How would you do it? (Just taking more subintervals is not necessarily the answer: your approximation may already be good enough away from the endpoints, so it could be a waste of time and effort to take more subintervals there.)
Now for the hardest part: how do we compute, or at least approximate, the surface areas of the piecewise-linear surfaces? It is enough to concentrate on one subinterval; if we can solve that part of the problem, we will do it for each subinterval and sum the results. On each subinterval, we are rotating a line segment about the -axis, which will give a ring. For example, here is a picture of the ring we get from the 4th subinterval of the 5-subinterval approximation to :
> plot3d([x,pl(f,-1,2,5)(x)*cos(t),pl(f,-1,2,5)(x)*sin(t)], x=0.8..1.4, t=0..2*Pi, axes=normal);
( Maple changes the scale, but notice that the -axis in this picture goes from 0.8 to 1.4.) Now imagine cutting this ring open parallel to the -axis, and laying it out flat. It will be approximately rectangular (especially if the subinterval is very short); the length of the rectangle will be the circumference of the ring, and its width will be the length of the line segment we rotated. The length of the line segment can be found from the distance formula, exactly as we did when we discussed arclength. The radius of the ring is given approximately by the value of at the right-hand endpoint of the subinterval, and so its circumference is times this. Putting everything together, we approximate the area of the ring by
.
Question 3
The following procedure takes a function , an interval , and a number , and returns the -subinterval approximation to the area of the surface of revolution. Use it to find (decimal approximations to) the 5, 10 and 100-subinterval approximations to the area obtained by rotating the graph of the function defined earlier around the -axis. Repeat with the function from Question 1.
> approxarea := proc(f,a,b,n)
> local l;
> l := (b-a)/n;
> sum( 2*Pi*f(a + k*l) *
> sqrt( l^2 + (f(a + k*l) - f(a + (k-1)*l))^2 ), k=1..n);
Solution. To get the decimal approximations, we nust use evalf . (You can try omitting evalf and seeing the exact number computed by approxarea ; it is not very illuminating!)
> evalf(approxarea(f,-1,2,5)); evalf(approxarea(f,-1,2,10)); evalf(approxarea(f,-1,2,100));
Recall that when we drew the pictures, we said that 10 subintervals seemed to produce a good approximation to the surface of revolution. That is partially confirmed by the numbers here: there is quite a big change when we move from 5 subintervals to 10, but a smaller difference when we go from 10 subintervals to 100. Even so, the 2nd significant figure changes in going from 10 to 100 intervals: if you want to be confident that your answer is correct to within 1% (say),
you should definitely try with more subintervals and see if the approximation continues to change.
Similar comments can be made about the approximations we get starting with the function :
> evalf(approxarea(g,-3,3,5)); evalf(approxarea(g,-3,3,10)); evalf(approxarea(g,-3,3,100));
The final step is to recognise that our approximate sums are Riemann sums for some integral, and let . The Riemann sums will converge to the integral, and we can conclude that the integral must give the exact surface area. There is a slight catch this time: the sums we have written down are not obviously Riemann sums. The difficulty is that we approximated the radius of each ring by taking the value of at the right-hand endpoint of the subinterval. This is good enough for numerical work, but as we will discuss in class, it is not good enough for the theory. Nevertheless, our sums do in fact converge as , to the integral
,
so we are still justified in concluding that this integral gives the exact surface area.
Question 4
(a) Compute the exact area of the surface generated by rotating the function from Question 1 about the -axis, by evaluating the integral above (with replaced by ). Compare with the approximations you found in Question 3. How many subintervals are necessary for the approximation to be within 1% of the exact area.
Solution. In principal, the first part of the question just involves translating the integral formula above into Maple syntax. The only possible difficulty is that, according to its help page, Maple 's int command integrates expressions and not functions, so you have to use expression syntax. (You can replace D(g)(x) by diff(g(x),x) if you like.)
> int(2*Pi*g(x)*sqrt(1 + D(g)(x)^2), x=-3..3);
Question. Is the correct answer for the surface area obtained by revolving the graph of around the -axis? Why?
To compare this exact area with our numerical results from Question 3, we should use evalf :
> evalf(36*Pi);
If we want our approximation to be within 1% of this value, it must be between the following two values.
> evalf(36*Pi - 0.01*36*Pi); evalf(36*Pi + 0.01*36*Pi);
Looking back at Question 3, 10 subintervals are not sufficient, but 100 certainly are. With a bit of trial-and-error, you can find that in fact 13 intervals will just work.
> evalf(approxarea(g,-3,3,13));
(b) (Save the worksheet before trying this part!!!) Repeat part (a) for our function . Maple should be able to do this, but on my office machine it took 400 seconds to fail to come up with an answer. Whether or not you choose to try this for yourself, what do you conclude about the usefulness of the integral formula for surface area? If you needed to find the surface area of a reasonably complicated surface of revolution, how would you do it?
Solution. If you try the solution used in part (a), replacing the function with , you will probably find that Maple cannot compute the integral. You might think that using evalf(int(...)) would work, but it doesn't, because with this command, Maple attempts to work out the integral exactly (and fails!) and only then computes the decimal approximation. Your conclusion should be that even though we have an exact integral formula for the area, it is useless because we can't evaluate the integral. (If Maple can't, we certainly can't!) Therefore, to compute a surface area (or, more generally, to compute any fairly complicated integral) we may have to content ourselves with a suitably accurate approximation.
Actually, we can do more. If you have been suitably impressed by Maple 's power to this point, you may be surprised that it cannot apparently evaluate an integral, even numerically. It can, of course, and one way to force it to do so is to use the unevaluated integral command Int . (Note the upper-case I.) You can read about this command on the help page for int , but to see what it does, compare the output to the following commands:
> int(x^2, x=0..3);
> Int(x^2, x=0..3);
Note that int attempts to evaluate the integral, while Int returns the integral unevaluated. This will get around our problem with the function : we can ask Maple to evalf the integral without attempting to evaluate it first:
> farea := evalf(Int(2*Pi*f(x)*sqrt(1 + D(f)(x)^2), x=-1..2));
To be within 1% of this answer, we must be in the interval below:
> evalf([farea - 0.01*farea, farea + 0.01*farea]);
Looking back at Question 3, even 10 subintervals seems to be sufficient fo 1% accuracy:
> evalf(approxarea(f,-1,2,10));
The savings in effort from using fewer intervals is probably not worth the effort spent in looking for the smallest number that will work, but if you like you can check that 7 subintervals gives 1% accuracy and 6 does not.
Final comment and Question. Using Int and evalf together as we did here is really something of a kludge: it works, but it skirts around the real question: how, exactly is Maple managing to evaluate an integral numerically, if it cannot compute the exact answer? What method do you think it is using?
