780.20: 1094 Session 15

Handouts: "Three-Dimensional Plots with Gnuplot", "Using the GDB Debugger", printouts of eqheat.cpp and square_test.cpp

Today we'll look at a couple of small topics and then allow time to work (and ask questions) on your projects.

Your goals for this session:


SET's: Course Evaluations

Thank you in advance for your comments, which are invaluable in planning future versions of this computational physics course. Some things I'd appreciate comments on:

  1. Please comment on the pace: too fast, too slow, not enough depth?
  2. Do the background notes work? (Do you need them further in advance?)
  3. Any topics you would omit? Any ones you would spend more time on? Any topics not covered you think should be covered?
  4. Do you think I should choose a text to go along with the course, even if we don't follow it closely? (Suggestions?)
  5. Would it be better to spend more time on C++ programming (e.g., C++ classes)? If so, what would you cut to make time for this?
  6. If you had a choice between computational physics courses taught entirely with Mathematica, entirely with C++, or entirely with Matlab, which would you choose? Or do you think a mix is more useful?
  7. As always, suggestions for improvements to any aspect of the course would be appreciated.

3-D Plots with Gnuplot

We have frequently used Gnuplot for visualization, but we have only considered two-dimensional plots. Now we will want to make three-dimensional surface plots of functions and data.

  1. Follow through the handout on "Three-Dimensional Plots with Gnuplot".
  2. Figure out how to make a parametric plot of a sphere using trigonometric functions. To plot a 2-d circle, you would type:
      gnuplot> set parametric
      gnuplot> plot [0:2*pi] sin(t),cos(t)
    (hint: think spherical coordinates).
  3. Take a look at the eqheat.cpp code and guess at what it is doing. Compile and link it using make_eqheat and then run it to generate eqheat.dat. Look at eqheat.dat and then plot it with gnuplot, using the comments in the code and the handout as guides. Interpret the plot for your partner (and play with the output a bit). What equation is being solved? [You can take a look at laplace.cpp as well, which generates a similar looking plot for a different physical situation.]




Squaring a Number

One of the most common floating-point operations is to square a number. Two ways to square x are: pow(x,2) and x*x. Which is more efficient? Is there an efficient alternative?

  1. Look at the printout for the square_test.cpp code. It implements these two ways of squaring a number. The "clock" function from time.h is used to find the elapsed time. Each operation is executed a large number of times (determined by "repeat") so that we get a reasonably accurate timing.
  2. Create a square_test project and run it. Adjust "repeat" until the minimum time for each is at least 0.1 seconds. Which way to square x is more efficient?



  3. If you have an expression (rather than just x) to square, coding (expression)*(expression) is awkward and hard to read. Wouldn't it be better to call a function (e.g., squareit(expression)? Add to square_test.cpp a function:
    double squareit (double x)
    that returns x*x. Add a section to the code that times how long this takes (just copy one of the other timing sections and edit it appropriately). How does it compare to the others? What is the "overhead" in calling a function (that is, how much extra time does it take)? When is the overhead worthwhile?



  4. Another alternative, common from C programming: use #define to define a macro that squares a number. Add
    #define sqr(z) ((z)*(z))
    somewhere before the start of main. (The extra ()'s are safeguards against unexpected behavior; always include them!) Add a section to the code to time how long this macro takes; what do you find?



  5. One final alternative: add an "inline" function called square:
    inline double square (double x) { return (x*x); };
    that is a function prototype and the function itself. Put it up top with the squareit prototype. Add a section to the code to time how long this function takes. What is your conclusion about which of these methods to use?



  6. Finally, we'll try the simplest way to optimize a code: let the compiler do it for you! Change the compile flag -O0 (no optimization) to -O3 (that's the uppercase letter O, not a zero). Recompile, link, and run the code. How do the times for each operation compare to the times before you optimized? (Increase repeat to make all times above 0.1 seconds again.)



  7. In your project programs, once they are debugged and running, you'll want to use the -O3 optimization flag. Note that there are other options you can learn about using man g++.

780.20: 1094 Session 15. Last modified: 10:17 pm, March 05, 2007.
furnstahl.1@osu.edu