NCAR/TN-174+IA Selected User Reference Papers

Home , Film speed

NCAR/TN-174+IA NCAR TECHNICAL NOTE ------l------I-----.~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ June 1981

Selected User Reference Papers

Editor: Gregory R. McArthur

SCIENTIFIC COMPUTING DIVISION NATIONAL CENTER FOR ATMOSPHERIC RESEARCH BOULDER, COLORADO Preface

This slim volume represents an amalgam of different user experiences with the NCAR Graphics System. Each of the papers presented herein contains some special application or use of the Graphics System (or its siblings) which may be of interest to other users of the system. Authors (if known) are listed with each of the papers in the Table of Contents. There are no page numbers, per se, as the collection of papers is sufficiently diverse to warrant presenting each of them as separate entities.

We hope the user will find this collection of Selected User Reference Papers helpful in tailoring various aspects of the NCAR Graphics System to your own unique needs. SELECTED USER REFERENCE PAIERS

A Guide to Making Movies at NCAR...... MAKING MOVIES-1 By: Fred Clare and David Kennison

A Portable Device-Independent FORTRAN Graphics System...... GRAPHICS SYSTEM-1 By: Lofton Henderson

Generating and Plotting Graphics Text at NCAR...... GENERATING AND PLOTTING-1 By: Fred Clare 1 PRFILM...... PRFILM- By: David Kennison

Printer Simulation on the Diccmeds ...... l...... PRSIM-1 By: Fred Clare Remote Job Entry Graphics...... RJE GRAPHICS-1 By: Fred Clare

The Metacode Translator MC2DD80B ...... MC2DD80B-1

The Production of Scientific Films Using a Digital Computer and Optical Output Device ...... FILM PRODUCTION-1 By: Thomas Wright

Using Metacode ...... USING METACODE-1

Using the Dicaned Off-line...... DICOMED-1 MAKING MOVIES TITLE A Guide to Making Movies at NCAR

GENERAL (XCENTS 1. This guide is meant to complement the article "The AND SIGESTIOIS Production of Scientific Films Using a Digital Com- puter and Optical Output Device" (also in this manual) which is more general in nature. The potential movie-maker should read both articles.

2. After reading this guide, the first thing to do is to talk with the personnel in the film room (room 18), particularly if you are going to make a color movie. They will probably have some good ideas on how to make your movie interesting, appealing, etc. Also, they would like to know what sort of additional work load is in store for the film operators, what kind of schedule you have in mind, etc. 3. Remember that almost all movie projectors run at 24 frames per second. This fact should be used in es- timating the time-sequencing in your movie. Getting the action in your movie to look right is not trivi- al, and may take several attempts. 4. NCAR presently has three COM (Computer Output to Mi- crofilm) devices. One is a CDC dd80 cathode ray tube plotter which produces 35mm microfilm. Another is the Dicomed D48 high resolution multipurpose graphic film recorder which produces 35mm or 16mm microfilm. The third is the Dicomed D48 film recorder which produces 105mm microfiche in either 24x or 48x format. The two Dicomed film recorders are presently run completely off-line; metacode is produced on tape and then run on a separate system to produce film. A document describing the usage of the D48's is available in the SCD Documentation Room. Within the next year or two, the D48's will replace the dd80, but right now it is much easier to use the dd80 for any movie work since the dd80 is faster and does not require a separate job submission to process metacode.

5. Create a test strip of 35mm microfilm containing about 300 to 500 frames of your movie. This should be run as a completely standard job, with standard microfilm output on the dd80. Don't forget to specify the appropriate frame limit on your *LIMIT card since the default limit is 100 frames. For reasons described below, this test strip should have a leader and trailer, each consisting of about 50 frames. To prevent the operators from cutting the

MAKING MOVIES - 1 leader and trailer off, these should not be blank frames. A good technique is to put the words "LEADER" and "TRAILER", as appropriate, on each frame, using the largest possible PWRIT letters. This test strip can also be used to get an estimate of the final cost of making your movie.

6. Frequently, one interpolates between data points to create the large number of frames necessary for a movie. If you use linear interpolation to get lots of frames between points (more than 50, say), it can happen that the original data points become noticeable as transitional points in the action of the movie. This problem can usually be solved by using a 1-2-1 smoother on three points, or some more complicated scheme.

7. If certain features are common to many or all frames in the movie, you should use the graphics utilities FLASHT, FLASH2, FLASH3, and FLASH4. These routines are described in the "SCD Graphics Utilities" manual.

8. Points present difficulties. They may appear very faint. Remedies for this are to draw them several times, or use the graphics routine OPTN to increase the plotter intensity before drawing the points.

9. To familiarize yourself with the graphics software available at NCAR, consult the Library Catalogue in the SCD Consulting Office, and the NCAR Graphics Software Manual.

10. In the film room there is a small projector termed a Movieola with a screen about 5 inches square. This device accepts reels of 35mm film up to 2000 feet in length. Adequate leaders and trailers are necessary if all of the good part of the film is to be viewed (hence the suggestion above for leader and trailer frames in the test strip). Take your test film into the film room and tell them that you would like to view it on the Movieola. The Movieola is automatic, and the film speed can be varied, in a continuous manner, from 16 frames per second to 30 frames per second. You can use this device to view the effects of speeding up or slowing down the action.

11. After viewing the 35mm test run, you may want to adjust the speed, lettering, etc. 12. Next, if it's not too expensive, you should do a second test. Run the program which will produce the entire movie, but instrument it so that only every

MAKING MOVIES - 2 n-th frame is actually produced. Choose n so that a representative sampling of what's going on is obtained (typically an n of 100 works well). Examine this film closely to see if the process being dep- icted behaves as you expect, and that the program is working properly.

13. You will probably want to put titles and explanatory information somewhere in the movie. Text may appear as a fixed frame which remains on the screen for a certain amount of time, or it may be scrolled from the bottom of the frame to the top. As a general rule-of-thumb allow about 2 seconds of movie time (48 frames) for each line of text you expect the viewer to read. It is necessary to have only one frame for a fixed title if you are going to produce a color movie (this frame is photographed and copied), but for a black and white movie, put in enough frames to keep it on the screen the desired amount of time. Also, somewhere in the movie you must give credit to NCAR. This usually takes the form of:

This movie was produced at The National Center for Atmospheric Research Boulder, Colorado

NCAR is sponsored by The National Science Foundation

you want to have nice scroled iit es use the ULIB routine SCROLL (this routine can be costly to run, however). After all the titling and explanatory materials are in, make a new test strip, or strips, and view the results again.

14. After you are satisfied with the test runs and are sure that everything is as you want it, prepare and submit the final runs. Since movies typically require thousands of frames, it is a good idea not to create the entire movie with one run, since unexpected errors can be costly. Take advantage of natural breaks (between titles, between different portions of the action, etc.) and create separate, smaller, segments. These can easily be spliced together in the film room. Be sure to specify the appropriate limits on the limit card; e.g., a 10 minute movie will run through 14,400 frames. Before making the final production runs, inform the film room of what you are about to do. They may want to tune the microfilm device for you and make sure there is adequate film in the magazine (a full magazine has about 15,000 frames). You should inform

MAKING MOVIES - 3 the operators that you are submitting these jobs so they will not be concerned about the huge number of frames coming out.

15. Make sure that the final version is produced within a day or two since the tuning on the microfilm devices will vary over a period of days; plots produced on a given day do not look exactly like those produced a few days later. This would cause a slight, but noticeable, discontinuity in the final version.

16. You will almost certainly have to put the dd80 "on line". The normal "off-line" mode of operation causes your plotting instructions to be saved in a buffer and automatically flushed to the dd80 at job termination. If too many plotting instructions are issued, this buffer overflows, causing job termination. With the dd80 on-line, instructions are flushed to the dd80 as they are issued. To put the dd80 on line, see: NCAR Computing Facility Notes #39, p7. 17. When you have the completed 35mm film, examine it to check that it is as you want. Currently, the Di- comed 16mm capability is not being used for movie making. To get a final 16mm version, go to the film room and tell them what you want. They will send it out (to Colorado Springs), and it may take from 10 days to two weeks to get the final 16mm version.

18. While not absolutely necessary, it may be a good idea to make a script showing what's in each segment of the movie, how long each segment is, what order they are in, how much gap is left between them, etc. This script can make splicing much easier for both you and the film operators, and it is a good organi- zational tool. For an example of such a script, see the last page of this guide.

MAKING MOVIES - 4 pecial Problems 1. The techniques for making movies on the CRAY-1 are on the CRAY-1 essentially those described above except that there are additional difficulties. There are several default limits on jobs coming back to the CDC 7600 from the CRAY-1: no more than 1000 dd80 frames may be produced; no more than 10 million CRAY-1 words of plotting instructions may be created; no more than 59 seconds of 7600 cpu time may be spent on metacode translation; no more than 36 seconds of 7600 ppu time may be spent on metacode translation. Since the film devices cannot be put "on-line" with the CRAY-1, these limits cause difficulties with producing large quantities of film with a single CRAY-1 run. The metacode-to-dd80O translator (program MC2DD80B on XLIB) can be run with the dd80 on-line. See the write-up of MC2DD80B, available from the SCD Consulting Office.

Using Color 1. Even though we have no in-house color capability (color wheels do exist for the D48's, but we do not have them), color is still possible. The technique is to produce a separate movie for each color desired, making sure that each such movie has exactly the same number of frames.

2. Proceed as above, and at the step where we have to send out for the final 16mm movie, we can also specify the color requirements.

3. Color is a little tricky. When two colors merge it frequently happens that white will result. Color can be frustrating and expensive for several reasons: it is often difficult to make completely accurate predictions of the final outcome; the turnaround can be up to 2 weeks; enormous quantities of film are required.

4. Check with the film room before starting any film.

MAKING MOVIES - 5 Example of a movie script

MOVIE FOR VLADIMIR ALEKSANDROV

DESCRIPTION OF MOVIE PORTION SECONDS FRAMES COMMENTS - - -_ _ -_ -______

1) TITLE FRAME ...... 8.0 192 (4 lines of text)

2) 1/2-SECOND GAP ...... 5 12 (blank frames)

3) DESCRIPTIVE TEXT ...... 20.0 480 (10 lines of text) 4) 1/2-SECOND GAP ...... 5 12 (blank frames)

5) CREDIT FRAME 1 ...... 8.0 192 (4 lines of text) 6) 1/2-SECOND GAP ...... -5 12 (blank frames)

7) CREDIT FRAME 2 ...... 8.0 192 (4 lines of text) 8) 1/2-SECOND GAP ...... 5 12 (blank frames)

9) CREDIT FRAME 3 ...... 6.0 144 (3 lines of text) 10) 1-SECOND GAP ...... 1.0 24 (blank frames) 11) MOVIE SEGMENTS 1 THROUGH 4 WITH NO GAPS ...... 846.5 20316

12) 1-SECOND GAP ...... 1.0 24 (blank frames)

13) MOVIE SEGMENT 5 ...... 137.5 3300

14) 1-SECOND GAP ...... 1.0 24 (blank frames)

15) END FRAME ...... 2.0 48 (1 line of text)

TOTALS ...... 1041.0 24984

MAKING MOVIES - 6 GRAPHICS SYSTEH

TITLE: A PORTABLE DEVICE-INDEPENDENT FORTRAN GRAPHICS SYSTEM

AUTHOR Lofton Henderson National Center for Atmospheric Research Boulder, Colorado

ABSTRACT Over the last decade, the graphics group at the National Center for Atmospheric Research has developed a portable, device-independent graphics system. Its broad utility comes from extensive capabilities in the areas of automatic graphing, contouring, global map projections, three-dimensional perspective representation of surfaces and solids, vector field representation, high quality typography, and others. While oriented toward passive graphics, the subroutine organization of the system makes it easy to design limited-interaction applications by writing the appropriate interactive drivers for the subroutines. Device independence is achieved by generation of metacode, a graphics instruction set for an imaginary but very powerful vector graphics device. Metacode is easily translated to drive a wide range of graphics devices. Portability is achieved by utilizing ANSI FORTRAN 66, by isolating inherently nonportable activities into a handful of small routines that the implementor is responsible for producing, and by a strong hierarchical organization (which also allows phased implementation of the system). The system has been installed on computers ranging from small PDPs to CRAY-Is, driving graphics displays from low-performance terminals to Dicomed COM devices.

INTRODUCTION The National Center for Atmospheric Research (NCAR) provides facilities and support for fundamental research in disciplines relating to the atmospheric sciences. Under sponsorship of the National Science Foundation, research projects are carried out by scientists resident at NCAR, by university scientists using NCAR facilities, and by cooperative research teams drawing from both groups. The diverse studies carried out with NCAR resources typically involve modeling of atmospheric, oceanographic, and solar phenomena, or large scale collection, analysis, and archiving of physical data, or both. Due to the level of such activities, one of the most heavily-used facilities at NCAR is its Computing Facility. In the environment of a local network to which over 50 remote sites have remote job entry (RJE) access, NCAR provides significant computing power on its CRAY-1 and Control Data mainframes, as well as considerable peripheral services. Graphical output to an expanding family of plotting and display dev-

GRAPHICS SYSTEM - 1 ices is perhaps the most heavily used of these peripheral services. Coping with the enormous quantities of data associated with large-scale atmospheric modeling and data collection makes computer-driven graphics a necessity. NCAR's hard copy microfilm production alone has exceeded 8,000,000 frames per year over the last several years. Currently, NCAR supports an expanding local network of mainframes, minis, diverse graphics equipment, and other peripheral equipment. The utilization of the resources is approximately half by resident NCAR staff and half by visitors and RJE users. The evolution of the Computing Facility to its present state has had two major implications for the heavily used graphics system. First, it was realized that new output devices were going to be acquired; access to these had to be provided quickly, and users would have to be given the capabilities to painlessly switch output devices from one run to the next, use multiple output devices on a single run, and even transmit graphical information to unknown devices at remote locations. Second, the popular family of graphical utility routines would have to migrate to new computers. These machines would include not only those added to the local network, but also computers at the home institutions of visitors who wished to transport their programs home with them. TWo design features of the NCAR Graphics System have proved to be most valuable in its adaptation to a changing environment. First, it is device-independent: when application programs that use the system are designed, no foreknowledge is required of what device is going to display the results. Second, it is portable: the system is easily installed on new computers, and provides an un- changing user interface from one machine to the next.

GRAPHICS SYSTEM - 2 Figure 1. NCAR Network Configuration (December, 1979)

CHARACTERISTISt

FCactional The NCAR Graphics System is a data representation system, haracteristics as distinct, for example, from the color image systems widely employed in commercial and media work. Its functions are heavily oriented toward organizing large amounts of numerical data and producing concise visual representations. Its capabilities are most suited for the representation of scientific and technical data: annotated graphs and scatter diagrams, a number of different techniques for presenting two- and three- dimensional data fields, and high quality text fonts suitable for annotation of publication-ready technical figures. It is weak in those display methods widely used in business data representation, such as bar charts, pie graphs, and commercial-quality text fonts.

GRAPHICS SYSTEM - 3 The system is primarily passive. Following directives from a user application program (which may be interactive), the system adds elements to the picture under development, but does not allow the sort of intense user interaction with the picture that is typical of CAD/CAM systems. Thus, the elements of the picture cannot be al- tered after they have been created.

Finally, the system is a vector graphics system. It can drive almost any plotter or plotter-like device to produce line drawings, as contrasted with television-like images of raster oriented systems.

Capabilities At the simplest level, the user has direct access to routines for plotting points, lines, curves, characters, and for generation of basic backgrounds. Figures 2 and 3, on the other hand, contain a sample of each of the major high-level functional capabilities of the NCAR Graphics System. For display of one-dimensional data, the system has a powerful automatic graphing package; among its capabilities are very sophisticated annotated backgrounds, multiple labelled curves per graph, and multiple labelled graphs per picture. One-dimensional data can be displayed under more direct user control with the family of software dashed line packages; four levels of quality are available, ranging from simple software dashed lines to spline-smoothed software dashed lines with labels inserted and crowded lines eliminated.

Two-dimensional data fields can be displayed in a number of ways. Contouring of both gridded and arbitrarily scattered data is available in the same four levels of quality offered by the dashed line support family. There is the capability as well for grayscale representations of data fields, where the gray levels are simulated by dense and carefully constructed dot patterns. Iwo- component fields, such as wind fields, can be represented by either vector fields which preserve magnitude and direction, or by streamlines which show only the flow pattern of the field. Finally, three-dimensional perspective representation with hidden line removal is available for two-dimensional fields which are proper mathematical functions of two variables.

GRAPHICS SYSTEM - 4 Figure 2. Utilities Samples

DEMONSTRATIONPLOTFOR EXAMPLE7 IEZMXYI DASHSMTH I PAT-DADOAADADADADAK-I LINES OF CONSTANTINCRUDESCENCE

DISTANCEFROM EQUATOR IMILESI

KI. _...... 'K - ......

IPAT=DDDDDDDADOODA,. K,2

-K = 2-K23-_ K

IPAT=ODDDDAAAAADODOD,K=4

(I 'K 3

PATDDDADDDADDDADDD. K:5

IN IPAT STRINGS,A ANDD SHOULDBE INTERPRETEDAS APOSTROPHE ANDDOLLAR SIGN

DEMONSTRATION PLOT FOR ENTRY HAFTON OF HAFTON

vs ,,1 !. -sI -1 f r -' 1 l g I 1- T | W J W

'D::,3 ..i i :,0:.if .l.,, ,E, ,:.L- :. ,.r',;: :-:: :: :::::: ::: ::: :: :::: ::

L NGS PERK

. OEMONSTRATIONPLOT FOR ENTRY EZVEC OF VELVCT DEMONSTRATION PLOT FOR ROUTINE STRMLN . I

IIII

/, I I I I-'-' IIII / A / U / /

-'1 \ I \ \

A t I I 1 I -. III I

GRAPHICS SYSTEM - 5 Figure 3. Utilities Samples (Con't)

I DEMONSTRATIONPLOT FOR ISOSRFHR

SRFACE EXAMPLE

DEMONSTRATION PLOT FOR PWRITX PRU PRL IRU IRL KRU KRL PGU PGL IGU IGL KGU KGL

A a A a A @ A C A A

B b B b B § B , B p B § SUPMAP DEMDNSTRATION: CYLINDRICAL EQUIDISTANT PROJECTION C c c C r 7 r Y r t

D d D do t A 8 A 6 A

E ee E 0 E e E E (

}':,':':'.':F".'-;''-/f F F F 9 Z Z z

G g G g G H H 7 H

H hH h A ch0 o eE

I i I ,i I L I E I,

J J J /K K K

K k K k A X A X A

______L L I1 L KkKk1L L \~~N M ~ M ~, , -

GRAPHICS SYSTEM - 6 Perspective representation of three-dimensional annotated graphs, curves in space, points in space, etc., is provided. Iso-valued surfaces of functions of three variables can be displayed in perspective with hidden parts removed. Two styles, distinguished by low and high resolution, are available. The family of three-dimensional display utilities includes a lettering utility which can write in any orientation in any one of the three orthogo- nal planes. There is a package for map representation of any section of the earth in any one of the important map projections. Facilities also exist for generation of characters and symbols in a range of qualities. The highest quality is generated from the Hershey database, and includes several fonts, alphabets, printer's symbols, mathematical symbols, astronomical symbols, etc.

ORGANIZATION A great deal of the flexibility of the NCAR Graphics Sys- tem comes from its organization as a FORTRAN subroutine family. The user writing an application program and desiring the display capabilities of the system simply decides what facilities are appropriate for the pictures to be produced, selects the modules providing the needed functionality from the family, and calls the modules from the application program, as appropriate. The functions provided are kept as general as possible; i.e., no as- sumptions are made as to what the data represent. The contouring, for example, does not assume that one is dealing with landforms, as do a number of special purpose cartographic packages.

As Figure 4 shows, the organization of the family, as perceived by the user, is strongly hierarchical. Solid lines in the figure represent the major logical dependen- cies. In more concrete terms, they correspond with the greatest number of program accesses between levels. The dotted lines indicate other possible, but less frequently used, access paths between levels.

GRAPHICS SYSTEM - 7 /.0

Figure 4. Organization of the Software

At the bottom of the hierarchy is a small cluster of support routines (there are 1i4, in fact) which provide primitive services such as I/O, Boolean manipulations, error processing, and character string manipulation. These are functions that are easily provided in most FORTRAN environments, but that vary widely from system to system, and are defined poorly or not at all in the FORTRAN standard s.

The System Plot Package, which draws heavily on the support of the primitive-services level, is a minimal vector graphics system. It contains routines to invoke all of the basic functions of plotter-like devices. The functions at this level include routines to perform "pen" moves and to draw lines; to plot character strings; to set plotter options, such as line width, intensity, and color; to plot points; to advance to next picture, etc. The definition of the mapping from world coordinates to normalized device coordinates (essentially plotter coordinates) is accomplished by routines at this level. This is the mechanism by which user plotting instructions, issued in the coordinate system of his application, end up in the graphics instruction stream as device coordinates. The System Plot Package also provides the capability of generating, saving, and reusing segments of

GRAPHICS SYSTEM - 8 instructions, which is useful and thrifty when many pictures have common elements. The most complex capabilities at this basic level are generation of simple annotated backgrounds, such as axis pairs and grids.

More complex tasks are performed by the graphics utilities. Each of these is designed to implement a particular data representation algorithm, such as contouring a field of numbers, in a way that is general but subject to user control. Each of the illustrations in Figures 2 and 3 was produced by one of the utilities. The utilities rely heavily on the services of the System Plot Package, and less heavily on the primitive service routines. User application programs have available the services of all three of these levels, but rely most heavily on the services of the utilities. The reason is clear: much can be accomplished with little programming when the utilities are used. A single subroutine call was all that was required to produce all but one of the pictures in Fig- ures 2 and 3. Not illustrated in Figure 4, but contributing greatly to the power of the graphics system, is the structure and organization within the family of utilities. Two features are important. First, the utilities are designed so that they work well together--they are well integrated horizontally. This is illustrated in Figure 5, where the contouring utility has been invoked to overlay a contour map on a global projection produced by the mapping utility, and then the vector field utility has been invoked to add its output. Such a picture is a standard procedure, and requires that the user produce some 15 lines of auxiliary code for use by the utilities. The utilities family is also integrated vertically: packages providing the same generic capability, but at different levels of quality, have identically-named user entry points. By changing a library access card, the user changes the quality of his output without having to alter his application program. This is the case, for example, with the contouring and software dashed line utilities. Figure 8 (at the end of this paper) illustrates vertical integration.

GRAPHICS SYSTEM - 9 Figure 5. Horizontal Integration of Utilities

POIRBILITY The NCAR Graphics System is portable in the sense that the code comprising the system can be transported to a wide range of computing environments. The criterion we use to evaluate portability is this: the effort to implement the system in a new environment should be very small relative to the effort to generate the functionality of the system from scratch in that environment. According to this criterion, we feel the NCAR Graphics System succeeds. Its portability is primarily a result of three design factors.

First, the language is FORTRAN, which, despite its draw- backs, is probably the most widely implemented language in technical environments. The graphics software is restricted to a subset of ANSI 66 standard FORTRAN which can

GRAPHICS SYSTEM - 10 be verified by an automatic tool, the PFORT verifier [4].

Second, the code for machine-dependent, inherently non- standard functions is strictly localized in a set of 1i4 routines (the primitive-services routines mentioned above) which the implementor of the system is responsible for providing in each environment in which the system is to be installed. In the manner of the PORT Mathematical Subroutine Library [1, two of the .14 support routines return required machine-dependent constants (I/O logical units numbers, characteristics of machine arithmetic, etc.) to the invoker.

Third, the hierarchical, modular structure isolates potential trouble spots and reduces the chances that a bug could cripple the entire system. An added benefit is that phased implementation of the system is possible. Typically, the machine-dependent support and highly portable System Plot Package are implemented very quickly. The utilities can then be installed, tested, and used as needed.

One of the common objections to portability standards is that they force program inefficiency. At the lower levels of the package, this objection has some validity, as all high level accesses funnel through a very small amount of code at the bottom of the hierarchy (it is es- timated that the code to construct a vector instruction is executed about 250 million times a day on NCAR's CDC 7600). For this reason, there is not just one System Plot Package, but there is one for each class of computers that has the same combination of word size and number of characters per word. These versions differ only in their internals.

DEVICE The system achieves device independence by generating DIBEPENENC metacode, a device-independent plotter instruction code. Metacode is the instruction set of an imaginary high resolution plotter with very comprehensive capabilities. The structure of metacode is simple, however, and it can easily be translated to drive a wide range of devices. The user, then, visualizing an abstract picture that he would like to see, executes a program on some computer on which the graphics system is installed and generates a metacode file. Then, either locally or remotely, immediately or at some later time, a postprocessor is run that translates the metacode file into the instruction set of some intended target device. Figure 6 illustrates the complete system now, from abstract picture generation to actual display.

GRAPHICS SYSTEM - 11 Pigure b. user s View of the Whole System

The resolution of the imaginary metacode plotter is 32K in its two coordinate directions. The metacode itself is a binary bit stream with only three instruction types, (Figure 7). The 4-byte instruction is for move or draw to an absolute address, whereas the 2-byte instruction is for move or draw to a relative address. The multi-byte instructions handle everything else, including character strings, frame advance, and setting plotter options. Current plotter options include line width, color, intensity, attributes of character strings, etc. (The NCAR Graphics Software manual [33 contains complete details). There is an ample number of unused codes for implementors who want to add their own op codes and plotter options. This provides the means to take advantage of special features of a given plotter or class of plotters that may not be covered by the metacode. Thus, for example, one could add a "background color" option if one intended using the system with a color terminal that supported changeable background colors.

GRAPHICS SYSTEM - 12 4 BYTE INSTRUCTION (ABSOLUTE POSITION)

x Y

\PEN CONTROL BIT MULTIBYTE INSTRUCTION |2 <-6 88-- =- -- 8 8

i| OPCODE N BYTE I BYTE N

2 BYTE INSTRUCTION (RELATIVE POSITION; subtract 25 from X and Y) =2 6 10olx ! Y

\PEN CONTROL BYTE

Figure 7. Metacode In struct ion Types

Designing, coding, and testing a metacode translator from scratch can be a substantial effort. For this reason, a portable FORTRAN "translator shell" has been designed. The implementor sets a handful of constants pertaining to the addressability of the intended output device, options for translation, etc., and provides three of the primitive service routines described above. There is a single, mandatory interface point in the code where the implementor has to generate actual device instructions for move, draw, point-plot, and new-picture operations. Vendor-supplied software, if available, can be invoked at this point to generate the instructions. Software character and dashed line generators are included in the program. Additional potential metacode-to-device interface points are clearly marked in the code, so that the implementor may take advantage of whatever more sophisticated hardware capabilities the device may have (hardware characters, color, etc.). The portable translator allows one to add a new device to the system very quickly; the time is typically measured in days.

]IWIEMENTION The implementation of the NCAR Graphics System in a new environment is a straightforward procedure if one has the full implementation kit, including NCAR's graphics manual. The recipe is as follows:

1. Code the 14 primitive-services routines.

2. Run the portable FORTRAN program which verifies correct behavior of the routines.

GRAPHICS SYSTEM - 13 3. Compile and load the System Plot Package and service routines along with the portable test program that generates two simple frames (it contains, as comment cards, a hexadecimal dump of the metacode that should result). Execute and verify that the resulting metacode is correct. 4. After setting three machine-dependent constants, run the portable metacode-to-line-printer translator with the metacode produced in the previous step as input.

5. Implement the portable translator shell for the actual graphics device(s) you have.

6. Implement the utilities as needed. 7. Propagate the system to other hosts and add other devices as desired. Selectively optimize and cus- tomize the portable software as required.

This formula has worked quite well in NCAR's local network. As an example, within three weeks of NCAR's CRAY-i becoming available for programming, basic graphics service to the 7600's dd80 was established. Over the next few months, the full capabilities of the system were brought up. Implementations of the system are known to have been made on the following equipment: * Control Data 6000, 7000, and Cyber series * CRAY-1, running COS and other systems * DEC 0TO * PDP U1s, running both RSX-11M and UNIX * VAX * Prime * Data General Nova and Eclipse * Honeywell * Univac * IBM 360s, 370s, and Amdahl equivalents * Distributed but not verified: Burroughs 7700, SEL 32/75, Harris/6, Interdata, and Texas Instruments ASC computers.

Devices known to be driven by the system include:

* Control Data dd80 COM devices * III FR80 color COM devices * Calcomp plotters * Dicomed D48 COM devices * Tektronix terminals * Hewlett-Packard terminals

GRAPHICS SYSTEM - 14 O Hewlett-Packard 4-color plotter * Ford Aerospace display terminals * Distributed but not verified: Versatec 1200A, Vari- an, Zeta, Gould 5000, and IMLAC graphics devices.

LIGMTATIOC The limitations of the system are generally a result of its evolving directly from a package exclusively designed to execute on the Control Data 6000/7000 series mainframes and drive NCAR's dd80s. The limitations fall generally into the categories of portability problems and device support.

All of the software in the NCAR Graphics System meets the portability criterion that it is much easier to port than to produce from scratch. The System Plot Package is highly portable, as are many of the most popular and heavily-used utilities. Work toward the goal that a single version should run on a wide range of computers without changing a single line of code is an ongoing project.

However, portability of parts of the system is still a bit uneven. In particular, some of the less frequently- used utilities have not gone through the full portability review and revision procedure and will trigger (usually non-serious) diagnostics from the PFORT verifier. Other portability problems remaining include: occasional as- sumptions that a local variable will retain its value between successive calls to the routine containing it (which is not the case in overlaid codes, for example); problems with floating point resolution or maximum sized integer on the host computer; recent use of more sophisticated plotters has uncovered scattered errors in utilities' setting of plotter options. The PFORT verifier cannot check for these.

Some of the primitive support routines are tricky to implement on some computers. It is required, for example, to produce a routine that distinguishes whether its single argument is a positive integer in a certain range, or is a floating point number. Under RSX-11M FORTRAN IV, with 2-byte integers, this can be accomplished only by assuming that no positive floating point numbers smaller than about 10**-36 will be passed to the package (the normal bottom limit is about 10**-38); this generally is not too serious a limitation.

On systems with small limits for program virtual address space (RSX-11M, for example), some of the utilities are so large that they cannot be easily loaded with a large application program. The implementor must decide on and implement an overlay scheme in such situations.

GRAPHICS SYSTEM - 15 Taking advantage of the special characteristics of a given output device is not immediately possible in a device-independent graphics system such as NCAR's. As pointed out above, however, it is quite easy to extend the instruction set of NCAR's metacode to do this.

Support of raster devices that cannot directly accept vector endpoint data is not completely straightforward. The implementor intending to drive such a device must include a vector-to-raster conversion algorithm in the metacode translator. Fortunately, the problem has been solved and many solutions are available from which to choose [2].

As can be seen from the list of implementations above, these problems rarely prove fatal; they tend, rather, to be annoyances.

There is one final notion of portability which we have not yet discussed. This has to do not with the transpor- tability of graphics systems but with the transportabili- ty of application programs that use computer graphics. There has been an effort for some years now to devise a graphics standard that defines a standard functionality and syntax for computer graphics [5]. The Graphics Stan- dard Planning Committee (GSPC) of ACM/SIGGRAPH has ar- rived at a proposed standard, known as the "Core System." While it is uncertain what will finally be decided upon for the core system, the mere emergence of the proposal has led to its acceptance as a de facto standard, and a number of systems have now been designed to meet it. The NCAR system contains most of the functionality of the non-interactive levels of the core proposal, but differs in syntax and in certain questions of coordinate systems.

GRAPHICS SYSTEM - 16 REFERENWES [1] Fox, P.A., A.D. Hall, and N.L. Schryer, 1978: The PORT Mathematical Subroutine Library, ACM Trans. Math. Software 4,2, 104-126.

[23 Franklin, W.R., :1979: Evaluation of Algorithms to Display Vector Plots on Raster Devices, Computer Graphics and Image Processing 11, 377-397.

[3] Henderson, L.R., and F. Clare, 1979: NCAR Graphics Software, preliminary edition. NC ~ Boulder, Colorado.

[4] Ryder, B.G., 1974: The PFORT Verifier, Software-- Practice and Experience 4, 359-377. [5] Status Report of the Graphic Standards Planning Committee,-7-M7[G PFRr Published as Computer Graphics 1$3, 3 (August 1979).

ACKNOWLEDGEMENTS Much credit is due to David Robertson and Tom Wright, both formerly of the NCAR Computing Facility, who con- ceived this system. My thanks to Fred Clare and Sara Ladd of the Computing Facility for their criticisms and assistance in producing this paper.

REAIER'S NOTE: This paper was originally prepared for and published in the Proceedings of the Digital Equipment Computer User' s Society (DECUS, TprTF198 T.

GRAPHICS SYSTEM - 17 Figure 8. Vertical Integration of Utilities

QU ICK STANDARD

SM00TH SUPER

GRAPHICS SYSTEM - 18 GENERATIIG AND PLOTTING GRAPHICS TEXT AT NCAR

OVERVIEW Discussed in this article are:

9 Ways of generating characters using either the direct-to-dd80 system plot package on the Control Data 7600 (the default) or an NCAR-supported metacode-producing plot package.

* Utilities for generating characters.

* Character plotting on the dd80 and on the Dicomed.

DEFIimTIu The default system plot package on the Control Data 7600 produces dd80 instructions; all other NCAR-supported plot packages produce "metacode." Metacode is a device- independent set of primitive plotter instructions which can be translated to drive any specific plotter. A complete description of metacode is contained in the appropriate section of the NCAR Graphics Manual. The document "Using Metacode" can be obtained by contacting the SCD consulting office.

Generating a character means creating code to produce that character; plotting a character refers to the actual drawing of the character on a graphics device.

The specification of the horizontal (+X-direction) and vertical (+Y-direction) positions will be given in one of two ways, corresponding to two distinct models of the abstract plotting screen.

Metacode address units -- Pertain to the virtual graphics device that the device-independent metacode instruction set drives. These units are in the range from 0 to 32,767. All plotter addresses in the metacode are in these units.

Plotter address units -- Pertain to an abstract plotting screen that is integer-addressable and resolution- definable by the user. By default these units are in the range from 1 to 1024. This range can be changed by a call to the plot package entry SETI. An NCAR metacode- producing System Plot Package will map these units into metacode address units.

GENERATING AND PLOTTING GRAPHICS TEXT AT NCAR - 1 This article will refer to "the basic 46 characters." The following 46 characters comprise this set:

ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 =+-*/(),.

Notice that the blank character is a member of this set. This character set is the same as the ANSI 66 standard FORTRAN character set except it lacks the dollar sign: $.

There are many ways to generate characters at NCAR, and the reason there are so many ways lies in trying to satisfy a wide range of often conflicting requirements such as character quality, CPU speed, CPU size, output file size, and plotter time. The default characters generated by an NCAR System Plot Package, and by most of the NCAR Graphics Utilities, attempt to minimize the requirements of CPU speed and size, output file size, and plotter time while still providing reasonable fidelity to the users' intended plots. In other words, the desire is to supply cheap default characters which will not be of- fensive when used for typical plots. The needs of higher quality, higher dimensionality, and greater fidelity can be serviced by using one of the more expensive character-generating packages.

HARDRE AND Most plotting devices have a special set of what are called hardware characters. Instead of having to execute CHARACTERS instructions to draw the necessary strokes for a given character, the stroke sequences for hardware characters are actually hard-wired into the device. The hardware character generator for a plotting device can be viewed as a black box which receives character numbers and, in response, produces the appropriate character on the device. There are two advantages of using a hardware character rather than executing a sequence of line-drawing instructions to produce the character: the instructions take up less space, and the character is drawn faster. The drawing of a hardware character is frequently at least an order of magnitude faster than executing a sequence of line-drawing instructions to draw this character. On any given plotting device there are only a fixed number of hardware characters, and these can be drawn in a limited number of sizes and orientations.

A software character is a character which is plotted on a graphics device by the execution of line-drawing instructions. In other words, at some point a user-supplied character is converted into strokes by software executing in a CPU. This character-to-stroke conversion can occur

GENERATING AND PLOTTING GRAPHICS TEXT AT NCAR - 2 at the time of execution of the user application program, or if metacode has been produced, at the time of execution of a metacode translator. The drawing of a software character is basically no different from drawing a contour line in this respect.

PlRIT Access to the cheap default characters, as discussed in the introduction, is via the System Plot Package entry PWRIT. The goal is to take advantage of the speed of the hardware characters. If a hardware character exists which is "sufficiently close" in size and orientation to the character requested, then it will be used; otherwise a simple software character of the correct size and orientation will be used. Thus, when using PWRIT it may be that the characters plotted are not exactly of the size requested, but they should be close enough not to be objectionable for use in a typical plot. The NCAR System Plot Packages and most of the NCAR Graphics Utiliies, call PWRIT whenever possible to generate graphics characters.

Characters are represented in the metacode by 8-bit ASCII codes, so when using a metacode-producing plot package on a non-ASCII machine the local character representations will be translated to ASCII before being stored in the metacode. This will usually mean that the full hardware character set of an ASCII-based graphics device (the Di- comed for example) will not be available when accessed via a non-ASCII machine. For example, on the CDC-7600 the display code representations for characters are six bits long, so the DPC-to-ASCII conversion table contains only 64 entries, hence only 64 distinct ASCII character codes will appear in metacode produced on the CDC-7600. On ASCII machines, a metacode-producing plot package will stuff any 8-bit ASCII code directly into the metacode, so the full hardware character set of the Dicomed will be available when accessed from the CRAY-1 -- to obtain the Greek letter pi on the Dicomed for example, one would call PWRIT with an octal 245 as the first eight bits in the ICHARS array.

The decision as to whether hardware or software characters will be plotted via PWRIT calls is made as "close" to the graphic output device as possible -- when one is using a metacode-producing plot package (the default plot package on the CRAY-1, or PLOT.META on the CDC-7600, for example), the metacode translator for the graphic output device in use will make this decision. One complicating factor is that the hardware character set used via PWRIT calls may not be the same, in either number of available characters or font, as the software character set used when hardware characters are not selected. The chart on the next page briefly summarizes this situation.

GENERATING AND PLOTTING GRAPHICS TEXT AT NCAR - 3 7600 An NCAR metacode-producing ------Sys Plot ------I Package

run on ASCII host run on non-ASCII host _ Host [I .______Level I

Translator/ I Device hardware software hardware software Level ------

II-full 8-bit ASIfull 8-bit, :the basic 46 J :host machine 1 I the basic 461 'ASCII set*' icharacters** :chars must be: characters J I -______0____ converted to , ------'ASCII

hardware ' software * Assuming an ASCII-based device _ __ _ _ * On some devices, such as the Dicomed, the Software Character Generator has been enhanced to Ifull dd80O 'the basic 46: supply the same set of characters I set I, characters i as the hardware characters.

For example, this chart implies that the full 8-bit ASCII codes are available to the Dicomed when accessed via the CRAY-1, but only 64 ASCII character codes are available to the Dicomed when accessed via a metacode producing plot package run on the 7600.

For a full explanation of when hardware or software characters will be selected on the dd80 or the Dicomed via PWRIT calls, see the sections dd80 HARDWARE CHARACTERS and DICOMED HARDWARE CHARACTERS below.

GENERATING AND PLOTTING GRAPHICS TEXT AT NCAR - 4 T WOHORSES Probably 99% of the graphics characters plotted at NCAR are generated by one of the following calls:

CALL PWRIT (X,Y,ICHARS,N,ISIZ,IOR,ICENT) CALL PWRITY(X,Y,ICHARS,N,ISIZ,IOR,ICENT) CALL PWRITX(X,Y,ICHARS,N,ISIZ,IOR,ICENT)

where ICHARS contains the characters to be written, X,Y specify where the characters are to be written, N is the number of characters to be written, ISIZ specifies the character size, IOR the character orientation, and ICENT the centering option. PWRITY and PWRITX will be described in detail later. ddw HAmAR The dd80 has 115 hardware characters which include the upper and lower case letters °of the alphabet, the numerals, certain Greek characters, and several special symbols. These characters can be written in any one of four sizes, two orientations (at 0 degrees and 90 degrees), two intensities, and in either block print or italics. The entire dd80 hardware character set is available only via a call to the subroutine PWRIT in the direct-to-dd80 system plot package on the CDC-7600. Here is a sample output from such a call:

The dd80 has UPPER CASE:, lower case, nume ra I s, (0,1,2,...), some Greek letters, (e.g. X, , iT,...), special symbo Is, (e.g. /, D), -,...), and //< t0w' .14s./CS .

Generating the special characters, Greek letters, etc. by using PWRIT on the 7600 is a bit involved. Complete details on how to go about this are contained in the article "Generating dd80 Hardware Characters on the NCAR Control Data 7600" which can be obtained by contacting the SCD consulting office. The metacode-to-dd80 translator (file MC2DD80B on XLIB) supports only the basic 46 characters in its translation of PWRIT calls. If one is using a metacode-producing plot package (for example,

GENERATING AND PLOTTING GRAPHICS TEXT AT NCAR - 5 PLOT.META on the 7600, or the system plot package on the CRAY-1), then only the basic 46 characters will be available on the dd80 via PWRIT calls. As will be mentioned later, many characters are available via various software character packages.

Here are the basic 46 characters produced as dd80 hardware characters by using a PWRIT call:

The following table summarizes the sizes of the dd80 hardware characters:

ISIZ in Maximum Maximum Increment Increment PWRIT call Char./line Lines/frame Along Line Between Lines

0 128 64 8. 16 1 86 43 12 24 2 64 32 16 32 3 43 22 24 48

The increments are given in plotter address units; 1024 resolution assumed. The increment along the line includes the white space between the characters. The increment between lines is chosen to provide an appropriate amount of space between lines so the lines will not look crowded. The increment between lines is automatically effected when using the full dd80 hardware character set, otherwise it is a guide as to what spacing will produce pleasing results.

If the character size parameter, ISIZ, of PWRIT is specified in plotter address units (either using a metacode- producing plot package, or using the direct-to-dd80 [default] system plot package on the 7600), the following chart summarizes what will be produced on the dd80:

GENERATING AND PLOTTING GRAPHICS TEXT AT NCAR - 6 If ISIZ equals 4 - 5 A software character of the requested size is drawn. 6 - 9 A size 0 hardware character is drawn. 10 - 13 A size 1 hardware character is drawn. 14 - 17 A size 2 hardware character is drawn. 18 - 32 A size 3 hardware character is drawn. 33 - 1023 A software character of the requested size is drawn. (The heights will be truncated near the upper limit.)

The software characters are drawn in the PWRITY font which is not the same as the dd80 hardware character font. The size of a character in plotter address units specifies the width of the character including white space. Software characters will also be selected if the current orientation is any other than 0 or 90 degrees.

DICMED HRWR Information on how to use the Dicomed 35rrn film or 105rmm fiche unit is contained in the article "Using the Di- comeds" which can be obtained from the SCD consulting office. The DICOMED plotters have 192 hardware characters. Each of these characters can be drawn in one of 9 sizes or 4 orientations (0 degrees, 90 degrees, 180 degrees, or 270 degrees). The hardware characters are drawn in only one intensity. Character size and orientation can be changed via calls to the system plot package subroutine OPTN. A complete list of the Dicomed hardware characters, together with their associated octal codes, is given on the following page. Note that characters 040-176 are the standard ASCII characters and the octal codes are the ASCII codes.

GENERATING AND PLOTTING GRAPHICS TEXT AT NCAR - 7 SAMU E PLA

DICOMED HARDWARE CHARACTERS AND OCTAL CODES

040 100 @ 140 240 o 300 0 340 041 ! 101 A 141 a 241 I 301 V 341 0( 042 102 B 142 b 242 II 302 4> 342 043 103 C 143 c 243 t. 303 F 343 7 044 $ 104 D 144 d 244 a 304 A 344 6 045 % 105 E 145 e 245 sI 305 3 345 046 & 106 F 146 f 246 t¢ 306 %4 346 0 047 107 G 147 g 247 + 307 8 347 050 110 H 150 h 250 c 310 A 350 77 051 ) 111 I 151 i 251 311 v 351 C 052 * 112 J 152 j 252 x 312 5 352 053 + 113 K 153 k 253 + 313 -F 353 054 114 L 154 1 254 314 A 354 A- 055 - 115 M 155 m 255 315 J 355 056 116 N 156 n 256 316 356 057 / 117 0 157 o 257 317 r 357 0 060 0 120 P 160 p 260 =0 320 L . 360 p 061 1 121 Q 161 q 261 e 321 fn 361 1' 062 2 122 R 162 r 262 ® 322 0 362 I 063 3 123 S 163 s 263 ® 323 E 363 064 4 124 T 164- t 264 324 364 T 065 5 125 U 165 u 265 325 T 365 U 066 6 126 V 166 v 266 326 V 366 a6) 067 7 127 w 167 w 267 a 327 Q 367 070 8 130 x 170 x 270 n 330 -1 370 x 071 9 131 Y 171 y 271 u 331 + 371 072 132 z 172 z 272 ,A 332 372 1 073 133 [ 173 { 273 v 333 373 ( 074 < . 134 \ .1 74 ' 274 > 334 374 -L 075 = 135 ] 175 } 275 ' 335 375 ) 076 > 136 176 276 < 336 376 077 ? 137 177 277 r 337 377 U

GENERATING AND PLOTTING GRAPHICS TEXT AT NCAR - 8 A hardware character is used on the Dicomed when there is one sufficiently close, in size and orientation, to the character being requested. What is meant by "sufficiently close" is still being tuned. When the Dicomeds are accessible on-line, a character quality option will be made available whereby a user will be able to specify always using hardware characters, or always using software characters, or using a hardware character when there is one available within a specified size and orientation range, and so forth.

The fonts for the hardware characters and the software characters selected by the metacode translator in translating a PWRIT character are identical on the Di- comed. Whereas on the dd80 .it is possible to tell whether a hardware character or software character was drawn strictly by examining the font, this is not so on the Di- comeds.

The Dicomed hardware characters are -digitized on a grid 144 metacode units wide by 224 metacode units high. This is the grid for the actual characters themselves, and an additional 72 metacode units is allowed for white space between characters. The Dicomed system allows for scaling of image sizes. The default scale factors for three common Dicomed formats are:

1.000 for metacode jobs run on 35mm film .685 for metacode jobs run on 105mm fiche in 48x format .800 for metacode jobs run on 105mm fiche in 24x format

When an image is scaled, a subrange of the metacode address unit range is mapped onto the full Dicomed address range (0-32767), and the metacode address units specifying character size are scaled appropriately. How- ever, the hardware character sizes are fixed as multiples of 216 Dicomed address units, and these sizes are not affected by image scaling. Thus, for example, to specify the precise size for the smallest hardware character (in metacode address units) for 105mm fiche in 48x format, use 216/.685 or 316. The following charts summarize basic facts on the nine hardware character sizes when using three common default situations:

GENERATING AND PLOTTING GRAPHICS TEXT AT NCAR - 9 I I Dicomed Hardware Character Size Index I 48x FICHE I I I 0 1 2 3 4 5 6 7 8

------ gm-------Wo ------a------6------I user specified I I width (assuming I 316 631 946 1262 1577 1892 2208 2523 2838 I a resolution of I I 2**15) .I I I I characters per I I line I 104 52 35 26 21 17 15 13 11 I I I recommended max. ,I I lines per page I 67 33 22 17 13 11 9 8 7 I I 'Dicomed Hardware Character Size Index 35mm FILM 0 1 2 3 4 5 6 7 8

------a------user specified width (assuming 216 432 648 864 1080 1296 1512 1728 1944 a resolution of 2**15) characters per line 151 75 50 38 30 25 22 19 17 recommended max. lines per page 97 48 32 24 19 16 14 12 11

Dicomed Hardware Character Size Index 24x FICHE 0 1 2 3 4 5 6 7 8 user specified 'I width (assuming 270 540 810 1080 1350 1620 1890 2160 2430 a resolution of I 2**15) I I I characters per I I line I 121 60 40 30 24 20 17 15 13 I I I recommended max 01 1 lines per page 1 78 39 26 19 15 13 11 10 8 1 1

GENERATING AND PLOTTING GRAPHICS TEXT AT NCAR - 10 To get a feel for the relative sizes of the Dicomed hardware characters, here is the letter A produced in each one of the 9 hardware sizes:

A A A AA A A A

ScFTWARE VS. The advantages of using software characters over hardware HARINARE characters are that software characters can be drawn at CHARACTERS any size and orientation and there are a variety of fonts available for drawing almost any character imaginable. The available packages for drawing software characters will be discussed below. The disadvantages of using software characters are that more plotting instructions are produced and it takes longer to process them. The following chart compares instruction set sizes and run times for Dicomed hardware characters, and the two most commonly used software character packages. These results are based on a test file containing 3000 lines of 80 non-blank characters each.

CRAY-1 time number of Dicomed chars./sec. to create bytes in execution for Dicomed metacode file metacode file time execution

PWRIT 1.7 sec. 554,880 28 sec. 8571 (hardware) I PWRITY 24.5 sec. 7,778,880 10 min. 400 (software)

PWRITX 165.0 sec. 22,394,880 35 min 114 (software),

GENERATING AND PLOTTING GRAPHICS TEXT AT NCAR - 11 Software characters are available in a variety of fonts, some simple and some fancy. Consider the letter G as drawn by the routines PWRITY, PWRITX, and TPGPHC (in Ger- man Gothic).

G G

Again, only larger:

A close examination of these characters reveals that PWRITY takes 9 strokes, PWRITX takes 30 strokes, and TPGPHC takes 73 strokes. In general, the fancier the font, the more strokes.

RE mCHARACTER PACKAGES

PIR There are two PWRY packages -- one is a part of the default system plot package on the CDC-7600 and contains the entry point PWRY, and the other is a package on ULIB. These packages produce the simplest of the software char-

GENERATING AND PLOTTING GRAPHICS TEXT AT NCAR - 12 acters. The 7600 system PWRY entry is non-portable and outdated. The recommended package for simple software characters is PWRY on ULIB which runs on both the CRAY-1 and the CDC-7600. This package retains an entry point PWRY in support of the old PWRY calling sequence, but the preferred entry point is PWRITY whose calling sequence is the same as the calling sequence of PWRIT. If one is using PWRIT calls and wishes to generate production of software characters, one can simply supply a subroutine PWRIT which does nothing more than call PWRITY with the same arguments. The PWRY entry on the CDC-7600 default system plot package supports the characters:

: RBCDEFGHIJKLMNOPORSTUVWXYZO123456789+-/ ) $ .. - ] -v 1<> t;

I The above characters were generated by PWRY and plotted on the dd80. The ULIB package PWRY supports the basic 46 characters:

RBCDEFGHIJKLMN0PQRSTUVWXYZ0123456789 =+-*/ (.

L These characters were generated by a PWRITY call and plotted on the Dicomed. The entries PWRY and PWRITY are on the default CRAY-1 library $NCARLB, so PWRY need not be shipped to the CRAY-1 unless mods are being made to that file.

The PWRY characters are digitized on a grid 4 units wide by 7 units high. On such a grid, each character is followed by 2 units of white space, making the total width 6 units.

PIR, FVRITZ There are presently four packages in this family:

PWRITX on ULIB PWRITX on CRAYLIB PWRX on ULIB PWRX on XLIB

GENERATING AND PLOTTING GRAPHICS TEXT AT NCAR - 13 The PWRX packages on ULIB and XLIB are outdated versions of the more recent PWRITX on ULIB. Their usage is discouraged, and they will in fact be deleted in the not too distant future. PWRITX on ULIB has a user entry point PWRX to support the calling sequence of PWRX on ULIB. PWRITX on CRAYLIB is essentially the same code as PWRITX on ULIB (the only difference being in how the data files are accessed.) The entry points PWRITX and PWRX are both on the default CRAY-1 library $NCARLB, so one need not send the CRAYLIB version over to the CRAY-1 unless mods are being made to that file.

PWRITX on ULIB provides the highest quality characters available at NCAR. It provides upper and lower case characters in Roman or Greek fonts, and in principal, indexi- cal, and cartographic sizes. It also provides a wide range of special symbols. Subscripting and superscripting can be done under function code control. The calling sequence for PWRITX is the same as that for PWRIT and PWRITY.

The PWRITX characters are digitized on a grid 21 plotter address units high with an additional 11 plotter address units used for white space between lines. The characters vary in width; a blank or an X increment will space across 16 plotter address units. For the size parameter equal to 0, 1, 2, or 3, the character sizes will be 1., 1.5, 2., and 3. times the basic digitized size. Thus, PWRITX characters of size 0 are about equal in size to PWRIT or PWRITY characters of size 2.

Here are the basic 46 characters as generated by PWRITX on the CRAY-1 and plotted on the Dicomed:

ABCDEFGHIJKLMNOPQRSTUVWXYZO 123456789 =+-*/(),

PWRITX on ULIB also supports a font for the Roman characters without-serif-s (sometimes called the sans serif font or the duplex character set.) This font can be accessed via the setting of a flag in a common block in PWRITX. Once the font is selected it cannot be changed during the same job step (the flag controls which data set is read in initially.) Here are the basic 46 characters plotted on the Dicomed in this sans serif font:

GENERATING AND PLOTTING GRAPHICS TEXT AT NCAR - 14 ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 - +-*/(),.

TIPGHC This program resides on XLIB and runs only on the CDC- 7600; it offers a vast array of characters, all of the highest quality. It has upper and lower case Roman letters in several fonts (including italics), script letters in two fonts, upper and lower case Greek in several fonts, the Cyrillic alphabet, Gothic German, Gothic English, and Gothic Italian, all manner of special ahd mathematical symbols, and sizes appropriate for subscripting and superscripting. The current documentation is a bit difficult to wade through, and the package is awkward to use. Since this package does offer the widest selection of characters and fonts, it is hoped that the code and documentation can be cleaned up and the package made to run on the CRAY-1.

SPECIAL PURFSE CHARACTER PACKAGES

FIRIQ This is an entry point of AGUSEPWRX on XLIB. This subroutine allows one to use PWRITX with AUTOGRAPH. It runs on the CRAY-1 as well as on the CDC-7600, but it is not an entry point of the CRAY-1 default library $NCARLB.

NRlTTV This is an entry point of the SCROLL package on ULIB and also of $NCARLB. This subroutine can be called to write characters vertically on the plotting screen. Each character is written in the +X direction, but the characters appear one below the other on the screen. The arguments are the same as those of PWRIT, except the positioning arguments must be floating point and within the range of the user's last set call. PWRIT is used to generate the characters.

F1RITW This is an entry point of the WINDOW package on ULIB and also of $NCARLB. The arguments of PWRITW are the same as those of PWRITY, and in fact PWRITY is used to generate the characters. The only difference between PWRITY and PWRITW is that, when using PWRITW, no portion of any character is allowed to be drawn outside the user's last set call. Characters straddling the borders of the set call limits are truncated appropriately.

GENERATING AND PLOTTING GRAPHICS TEXT AT NCAR - 15 PWRZI, PIRZS, These three ULIB subroutines are software character pack- IVRZT ages which support the plotting of characters in three- space with different sizes and orientations. The files PWRZI, PWRZS, PWRZT are meant to be used with the ULIB files ISOSRF, SRFACE, and THREED respectively. None of the subroutines will run independently of its companion routine. Characters hidden behind the three-dimensional surface being drawn are not drawn (in fact, this is why it is necessary for the PWRZ routines to be tied to their respective surface-drawing routines--it is necessary for them to know the hidden line removal algorithm in effect.) Only the basic 46 characters are supported, and they are drawn in the same font as the PWRITY characters. All of these routines run on the CRAY-1 as well as the CDC-7600. On the next page is an example of characters generated by PWRZS and plotted on the Dicomed.

WPlR PWRM is an entry point of the CONRECSUPR and DASHSUPR packages which generates characters via PWRIT and addi- tionally marks the area surrounding the generated characters so that the underlying utilities will not draw lines over them.

GENERATING AND PLOTTING GRAPHICS TEXT AT NCAR - 16 SAPLE FLOT

DEMONSTRATION PLOT FOR PWRZS

Oft

GENERATING AND PLOTTING GRAPHICS TEXT AT NCAR - 17 All characters generated by any of the graphics utili- GENERATED BY THE ties: GRAFHlIS UTILITIES

AUTOGRAPH CONRECSMTH HAFTON CONRAN CONRECSUPR SCROLL CONRAQ DASHCHAR STRMLN CONRAS DASHLINE SUPMAP CONREC DASHSMTH VELVCT CONRECQCK DASHSUPR

are by default generated by calls to PWRIT. The plot package entry point POINTS will produce PWRIT characters in the current size and orientation (when characters are requested.) The size and orientation of these characters can be changed by a call to OPTN (on the 7600, the default system plot package entry OPTN will always round to the nearest hardware character size, so POINTS will only produce one of the four dd80 hardware character sizes in this case.)

FTLES WHICH ARE PSYM - Obsolete entry of the plot packages which LETEOR WHOSE now results in a call to PWRIT. TSAG iS PSYMD-- Obsolete entry of the plot packages which DISCOURAGED now results in a call to PWRIT. PSYM3 -- Obsolete entry point of the THREED package . on ULIB. PWRT -- This is an entry of the plot packages which is the predecessor to the currently recommended entry PWRIT. PWRX -- Packages-on both XLIB and ULIB which have been supplanted by the one package PWRITX on ULIB. PWRY -- Entry of the default system plot package on the 7600 which is a predecessor to the recommended file PWRY on ULIB. PWRYW -- Entry of the ULIB package WINDOW which supports the old PWRY calling sequence. PWRITZ-- Obsolete three-dimensional character drawing package which has been replaced with the three packages PWRZI, PWRZS, PWRZT. PWRZ -- Obsolete three-dimensional character drawing package which has been replaced by the three packages PWRZI, PWRZS, PWRZT.

- hr IEnb -

GENERATING AND PLOTTING GRAPHICS TEXT AT NCAR - 18 PFRM

LATES REVISION June 1978

PUhIOSE PRFILM is a FORTRAN routine, callable from user CRAY-1 programs, for sending disk records to film. Specifically, PRFILM converts records (e.g. ones written by a formatted WRITE) to their equivalent plotter characters, and appends the converted records to the CRAY-1 plot file $PLT. PRFILM should be used in only two cases: when the user desires to mix text and graphics, or when the user wants to dispose text from the CRAY-1 to the dd80. For disposing text from the CRAY-1 to the Dicomeds, users should use PRSIM, as it requires about 1% of the plotting time required by PRFILM. Write-ups for PRSIM can be obtained from the SCD Consulting Office. Also, in the near future, it will be possible to intermix text and graphics on the CRAY-1 without using PRFILM.

ACCESS No access cards are required: PRFILM resides on CRAY-1 library $NCARLB which is automatically searched for entry points.

1SAGE 1. CALL PRFILM(IUNIT) where the value of IUNIT is the logical unit number to which the records have been written.

2. PRFILM is cumulative: the first call sends to film whatever has been written on unit IUNIT prior to the call. Each subsequent call sends to film that portion of the disk written after the previous call and before the present call.

3. When IUNIT is specified as 6, print statement and WRITE(6 output is sent to film.

4. The calling program may contain PRFILM calls for several values of IUNIT.

5. Jobs using CRAY-1 JCL must dispose the plot file $PLT. DISPOSE cards should be placed before and after the EXIT card in the CRAY-1 deck if the plot file is to be disposed regardless of exit status. The DISPOSE card is DISPOSE,DN=$PLT, DC=PT, F=BB.

ARGHET CO INFPUT IUNIT - Logical unit number to which the records have been written.

PRFILM - 1 ARUMENTSCM None OUTFUT

HISTORY Written by Dave Kennison in December 1977, tested by Dick Valent in June 1978.

SPECIAL CoKDmOIs 1. On the DD80 film device, attempts to write or print lines longer than 128 characters on unit IUNIT result in loss of information on film. 2. CRAY-1 jobs sending significant amounts of output to film should contain PRFILM calls at strategic points in the program, rather than relying on a single PRFILM call at the end of the program.

3. Unit IUNIT is rewound after each PRFILM(IUNIT) call; consider, the consequences of these disk rewinds in your program.

4. Avoid IUNIT value 5--it is reserved for the card reader.

PRFILM - 2 PRSIM

PRINTER SIMULATION The Dicomed film and fiche units may be used to simulate C( THE DICCHEDS a line printer on 35mm microfilm, or 105mm microfiche. The fiche unit will be the more popular target for printer simulations, since one can get 270 printer pages on one fiche card with the 48X format. For general information on using the Dicomeds, consult the article "Us- ing the Dicomeds" which is available in the SCD documentation room. In order to put print files to either of the Dicomeds, it is necessary to translate these files into a format acceptable to the Dicomed operating software. Since the Dicomeds presently are run off line, it is necessary to store the formatted printer files on a physical tape for subsequent processing on the Dicomed system. Utilities exist on the CD7600, the CRAY-1, the PDP 11/34, and the PDP 11/70s for the purpose of translating printer files to the proper format. The IFTRAN master file for producing the CD7600, CRAY-1, and 11/70 versions, as well as a portable version, is on volume SOURCE in file PRSIMMI. Instructions for creating the various target files are contained in comment cards at the beginning of PRSIMMI.

*Printer Files There are three types of printer files which can be put to fiche or film: 1. FORTRAN-type printer files. A file of line images in which the first character in each line is to be used as carriage control (1 for new page, 0 for double space, etc.). Compiler listings on the 7600 are examples of such files.

2. Card image files. Files containing 80 character card images.TLB files on the 7600 are examples of such files.

3. ASCII-type printer files. A file of ASCII characters where the carriage and page controls are imbed- ded in the file (form feed for new page, carriage return and line feed for new line, etc.). These files are rare in the NCAR environment, but are generated by some minicomputers.

CD7600 Formatted printer files acceptable to the Dicomeds may be generated on the 7600 by using the binary file PRSIM on XLIB; the FORTRAN source for this file is on PLIB 43510006 in file PRSIM7F (this source is created from the IFTRAN master). By default, input is assumed to come from the card reader, and output is sent to unit 11. Users should be reminded here that non card-image data should not be sent to the card. reader. Various options

PRSIM - 1 may be exercised through control cards in the input stream.

CGNTRLL CARES Control cards have the form /NN:

/APN -- The results of the current execution will be appended to the current output file (the /APN card should occur after a /Onn card, if there is one). /BNN -- Specify number of records to be backspaced on unit NN. The number should follow /BNN and be separated from it by at least one blank, e.g. "/B20 11" would backspace 11 records on unit 20. /CAR -- Indicates that the following input will be card images (this would be used for obtaining a listing of a ULIB file). /FIN -- Terminate processing. This card must be present in every deck. /FRM -- A frame advance is done and the first non-blank character after the final M of FRM will be taken as the start, and the final non-blank character on the card will be taken as the end, of a title for the frame. This title will be centered on the frame, and can be at most ten characters long. /HDR -- Calls to the header routine will produce a header record. This is the default (see /NHD below). /INN -- Redirect the input to come from unit NN. A number may follow /INN separated by at least one blank. If such a number is specified, it will be used to specify how many files should be read from the input unit. If such a number is absent, only one file will be read. After readin the appropriate number of files, the input unit will be reset to unit 5. /KNN -- Specify number of files to be skipped on unit NN. The number should follow /KNN and be separated from it by at least one blank, e.g. "/K20 15" would skip fifteen files on unit 20. /MCL -- Specify maximum card length for input lines. The number should follow MCL (e.g. /MCL 72), and it should not exceed 133. The number assigned to MCL will be the actual number of characters which will appear on the output lines. The default is 80 for card-image files, and 133 for FORTRAN-type files. /NHD -- Calls to the header routine will not produce a header record. This will suppress all subsequent titling until a /HDR card is encountered.

PRSIM - 2 /Onn -- Redirect the output to go to unit nn. Default is logical unit 11. If the input for the output unit specified on a /Onn card is to come from a unit specified by a /Inn card, the /Onn card must appear first since processing is initiated by a /Inn card. /PRL -- Indicates that the following input will be a FORTRAN-type print file (as discussed above). This is the default setting. /Rnn -- Rewind unit nn. /Snn - Redirect echoing of control cards to unit nn. /SOO will completely suppress the echo. /TIT -- The first non-blank character after the last T of TIT will be taken as the start, and the last non-blank character on the card will be taken as the end, of a new current title. A fiche advance will be effected and the new title will be used as the main title on all subsequent fiche until another /TIT card is encountered. If a title is requested operators, this title will override all titles specified on /TIT cards. The maximum number of characters allowed for the various units is:

22 for 35mm film 15 for 24x fiche 28 for 48x fiche

Any title longer than what is permissible will be truncated appropriately. A standard feature of all titles originating from a /TIT card is a section similar to the one produced by the system library routine NAMEFR wherein is displayed the user name, time of job execution, date of job execution, scientist number, project number, sequence number, and a code to indicate the machine of origin. This section will be produced even if no title is specified, so the user need not be concerned about specifying a name or other identifying words in the title. /ZRO -- Put out a zero-byte-count record. This is a technical feature to aid in using the off-line system, and the average user will never want it.

The range of nn on the preceding control cards is from 01 to 99, with the one exception being /SOO. Control cards are echoed to unit 6 in the absence of a /Snn card. PRSIM on the 7600 does not rewind the input unit at any time, unless a /Rnn card is processed. SYSRCL is called upon normal termination. As a worst case time estimate, PRSIM runs at the rate of 10 full pages per second of 7600 CPU time. Typical printer listings will run from

PRSIM - 3 1.5 to 4 times this fast. A PPU time equal to CPU time will always be more than adequate.

PRSIM - 4 EXAMPLES (F 1FSI USAGE (N THE 7600

Example 1 ULIB LISTING TO MICROFICHE Suppose it is desired to get a listing of the ULIB version of AUTOGRAPH on microfiche. The following deck will put the formatted printer file on user tape Bxxxxx:

*JOB,... **AUTOGRAPH TO TAPE** *LIMIT,T=20S, PT=15S *VOLUME, 11, VSN=Bxxxxx ,STAGEOUT=DT *RUN, BS=PLIB,BN=PRSIM, P=XLIB, ED,EM /CAR FETCH S=ULIB, SN=AUTOGRAPH /FIN *END

After completion of this run on the 7600, submit a Dicomed request card to the operators requesting fiche text. Specify a title on this card if you want. Remote users will either have to phone an operator or send a message over their rje terminal to the operators to accomplish this.

Exaple 2 COMPILER LISTING TO MICROFICHE

At the present time it is not possible to obtain a copy of a complete 7600 printer file on any device other than the line printer or the dd80. It is possible to obtain compiler listings on MSD volumes, however, by simply specifying LU=n (where n is a logical unit number) on the *FORTRAN card. Since the compiler will not write an EOF after each file, if it is desired to have such, execute the binary file EOF10 on PLIB 43510006. This will write an EOF on logical unit 10, so logical unit 10 will have to be used to receive the FORTRAN compilations in this case. The following deck will produce, on user tape Bxxxxx, a formatted printer file of the FORTRAN compiler listings of the ULIB files RK1 and AMI.

PRSIM - 5 *JOB ,.. **RK1, AM l TO TAPE** *LIMIT, T2S,=2S PT *VOLUME, 10, VSN=RK 1AM 1 *VOLUME, 11, VSN=Bxxxxx, STAGEOUT=DT *FORTRAN, S=ULIB, SN=RK1, LU=10,FL *RUN, BS=PLIB, BN=EOF O,P=43510006, EM *FORTRAN, S=ULIB, SN=AM 1,LU=10,FL *RUN,BS=PLIB, BN=EOF10,P=43510006,EM *RUN, BS=PLIB, BN=PRSIM ,P=XLIB,ED, EM /R10 /ITO 2 /FIN *END

Example 3 EDITOR LISTING TO MICROFICHE At the present time it is not possible to obtain a copy of a complete 7600 printer file on any device other than the line printer or the dd80. This makes it impossible to obtain editor listings from the print file directly, but a utility has been written to simulate editor listings. This utility is on binary file ED2FI on PLIB number 43510006; it reads precisely one card, and the characters on this card will be used as the title on each page header (this will normally be the file name). Each invocation of ED2FI writes the current editor listing to logical unit 1 together with an EOF, so logical unit 1 must be assigned. ED2FI must be executed immediately after a *EDIT since it uses a temporary file created by the editor. The following deck will produce, on user tape Bxxxxx, a formatted printer file of the editor listings of AMI and RK1:

PRSIM - 6 *JOB,... **EDITOR LISTINGS** *LIMIT,T=15S, PT=15S *VOLUME, 1,VSN=AMRKSC *VOLUME, 15, VSN=Bxxxxx,STAGEOUT=DT *ED IT,S=ULIB, SN=AM 1 *RUN,BS=PLIB,BN=ED2FI, P=4 3510006, EM AMI *EDIT, S=ULIB,SN=RK1 *RUN, BS=PLIB, BN=ED2FI, P=43510006,EM RK1 *RUN,BS=PLIB,BN=PRSIM,P=XLIB,ED,EM /015 /R01 /I01 2 /FIN *END

Example 4 DIFFERING FILE TYPES TO THE SAME MICROFICHE As a more complicated example of the usage of PRSIM, suppose it is desired to get a listing of AUTOGRAPH from ULIB, a FORTRAN-type print file stored as the third file on mass store volume DCOT07, and card file FISH.EX1 on PLIB 43230001. The following deck will produce the desired formatted print file on user tape Bxxxxx, together with appropriate frame titles between files, and with a main title as specified on the /TIT card.

PRSIM - 7 *JOB,... ** CREATE PRINTER FILE ** *LIMIT,T=25S, FT=25S, PR=70 *VOLUME, 10, VSN=DCOT07, STAGEIN=MA *VOLUME, 15, VSN=Bxxxxx, STAGEOUT=DT *RUN, BS=PLIB, BN=PRSIM, P=XLIB, ED, EM /015 /CAR /TIT DIFFERING FILE TYPES /FRM AUTOGRAPH FETCH S=ULIB, SN=AUTOGRAPH /PRL /FRM DCOT07 /K10 2 /I TO /CAR /FRM FISH.EX1 FETCH S=PLIB, SN=FISH. EX 1,P=4 3230001 /FIN *END

CRLAY-1 The text formatter on the CRAY-1 is absolute binary module PRSIM; the FORTRAN source for this file is on PLIB 43510006 under PRSIMCF. This source was created from the IFTRAN master. This program can be used in one of two modes: program control may be specified by data cards or by parameters on the PRSIM control card (these modes will be called card input mode or parameter mode respectively). Once a mode is selected for a given invocation of PRSIM, it cannot be changed.

PRSIM - 8 The general form of the PRSIM CRAY control statement is:

PRSIM,I=inl:in2:... :in50,0=on,SAVE=sv,TITLE=ti,KEY=ky, BLANK=bk,IMODE=im,ITYPE=ty,MCL=cl,FRM=fm,APN,LOG

Parameters are in keyword form and none is required.

I=inl:... :in50 Input file specification in parameter mode (see IMODE below). inlt,...,in50 are CRAY dataset names. Any number of input datasets from 1 to 50 may be specified. The default is $OUT for int, and in2,...,in50 are undefined in the default case. The input files are rewound both on entry to and exit from PRSIM.

O=on Output file specification. "on" is a CRAY dataset name. Default is $CPR.

SAVE=sv Specify whether the input files should be preserved or destroyed. sv can be either S, for save, or D for destroy. If SAVE=S, then a copy is made on the CRAY-1 disks of each successive input file, and that copy is used for all subsequent execution. The initial input files are unchanged in the case SAVE=S. Usage of SAVE here should not be confused with the SAVE control statement on on the CRAY-1. Default is SAVE=D.

TITLE=tl Specify title for header record. tl is a quoted character string. See the description of the /TIT control card in the CD7600 section for a complete description of title lengths, etc.

KEY=ky Specify key for control cards in card input mode. ky is a single character which will be taken as the key for control cards in card input mode. Default is /.

PRSIM - 9 BLANK=bk Specify, in decimal, the blank compression key used in $OUT. This is a technical detail and the average user need never pay any attention to its setting, but the option is offered here for compatibility with the similar option offered by the COS. The default is 27 (base 1O), which is the default as set by the COS.

IMODE=im Specify input mode. im can be either C for card input mode as discussed above, or P for parameter mode. All parameters described here are valid equally for card mode or parameter mode except for I and 0. If IMODE=C, then I and 0 will be ignored, and the program will look for its input and control from unit 5. Default is IMODE=P.

ITYPE=ty Type of the input file. ty can be either F, for FORTRAN-type, or C, for card image. The default is ITYPE=F (which is compatible with $OUT).

NF=NMF Specify the number of files to be read from the input file. If NF does not appear, all files will be processed (the default is set in this manner in order to accommodate $OUT files which in general have an indeterminate number of end-of-file records.)

SKIP=SKP SKP files will be skipped on the input dataset before processing begins. Recall that the input dataset is rewound before and after PRSIM execution in parameter mode, so if SKIP=N, N files are skipped, starting at the load point.

MCL=cl Specify maximum card length for input lines. The number assigned to MCL, which cannot exceed 133, will be the actual number of characters which will appear on the output lines. The default is 80 for card-image files, and 133 for FORTRAN-type files.

FRM=fm A frame advance will be executed as the first frame of this execution having as a frame title the first ten characters of fin. This feature can be used in conjunction with APN to produce frame titles between listings in parameter mode.

PRSIM - 10 APN If APN appears in the control parameter list, the results of the current execution will be appended to the current output file. This parameter allows for successive calls of PRSIM in parameter mode, with all the results going to one output file.

LOG If LOG appears in the control parameter list, a modified version of the user log file will be appended to $OUT. The accounting information and accumulated CPU time will not appear. The complete user logfile will still be produced on paper.

Paraeter Mode In parameter mode, all input datasets are rewound before and after PRSIM execution, but in card input mode the input files are never rewound unless a /RNN control card is encountered.

Usage in card input mode is almost identical to the way the 7600 version of PRSIM is used. There is one additional control card, /LOG, for the CRAY-1. When this card is encountered, a modified version of the user logfile will be produced, which will be accurate only up to the time of the call. To use the program in card input mode, specify IMODE=C on the CRAY control card. Also, control cards are echoed to the user logfile in this case, but due to a buffer size limitation, only the first 64 characters of the card are echoed.

The worst case time estimate for PRSIM on the CRAY-1 is 40 full pages of printer output per CRAY CPU second. Typical jobs will run 1.5 to 4 times faster than this.

EXAILES (IFPRSIN tAGE ON THE CRAY-1

ExajLe 1 $OUT TO MICROFICHE The following deck is an example of how to put $OUT to mass store volume Bxxxxx.

PRSIM - 11 *JOB,... ** $OUT TO MASS STORE VOLUME** *CRAYT, CH JOB, T= 1. ACCESS, DN=PRSIM. CFT. PRSIM, O=Bxxxxx. DISPOSE,DN=Bxxxxx,SDN=Bxxxxx,DC=ST,DF=BB,MF=76,WAIT. *. SHIP JOB TO DESCEND TAPE TO 7600 COPYF, I=$IN, O=TEMP. DISPOSE, DN=TEMP, DC =IN. EOF PROGRAM SMALL C C SMALL PROGRAM JUST TO PUT SOMTHING IN $OUT C A = 0. STOP END EOF *VOLUME, 9, VSN=Bxxxxx, STAGEIN=MA, DS=600,STAGEOUT=DT *END

This job will automatically descend mass store volume Bxxxxx to physical tape in a separate job on the 7600.

Exaple 2 TWO FILES TO MICROFICHE

The following deck is an example of how to put $OUT (with a modified version of the user logfile) as well as a FORTRAN-type file (stored as the first file on volume DCOT07) to user tape Bxxxxx:

PRSIM - 12 *JOB,... ** TWO FILES TO Bxxxxx ** *VOLUME, 2,VSN=DCOT07,STAGEIN=MA *CRAY I1 *VOLUME, 2, VSN=DCOT07 *CRAYt, CH JOB, T= 1. ACCESS, DN=PRSIM. ACCESS, DN=DCOT07. CFT. PRSIM, I=$OUT: DCOT07, O=Bxxxxx, LOG. DISPOSE, DN=Bxxxxx, SDN=Bxxxxx, DC=ST, DF=BB,MF=76,WAIT. *. SHIP JOB TO DESCEND TAPE TO 7600 COPYF, I=$IN, O=TEMP. DISPOSE, DN=TEMP, DC=IN. EOF PROGRAM SMALL C C SMALL PROGRAM JUST TO PUT SOMETHING IN $OUT C A = 0. STOP END EOF *VOLUME, 9, VSN=Bxxxxx,STAGEIN=MA, DS=600, STAGEOUT=DT *END

PRSIM - 13 CARD INPUT MODE

Suppose one wanted to do the same task as in the 7600 example 4, A deck to do this would be:

- - - 2u>ffian:

*JOB ,... ** PRINTER FORMATTER FOR THE CRAY ** *VOLUME, 1,VSN=FRDTMP,STAGEINZS, STAGEOUT=ZT *VOLUME, 2, VSN=DCOT07,STAGEIN=MA *VOLUME, 3, VSN=FRDTP 1I,STAGEIN=ZS, STAGEOUT=ZT *EDIT, D=3 FETCH S=ULIB, SN=AUTOGRA PH *EDIT, D=1 FETCH S=PLIB, SN=FISH.EX 1,P=4 3230001 *CRAYT *VOLUME, 1, VSN=FRDTMP *VOLUME , 2, VSN=DCOT07 *VOLUME, 3, VSN=FRDTP T *CRAYT, CH JOB, OLM=50,T= 10 ACCESS, DN=PRSIM. ACCESS, DN=DCOT07. ACCESS, DN=FRDTMP. ACCESS, DN=FRDTP . ASSIGN, DN=DCOT07, A=FT 10. ASSIGN, DN=FRDTMP, A=FT 1. ASSIGN, DN=FRDTP t A=FT T2. ASSIGN, DN=FRDOUT,A=FT 15. PRSIM, IMODE=C. REWIND, DN=FRDOUT. DISPOSE, DN=FRDOUT, SDN=Bxxxxx,DC=ST,DF=BB,MF=76,WAIT. *. SHIP JOB TO DESCEND TAPE TO 7600 COPYF, I=$IN, O=TEMP. DISPOSE, DN=TEMP, DC=IN. EOF /015 /CAR /TIT DIFFERING FILE TYPES /FRM AUTOGRAPH /IT2 /PRL /FRM DCOT07 /IT0 /CAR /FRM FISH.EX1 /I 1 /FIN EOF *VOLUME, 9, VSN=Bxxxxx,STAGEIN=MA, DS=600, STAGEOUT=DT *END

PRSIM - 14 The control cards are echoed to the log file in this case (in the absence of a /Snn card).

The following documentation will be of no value to the general user since the PDP 11/34 is dedicated to the Dicomed system and is not available for general use.

PDP 11/34 PRSIM.TSK is a task on DK2:[10, i] for creating tapes from RSX-11M files which can be input to the printer translator NCARPR. This task is most useful for creating microfiche of listings which are too large for printing on the DECwriter in a reasonable amount of time.

Before using PRSIM, you should know the file type of the files you wish to put on fiche (as described above). If you are unsure of the file type of your file, use DMP to dump out the first record. The program is interactive, and it will ask you what it needs to know. Just mount a tape and enter RUN DK2: [10, 1]PRSIM

and answer the questions it asks. The Dicomed software has yet to be modified to take its titling information from a header record, so if you request a header record, it will be produced, but ignored by the Dicomed software at the present time.

The tape produced is 1600 bpi. After creating the tape, log off and log on for production. Use MAC 54 (assuming the default settings) and specify a title if desired. PRSIM on the 11/34 takes about 15 seconds of machine time to produce one full page of printer output on film. This is a worst case figure, and one recent dump of the activity log took 80 minutes to produce about 1400 pages of output, thus running about 15 pages per minute.

PRSIM is written in IFTRAN and the IFTRAN source is stored on DK1: TOM X[200,2]PRSIM.IFT.

PRSIM - 15 RI GRIAWFI{ CS

]T_]IfETIQWI The typical way in which most remote users utilize the NCAR graphics facilities is to submit a remote job which runs on one of the NCAR mainframes and produces microfilm. This film is then automatically mailed to the site. If a remote user has access to a plotting device or a graphics display terminal (even a line printer can be used as a crude graphics device), it is now possible for him to receive graphics instructions directly at his site and display the results on the local graphics device. The primary advantage of doing this is the drastic reduction in turnaround time. For example, it would be possible to submit and receive several debug runs in a single day by disposing the graphics instructions directly to a site and displaying them there, as opposed to waiting several days for a single microfilm output to ar- rive by mail. Described here is the procedure for producing graphics instructions at NCAR, disposing these instructions to a remote site, and displaying the resultant picture(s). Two examples are given, and some timing results are considered. The procedure we describe here assumes the user has sufficient local computing power to compile and execute a FORTRAN program of about 1600 lines, which will require about 20K words of central memory to load on a computer such as a PDP 11. If such requirements are not met, less desirable alternatives to the procedure described here exist, and these are discussed in the last section of this article.

CATING GA1MI(H ; A prerequisite to RJE transmission of NCAR mainframe- INSTRUCTIONS AT generated graphics is generation and capture of graphic 1AR instruction files in NCAR's device-independent code, called metacode. Metacode is a graphic instruction set with fairly primitive capabilities-- drawing lines, plotting characters, setting options. A detailed description of the metacode instructions and the metacode file structure can be found in the current NCAR graphics manual. Also, a short article titled "Using Metacode" is available from the Computing Facility Consulting Office. Understanding the details of metacode is not essential for understanding the contents of this article. On the NCAR Control Data 7600 the generation of metacode can be accomplished by running the user's graphics- producing program in conjunction with the metacode- generating system plot package PLOT.META which resides on the NCAR program library XLIB. The inclusion of the access card

RJE GRAPHICS - 1 *FORTRAN, P=XLIB, SN=PLOT.META

in a graphics-generating job on the 7600 will cause the graphics instructions (metacode) to be written to logical unit 8 (unit 8 will have to be assigned in the user's job deck).

The default system plot package on the Cray-1 is a metacode-producing plot package. At termination, the Cray local data set $PLT will contain the generated plotting instructions, and this dataset can be further processed on the Cray-1, or it can be disposed to the 7600 mass store with the execution of a DISPOSE card of the form: DISPOSE,DN=$PLT,SDN=nane,DC =ST, DF=BB,MF=76.

which will dispose the graphics metacode back to the mass store volume "name".

DISOSIGE tMAHIICS Once the graphics instructions are stored on a volume, l]S1iILnO7O TO A the next step is to get them over the phone lines to the REHIOE SITE remote site. There is a small problem here at the present time: the buffer computer through which all remote jobs are transmitted and received (the MODCOMP) cannot transmit binary data. The solution to this problem is to transmit the graphical information as a stream of characters. A utility, HEXER on XLIB, has been written to produce a character representation of a binary dataset. This program reads binary records from logical unit 8, transforms them into records of hexadecimal di- gits and writes these records to the standard output unit (unit 6). The hexed graphics metacode will then be a part of the print file. Since it is desirable to be able to distinguish the hexed metacode from the regular printout in some automatic way, the hexed metacode is written out in lines having 128 hex characters with two right parentheses prepended. These special lines can thus be easily redirected to some alternative to the line printer (such as a file) at the remote site. The fate of the first of the two initial right parentheses depends upon the disposition of the output file--if it is disposed to a printer the first parenthesis will be taken as carriage *control. Both parentheses will survive if the output is redirected to a disk.

The hexadecimal encoding done by HEXER converts each 4 bits of binary graphics instructions into 8 bits of character information. While more compact encodings are possible, they have been avoided for two reasons. First, it is much more difficult to design reliable, portable pro- grans to do 6-to-8 bit or 7-to-8 bit encodings. Second, 4-bit boundaries correspond naturally with the structure

RJE GRAPHICS - 2 of metacode. It is possible, with a little experience, to quickly spot certain instruction types in the hexed metacode, and this can be an aid to debugging.

Once the hexed metacode is at the remote site, it will be necessary to reconvert the hexed lines back into the original binary metacode format. There is a program UNHEXER on XLIB which can be used for this. For UNHEXER to run at a remote site, it will to be necessary to implement a couple of support routines. All required support routines are discussed in the NCAR Graphics Manual. The program UNHEXER will read the hexed metacode file (it will figure out automatically what has been done with the special initial characters) and produce the binary metacode file as desired. Once the new I/O satellite computer arrives and is opera- tional at NCAR (projected date is early in calendar year 1982), the hexing and unhexing part of the procedure will no longer be necessary.

TRANSLATIOIN OF Finally, the metacode must be translated into plotting GRAfHICS instructions for the local device. NCAR supplies a port- INSTRUCBIO~S able FORTRAN metacode translator shell (MCTR.PORT on PORTLIB) which can quickly be adapted to drive a wide range of graphics devices. Complete implementation instructions are contained in comment cards in MCTR.PORT.

Also supplied is a metacode-to-printer translator (MCTR.PRNP on PORTLIB) which can be implemented by setting a few machine constants. Under most circumstances, it is better to use the existing printer translators on the NCAR mainframes (absolute binary module MC2PR on the CRAY-1, or Fortran program MCTR.PRN7 on PLIB 43510006 on the 7600) and transmit the resulting print file, rather than disposing the metacode and translating to a printer at the remote site.

SAMPLE IECSn Consider two very simple example runs illustrating how to create a hexed metacode file on the printer. The first example is for the Control Data 7600 and the second for the Cray-1.

RJE GRAPHICS - 3 Example 1.

*JOB ,ssss ,pppppppp ,nnnn ** SIMPLE 7600 DEMO FOR RJE ** *LIMIT, T=1S, P-=S *ASSIGN, DISK=8 *FORTRAN, FL PROGRAM DRBOX DATA N/32767/ C C USE THE SYSTEM PLOT PACKAGE ROUTINE PLOTIT C TO DRAW A BOX C CALL PLOTIT (0,0,0) CALL PLOTIT (N,0, 1) CALL PLOTIT (N,N, 1) CALL PLOTIT (0,N, 1) CALL PLOTIT (0,0, 1) C C PLOT CHARACTERS C CALL PWRIT (512,512,22HNCAR PLOT PACKAGE TEST,22,3,0,0) CALL FRAME CALL SYSRCL END *FORTRAN, P=XLIB, SN=PLOT.META *RUN, I *FORTRAN, P=XLIB, SN=HEXER *RUN, I *END

When submitted to the 7600, the above deck will produce the standard Fortran listing, load map, etc. In addition, the lines

) 00562800000000007FFF80007FFFFFFFOOOOFFFF00008000E30404000300E302 08013FE03FEOE 1164E43415220504C4F54205041434B4147452054455354E200 )E708000000007FFF7FFFA02OA020A020A020A0 020A020A020A020 )00002800

ALL METACODE DUMPED. NUMBER OF FRAMES= 1

will appear in the listing (the first line above is listed as two lines to get it on the page). The three lines above which have the special character ")" preceding them are the hex representation of the binary metacode produced by program DRBOX. The program HEXER

RJE GRAPHICS - 4 suppresses trailing zeros in the metacode records in order to save time and space; UNHEXER reinserts these. If we were to run the program UNHEXER on a file containing the lines listed above, we would get back the exact binary metacode produced by program DRBOX. The program UNHEXER ignores all lines in the file except those beginning with a ")". Example 2.

*JOB,ssss,pppppppp,nnnn ** SIMPLE CRAY-1 DEMO FOR RJE ** *CRAY1, CH JOB, OLM=20,T=50. ASSIGN, DN=$PLT ,A=FT08. ACCESS, DN=HEXER. CFT. LDR ,MAP. REWIND, DN=$PLT. HEXER. EOF PROGRAM DRBOX DATA N/32767/ C C USE THE SYSTEM PLOT PACKAGE ROUTINE PLOTIT C TO DRAW A BOX C CALL PLOTIT (0,O,0) CALL PLOTIT (N,0,1) CALL PLOTIT (N,N, 1) CALL PLOTIT (0,N, 1) CALL PLOTIT (0,0, 1) C C PLOT CHARACTERS C CALL PWRIT (512,512,22HNCAR PLOT PACKAGE TEST, 22, 3,0,0) CALL FRAME STOP END *END

If the above deck is submitted for execution on the CRAY-i, essentially identical lines as those for the 7600 example will appear in the printout (a few additional no-op instructions appear because of differing buffer sizes in the CRAY-1 system plot package).

Once the printouts are received at a remote site, all that remains is to run UNHEXER and translate the resulting metacode to the appropriate plotter instructions. This can usually be done in one run, just as the metacode production and hexing were done in one run in the above examples.

RJE GRAPHICS - 5 TIMING Our estimates of machine resource requirements and file OamSIEAT S transmission sizes assume the use of a portable, metacode-producing, plot package supported by NCAR. This package could be modified or replaced for somewhat im- proved performance and smaller files, at the expense of portability, reliability, and NCAR support. If a significant amount of graphics is done at a remote site, it will not take long to discover a basic fact--it is expensive. For example, based on statistics of graphics usage, the "average" frame has 15,000 8-bit bytes of binary metacode (this statistic is obtained by dividing total bytes of metacode by total frames produced over a four month period). The amount of Control Data 7600 CPU time required to hex this amount of metacode is 1.18 seconds. Recalling that the hexing results in about a 2-to-1 expansion in file size, an average frame will require that about 30,000 bytes be shipped over the phone lines. The transmission rates of the phone lines coming into the MODCOMP range from 300 to 4800 baud. Transmis- sion of 30,000 bytes would take 800 seconds over a 300 baud line, or 50 seconds over a 4800 baud line. The amount of time required to unhex the hexed metacode at the remote site would of course depend on what machine it was done on. The amount of 7600 time required to unhex 30,000 bytes of hexed metacode is 1.98 seconds.

To get a feel for how much binary metacode is associated with what kind of plot, consider the following table, all of whose plots can be viewed in the sample plots section of the NCAR Graphics Manual.

ROUTINE BYTES OF BYTES OF HEXED METACODE METACODE

CONREC entry of CONREC 7200 9230 EZMXY entry of AUTOGRAPH 8640 9880 HAFTON entry of HAFTON 223200 459680 ISOSRFHR 28800 55640 SRFACE entry of SRFACE 8640 13130 Orthographic projection of SUPMAP 69120 138320 WINDOW 2880 1040

The bytes of hexed metacode should be approximately twice the number of bytes of metacode. However, the hexer truncates trailing zeros on metacode records (which have a fixed length of 1440 bytes). Since the metacode for the last record of a frame may not fill the record, and since the final record in a metacode file is nearly all

RJE GRAPHICS - 6 zeros, the bytes of hexed metacode, which is what is transmitted, may fall short of being double the number of bytes of metacode. This is seen in the CONREC, AUTO- GRAPH, and WINDOW files in the preceeding table. On the other hand, due to the two additional characters at the beginning of each hexed metacode line, and due to the fact that the line of hexed metacode associated with the end of an input record is blank padded, it may be the case that the hexed metacode is actually more than double the number of bytes in the original metacode. We see this in the HAFTON example above.

Because of the relative expense involved in RJE graphics, heavy production should still be done by traditional microfilm recording and mailing. However, careful selection and transmission of a few diagnostic pictures can greatly reduce development and debugging time for remote users, at reasonable cost.

ALTEHTIWS If a remote user is contemplating RJE graphics and has the necessary computing power, it is most desirable to proceed as described above. Receiving the metacode at the remote site and doing the translation as close as possible to the target graphics device(s) allows for the greatest flexibility: the metacode can be repeatedly translated with different options (blow-up, rotation, color, character styles, etc.), and if multiple devices are available, the same metacode can be used to drive each of them. If the user does not have sufficient computing power at the remote site to translate the metacode, it still may be possible to do RJE graphics. The remote user can configure the portable translator shell to run at NCAR and produce instructions particular to a specific graphics device and transmit these instructions. This is a practical approach for those devices, such as Tektronix and Hewlett Packard graphics terminals, whose instruction stream is composed of characters, although some scheme would have to be devised for transmitting non-standard characters, such as the ESC character on HP terminals. For binary oriented devices, a character encoding of the instruction stream at NCAR, and decoding at the remote site, would still be required.

AIIUS Fred Clare and Lofton Henderson

RJE GRAPHICS - 7 HCa)D80B

INTRODUCTION Various versions of the system plot package, for a variety of reasons, produce "metacode". A file of metacode (a "metafile") contains a set of instructions for a simple hypothetical plotter, translatable to drive a wide variety of real plotters. Few users of the NCAR Computing Facility need to be aware that there is such a thing as metacode. This article is addressed to users with a specific set of problems with the metacode translator MC2DD80B; others may safely ignore it. Additional and more general information may be found in the Comput- ing Facility Consulting Office, in a document called "Us- ing Metacode".

The Netacode The metacode translator MC2DD80B runs only on the 7600; Translator it reads one or more volumes of metacode and sends instructions to the DD80, creating microfilm with the pictures (graphs, maps, printing, etc.) specified by the metacode. The most commonly used metacode-generating version of the system plot package is the one which runs on the CRAY. Whenever a CRAY job disposes "$PLT" to the 7600 with a disposition code "PT", a 7600 job is spawned to run MC2DD80B with the disposed file (of metacode) as input. If all goes well, this process is essentially in- visible. However, the spawned job may fall short of the desired mark in a variety of ways, some of which are as follows:

1. The default CPU time limit (1 minute) may be exceeded.

2. The default frame limit (1000 frames) may be exceeded.

3. The number of instructions which may be written to the DD80 in off-line mode (about 2 million words) may be exceeded.

4. You may want to make more than one copy of your DD80 output without re-running the entire CRAY job.

In all of these cases, it is necessary to use a different strategy to get your DD80 output. One strategy is this. First, dispose "$PLT" using a CRAY control card like DISPOSE,DN=$PLT,SDN=metacode volume name, EF=BB, DC=ST. so that it will go to a named TMS volume. Then, at your leisure, run the metacode translator to dump translated metacode from one or more TMS volumes to the DD80. The job required will look something like this:

MC2DD80B - 1 *JOB ... (Your job card) *LIMITT=... ,PT... ,DD80=... (Define required limits) *ASSIGN, DD80=ONLINE (Only if absolutely necessary!) *VOLUME,8,VSN=metav1,STAGEIN=MA (The first metacode volume) *VOLUME,9,VSN=metav2,STAGEIN=MA (Second metacode volume, if any) .. .. (Other metacode volumes, if any) *RUN, I,BS=PLIB, P=XLIB,BN=MC2DD80B(Run the translator) *END

The *LIMIT card allows you to set the CPU and PPU time limits and the DD80 frane limit large enough for the volume of metacode being processed.

DDoO GO-Line Jobs with the DD80 on-line are normally not run during the day and tend to interfere with smooth running of the 7600 system, so the card putting the DD80 on-line should be included only when absolutely necessary (when the volume of metacode to be translated is such that the buffer space set aside for the off-line DD80 would over- flow or when more than one volume of metacode must be processed see the next paragraph).

DD8I0 Off-Line With the DD80 off-line, only the metacode volume assigned to unit 8 - "metavl" in the example - is processed; volumes assigned to other units are ignored. With the DD80 on-line, the volume assigned to unit 8 is processed first, followed by volumes assigned to units between 9 and 99, inclusive. These volumes are processed in order of increasing unit number. Because of a system limit, only about 21 such units may be defined for a single job. Also, since all of the volumes assigned in this manner must fit on the disk at once, you may exceed the current disk-block limit and have to add "DO=..." and "DI=. ." parameters to the *LIMIT card; check with a consultant if the number of words of metacode you want to process exceeds 10 or 20 million words or so. If all goes well, MC2DD80B terminates execution with a call to SYSRCL, so that further job steps may be executed.

. Oeaticn Of The creation of metacode volumes involves some problems Metacodxe Volumes for the user; in particular, since no metacode volume written to the TMS may be longer than 10 million words, a CRAY job which writes more than 10 million words of metacode must either be broken into pieces which will write less than 10 million words apiece or be modified so as to dispose "$PLT" every so often. The obvious ques- tion, then, is "How often?". To make life a little

MC2DD80B - 2 easier for users faced with this problem, a routine called DUMPLT has been added to the binary library $NCARLB; the source deck for it is on CRAYLIB, in the dataset named DUMPLT. To use the routine DUMPLT, modify your CRAY program as follows: First, initialize a "volume-nane" parameter, using a statement like

DATA IVNM / 6Lxxxxxx /

where "xxxxxx" is a 6-character prototype metacode volume name, unique to your job. Then, put a call like

CALL DUMPLT (IVNM,nwds,IWRI)

someplace where it will be executed frequently - once per frame, right after the "CALL FRAME", is best, but this rule can be bent a little. (In fact, the rule can be bent a lot, but adhering to it ensures that volumes created will be separately processable, a distinct advantage.) The routine DUMPLT checks to see if the number of words currently on $PLT is less than "nwds"; if so, it returns immediately with IWRI set to zero; if not, it updates IVNM to form a volume name, disposes the current contents of $PLT to a volume of that name on the TMS, and returns with IWRI set to the number of words sent to the TMS. The parameter "nwds" should be less than 10 million by enough so that no volume will be longer than 10 million words; in fact, it is best to use an even smaller number, if possible, so that, if something goes vrrong with a "DISPOSE", not so much will be lost. Put another

CALL DUMPLT (IVNM,0,IWRI)

where it will be executed following the final "CALL FRAME" to force the remaining metacode to be sent to a final TMS volume.

V lume .m.es The volume names generated by DUMPLT will be six characters long, with a sequence number on the right end. For example, if your initial IVNM is XYZOOO, DUMPLT will generate names XYZ001, XYZ002, XYZ003, etc. If your initial IVNM is KMQUAT, DUMPLT will generate names KMQUA 1, KMQUA 2, KMQUA 3, ... KMQU10, KMQU11, etc. Embedded blanks in IVNM will be changed to zeros. If there are calls to DUMPLT in more than one routine, IVNM must either be placed in a COMMON block which is declared in each of the routines or be passed through argument lists in such a way as to ensure that all references to it refer to the same memory location. It is probably a good idea to print the variables IVNM and IWRI whenever the latter comes back from DUMPLT non- zero, so as to have a log of the metacode volumes created.

MC2DD80B - 3 FILM PRODUCTION

TITLE The Production of Scientific Films Using a Digital Com- puter and Optical Output Device

]1NThfI( ON This report considers some of the aspects of the production of movie films using a digital computer and an optical output device. It contains only basic information on the subject and for best results should be supplemented by consultation with experienced personnel. Although the software and hardware assumed available are those existing at the National Center for Atmospheric Research (NCAR) at Boulder, Colorado, it is felt that close paral- lels will be found elsewhere. Computer-generated 16 mm movie films will usually display the results of numerical models, time being one of the independent variables. The objective will often be to present the evolution in time of a variable in a smooth fashion, thus improving on the method of presenting similar information in discrete form by slides. An additional, but at present costly, use for such films is that of a research tool; unexpected oscillations and pulsations in the data may show up in a movie that would remain un- detected in separate pictures. In the sections that follow, attention will first be directed towards the software and hardware tools available, since the movie maker must operate within a rather restricted framework. Following this, general rules for the production of computer-generated films will be discussed together with details of their implementation and of the generation of titles, leaders, trailers, etc. A summary of the photographic processes used is given in the Appendix. COMPUTER RE A comprehensive set of filmmaking tools are available at A SOF RE NCAR. These fall into two categories: (1) the computers and microfilm devices, and (2) established subroutines and subprograms. A third category, the film processing and editing equipment, will be described in the Appendix.

Cputer Hardire Two main computers are used at NCAR: a CRAY-1, and a Control Data 7600. Peripheral equipment includes: large, slower-speed core (7600), disks, and magnetic tape. Of more immediate importance is the microfilm recorder, which is a CDC dd80 cathode ray tube (CRT) plotter, and its associated 35 mm microfilm camera. The CRT consists of a monochromatic beam capable of two levels of intensity other than the normal off state. The beam is posi-

FILM PRODUCTION - 1 tioned according to X-Y coordinates, each of which can take on 1024 discrete values. The resolution is thus approximately that of a 10" x 10" pen plotter with 100 increments per inch, except that the dd80 draws straight lines between any 2 coordinates. A 35 mm camera without a shutter is attached to the CRT via a light-tight case. The picture is produced as follows:

Each trace is made by the beam as it travels in a straight line from one set of X-Y coordinates to the next, illuminating the CRT momentarily. The camera lens is set so that the light from the CRT is focused on the film, and thus the line is recorded on the film. The CRT beam is then turned off. When the plot has been completed the film is advanced. It should be noted that the CRT is not of the "refreshed" type. It would not in general be possible to view pictures directly on the CRT or to obtain conventional movie or videotape films.

The camera is loaded with 35 mm black and white negative film. The spacing between frames is 18 mm, and the used portion of each frame is 14 x 14 mm. The film is equipped with sprocket holes, 4 per frame. This feature is essential to filmmaking, for without it successive frames would not be correctly registered. The frame advance and the plotting may be done on-line or off-line. In the off-line mode the plotting instructions are stored on a disk of limited capacity for plotting during output phase. The camera can plot pictures at a maximum rate of about 30 frames per second, although complex pictures can slow the rate to as slow as one picture per second. When operating in the on-line mode the complexity of the calculations generating the picture may further increase the production time. In order to produce films of high quality, the microfilm recorders must be in good mechanical and optical adjust- ment, otherwise the resulting films can show evidence of jitter or poor focus. It is therefore advisable to noti- fy the computer operations personnel that a lengthy run is about to be made, and request a test. Finally, the magazine should be checked to see that sufficient film is available (a full magazine holds about 15,000 frames).

GCcutber Sftare The software described in this section is of two types: (a) subprograms that are used to produce displays such as contours and perspectives (see [1]), and (b) subroutines that are used in the plotting phase (automated production of labelled axes, graph backgrounds, writing, etc., see [2]). The software is provided as a service of the computer center and spares user's having to write their own programs. Typical programs of class (a) are discussed below.

FILM PRODUCTION - 2 Contouring These are available in various degrees of sophistication, Programs and are based on computing the points of intersection between a contour and the sides of a square having data at its four corners. Simple contouring programs merely connect the points of intersection by straight lines (see the Sample Plot for CONREC in [1]). In more sophisticated programs, the points of intersection encountered by a particular contour are placed in order and use is made of splines to produce a suitable curve (see the Sample Plot in CONRECSMTH in [1]). Automatic labelling of contour levels, highs and lows, and accentuation of particular contours are available. The amounts of computer time required by these programs may differ considerably, an important factor when perhaps 5000 different diagrams have to be calculated.

Perspective Considerable use is made of this type of presentation in Programs computer-generated films. A real surface (land, sea, etc.) or a mathematical surface may be shown (see the Sample Plot for SRFACE in [1]). For input the programs are given the X or Y coordinates of perpendicular lines at whose points of intersection the data exists, the height of the surface at these various points, and information concerning the observer's position and line of sight. The line of sight information gives the orientation of a plane which will ultimately coincide with the plotting surface. Hypothetical lines are then drawn between the observer and each data point, and the X-Y coordinates of the point of intersection of this line and the above plane are then computed. These coordinatige are then scaled according to the size of plot desired. Be- fore the points are connected to form the surface, the program may compute how much of the line connecting the points is visible. A variety of options are available. For example, one can choose to draw all the lines (whether hidden or not), to draw only those lines visible from above (or below), and to add a "skirt" so as to provide the viewer with the impression of looking at a solid ob- ject.

Vector Programs This type of routine displays two-dimensional velocity fields. Arrows are drawn at the data locations showing the speed and direction of the flow (see the Sample Plot for VELVCT in [1]).

Subprograms of class (b) are chiefly concerned with the plotting of previously processed data. Most of the dd80 plotting subroutines are similar in nature to those used with pen plotters, with the exception of a CALL FRAME instruction which is used to advance the film.

One particular set of subroutines of great importance in computer-assisted filmmaking are the NCAR FLASH routines.

FILM PRODUCTION - 3 These routines are used to avoid having to recalculate plots (such as grids, axes, map outlines) of a repetitive nature. In film production the FLASH routines are of inestimable use. For example, one can often employ 2 or 3 identical frames in succession for motions which are not rapid and significantly reduce the computer resource expense. As developed by NCAR, the FLASH routines are applied in the following manner.

At the start of the program an array is dimensioned for example,

DIMENSION ISTORO (1000)

and is set aside to hold plotter commands. Up to 11 arrays can be used in this fashion. When a series of plotter commands is to be stored in the ISTORO array, the instruction

CALL FLASH ! (ISTORO, 1000)

is inserted. Plotting instructions are then programmed as usual, however, the resulting plot commands are not executed but are stored in the array ISTORO.

When the series of plotter commands is to be terminated the instruction CALL FLASH2(0,LNGTHO)

is inserted. The integer 0 refers to the first array of 11 permissible arrays and integers I through 10 would serve to identify the remaining 10 arrays. The number of words actually filled in ISTORO by the plot commands will be returned in LNGTHO. This is used to reduce the dimension of ISTORO to a minimum in later program runs.

Finally, whenever one wishes to send the plot commands contained in ISTORO to the dd80, the instruction CALL FLASH3 (0)

is used. Instead of 0, any other integer (1 through 10) corresponding to any other of the filled storage arrays can be used.

To produce three identical frames, say of a perspective view, at each time step FLASHI is used, then one computes the perspective view, terminates the calculation with FLASH2, and then uses a DO loop encompassing FLASH3. By this stratagem one has reduced the number of computations from 24 to 8, per second of the final film. The importance of making full use of the FLASH routines cannot be

FILM PRODUCTION - 4 too strongly emphasized.

F]LN PRODUITION It is greatly to the filmmaker's advantage if the decision to produce a film is made at an early stage of the research. All too often the idea of making a film occurs after the research has been completed, with the result that much of the work may have to be redone to put the results into a form suitable for filming.

The magnitude of the task faced in the production of a scientific film can be formidable in terms of programming effort as well as expenditure of computer resources. A 16 mm sound film will ultimately be run at 24 frames per second: 1400 frames will be required for a 1-minute film, 7200 for a 5-minute film, and 14400 for a 10-minute film. Should a color film be desired, the 35 mm black and white film requirements are multiplied by the number of basic colors involved (generally 2). These figures indicate that filmmaking is likely to be costly in terms of computing time and film.

General RIles Although most of the following comments may be considered obvious to those with experience in film production, an attempt will be made to set down some general rules concerning the choice and generation of displays. 1. If a film is to be made, one should have something that moves. That is, one should have an appropriate subject, not merely the desire to make a film.

2. Avoid overpowering the audience with too much information. The temptation to do this is admittedly great for two reasons. The first is the very human urge to impress people by cramming as much information as possible into the picture. The second reason is that often much of the initial research is conducted with the aid of detailed diagrams produced on microfilm. During the research phase, the scientist can study these "frozen" diagrams at his leisure, becoming familiar with them. When the research has been completed, it is tempting to make a film merely by producing a much larger number of frames separated by small time intervals. This, of course, will serve the dual purposes of producing a 16 mm film while leaving the scientist with the original detailed 35 mm microfilm for later analysis. The problem is that the audience may be unfamiliar with what is being shown, and furthermore, is being presented with a situation that is evolving with time. As a result, the audience may be impressed with the presentation, but fail to grasp the scientific content of the film.

FILM PRODUCTION - 5 Ideally, the filmmaker will decide well in advance what he wishes to bring to the attention of the audience and will clarify his display to achieve this goal. A possible exception to this approach might occur when the film will ultimately be shown in closed-loop or cartridge form. In this event a more complicated film, lasting, say three minutes, might be shown. By repeating the projection, the audience will become familiar with the display and with the sequence of events.

3. Extensive computation should be avoided during the production of the film; films should be made from history tapes of the model runs. Because of the complexity of filmmaking, mistakes can be made that spoil the film and require recomputation of the 35 mm frames. By making the film from a history tape and using practice runs, the cost of blunders is drastically reduced. 4. The fourth rule is to avoid gimmicks. This form of temptation is best illustrated by an example. A film was produced that made use of a sophisticated perspective subprogram to display the vertical move- ment of the Irish Sea. Time was displayed by means of a clock, the hands of which rotated. On showing the film to various audiences, it became apparent that the clock had a hypnotic effect, to the extent that instead of asking questions about the subject matter or the perspective program, most of the questions asked concerned the clock. 5. Adequate time should be available for comprehending the events in the film. Additional complications arise when a sound track is to be included: sufficient time must be available for the commentator to describe the events taking or about to take place.

The heart of the time problem is the 24 frame per second projection film speed. It is essential that a certain minimum number of views be obtained to avoid jerky movements. This is related to the time step and time duration of the original calculations. Often a particular model time step is selected at an early stage in the research, and this value is used in preparing some driving function (such as wind field data for a storm surge model). Ultimately, for purposes of film production, it may be desirable to halve the time step to obtain a film of suitable length. However, it might prove totally unaccept- able to recreate the wind fields associated with the new time interval by rerunning the problem. Thus it is worth paying careful attention to the time step

FILM PRODUCTION - 6 and computation procedure. If the time step is not reduced, there are three ways in which a short length of film can be made more acceptable. The first two of these depend on frozen motion. The fist of the methods is to freeze the motion at the start of the film sequence. As much time as is needed can be used to orientate the audience and to acquaint them with what they are about to see. Similarly it is good practice to freeze the motion at the end of the film. The second method is to intentionally produce a jerky motion by having perhaps 24 identical frames for each original time step. This obviously extends the total running time and can on occasions be useful for imparting to the audience a feeling for the discrete nature of the original calculations. Last- ly, intermediate steps between data at two times can be generated by interpolation. Linear interpolation produces completely acceptable results. The following section concerns points to bear in mind when writing the basic program. Plotting algorithms may produce satisfactory results for individual times during a simulation, but problems can arise when these displays are used in a filmmaking mode. For example, the numerals indicating the contour level values in a contour may appear to jump around, instead of progressing smoothly across the screen as time progresses. NCAR's contouring routines attempt to minimize this problem.

A second and more easily corrected problem is associated with the need to reduce the information contained in a single film frame. When going from a pen plot to a film frame, one should consider reducing the number of contour levels (or streamlines, or current vectors) by a factor of four. A final example, along the same lines, is that writing and numbers should be made large in size and kept to a minimum.

Color Files The extension from black and white films to color films is straightforward. The main obstacles are economic. Remember that the dd80 microfilm recorders are equipped with monochromatic cathode ray tubes, and that the microfilm itself is black and white. Assume that the color film to be produced will be based on two colors, A and B. Thus, besides the background (normally black), three colors are available: A, (A + B), and B. Consider a figure having titles, a clock, and a sea having an outline, sea current vectors, and surface contours. The following division between the two colors is suitable:

FILM PRODUCTION - 7 Color A: current vectors Color B: contours, clock, titles Color (A + B): sea outline. Use can be made of the FLASH routines to store the plot commands associated with stationary parts of the display (clock face, titles, sea outline). The technique for producing the color film is then as follows. For a particular time step two successive microfilm frames are required. The first frame will contain all the lines to be shown in color A, the second frame will contain all the lines to be shown in color B. A line ultimately to be shown in color (A + B) is drawn in both the frames (this will also have the effect of slightly thickening the line). For the above film we have: 1. 1st frame: current vectors, (sea outline)

2. 2nd frame: contours, (sea outline), [clock face and titles], clock hands. (The two types of parentheses indicate items stored in two FLASH storage arrays.)

This process is repeated for every time step. To produce the color film it is necessary to merge each pair of black and white frames onto a single frame of color film. The process is described in the Appendix. Additional points to remember are:

1. The process at once doubles (or triples, in the case of three basic colors) the black and white microfilm requirements. 2. It is difficult to check the appearance of the 35 mm black and white film on a film viewer, since, for two colors, the film would have to be run at 48 frames per second so as to be equivalent to the final 24 frames per second projection speed.

3. Care should be exercised in the choice of the colors. If the 16 mm film uses a black background one should avoid colors of dark hue (deep blues or reds) and stick to colors such as yellow or light blue.

Leaers and To facilitate editing and to protect the start and end of raiers the film roll, produce a few blank frames at the beginning and end of each film sequence. This is easily accomplished by making ten calls to FRAME.

FILM PRODUCTION - 8 Titles Titles can easily be produced by the computer and should be of fairly large size and clearly legible. Further- more, for a static title, it is good practice for the title to remain on the screen for an amount of time equal to that required to read it slowly aloud.

If technical information is to be conveyed to the audience by means of writing, the use of scrolling should be considered (see the write-up for SCROLL in [1]). The writing appears at the bottom of the picture, moves slowly through the field of view, and out of the top of the picture. This type of presentation has the great advantage that the audience knows just how much time is available for reading the information shown on the screen. Viewers do no have to race through the writing for fear that the static writing will disappear. It is good practice to start and end with one second of frozen scroll. Finally, the acknowledgments should not be neglected.

Tracks The addition of a sound track can substantially add to the value of a film. First, the best possible use of the available time is made (usually very limited in films produced on a computer). Second, the film can achieve a wide distribution without the need for the scientist him- self to be present.

The techniques used in producing the sound track will not be described here since a professional studio is normally employed. However, there are several points to bear in mind. The most important is that it is advisable to have a tentative sound track prior to beginning film production. As in the visual portion of the film, avoid overpowering the audience with too much information. Use should be made of frozen motion at the start of a sequence in conjunction with narration to orient the audience. At the end of the description the scene would be unfrozen, and the audience would be able to devote full attention to the scene itself. Similarly, if the motion is again frozen at the final frame of the sequence, a summary can be given to reinforce the description previously given.

A second helpful technique for drawing attention to a particular highlight occurring at a given time is to describe the event about to occur well in advance, leaving a few seconds of silence before the event. The audience will then anticipate the event.

Editing It is usually not practicable to produce the entire film, titles, scenes, acknowledgments, and "end" in one computer run. Although the editing process is reasonably straightforward there are two items worth mentioning. Making use of a film editor, the sequences can be assem-

FILM PRODUCTION - 9 bled in the correct order on a large reel, joining the sequences with tape in a form ready for splicing.

Secondly, using a viewer of good quality, running at 24 frames per second, the sequence should be checked to see that it is free from jitter. At the same time the sequence content can be checked.

SUMMARY Although basic rules and advice for making computer- generated films have been covered in the preceding sections, it is worthwhile noting some of them again. 1. Consult with computer department staff and look at examples of computer-generated films. 2. Decide whether or not a film is the best way of presenting the information.

3. Decide whether the film is to be accompanied by a sound track, and if so write it down and put time marks on it. 4. If possible, select a time step for the numerical model that will allow the film to satisfy both the requirement of giving the audience sufficient time in which to assimilate the events taking place and, if relevant, the requirement that the narration must dovetail with the events being described.

5. If possible, create a history tape of the output from the numerical model so as to reduce computer costs.

6. Select the most effective way of displaying the data fields (graphs, contours, vectors, perspectives, etc.). Keep the plot as simple as possible, avoid gimmnicks likely to distract the audience, and avoid the unnecessary use of more than one color. 7. Avoid the temptation of taking the shortcut of making a film by merely decreasing the time internal between complex plots that were initially designed to display large amounts of information at infre- quent times.

8. Make the greatest possible use of the FLASH routines.

9. Generate 10 or so blank frames at the start and end of each sequence. If necessary, identify the sequence before the leader by generating a suitable plot.

FILM PRODUCTION - 10 10. When generating titles, allow sufficient time for them to be read slowly. The use of scrolling re- lieves the viewer of the worry that the title will disappear before he or she has finished reading a static title. 11. In the absence of a narration, it may be desirable to generate explanatory text for insertion between the various sequences. 12. Consider the generation of acknowledgments; their use is usually appreciated. APPENDIX

Ptotographic The dd80 uses a 35 mm black and white film, Dacomatic K, Processes which is sensitive to the green light given off by the CRT. As stated previously, the use of sprocketted film is vital when movies are being made. Exposed film is collected on the take up reel of the dd80 and periodical- ly unloaded for developing. In a darkroom, the film is transferred to the input canister of the developing machine with a (reused) trailer added to allow t:he film to pass completely through the developing machine. The machine is constructed so as to prevent light from reaching the film while it is still sensitive. Thus, the machine can be operated in normal room light.

First, the canister is mounted on the developing machine with the film attached to the trailer from the last batch of film developed. The film developer must be capable of "reversal" type film processing where the film is passed through a "first developer" solution, a bleach and a clearing bath and then is exposed to a bright light. Then the film passes through a "re-developer" and the normal stop, fix, and rinse solutions before being dried and rolled on the output reel. All the chemicals are compatible with Dacomatic K film. After the film has passed through the machine, the end of the trailer is found and the machine stops. At NCAR, a Fulton developing machine is used, and it processes 28 feet of film per minute. With reversal-type film processing, lines drawn on the CRT appear as clear lines on the black background of the film. When a print is made, the lines appear dark on the white background of the paper, as with plots made on a mechanical plotter. Because few institutions other than movie theaters have 35 mm projectors, the film must be reduced to 16 mmn. For black and white movies, this is done by making a master negative on an optical reduction printer and using the

FILM PRODUCTION - 11 negative to make prints of the movie for projection. Us- ing this process, the lines drawn on the CRT appear as dark lines on an illuminated background when projected on the movie screen.

When making color movies, an optical printer with special capabilities must be used. A filter is used to change the white light passing through the film into the appropriate color. The black and white input film must be advanced once for each color before the output color film is advanced. Once the 16 mm color positive is made, it is used on an optical printer to make prints for projection. Using these processes, the lines drawn on the CRT appear as colored lines on a dark background. Where two colors superimpose, the resulting color tends toward white.

Because of the number of photographic steps in producing the print for the projector, and because no optical device is perfect, the lines on the projection print appear thicker than the lines on the original film. It is advisable to anticipate this reduced resolution when planning the movie.

[1] The SCD Graphics Utilities Gregory R. McArthur, Ed- itor. NCAR-TN/166+IA, February, .1981.

[2] The System Plot Package Gregory R. McArthur, Edi- tor. NCAR-TN/162+IA, January, 1981.

FILM PRODUCTION - 12 USING METACODE

INTIODULTION This document describes what files to use for creating graphics instructions on various computers and plotting them on various graphics devices.

Graphics device-independence is attained at NCAR by having system plot packages availab].e on the computers which run user programs configured so they output a common graphics instruction set which is called metacode. This code can then be translated into instructions for a particular graphics device. Metacode translation is generally done on the computer which hosts the device. Thus metacode translation for the d(80 is done on the CDC7600 regardless of where the metacode is created. This minim- izes the number of computers which must know the instruction set for a given graphics device.

cwuRIcAT aC METACUODE

CRAY-1 The default system plot package on the CRAY-1 produces metacode. This package is automatically loaded if $NCARLB is used on the LDR card. All graphics utilities on the CRAY binary library $NCARLB (which is automatically scanned upon invocation of the loader) and it's associated source volumes ULIB and CRAYLIB are configured to take full advantage of the metacode and its efficient method of character plotting. (The more efficienr, way that characters are manipulated implies that the routine PWRY should not be used unless absolutely necessary to obtain some feature inaccessible via metacode characters; see Character Plotting, below). The system plot package from $NCARLB writes metacode on a file named $PLT. CRAY job control language (JCL) can be used to direct the metacode to various locations. With the 7600 acting as the CRAY's front end, there are two possibilities currently: send the metacode to the CDC7600 to be translated into dd80 instructions for plotting there, or send the metacode to the 7600 for saving on the mass store or 1/2" tape. The first method is the one generally used: dd80 film is produced and the metacode is dis- carded. With the second method, different metacode translators ca be invoked producing output on various graphics devices, multiple copies, and so on. These ac- tions are spawned by the following CRAY JCL: DISFOSE,DN=$PLT, SDN DD80, DC =Fr, LDFBB MF76.

and/or DISPOSE, DN=$PLT SDN =nane , ECGST, DF =BB, MF 76.

USING METACODE - 1 The CDC7600-to-CRAY JCL translator invoked by using a *CRAYT card in front of the 7600 JCL automatically generates CRAY JCL which accesses $NCARLB and disposes the metacode to the 7600 to be translated into dd80 instructions and plotted. The instructions are not saved.

CDC760 The default system plot package (i.e. the one loaded automatically from the binary system library) on the CDC7600 produces dd80 instructions for immediate plotting; no other manipulations of these instructions are user accessable. However, using a different system plot package, metacode can be produced and manipulated in various ways, such as those discussed in the CRAY-1 section above. To access this system plot package use the following CDC7600 JCL: *FORTRAN,S=PLIB, P=XLIB, N=PLOT.META,LO=120 14

The graphics utilities on ULIB were originally written to be optimized for the dd80 and, while they will function correctly using PLOT.META, they will not take advantage of various features of the metacode. This means may will produce dd80-like pictures on devices which can do much better. The graphics utilities are continuously being re-written to allow full access to the features in the latest system plot packages.

TRASLfATION OF METACODE

dd80 A binary file for translating metacode into dd80 instructions is available. To access it, use the following deck structure:

*JOB,... *LIMIT,... *VOLUME, 8, VSN=nane ,STAGEIN=whatever,... *RUN, I, BS=PLIB,BN=MC2DD80B P=XLIB *END

where 'name' and 'whatever' are chosen in accordance with how the metacode was saved. MC2DD80B can be run as one step in a sequence of job steps, in which case it may not be necessary to stage in the metacode if it is created in a previous job step and stored on a temporary disk unit.

The source code for MC2DD80B is found on mass store volume SOURCE, in the two files MC2DD80B7A (ASCENT) and MC2DD80B7F (FORTRAN). Access to the source volume can be achieved with the CDC7600 JCL statement: *VOLUME, 1, VSN=SOURCE, STAGEIN=MA

USING METACODE - 2 and the load module can be prepared with the two state- ments: *FORTRAN, S= 1, SN=MC2DD8OB7F, LO= 120 14 *ASCENT, S= 1, SN=MC2DD80B7A

Accessing the source is generally not necessary.

Printers An approximation of the pictures represented by a file of metacode can be produced on a printer. If the pictures are very intricate, the result is unintelligible, but for most pictures the results are satisfactory. On the CDC7600, use: *FORTRAN,S=(435 10006) ,N=MCTR. PRN7,LO=120 14 *RUN, I

The metacode is assumed to be on unit 8. A portable printer-translator is also available on PLIB volume PORT- LIB under the name MCTR.PRNP, and it contains implementation instructions.

C&LCiKP The CALCCMP is NOT the property of the Scientific Comput- ing Division and permission for its use must be obtained from AAP. To create a CALCOMP tape and exercise the many options of the CALCOMP translator, see the current spe- cialist for a writeup.

DICMNED Metacode access to the DICOMEDs, as well as other forms of access, are explained in the companion documents in this manual. RJE The MODCOMP II does not support sending of binary information to remote sites. To send metacode to a remote site, the information must be transmitted in a character form. To change the character information back into metacode and translate the metacode into instructions for the plotter at the remote site requires the presence of a programmable minicomputer acting as the RJE station at the remote site. A good rule of thumb is that if the RJE station can run FORTRAN programs locally, it is powerful enough to receive and translate metacode to drive a graphics device at a remote site.

Programs are available on both the CDC7600 and the CRAY-1 to convert the binary metafile to a character stream. Portable programs for performing the reverse transforma- tion are also available. For details, see the document entitled "RJE Graphics" in this manual.

USING METACODE - 3 METACWCE FMAT The metacode format consists of a single binary file of fixed-length records. See the document entitled "NCAR's Graphics Metafile Structure" in the Implementor's Guide section of the Graphics Manual for details. in the remote translation of metacode and to as- PORTALEPhageL1 To aid sist in the adding of new graphics devices to network computers, a portable metacode translator shell is available on PORTLIB under the name MCTR.PORT and can be implemented by following the implementation instructions contained on comment cards at the beginning of the file. The NCAR Scientific Computing Division (SCD) is not responsible for implementing translators at remote sites. However feedback, trouble reports, and suggestions are welcome and can be appropriately routed by contacting the SCD Consulting Office. This shell can be used on various network computers to form drivers for graphics devices.

To insure maximum efficiency and picture quality regardless of the graphics equipment used, the routine PWRIT in the system plot package should be used for character plotting. The routine PWRY should not be used except in the case of unforseen metacode generator/translator bugs which prevent attainment of desired results. High quality characters such as those in FWRX will ultimately be made available through various metacode translators. This will mean that users can select the kind of characters to be used in a plot at metacode translation time. This will allow for "quick look" plotting with hardware characters, or publishable graphics with high quality characters from the same file of metacode.

For a complete description of character plotting, see the paper entitled "Generating and Plotting Graphics Text at NCAR" in this manual.

USING METACODE - 4 DICGOfED

USING THE DICHED The DICOMED film recorders are now available for use. (FFIE Features include much higher resolution, multiple intensities, and a variety of film formats. Users should realize that developmental work is still in progress on the system, so turn-around times may be slower than with the dd80.

The Scientific Canputing Division currently supports software allowing access to the DICOMEDs' vector graphics and printer simulation (test on microfiche) mode. Software is being prepared for access to the raster image mode. In lieu of this, there is some non-supported software available through some of NCAR's scientific research projects.

Note that for now, there is no way to assign a unit in such a way that graphics and listings can be intermixed on one piece of film. It is possible to simulate this capability by using ENCODE and PIRIT (or PRFILM on the CRAY-1).

CFF-LIE OPERATION Pending the completion of the on-line operating system, the DICOMED will be run off-line. This has four important implications:

1. You must use device-independent software for graphics production. This means using a device- independent system plot package to generate metacode.

2. You must force the creation of your own name frame or else there is no way to associate your film with you.

3. You must use a tape to store the graphics instructions for later processing on the DICOMED system.

4. You must fill out a card to tell the operators to run your tape on the DICOMED system.

DEVICE-INWEENDENT The usual entry points are supported with the argument GUAfICs FIIR lists unchanged. You can still think of the device as being 1024 x 1024, although the underlying software will be operating in higher precision. For more details on generation and manipulation of graphics data files (metafiles) resulting from the use of this software, see the companion document entitled Using Metacode in this manual.

DICOMED- 1 On the CRAY-1 If you are running on the CRAY-1, you are already using the appropriate software packages.

On the CDC7600 To access the device independent system plot package (SET, FRSTPT, etc), use: *FORTRAN, SPLIB,P=XLIB, NPLOT.META, LO= 12014

MAE FRAMES Until the network is implemented, data transfers will not have ownership information associated with them. There- fore, the user must get this information into the data. In the case of graphics, this is done by placing a CAlL HMIkEFR as the first executable statement of any program which is to produce graphics on the DICOMED. If the graphics instructions are also sent to the dd80 translator, you will get two name frames at the start of the job.

TAPE OITIUT

On the CRAY-1 You MUST use CRAY JCL. Tapes of the proper format cannot be directly created via a DISPOSE card on the CRAY-.o First send the graphics to the mass store by using. DISPOSE, DN=$PLT, SDN=Bxxxxx, DC=ST, F =BB,MF=76

"Bxxxxx" should be replaced by the name of on of your tapes. The mass store image can then be put on tape in the proper form with a 7600 run of the following form:

*JOB,... *VOLUME, 1VSN=Bxxxxx,STAGEIN=MA,STAGEOUT=DTI *END

This procedure may also be undertaken without using the mass store by changing "DC=ST" to "DC=MT" and subse- quently creating a copy of the tape which is not in mass store format with a separate run on the 7600. The copy can then be used to drive the DICOMED. Mass store format tapes CANNOT be used on the DICOMED system because the records are too big.

On the CDC7600 The device independent system plot package writes the instructions on Unit 8, so include the following assign- ment:

*VOLUME, 8, VSN=Bxxxxx ,STAGEIN=ZS, STAGEOUT=DT

Replace 'Bxxxxx' with your tape's name.

DICOMED - 2 PRINTE SIMULATI To produce such output as listings on microfiche, the (TEX (CMFICE) listings or other text data must first be formatted properly and put in the proper character set. This is accomplished by means of the program PRSIM , a version of which runs on any public computer in the network. A complete description of the use of PRSIM on various machines may be found in the document entitled PRSIM in this manual. As long as the DICOMED is being run off-line, the output of PRSIM must be captured on 1/2 inch magnetic tape prior to DICOMED job submission.

DICNED REUES T This form is used to inform the operators that your tape FOM is to be used as input for a DICOMED run. This form should be submitted only after you have verified that your tape has been correctly written by examining your mainframe output. Remote users should use the OPR com- mand to send the equivalent information to the MODCOMP to inform the operators of a DICOMED request.

DICOMED - 3