Introduction to Graphics at the Pittsburgh Supercomputing Center 1. Building a picture 1.1. What graphic libraries are available? 1.2. A comparison of four libraries for a simple task 1.2.1 SMDLIB 1.2.2 DISSPLA 1.2.3 NCARGKS 1.2.4 DI3000 1.2.5 Remarks 1.3. Special features of the libraries 2. Seeing the picture 2.1. Graphics images stored in CGM metafiles 2.2. Display and conversion of CGM files via GPLOT 3. Graphics issues 3.1. Choosing a Package 3.2. Storage and transfer of CGM files 3.3. Animations 3.4. Three dimensional modeling 3.5. Headaches 4. Online documents and examples 5. Exercises 5.1 Display or print images in a CGM file 5.2 Write a program from scratch 5.3 Intermediate exercises 1. Building the picture 1.1. What graphic libraries are available? At the PSC, we have four different graphics libraries of roughly similar capabilities: DI3000, a commercial package from Precision Visuals Incorporated, including the GRAFMAKER line/bar/pie graph and CONTOURING options. DISSPLA, versions 10 and 11, a commercial package from Computer Associates, which includes maps and the engineering option. NCARGKS, a very inexpensive package from UCAR, which includes GKS support, maps, and strong scientific routines in contouring and 3-D plotting. SMDLIB, a "public domain" package, currently being developed at NASA Ames Research Center, which has much in common with the basic DISSPLA package. SMDLIB does NOT have maps, contouring, or 3D plotting. This package is built on top of the PSC DRAWCGM package. Each of these libraries has a full writeup, in DI3000.DOC, DISSPLA10.DOC, DISSPLA11.DOC, NCARGKS2.DOC and SMDLIB.DOC. Each has a set of examples. Each can carry out the basic graphics tasks. But you will find that each has a personality, and perhaps one will be most suited for your work. Other libraries we will not mention further include: DRAWCGM A locally developed graphics package, which is closely related to GPLOT. It can generate CGM or PostScript files, X-Windows or Tektronix screen output. It is a library of routines for simple line graphics, or color cell array display. This is a package suitable for displaying a 2D array of pressures, temperatures, densities, or other scalar quantities that can be color coded. MOVIE6 Version 6 of MOVIE.BYU, which allows you to define 3-D objects and move them from frame to frame. 1.2. A comparison of four libraries for a simple task Just as a starting point in discussing the libraries, let's look at how one hard it is to do one graphical task with each package. The task is to display two line graphs on a single grid, one generated by a function, the other representing a few given data points. We want labeled axes with tick marks, and a plot title. It would be nice to mark the data points as well. 1.2.1 SMDLIB The first library I tried was SMDLIB, mainly because I had just got done typing in documentation for the program, and so I thought I'd like to know if there were flaws in the writeup. Just to remind you of what a graphics program looks like, let me list here the set of calls: CALL PSCCGM <-- start graphics, choose the output device CALL PAGE <-- setup this plot. CALL ORIGIN <-- set the origin of the user coordinate system. CALL SETSUB <-- setup this subplot CALL HEADIN <-- label this subplot CALL XLABEL <-- label X axis CALL YLABEL <-- label Y axis CALL AXES2D <-- define user coordinate system CALL CURVE <-- draw first curve CALL MARKER <-- turn markers on CALL CURVE <-- draw second curve CALL STOPLT <-- done with this plot. CALL FINPLT <-- done graphics. The indentations in the list above are meant to suggest the "level" at which we are. At the first level (PSCCGM/FINPLT) we are entering or leaving graphics mode. At the second, we are defining the shape and size of the whole graphics image, or declaring that the image is done. At the third level, we are specifying a specific subplot. One image or "piece of paper" may have one or more subplots on it, and we are allowed to work on one at a time. SMDLIB (and DISSPLA) both carry out each command when you give it. Thus, if you give a command at the wrong level, you will be told so immediately. You will know what "CALL" statement was in the incorrect place, and what level you should have been at. This is NOT true of DI3000, which we will explain in a minute. 1.2.2 DISSPLA Because I knew that SMDLIB and DISSPLA are very similar, I tried DISSPLA next. In most cases, the calls were identical. The only differences were CALL CGMBO <-- start graphics, choose the output device CALL PAGE <-- set up this plot CALL PHYSOR <-- set the origin of the user coordinate system CALL AREA2D <-- set up this subplot CALL HEADIN <-- label this subplot CALL XNAME <-- label X axis CALL YNAME <-- label Y axis CALL GRAF <-- define user coordinate system CALL CURVE <-- draw first curve CALL MARKER <-- turn markers on CALL CURVE <-- draw second curve CALL ENDPLT <-- done with this plot CALL DONEPL <-- done graphics In some cases, the routine names were the same, in others the names were different but the arguments were the same. In only one case, "CALL CGMBO", were the arguments different. Interestingly, the graph did not come out the same! The main problem was that DISSPLA didn't think there was enough room for the title, so it just left it out. I had to modify the problem to move the graph down a bit in order to get the title onto the plot. The other problem with DISSPLA is complicated. It doesn't involve the program itself, but the tricks that have to be done to display the graphics file once it's been created. So we'll talk about that later. I would repeat, though, that the way DISSPLA is used to build a picture strikes me as fairly natural and understandable. 1.2.3 NCARGKS I asked a friend, Debbie, to do the NCAR example, and I must confess that she was swearing up and down at NCAR while I swore at DI3000. In order to do the graph, Debbie used a special library called AUTOGRAPH, which is the part of the NCARGKS package which does line graphs. The way AUTOGRAPH works is that it already has a set of default options chosen, and to draw your graph you change the options you don't like, and supply the data that goes on the graph. You communicate with AUTOGRAPH mostly by calling one of the option setting routines, AGSETF for an option involving a REAL value, AGSETI for an INTEGER value, or AGSETC for a CHARACTER value. Thus, instead of calling a routine named, say, "AXES2D" to choose linear X and Y axes, with arguments XMIN, XMAX, YMIN, YMAX to define the beginnings and ends of the axes, you make calls to AGSETF('X/MINIMUM.',0.0) to set the X minimum to 0.0, and so on. Only when you have made all your choices do you go ahead and draw the graph. The good news is that it is very easy to set up a graph, because you can just choose options, one after another, in any order you like. The program does not care very much what order you choose. The bad news is that the idea of option choosing is not very natural. It can be difficult (it was for Debbie!) to get used to the idea of looking through the manual, trying to find the option you want to pick to get something to happen. It is not easy to design a package to work this way, and it certainly isn't easy to use! While I don't want to overstate my case, here are the subroutine calls that Debbie had to make. Of necessity, I will include the input arguments to the subroutines: CALL OPNGKS <-- Start graphics CALL AGSETF('FRAME.',2.) <-- Allow me to superimpose 2 curves CALL AGSETF('X/MINIMUM.',0.0) <-- Define XMIN, XMAX, YMIN, YMAX CALL AGSETF('X/MAXIMUM.',5.0) for axes. CALL AGSETF('Y/MINIMUM.',-10.0) CALL AGSETF('Y/MAXIMUM.',60.0) CALL AGSETF('GRID/TOP.',.85) <-- Use inward facing tick marks CALL AGSETC('LABEL/NAME.','B') <-- Label the bottom axis CALL AGSETI('LINE/NUMBER.',-100) CALL AGSETF('LINE/CHARACTER.',.03) CALL AGSETC('LINE/TEXT.','Days$') CALL AGSETC('LABEL/NAME.','L') <-- Label the left axis CALL AGSETI('LINE/NUMBER.',100) CALL AGSETF('LINE/CHARACTER.',.03) CALL AGSETC('LINE/TEXT.','Number of cases$') CALL AGSETC('LABEL/NAME.','T') <-- Define the position of the plot CALL AGSETI('LINE/NUMBER.',100) title. CALL AGSETF('LINE/CHARACTER.',.04) CALL EZXY(X,Y,NPTS,'NCARGKS Demo plot$') <-- Draw the first curve, with a title. Normally this would be a complete plot, but we told the package to wait. CALL POINTS(X,Y,NPTS,111,1) <-- Draw another curve, with markers. CALL FRAME <-- Now the plot is done. CALL CLSGKS <-- Now graphics is done. Got that? It looks easier than it is! Debbie tried to increase the size of the markers, following directions, but couldn't. She had a lot of trouble getting the title to appear in the right place and in the right size. Amazingly, the more complicated plots are much, much easier with NCAR! 1.2.4 DI3000 CALL JCHINI <-- Begin graphics CALL JCHART <-- Begin the definition of an image CALL JXLINE <-- Define a line style CALL JGRAPH <-- Begin a line graph CALL JSTVAX <-- Label the vertical and CALL JSTHAX horizontal axes CALL JSTNOT <-- Define a plot title, and its position CALL JPONOT CALL JRDATA <-- Define three sets of data, the X values, and the CALL JRDATA Y values of the first and second curves. CALL JRDATA CALL JINDEP <-- Use the X values as the independent data. CALL JDEPEN <-- Define the first curve using X, and Y1. CALL JDEPEN the second curve using X, and Y2. CALL JDTATR <-- Define the line style used to draw the first CALL JDTATR and second curves. CALL JCHSHW <-- Display the image as it is defined so far (We could see other interim versions of the image by repeating this call earlier) CALL JCHTRM <-- Done graphics Notice how DI3000 is not so much a "procedural" language. You don't "do" things so much as "define" them. Thus, we have to define all the data sets we're going to use (X, Y1 and Y2) and only later build curves out of them. A frustrating feature of DI3000 was the fact that you are only allowed one independent (X) data set! That's fine if all your curves use the same X values, but in fact the example I had chosen doesn't. I had to go to considerable work to get both curves to show up, and I am not happy with the result! Another problem I had was that at first I did not understand what I was doing, and I got some error messages. The errors were caused by calls I made early in the setup, but the error message was not printed out until I called JCHSHW, by which time DI3000 could not really give me any information about when I had made the bad choice. 1.2.5 Remarks Note that this comparison is not fair or typical. Once you've used a graphics package for a while, you get accustomed to it. You can use some routines over and over, with minor adjustments. So it may not matter so much that it's hard to learn. Also, this comparison used the most basic part of each package. It did not test some of the best features of the packages, such as contouring, maps and so on (we'll get to them in a minute!). But it may give you a feeling for how different each package is, and how much trouble it may be to do what you want if you don't have good documentation or examples! 1.3. Special features of the libraries NCARGKS was developed at the National Center for Atmospheric Research. It was originally used for graphics of weather. The package was used by the same scientists who did the computations. For these reasons, NCARGKS has strong abilities in mapping, contouring, and three dimensional graphics. It also is set up to easily build animations, or to overlay one type of graph on another, such as adding a vector field to a world map. Also, because of its technical origin, the package assumes that its users may want to try to experimenting with the program, altering its behavior or trying new fonts and so on. The documentation include details for how to get extra performance out of the package using COMMON block variables, or special subroutine calls. As I mentioned earlier, the clumsy behavior of the AUTOGRAPH package used to make the NCARGKS example graph is deceptive. To draw some of the more interesting graphs in NCARGKS takes only three or four subroutine calls. For instance, once you've set up the data, you can get a basic streamline, velocity vector, or three-dimensional plot with a single subroutine call. All the axis labeling, scaling, and marking are done automatically. Another advantage of NCARGKS is its very low price, on the order of a $300 one time fee. The price includes source code, test examples, and a set of manuals. Typical prices for DISSPLA and DI3000 are $20,000 to $60,000, per year, and you don't get source code, and you can only install those packages on machines that you register with the company, and it costs more every time you buy a new machine. DI3000 is a package with special attraction for advanced users. It is not a "procedural" but rather a "descriptive" approach. You define sets of data, you define curves based on that data, you set up line styles and so on. At any time, you can get a "snapshot" of what you have defined, but until you ask for such a snapshot, the graph is not really drawn. This takes some getting used to, and in particular, if you do something wrong, you won't find out until you try to display the graph. You'll get a message like "undefined curve type", but you don't know when you asked for this undefined curve. Debugging can be difficult! On the other hand, once you have defined your graph abstractly this way, it is very easy to create a new graph out of some of the old pieces, or to create an animation, where each image uses most of the same information. DI3000 is very strong in having interfaces to specific types of graphics devices, such as a mouse, cross hairs, digitized tablet, light pen, or keyboard. DISSPLA is the most widely available graphics package. The manual is good and easily available. The basic package includes fonts, blanking, 3-D graphics, and there are a wide range of (expensive) options such as maps, contours, object rendering, business graphics, and so on. DISSPLA is a "procedural" library which constructs a graph by calling subroutines which carry out actions. You don't get source code, which can make it hard for a site to adjust the code to local conditions. I must mention that we have had a lot of difficulty dealing with the company that sells DISSPLA. SMDLIB was designed to do some of the same work that DISSPLA does. So it inherits some of DISSPLA's advantages. It is a "procedural" library, with a fairly natural way to build a picture by calling subroutines to carry out actions. It is not a commercial product. The good news is that that means that we can give SMDLIB and its documentation away. The bad news is that there is no toll free number to phone up and complain about. There is not yet a set of routines for plotting maps, contours, or 3-D plots. And there is no staff of people to write versions of the library for new machines. If you want to install it, you may have some work to do yourself. 2. Seeing the picture Once you've written the calling program, linked the graphics library, and started the program running, a CGM file should be created containing your graphics output. That's only half the job. Now we have to discuss ways of getting those images onto the screen. The PSC has tried to simplify the graphics environment by supporting only one type of graphical output: the CGM metafile. The PSC also provides an interpreter program, GPLOT, which can read a CGM metafile and display the graphics in it to a screen, or create a copy suitable for printing on a graphics printer. 2.1 The CGM standard Sometimes standards come along at the right time. The "Computer Graphics Metafile" standard, or CGM, is a graphics standard that can solve many of the problems of incompatibilities of software and display devices. The CGM standard describes the format of a file which contains the information that specifies one or more graphics images. If you can figure out how to get every piece of software to generate CGM output, and how to get every piece of hardware to display as much as it can of a CGM file on command, you have vastly simplified the problem of graphics display. You only have to write one interface per library, and one device driver per device. 2.2 Display and conversion of CGM files via GPLOT GPLOT is a locally developed utility program, written in C, which can display or manipulate CGM files. GPLOT is available on both the VMS front ends and the Cray, and we distribute copies of the source code to our users and any interested people. GPLOT understands the information in a CGM file, and can display one or more of the images stored there to a terminal, or it can create another kind of output file. The most common output devices used are PostScript files and Tektronix screens, but other options available include DEC/GKS, Peritek, Silicon Graphics Iris, Sun, UIS and X-Windows. GPLOT can also convert a CGM binary file to clear text mode, and vice versa. A particular version of GPLOT will have only a selection of these devices available, chosen by the person who installed the package. The typical user of GPLOT logs in on the PSC VAX with a Tektronix emulating terminal. The user has a file named "MYFILE.CGM" which is a binary CGM file containing many images. The user types GPLOT/SCREEN=4010 MYFILE.CGM and the first image is displayed on the screen. The user can hit return repeatedly to see the succeeding images. If the user wishes to make a PostScript version of the entire file, the command GPLOT/DEV=PS MYFILE.CGM will create a PostScript file "MYFILE.PS". Similar commands can be used if the user is logged in on UNICOS and working there. One useful feature of GPLOT is the ability to view only particular images from a file. For example, the command GPLOT/SCREEN/PAGES=(1,5,20_35) MYFILE.CGM would display only the first, fifth, and twentieth through thirty-fifth of the images in the file. 2.3 How CGM and GPLOT are used at the PSC You should not run large programs interactively on the Cray. This is doubly true for large programs which include graphics. Graphics routines are often not very efficient on the Cray, and a single run of a large inefficient graphics program could cost you a lot! Hence, we encourage users to run programs in batch, and either to dump their graphics into a CGM file, or perhaps to dump their data at the end, transfer that to the front ends, and do interactive graphics there. 3. Graphics issues 3.1. Choosing a package Some of our users come to us with programs that already use a particular graphics package, and for them, it's too late! But for those of you who are just starting out, you're free to pick a package that suits your personality and programming needs. The most important feature a graphics library can have is usability. Most people are using graphics as part of a larger job. They don't have a lot of time to invest, and they are frustrated when simple graphics tasks become impossible to carry out. If you're doing only simple line graphics, SMDLIB or DISSPLA is a best bet. For simple examples of scientific graphics (contours, 3D and so on) NCARGKS is the best. You should also test drive each package for "naturalness". I hope you've gotten a feel for the fact that the packages have different approaches to building a graph. You really ought to make sure you can work with the style and abilities of a package. Another important thing to check is the documentation. We have some documentation on line for every package, but it is abbreviated. The online documentation is not going to be able to guide you into the details of how to use a subroutine, if there's any doubt. So if you're doing a lot of graphics, you'll really want to have access to a manual. Your local site may have such manuals, but otherwise you may need to order them from the company. There's a tradeoff between ease of use and power. For example, when you're putting a title on your graph, some packages allow you to pick a font, pick a font size, pick a font style, pick a font angle, specify centering or justification and so on. That's nice, but suppose you're in a hurry? Suppose you pick a stupid value for one of the parameters and your title never shows up? Some packages allow you to use a simple call, with default values, for most uses, so that you only have to learn about things one at a time. Another issue is cost. Even though you don't pay for our copies of software, you might be interested in getting a copy for your local site, or for your own machine, say a Sun workstation. Graphics software can be very expensive. It is not at all unusual to pay between $20,000 to $50,000 per year for one package, for a machine like the VAX. And then of course, the "extra features" like fonts, maps, and contouring are extra! If money is a concern for you, forget DI3000 and DISSPLA. Order a copy of NCARGKS for a few hundred dollars, and ask us for free copies of DRAWCGM, SMDLIB and GPLOT. You even get source code and online documentation. If you haven't committed to using a particular graphics package, I would strongly urge you to try to do some exercise like the one I did above. It's much better to test the packages on a simple problem, so you can bail out fast if necessary. 3.2. Storage and transfer of CGM files Once you've created a CGM file, what do you do with it? Well the first thing to worry about is its name. With some of the packages, such as DISSPLA, you can specify the name of the output file, and with others, like NCARGKS, you don't have a choice. NCARGKS always makes a file named "GMETA" on UNICOS, or "GMETA.DAT" on VMS. I would suggest that if you can pick the name of your file, you always give it an extension of "CGM", and if you can't, you rename it to have such an extension once the file has been created. This will be of a great deal of help in keeping your work organized. The second thing to worry about with a CGM file is its format. The most common CGM format is binary. It's not printable, and it can't be transferred like a text file. KERMIT, FTP, and the VMS-Cray station each need to be warned that you have a binary file to transfer. In the case of FTP, you simply give the command "BINARY" or "IMAGE" depending on the FTP you are using. Then you give the usual FTP "put" or "get" command. With the Station, assuming you are copying from the Cray to the Vax, the typical dispose command would be something like this: dispose myfile.cgm -f TR -t 'myfile.cgm/norat/rfm=fix/mrs=512' where the items after the slashes are messages to VMS telling it how to treat the file once it receives it. The "MRS=512" is specifying a maximum record size of 512 bytes. For NCARGKS files, this must be changed to "MRS=1440". If you simply want to store a CGM file in CFS, you don't have to do anything differently than for a text file. So a typical command might be cfs store myfile.cgm Also, when copying from one VMS machine to another, no special commands have to be given to take care of the binary format. You can use GPLOT to convert a CGM file into a PostScript or CGM cleartext file. Both of these file formats are "text". That is, you can print, type, or edit these files. They are also, therefore, easier to transfer from one system to another. However, the price you pay for this is that both files will be much larger than the original CGM binary file. 3.3. Animations At the PSC, it is possible to create a movie or "animation" of your graphics. You can store all your work in one or more CGM files, and have all or some of the images in those files transferred to a VHS tape. All transactions are carried out by VMS mail. This means that you can make animations remotely, and at any time. The transfer process requires that at least one UMATIC and one standard VHS tape be set aside for your work. To take care of this, you just send mail to a special address and the proper billing is made. Thereafter, when you're ready to create an animation, you just run the ANIMATOR program. The ANIMATOR program does not create the animation, but rather a command file that describes what images are to be extracted from the CGM file and placed on tape. 3.4. Three dimensional modeling The PSC has been developing a file standard for the storage and retrieval of three dimensional graphics objects. The "P3D" metafile system is just being made public now. What we have made available so far includes routines to create such files from data, to display pictures from such files, and to convert MOVIE.BYU files to this format. Remember that a CGM file, for example, can contain a two dimensional image of what is meant to be a 3D objects. But that is only one view point of the objects, and you could not use that information to draw another image of the same objects from a different angle. By only defining the actual 3D objects in the file, the user can interactively choose to move the view angle and distance from the center, and in effect "fly" around or through the set of objects. 3.5. Headaches We'd all be out of a job if there weren't any problems. Never fear, there are plenty of them! In particular, the four main graphics libraries we have installed each come with maddening flaws. DI3000: A) Generates PVI metafiles, which must be converted to CGM. B) Front end only on CPWSCB. C) We have the contouring option, but no 3D, maps, streamlines or vector plots. DISSPLA: A) Version 10.01 on UNICOS, 10.5 and 11.0 on VMS. B) Front end only on CPWSCA. C) No direct CGM capability on UNICOS, consequences are very tedious. D) DISSPLA 10.01 and 10.5 use Holleriths to store character data. NCARGKS: A) CGM metafiles are slightly irregular (1440 bytes, rather than 512). These can be more difficult to transfer over some networks. B) The package is elaborate, and sometimes not well thought out. For example, you can get quick, regular or super contour plots. But rather than having an option you specify, or a parameter you set, the authors supply you with three sets of routines, all having the same name, and suggest you put the regular routine in the NCARGKS library, but set up two small alternative "quick" and "super" libraries, which you can choose at load time if you know how! SMDLIB: A) While the package is meant as a replacement for DISSPLA, there are many capabilities it does not have, such as contouring, 3D, maps, vector plots, and streamlines. A heavy DISSPLA user will not be satisfied. (The authors promise more routines soon!). B) The use of Holleriths to store character data was a very bad choice. C) The linking procedure can be very awkward on a VAX unless a symbolic abbreviation is used. 4. Online Documents and Examples For most graphics topics, the PSC has provided the following information: Online help, accessible on VMS or UNICOS by typing "pschelp topic" Online documentation, accessible on VMS as "pscdoc:topic.doc" and on UNICOS in the CFS directory "/usr/local/doc/topic.doc". Online examples, including job control language, calling programs, log files, and output CGM files, available on VMS in directories named "doc$root1:[examples.topic]" and also accessible by typing "setup examples" and then "examples topic", and available on VMS in the CFS directory "/usr/local/examples/topic". The topics treated in this way include: The graphics libraries DI3000, DISSPLA10, DISSPLA11, NCARGKS and SMDLIB. Other graphics programs such as CODEBOOK, IMAGETOOL, MOVIE5 and MOVIE6 (versions of MOVIE.BYU) and PLOT10. The locally produced CGM utilities DRAWCGM, GPLOT, GTEX, and the three-dimensional graphics metafile format P3D. The PSC ANIMATION system. Applications programs which include a CGM interface, including ABAQUS, ANSYS, ELLPACK, FIDAP45, TAURUS and many others. 5. Exercises There is no substitute for learning by doing. Just to get a picture to show up on your terminal screen or plotter tests many different components of the computing environment. To write a simple program from scratch can give you a good understanding of what you're up against when trying to display data. And to try to improve the basic graphics output will show you whether the graphics library is on your side or not! 5.1 Display or print images in a CGM file Copy a CGM file from the CGM or NCARGKS EXAMPLE directories to your own account. If you have a graphics terminal, try to display the image on your screen. If you have access to a PostScript printer, try to a PostScript file to print out. Here, for example, is a set of commands that a user might give who was logged in to UNICOS on a Tektronix or Tektronix-emulating terminal: cfs get /usr/local/examples/cgm/dna.cgm gplot -stek dna.cgm and here is how a user might create and print a PostScript image on VMS: $ COPY DOC$ROOT1:[EXAMPLES.NCARGKS2]TCONRE.CGM * $ GPLOT/DEV=PS TCONRE.CGM $ PRINT/PARA=DATA=POSTSCRIPT TCONRE.PS <-- Don't do this! You must move the file TCONRE.PS to some machine where you have access to a PostScript printer! 5.2 Write a program from scratch If you flip a coin many times, the number of heads minus the number of tails tends to 0. You can generate a jagged curve that records the running value of (heads-tails) by code like this: SUM=0.0 DO 10 I=1,N TEMP=RANF() <-- RANF is the Cray's random number generator. IF(TEMP.LT.0.5)THEN SUM=SUM-1.0 ELSE SUM=SUM+1.0 ENDIF X(I)=I Y(I)=SUM 10 CONTINUE Now plot the points X(I), Y(I) for I=1 to N, using any graphics package you like, with N=100 or 500. For fun, you might also set Z(I)=SUM/SQRT(REAL(I)). Z records the typical size of fluctuations of SUM away from the value of 0. In other words, after 100 coin flips, the number of heads minus tails is typically between 10 and -10. First generate a graph with N=100. This will probably not be too interesting. Then try N=10,000. This graph may take too long to generate or display. In that case, it turns out, you might want to plot just every 20-th or 50-th point, for example like this: SUM=0.0 J=0 DO 10 I=1,N TEMP=RANF() <-- RANF is the Cray's random number generator. IF(TEMP.LT.0.5)THEN SUM=SUM-1.0 ELSE SUM=SUM+1.0 ENDIF IF(MOD(I,20).EQ.0)THEN J=J+1 X(J)=J Y(J)=SUM ENDIF 10 CONTINUE and then plot X(I), Y(I), for I=1 to J. 5.3 Intermediate exercises The following exercises are offered for further work with graphics packages. Don't do them all! You may find one or two that are related to your own work. Be sure you use a package that can handle your project! Repeat the previous exercise using a different package. Repeat the previous exercise, by getting a set of 25 data points X(I) and Y(I), and plotting them. But now, also find a routine in your library that passes a smoothed curve, polynomial or spline through the data. Plot that too. Try to draw a polar plot, complete with grid lines, of R=1+SIN(THETA). Try to draw a pentagon. Now see if you can shade the interior of the pentagon, or color it. Can you draw a plot where Y is not a function of X? For example, can you set up the data points X(I)=COS(T)**3, Y(I)=SIN(T)**3 for 50 points from T=0 to 2*PI? Draw a field of vectors, representing the direction field of an ordinary differential equation, y'=-y+sin(x). In other words, at every integral point (X,Y) with 0 <= X <= 2*PI, and -2 <= Y <= 2, draw the vector (1, -Y+SIN(X)). Draw a set of contours for the function Z=SIN(X**2 + 4*Y**2), say in the box -4 <= X <= 4, -4 <= Y <= 4. You can also try to get a "3D" view of this function. You will probably find this to be a much more difficult exercise than to do the contours. You must pick a point of view, and you will find the picture very confusing if the graphics package can't handle hidden portions of a graph.