AVS Network News Summer 1993 Volume 2, Issue 3 ASCII only edition - INTERNAL DISTRIBUTION ONLY PLEASE For information on how to obtain hard copies of this magazine, which include many AVS images, please contact the IAC at: International AVS Center Post Office Box 12889 3021 Cornwallis Road Research Triangle Park, NC 27709-2889 Telephone 919-248-1100 Fax 919-248-1101 Email: avs@ncsc.org Contents: Second Annual International AVS User Group Conference Review 3 Module Submission Criteria 4 Visualization Using AVS and Massively Parallel Systems 5 Obtaining Modules 8 IAC Module Contest Winners Announced 9 Visualization in Atmospheric Sciences 13 AVS Tricks: Coroutines and Animation 15 How I Do An AVS Kickstart, Part 2 17 In Touch with the IAC 21 Simulating ÒSmart ReadersÓ for ÒLarge DataÓ Using Existing AVS Tools 22 Users Group Membership and Subscription 23 AVS Network News The International AVS Center serves as a catalyst for expanding the AVS user base and for increasing AVS functionality by fostering discipline-specific module development and new AVS uses. Located at the North Carolina Supercomputing Center, a division of MCNC, the worldwide clearinghouse collects, ports, and distributes user- contributed, public-domain modules and acts as liaison between users and vendors. AVS Network News is the CenterÕs quarterly magazine serving users and vendors with updates on AVS programs and their use, usersÕ images and editorial viewpoints, and product information postings from vendors and independent software developers. For an annual subscription, send an $18 check or money order ($28 if outside the United States), payable to the International AVS Center, to Post Office Box 12889, 3021 Cornwallis Road, Research Triangle Park, NC 27709-2889. David Bennett, AVS Project Leader, avs@ncsc.org Katie Mohrfeld, AVS Specialist, avs@ncsc.org Steve Thorpe, AVS Specialist, avs@ncsc.org Dianne Reid Sanders, Database Specialist, avs@ncsc.org Joel Page, Contributing Editor, page@mcnc.org Fran Wise, Design Coordinator, wise@mcnc.org For more information, contact International AVS Center Post Office Box 12889 3021 Cornwallis Road Research Triangle Park, NC 27709-2889 Telephone 919-248-1100 Fax 919-248-1101 Second Annual International AVS User Group Conference Review Dianne Reid Sanders, International AVS Center, located at NCSC, a division of MCNC, Research Triangle Park, NC, USA Even before the last few boxes from AVS Õ93 had been unloaded, we at the International AVS Center (IAC) were reviewing and evaluating the conference held May 24-26 in Orlando, Florida. Was it a success? We would have to answer with an emphatic Òyes!Ó The lectures, panels, tutorials, and workshops were divided into six tracks -- chemistry, earth sciences, geographic information systems, medical imaging, and two general tracks. Hundreds of attendees commented on the excellent content and quality of the more than 60 lectures. Attendees also told us that they really enjoyed the hands-on, small classroom environment of the tutorials and workshops. This was especially helpful during the introductory courses. Moving to the other end of the spectrum, some of the panels had more than 100 attendees. Once again, the participants said that these were all highly informative and educational. One of the conference highlights was the Monday night reception and keynote address. The evening began with a welcoming address from IAC Director David Bennett. This was followed by Dr. Larry Smarr, director of the National Center for Supercomputing Applications, who gave the keynote address on AVS and the Metacenter. Afterwards, Steve Thorpe of the IAC presented recognition plaques to the winners of the quarterly AVS module contest. Finally, the night ended with the presentation of the first AVS Video Review Theater. This hour-long show featured animation clips from around the world on research being done using AVS. Another new feature of this yearÕs conference was the addition of an exhibit hall. Exhibitors displayed their AVS hardware and software during the three days of the conference. The future technologies exhibit featured the Vision Dome, a collaborative project between the IAC and Evans and Sutherland that demonstrated the high spatial fidelity and participatory visualization capabilities offered by the Digistar projection system. Other exhibitors included ADAM NET, LTD. Advanced Visual Systems Inc., Folsom Research, Hewlett-Packard, HRB Systems Inc., Kubota Pacific, Essential Planning Systems Ltd., Research Systems Inc., SET Technology, Sun Microsystems Computer Corporation, and Scientific Visualization Associates Inc. The vendors were very pleased with the results of this first-time event, as the audience was much more focused and interested in these AVS-related products than a typical attendee of another larger conference, such as SIGGRAPH, would be. If you have any questions regarding AVS Õ93 or wish to obtain copies of the AVS Video Review and/or conference proceedings, contact the IAC by sending email to avs@ncsc.org, by telephoning 919-248-1100, or by faxing to 919-248-1101. Special thanks are due to all those who contributed to the success of this event -- speakers, attendees, exhibitors, WALT DISNEY WORLD DOLPHIN staff, and, finally, MCNC. Hope to see you next year! Module Submission Criteria We encourage modules of all types. We are not looking for perfect productizable code but rather code that is used everyday and would be useful to users. Several users have indicated that their code was not good enough or would not be useful to the AVS user community. This is not true. We have many different levels of users -- from the total novice to the experienced professional -- and code is needed for all levels. All we require is source code, a Makefile, and either a readme file or man page. Data, networks, etc. are strictly optional. Source file and Makefile -- Source code and Makefile must accompany all modules submitted. We encourage extensive commenting and ask that port-specific lines be so commented. Module description -- A detailed description of the module must be included with its submission. This may be in the form of a man page or ASCII text format (as in a README file). Module description is one of the most important criteria for submission. Please indicate if multiple modules are in one source code file. The International AVS Center staff will rewrite the documentation as necessary. Data -- If your module uses a nonstandard data format, you must include an example (not necessarily real) of that data. Explanations of how to read the data should be placed in the required manual or README file. Miscellaneous -- You are requested to provide sample network and scripts when appropriate. To submit modules, ftp to avs.ncsc.org and cd to the SUBMIT directory. You will be prompted on how to create a directory. The directory itself will be invisible so that others may not inadvertently copy over your files. When you are in your directory, use standard ftp protocol to submit your modules and associated files. Information on using ftp for basic submission and retrieval can be obtained by sending a request to avs@ncsc.org. You also can submit modules and associated files by email to avs@ncsc.org and by tape (tape will be returned if requested) to the International AVS Center, Post Office Box 12889, 3021 Cornwallis Road, Research Triangle Park, NC 27709-2889. Visualization Using AVS and Massively Parallel Systems Mike Sharrott, Visualization Systems Program, CSIRO Division of Information Technology, Canberra, Australia Introduction The Visualization Systems Program of the CSIRO Division of Information Technology is working towards the real-time visualization of large complex data sets. As part of this research and development program, scalable massively parallel algorithms have been developed for visualization and other related tasks. These algorithms have been implemented on the DivisionÕs DECmpp/MasPar MP-1 massively parallel computer [1]. Two interfaces to the software currently are provided. The first is through a library of MasPar Programming Language (MPL) functions that may be called from a C program running on the host to the MasPar. The second is as a set of modules incorporated into the Application Visualization System (AVS) visual programming environment. This article describes the AVS interface and the associated Parallel Computation Service (PCS) that has been developed to allow efficient distributed access from the AVS environment to a high- performance computation resource such as the MasPar. Visualization Software The ProgramÕs visualization software includes a set of core algorithms for surface shading, perspective viewing, surface shadowing [2], and volume rendering [3]. This software is being developed towards a wide range of applications such as the following. ¥ Mine planning ¥ Geophysical data processing ¥ Animation ¥ Image warping ¥ Image processing ¥ Video processing An example of geophysical exploration data is shown as a perspective surface in Figure 1. This data represents the distortions in EarthÕs magnetic field strength over an area of terrain that provides constraints to the possible 3-D geological structures being present. The software is based purely on image-space algorithms, since pixel- or voxel- based algorithms can have very efficient realizations on Single Instruction Multiple Data (SIMD) massively parallel computers. An image-space approach also avoids the problems of artifacts along polygon edges that are unrelated to the sampling resolution of the data. This becomes increasingly important as more consistency and reliability are demanded in the interpretation of the visualization. A further advantage to the pixel-based approach is the linear scaling of computation time. For example, if the data set size is increased, the computation time increases linearly; or if the machine size is increased, the computation time decreases linearly. The general system approach, undertaken by the research program, is to integrate the parallel machine into the working environment rather than trying to integrate the working environment onto the parallel machine. For example, taking the latter approach would require a port of AVS to the MasPar, which would be very time-consuming and costly. To this end, a project was undertaken to develop a software architecture that would enable the MasPar to be used invisibly from AVS running on any workstation on the local network. Parallel Computation Service The PCS was required to meet several goals in order to provide an efficient interface to a user application: ¥ Support distributed computing. ¥ Keep data transfers to a minimum. ¥ Support multiple users. ¥ Prevent resource hogging. ¥ Hide the use of the MasPar from the user. The PCS is designed to be a general client/server system but with a broker to control and schedule the execution of the servers. This architecture is shown in Figure 2. The PCS project used object-oriented design techniques and the language C++ for implementation. The following sections give an overview of the PCS. A more detailed description can be found in [4]. Client The PCS client process is the user application. This makes requests to a broker process for computations to be carried out. It does not know what compute server is being used to service the requests (i.e., MasPar, CM-2, workstation, etc.). The client writes all the necessary computation parameters and source and destination data handles into a shared memory segment. Once this is done, it may make a computation request to the broker. If the client is event-driven, then it will remain active and, hence, responsive to further input whilst the computation is in progress. A C++ class ÒPcsAiÓ is provided for client developers. This provides a simple interface to the broker connection and shared memory creation and handling. Broker The broker process creates appropriate server processes to service computation requests that it receives from clients. It supports multiple client and server processes running in parallel. A scheduling and control policy may be built into the broker. This allows features to be built in that may not be available on the server itself. The broker keeps lists of the currently active clients and servers. This allows it to match requests to servers to keep the efficiency as high as possible. If a request has not been sent to a server for a configurable amount of time, then the server will be killed. Server The server process will perform the computation as defined originally by the client and passed to it through the broker. On completion, it will pass a status back to the broker, which in turn will be passed back to the client. How the server handles the computation with respect to the parameters and data is application- and device-specific. The PCS system provides the event manager and computation handler for the server. Developers then can plug in their own computation code. Typically, the server will cache the data that it loads in case it can be used for a following computation. This reduces the required data transfers to a minimum. Also, secondary caches may be used, such as RAM disks (Mas-Par IORAM) or parallel disk arrays. AVS Interface Using PCSThe following sections give an overview of the AVS interface to the visualization software running on the MasPar. A more detailed description can be found in [4]. An example AVS network to carry out a rotation is shown in Figure 3. Intermodule Communication A user-defined data type, called MPPdata, is used to pass data between modules of the visualization software. Data is converted to type MPPdata using the module Field_To_ Mpp. This does not require a data move or copy, since the MPPdata type consists of a handle to the input AVS field. The use of handles to pass data between modules, rather than the complete data set, means that data transfers and storage are reduced to a minimum. Data may be converted back to AVS field format by using the module Mpp-To-Field. This forces a flushing of the associated data cache on the PCS server if required. Clients Each AVS module of the visualization software is configured to be a coroutine that is a separate PCS client process with its own shared memory segment for parameters and data handles. The moduleÕs input and output ports accept data of the user-defined data type MPPdata. After the module has written all the required parameters and data handles to the shared memory segment, it makes a computation request to the broker. The connection to the broker is made when the module is started. The module then enters a blocked wait until the broker returns a status message indicating that the computation has been completed or terminated. The module then may output the computed results before returning to wait for the next parameter or data change. Server A single server process has been implemented to carry out the visualization software computations. Further servers could be written for other classes of computation, such as fluid dynamics calculations. When a computation request has been received, the server checks whether the input data already is stored on the MasPar Processing Elements (PEs). This allows the server to optimize data transfers, only loading data when necessary. After completing the computation, the server holds the resultant data on the PEs until either a specific writeback request is received or the server is about to be killed. A writeback request is received when the data is to be transferred back to AVS field format. The server will be killed if the broker times it out. This occurs when the server has not received a computation request for a configurable amount of time. This mechanism prevents resource hogging. If the server has timed out and been killed and the client makes a new computation request to the broker, then a new server will be created and the necessary data for the computation reloaded. This is carried out transparently to the client, with the only indication being that the computation takes slightly longer than normal due to the startup and data transfer overheads. Future versions of servers running on the MasPar could make use of the IORAM and Parallel Disk Array (if present) for the fast swapping in and out of server processes and data. Figure 3 shows a Display module connected directly to the MPPdata channel. This is a module under development that will display data in a high-speed frame buffer that is connected directly to the server. Summary This article has described a general approach for making high-performance computation resources available to AVS modules without the need of porting AVS to the resource or modifying the AVS source code. The PCS harness provides a powerful mechanism for keeping all data handling and transfers to a minimum while retaining full control over the resource through the broker policies. The interface will hide the computation mechanism from the user allowing very effective integration of the resource into the standard computing environment. By making use of the features, it is possible to run AVS modules interactively for large complex data sets. References 1T. Blank, ÒThe MasPar MP-1 Architecture,Ó Proc. CompCon 1990, pp. 20-24. 2G. VŽzina and P.K. Robertson, Proc. CGI Ô91, published in Scientific Visualisation of Physical Phenomena, Springer- Verlag, Tokyo, 1991, pp. 163-188. 3G. VŽzina, P.A. Fletcher, and P.K. Robertson, ÒVolume Rendering on the MasPar MP-1,Ó Proc. 1992 ACM Workshop on Volume Visualisation, Boston, pp. 3-8. 4S. Milton, M.R. Sharrott, R. Ackland, and K.A. Smith, ÒThe Parallel Computation Service (PCS),Ó CSIRO Division of Information Technology Technical Report TR-HJ-92-10, August 1992. Information Contact Andrew Vincent, Project Leader Visualization Systems Program CSIRO Division of Information Technology Anutech Court, Cnr North and Daley Roads Australian National University GPO Box 664 Canberra, ACT 2601 Telephone: +61 6 275 0911 Fax: +61 6 257 1052 Email: a.vincent@csis.dit.csiro.au Trademarks and Copyright Information AVS is a trademark of Advanced Visual Systems Inc. DEC is a trademark of the Digital Equipment Corporation. MasPar is a registered trademark of the MasPar Computer Corporation. MasPar Programming Language (MPL) is a trademark of the MasPar Computer Corporation. Obtaining Modules Modules may be obtained by three basic methods. The first is standard ftp protocol. When you ftp to avs.ncsc.org (128.109.178.23), text will be displayed that will guide you in using the ftp site. Please read the AVS_LICENSE file located in the top-level directory before downloading modules from the site. Among the directories on the site is avs_modules, which has several directories within it: catalogs/ mappers/ data_output/ khoros/ data_input/ filters/ The catalogs directory contains ASCII and PostScript versions of the latest modules, whereas the other directories contain the modules themselves. Each module subdirectory has many Makefiles, one for each port of the module and its associated files. The second method for obtaining modules is through standard email. When you send an email message to avsemail@ncsc.org, you receive automated replies detailing this procedure. These replies also include a copy of the module catalog, the latest README file about the International AVS Center, and International AVS User Group information. Finally, if you donÕt have network access, you may request a tape via mail. Please send a tape and a $5 handling fee ($15 if not in the United States) with your request to the International AVS Center, Post Office Box 12889, 3021 Cornwallis Road, Research Triangle Park, NC 27709-2889. State the hardware configuration you will be using, and we will send you a copy of all of the modules on the ftp site. IAC Module Contest Winners Announced Dianne Reid Sanders, International AVS Center, located at NCSC, a division of MCNC, Research Triangle Park, NC, USA The International AVS Center (IAC) once again is pleased to announce the winners of the quarterly module contest. For the first quarter of 1993, the winner is James Pipe of the University of Michigan Medical School for his crop_and_slice module. The winner for the second quarter is Phil McDonald of NOAA/ERL/Forecast Systems Laboratory for his line_probe module. Congratulations to them both! For one year we have selected winners for our module contest. Criteria considered in the evaluation of a module include utility, uniqueness, and popularity. Because of outstanding service to the IAC and to the entire scientific visualization community, each winner was awarded a $250 (U.S. currency) prize or $250 credit toward attendance at the next International AVS Users Group Conference. In addition, each winner received a plaque in recognition of achievement and service. Special thanks to all module writers who have contributed! Modules from First Quarter 1993 Name: add_extents Module Number: 1602 Author: Steve Larkin, University of Manchester, UK Description: This module copies the input field to the output field while recalculating the extent information for the data and coordinates supplied in the input field. This module is useful when modules further up a network produce fields that do not have the extent information added. Name: carpet Module Number: 1569 Author: Ian Curington, Advanced Visual Systems Inc. Description: A Carpet Plot surface is made showing surface height variation from one field, with color variations from data in a second field. Name: collapse Module Number: 1607 Author: James Pipe, University of Michigan Medical School Description: This module reduces an N-dimensional data set (1 < N < 5) to an N-1 dimensional data set by taking the (min|max|mean|std) of the data across dimension E (the dimension to be eliminated). Name: collapse_2_num Module Number: 1608 Author: James Pipe, University of Michigan Medical School Description: This module reduces an entire data set to a single floating-point number. This number is either the minimum, maximum, mean, sum, standard deviation (std), or count (n) of the input data set. Name: colorizer_2d Module Number: 1587 Author: Wes Bethel, Lawrence Berkeley Laboratory Description: This module is similar to the colorizer module in function. Whereas the colorizer module takes a single scalar field and a single colormap, colorizer_2d takes two scalar fields (of the same dimensions) and two colormaps. The resulting color vector is a function of the two scalar values and the two colormaps. Name: combine_vecto_2 Module Number: 1609 Author: James Pipe, University of Michigan Medical School Description: This module is an extension of the supported module combine_scalars. This module combines a number of input data sets into a single output data set with one vector component of the output data set corresponding to each vector component of each input data set. Name: compress_file Module Number: 1588 Author: Lee J. Silverman, Brown University Description: This module allows data sets, images, or other files to be stored and kept in compressed format but still be read into an AVS network. Name: contour_to_posts Module Number: 1586 Author: Rob Kuyper, University of Technology Delft, The Netherlands Description: contour_to_posts is the ultimate contour module -- automatic scaling, min/max scaling, typein levels, colormap port to color the contours, postscript output for contours, and straight lines on the plot. Name: crop_and_slice Module Number: 1610 Author: James Pipe, University of Michigan Medical School Description: This module combines the functionality of series of the supported orthogonal_ slicer and crop modules and has some additional capabilities. For each dimension in the input data set, one may crop or slice away the data along that dimension. Name: ccyl_pipe Module Number: 1581 Author: Ken Flurchick, NCSC Description: This module defines the cylindrical geometry coordinates that can be used by volume_bounds to draw a hull. This module also passes the geometry field to newfilla (available via anonymous ftp) that in turn fills the cylindrical geometry with data. Name: E01SAF Module Number: 1568 Author: Steve Larkin, Computer Graphics Unit, University of Manchester, UK Description: This module provides an interface to the NAG FORTRAN routines E01SAF and E01SBF. The first routine generates a 2-D surface that interpolates a set of scattered data points, using the method of Renka and Cline. The second then evaluates the surface at a given point. Name: extend Module Number: 1611 Author: James Pipe, University of Michigan Medical School Description: This module turns an N-dimensional data set into an N+1-dimensional data set. It does this by copying the N-dimensional input data set m times across the N+1th dimension, where m (the size of the added dimension) is specified by the user. Name: field_to_globe Module Number: 1595 Author: Ed Bender, CONVEX Computer Corporation Description: This module is used to wrap field data around a globe. Name: fix_field_edge Module Number: 1613 Author: Anonymous. (Please forward any author information to the IAC.) Description: For each cell in a field (2-D 2- space 1-vector rectilinear integer) that has a zero value, this module searches for the closest neighbor that has a positive value and replaces the zero value with that one. Name: generate_contine Module Number: 1594 Author: Ed Bender, CONVEX Computer Corporation Description: This module is useful for decorating globes that represent Earth. Given an Earth radius, a geometry is generated consisting of multiple polylines that show the outlines of the continents and islands of Earth. Name: genloadmd Module Number: 1603 Author: Ken Flurchick and Mark Reed, NCSC Description: This module is designed to read in position and velocity information from the file specified as ÒInput FileÓ for a group of point particles in three dimensions. The program represents each point with a sphere at the position specified and color-coded by the magnitude of the velocity. Name: geom_parent Module Number: 1592 Author: Ed Bender, CONVEX Computer Corporation Description: The geom_parent module allows an interactive user to reparent any and all objects in the geometry viewer system. This is useful if you want some but not all objects to move together. Name: glue Module Number: 1612 Author: James Pipe, University of Michigan Medical School Description: This module continually pastes on incoming data onto the end of a growing output data set, always checking to make sure that the dimension lengths of the input and output data sets are identical except for the dimension in which the glue operation is proceeding. Name: Image_to_Postscr Module Number: 1578 Author: Lars M. Bishop, National Ctr. for Comp. Elect., University of Illinois Description: The Image_to_Postscr module prints an Adobe Postscript file containing the image that is connected to the input port. It is designed to give the user a wide variety of sizes, orientations, positions, and qualities. Name: integer_to_real Module Number: 1572 Author: Lars M. Bishop, National Ctr. for Comp. Elect., University of Illinois Description: integer_to_real simply takes in an integer-valued input port and passes its truncation to the output port as a real. Name: load_mdn Module Number: 1583 Author: Ken Flurchick, NCSC Description: This module is an enhancement of the load_md module already available. It is designed to read in one time step of data from a series of input files and provide the user with the ability to select an individual time step or cycle through a series of selected time steps. It has been used to visualize molecular dynamics. Name: newfilla Module Number: 1582 Author: Ken Flurchick, NCSC Description: This module inputs a field from ccyl_pipe (available via anonymous ftp) and fills a cylindrical geometry. Name: non_ortho Module Number: 1605 Author: Tim O. Robinson, University of California at Berkeley Description: This module applies a nonorthogonal transform to a uniform input field. The typein_real values determine the axis length and directions. Name: print_real Module Number: 1575 Author: LLars M. Bishop, National Ctr. for Comp. Elect., University of Illinois Description: print_real creates a widget on the control panel that will contain the value of the moduleÕs input port. Name: read_netcdf_2 Module Number: 1564 Author: E.L. Wright, U.S. Geological Survey Description: This module reads data from netCDF files into uniform or rectilinear AVS fields. Name: Read_SDRC Module Number: 1590 Author: Steve Larkin, Ian Curington, and Geoff Cook, University of Manchester, UK, and AVS Inc. Description: Read_SDRC reads a file that is in the SDRC I-DEAS universal format and converts it into an AVS UCD format. Name: ReadLat Module Number: 1596 Author: Dominique Le Corre, Tethys S.A. Description: This module reads an Iris Explorer Lattice file and generates a field. Name: ReadSeqAnim Module Number: 1584 Author: Ion Barosan, Eindhoven University of Technology, The Netherlands Description: The ReadSeqAnim input modules sends a sequence of file names to a string of parameter ports. Name: real_math Module Number: 1574 Author: Lars M. Bishop, National Ctr. for Comp. Elect., University of Illinois Description: This module works with the same interface as the Field_Math module, with two input ports and one output. If the operation selected from the control panel is unary, the required input port is used as the operand. If the operation is binary, both ports are used if they are both connected. If only the required port is connected, the required port and the scalar parameter are used as the two operands. Name: real_to_integer Module Number: 1573 Author: Lars M. Bishop, National Ctr. for Comp. Elect., University of Illinois Description: The real_to_integer module simply truncates a real value into an nteger. Name: river_bed Module Number: 1579 Author: Ken Flurchick, NCSC Description: This module is used to construct the outline of a river bed. It can be connected to the river_fill coroutine to create a simulation of river contaminants. Name: river_fill Module Number: 1580 Author: Ken Flurchick, NCSC Description: This module continuously pads a 2-D array with data until it is turned off. This can be used with the river_bed module that generates the coordinates for the array to show a simulation of concentration over time. Name: shutter Module Number: 1571 Author: Wes Bethel, Lawrence Berkeley Laboratory Description: The shutter module allows the user to control the flow of an AVS image to downstream modules. This module is designed for use in networks in which animation sequences are created using the geometry renderer. shutter will be useful in making sure the entire scene has been rendered prior to passing the resultant image downstream to a data output module. Name: sololoadmd Module Number: 1604 Author: Ken Flurchick and Mark Reed, NCSC Description: sololoadmd reads velocity and coordinate information for N-point objects and represents them as spheres color-coded by velocity. This is a modified version of the genloadmd module. It only reads in one data set at a time, discarding it when a new set is read in. Name: Splash Module Number: 1585 Author: Marc Curry, NCSC Description: This module is a simple C subroutine that will output a variety of surfaces/colors depending upon what 3-D mathematical function you choose it to have. This is a great example to learn how to manipulate AVS fields. Name: tracer_bounds Module Number: 1570 Author: Lars M. Bishop, National Ctr. for Comp. Elect., University of Illinois Description: This module takes in a 3-D uniform 4-vector byte field and adds a white frame to the edges. It is designed to be applied to a volume of data right before it is sent to the tracer module and allows the addition of lines that look like the geometry viewerÕs volume bounds. Name: transform_tool Module Number: 1606 Author: Tim O. Robinson, University of California at Berkeley Description: transform_tool obtains a copy of the current transformation matrix from the geometry viewer to apply to an object in another geometry viewer window. Name: trigger_int Module Number: 1601 Author: Wes Bethel, Lawrence Berkeley Laboratory Description: The trigger_int module waits for a field to be presented on its input port. When a field (new data) is detected, an integer is stuffed into the output port. This module is useful in creating networks to facilitate animations based upon a single coroutine. Name: ucd_to_wave Module Number: 1597 Author: Ion Barosan, Eindhoven University of Technology, The Netherlands Description: This module writes a ucd structure to disk in wavefront format that is supported by Data Visualizer. Name: uncompress_file Module Number: 1589 Author: Lee J. Silverman, Brown University Description: The uncompress module will decompress a file, then pass the filename on to a data-input module such as Read Field. Name: Unjaggy Module Number: 1591 Author: Steve Thorpe, NCSC Description: This filter module slightly blurs a color image in order to reduce aliasing effects, or Òthe jaggies.Ó Name: volume_mesh Module Number: 1593 Author: Ed Bender, CONVEX Computer Corporation Description: The volume_mesh module is similar to the volume_bounds module. The difference is that it generates a mesh using a colormap for the desired faces of the irregular field instead of a wireframe. Name: Wide_Arrow Module Number: 1567 Author: E.L. Wright, U.S. Geological Survey Description: This module reads a 1-D, three- coordinate, irregular field containing a single floating- point, two-element vector specifying X and Y velocity components at the specified (X,Y,Z) coordinate. Name: write_pict_seque Module Number: 1577 Author: Michael Rangitsch, Dow Chemical, and Terry Myerson, NCSC Description: This module writes a series of images in the pict format from an AVS Network. Name: write_rgb_sequen Module Number: 1576 Author: Michael Rangitsch, Dow Chemical, and Terry Myerson, NCSC Description: This module writes a series of images in the rgb format from an AVS Network. Name: WriteSeqAnim Module Number: 1598 Author: Ion Barosan, Eindhoven University of Technology, The Netherlands Description: The WriteSeqAnim module sends a sequence of file names to a string parameter port. Name: Z_slicer Module Number: 1566 Author: E.L. Wright, U.S. Geological Survey Description: Z_slicer interpolates a 2-D irregular field at a specified Z value from a 3-D irregular field with stretched (ÒsigmaÓ) vertical coordinates. Modules from Second Quarter 1993 Name: GeomXYZtoFld Module Number: 1618 Author: Dominique Le Corre, Tethys S.A. Description: This module takes as input a geometry, gets all vertices, and generates a 1-D three-space field with the coordinates of these vertices. It can be used for instance as the ÒsamplerÓ input field to hedgehog, streamlines, particle advector, scatter dots, etc. Name: Graph_slider Module Number: 1614 Author: Hideo Miyachi, Kubota Corporation Description: Graph_slider can shift the range in x axis in graph viewer. It uses CLI commands to do this. Name: image_combine Module Number: 1615 Author: Hideo Miyachi, Kubota Corporation Description: image_combine generates an image from two imagesÕ data. Name: labeler Module Number: 1621 Author: Phil McDonald, NOAA/FSL Description: This module creates labels from field data or from text. They may be fixed or attached to points in space. Name: line_probe Module Number: 1620 Author: Phil McDonald, NOAA/FSL Description: This module samples a 3-D field along one or more lines or paths. A polyline geometry object is created for the line probe(s), and spheres may be used to show the locations of the nodes. Name: read_tiff_section Module Number: 1616 Author: Joe Panico, Department of Neurosciences, University of Pennsylvania Description: This module reads single planes (slices) from a multiplane TIFF file and provides at the output port an AVS image (2-D scalar field). Name: read_tiff_vol Module Number: 1617 Author: Joe Panico, Department of Neurosciences, University of Pennsylvania Description: This module reads in a multiplane TIFF file and provides at the output port an AVS volume. Name: UcdXYZtoFld Module Number: 1619 Author: Dominique Le Corre, Tethys S.A. Description: This module converts the nodes of a UCD structure to a 1-D three-space (scatter) field. Visualization in Atmospheric Sciences Ruiyan Lin, Department of Atmospheric Sciences, University of California at Los Angeles, CA, USA ÒAir, clean and clear, fresh to the smell and cool to the touch, nurtures me and lifts my sprits.Ó Those are the words of Professor Richard Turco, the famous UCLA atmospheric scientist. This is the dream of humans in the 20th century. Atmospheric scientists are keenly aware of the pressing environmental problems of the day -- urban pollution, acid rain, global ozone depletion, and greenhouse warming. They are seeking a comprehensive understanding of the atmosphere and its chemical composition; how it interacts with the oceans, land, and biosphere; and the influence of the atmosphere on the quality of life, including its role in the global climate. Turco and his collaborators are developing various modeling techniques to study the impact of atmospheric chemistry on the global environment. Visualization of the large-scale data sets generated by the models is a challenge for computer engineers. No existing powerful visualization package can completely satisfy all the needs of these studies. I am using AVS for all visualizations, and three of the important projects involving different types of data are described below. Pollution Emission and Transport in the Los Angeles Basin To predict the Los Angeles basin airflow pattern and concentration distribution, an atmospheric mesoscale model has been developed by Mr. Rong Lu, Mr. Mark Jacobson, and Turco. The model includes major physical processes such as boundary layer turbulent diffusion, water vapor condensation and precipitation, solar and infrared radiation transfer and heating, soil heat and moisture transfer, and complex topographic effects over the basin. Photochemical processes leading to ozone production and haze also are treated. Visualizing this data is difficult because it must be viewed in three dimensions while preserving depth perceptions against the topographic background. The original design of AVS orthogonal slicer module and composite module cannot completely satisfy this purpose. We have developed a code that allows a selected color of a slice snapshot to become transparent. The result of this merging technique is shown in Figure 1. 3-D Global Ozone Distribution and Depletion Stratospheric ozone absorbs biologically harmful ultraviolet radiation emitted by the sun. The ozone distribution research is concerned about the survival of most forms of life on the earth. A sophisticated photochemical model that includes 45 chemical species, 99 photochemical reactions, 30 photo dissociations, combined with the general circulation model, was developed by Mr. Xuepeng Zhao and Turco. The data produced by this model is gridded on the entire globe and is multiple gigabytes in size. Since the existing AVS does not have a globe module (while I was working on this subject), we have developed our module to handle this problem. Combining this module with other AVS modules, we can display the ozone distribution by slicing it or forming the isosurface imposed on a 3-D globe. Figure 2 shows one of these results. It was produced by AVS first, then treated by Adobe PhotoShop on Macintosh. Polar Stratospheric Clouds Model Polar stratospheric clouds are a primary cause of the Òozone holeÓ and depletion of the protective ozone layer. This model simulates the formation of polar stratospheric clouds based on atmospheric data. It consists of the trajectory of a specified air parcel and the temperatures and pressures experienced by this parcel along the trajectory. The visualization tools we have developed in the form of an AVS module can display multitrajectories and their projections on the earthÕs surface, as is shown in Figure 3. A module that can display hundreds of trajectories is being considered at present. The data was given by Katja Drdla and John D. Farrara. Acknowledgment This work was sponsored by the University of California and Digital Equipment Corporation under Research Grant #1243 and a consortium of government and industrial partners. I would like to thank Visualization Laboratory Consultant Joan Slottow of UCLAÕs Office of Academic Computing for helpful discussions and comments concerning this work. AVS Tricks: Coroutines and Animation Wes Bethel, Lawrence Berkeley Laboratory, Berkeley, CA, USA Webster provides several definitions of Òanimate.Ó Of most interest is the Òbring life toÓ aspect. We all are aware of the benefits of bringing life to visualizations, particularly the insight gained by viewing a dynamic sequence of images as opposed to a static image. So what does one do to get animation off the ground in AVS? There are a number of options. There is the AVS_Animator. There is an animation tool available from the International AVS Center (IAC) called keyframe_animator (by Brian Kaplan of Indiana UniversityÕs Center of Innovative Computer Applications). And then there is your own resolve and patience to learn AVS well enough to get the results you want without using one of these tools. It is not my intent to outline the strengths or weaknesses of these tools for creating animations. Rather, letÕs get dirty rolling around in the network editor to see just how much animation we can accomplish. Before we get started, letÕs agree that what we mean by animation in AVS is changing one or more moduleÕs parameters over time, thus producing a (deterministic) sequence of images, data files, or whatever. Without using one of the tools previously mentioned, the key to doing animation is the coroutine. If we are going to animate a single integer parameter over time, for example, we can use the module animate_integer and similarly for a single floating-point parameter. But what if we want to animate disparate primitives over time? In other words, what if we want to read in a file, change a floating-point value or an integer value, and write out a file on a per-timestep basis? What do we do? Well, we canÕt use more than one coroutine in a network. Why? In coroutines, synchronization is coded explicitly into the coroutine, typically with code that looks something like. main() { for (;;) /* loop forever */ { do_something(); put_data_onto_output_port(); AVSwait_for_network_to_finish_executing(); } } This code fragment is an oversimplification but captures the essence of the problem. What happens when there are multiple coroutines that are waiting on the network to finish executing? Which one fires first? Is the firing sequence the same each time? From experience, the firing order is nondeterministic but consistent once it gets started. But this knowledge isnÕt much help. Knowing that we may have only one coroutine in a network is the place to start on our quest for animation. As a simple example, letÕs consider a fairly common problem -- changing the value of an isosurface over a known range, rendering the isosurface, and creating an image file for each frame. There are two parameters that are changing over time. The first is the isolevel parameter, and the second is the filename. We can use the animate_float coroutine module to provide the floating-point values to the isosurface module. But wait. WeÕve now used up our one coroutine module. We can have no more in the network! That means that we canÕt use the animate_string coroutine (available from the IAC) to produce filenames for the image writing module. What do we do now? We can use the module called animate_filename (from the IAC), which will produce a string that then may be passed along to the image_writing module. However, this module wants an integer on its input port in order to generate strings of the form base name .xxxx.suffix, where xxxx is a string represented by the input integer. Clearly, we canÕt generalize the use of the existing floating-point value in our network due to precision problems. What next? The dirty trick that we will use to get around this problem is a module called trigger_int (from the IAC). This module, which functions as a normal subroutine module, waits for a field on its input port. When a Ònew fieldÓ is received, it will output an integer onto its output port. The beginning integer value, as well as the step value, are parameters to this module. We will wire this module in between the geometry_viewer module and the animate_filename module. This subnetwork is shown in Figure 1. As a side note, if you donÕt change the widget type of the filename parameter of the write_image module from a ÒbrowserÓ into something else (preferably ÒnoneÓ or no widget), the performance of this network will degrade to the point of being nearly useless after a few hundred image files. The degradation occurs as the browser is updated each time that a new file is written. The time required to perform this update grows with the number of files in the directory. The way the complete network (Figure 2) functions is as follows. The data to be visualized is read. The animate_float coroutine is Òturned onÓ and produces a floating-point value. The geometry is rendered, and the output image is sent to the image_writing and trigger_int modules. This produces an integer used by the animate_filename module, which then provides a string (a filename) to the image_writing module. The result is a disk full of image files for subsequent recording onto videotape or later playback using some other means. How I Do An AVS Kickstart, Part 2 Alan Barnum-Scrivener, Advanced Visual Systems Inc., Laguna Hills, CA, USA Assuming your system administrator has installed AVS and the license file correctly, you should be able to type avs & here and bring up the application. This is the main AVS menu. If you type avs -usage youÕll get a list of all the AVS command line flags. This and the ÒversionÓ flag just print text without opening an X window. Two important ones are the Ò-dataÓ and Ò-netdirÓ flags, each of which takes a path name of a directory as its argument. They tell AVS where to look for data and networks, respectively. So if you invoke avs by typing avs -data $cwd -netdir $cwd it will use the current working directory for both these. I have this set up as an alias. But for learning, itÕs best to use the default data and network directories. Also, you should know that there are three ways to affect the way AVS comes up -- command line flags, shell environment variables, and the Ò.avsrcÓ file. This filename follows the UNIX convention that a resource file begins with a dot and ends with Òrc,Ó such as Ò.cshrcÓ for the c shell (csh) or Ò.exrcÓ for the ex editor. The search order is that first AVS looks in the current directory for a Ò.avsrcÓ file, then in your home directory, then in special file Ò/usr/avs/runtime/avsrcÓ (without the dot). All of this is described in the UserÕs Guide in Chapter Three, ÒStarting AVS.Ó After starting AVS, you see the main AVS menu. Some viewers are listed, then ÒNetwork Editor,Ó then ÒAVS Applications,Ó and lastly ÒExit AVS.Ó I want to go through these quickly, indicating how to exit things and close windows, since thatÕs one way people commonly get stuck. (Also, you might walk up to an AVS session that somebody else left running.) Image_Viewer In Image_Viewer, you can read in images with the ÒRead ImageÓ button, and you get what we call a ÒFile Browser.Ó The little slider on the right is sort of Mac-like. If you drag the middle mouse button up or down inside the slider itself, you scroll the list of files up and down. In the little square icons at the top and bottom of the scroll bar -- the ones with up or down pointing triangles in them -- you can use the right mouse button to go down and the left mouse button to go up at a smooth rate. In the browser header, you see the name of the directory youÕre currently in. It should say Ò/usr/avs/data,Ó if we started AVS with no flags or other options telling it to use a special directory for data. (In AVS5, this also assumes the AVS subtree is installed under the Ò/usrÓ directory.) In the file browser text, red means a directory and black means a file. The first directory listed is Ò./Ó with a name in parentheses. DonÕt pick that unless you want to go up one directory, because you easily can get lost. I can go down one directory into ÒimageÓ and select an image file, which ends with a Ò.xÓ suffix. I can read another image on top of it. Among the Image_Viewer mouse bindings, the left button picks an image. A small picture of the image youÕve picked shows up in the little square gray window right above the ÒResetÓ and ÒNormalizeÓ buttons, and the imageÕs name shows up in the gray strip above that. Dragging the right button translates an image in X and Y. Holding down the shift key while you drag the middle button scales an image. This is a nonintegral, interpolated zoom. Moving up or to the right makes it larger. (We couldnÕt agree on which was more natural, so we did both.) Now you can do all sorts of other great things with these images. Read Chapter Four, ÒImage Viewer Subsystem,Ó in the UserÕs Guide for that. The question now is: How do we get rid of this window? You could just iconify it, but thatÕs the wrong answer -- it would still be lurking, using memory. You go into the ÒViewsÓ submenu and select ÒDelete View.Ó Now we exit the Image_Viewer by clicking on the ÒCloseÓ box at the very top right of the Image_Viewer panel. Graph_Viewer Note that Graph_ViewerÕs top set of radio buttons, as we call them, with the ÒOption SelectionÓ label, selects only which panels of control will show. Pressing one of these top radio buttons doesnÕt cause any action, just a panel display. I use the ÒRead ASCII FileÓ button to read a data set -- in this file browser, I select the ÒgraphÓ directory and then the Òsine.datÓ data set. Now a plot window opens with the sine wave plotted. You can learn to do lots of things with plots by reading Chapter Three of the Tutorial Guide, ÒGraph Viewer Tutorial,Ó and Chapter Seven of the UserÕs Guide, ÒGraph Viewer Subsystem.Ó Now, how do we get rid of this window? With the ÒDelete Plot WindowÓ button on the ÒRead DataÓ panel. Remember that you get to the ÒRead DataÓ panel through the top selection on the top set of radio buttons. Now exit the Graph_Viewer with the ÒCloseÓ button at the very top right of the Graph_Viewer panel. Geometry_Viewer Geometry_Viewer is the oldest component of AVS. You use it to render 3-D geometric primitives into 2-D pixels, providing information on the positions of objects, lights, and cameras, as well as clip planes, surface properties, and rendering methods. The upper radio buttons under the ÒTransform SelectionÓ title -- Transform Object, Transform Light, and Transform Camera -- affect what the mouse moves, and thatÕs all they do; they donÕt select any submenus. The middle set -- Objects, Lights, Cameras, Labels, and Action -- select which menus appear below, and thatÕs all they do; they donÕt cause any action. People sometimes get confused when theyÕre in the ÒLightsÓ submenu, have selected a light to move, but havenÕt selected ÒTransform LightÓ up above. By default, ÒTransform ObjectÓ is selected above, and ÒObjectsÓ is selected in the middle. When you do a ÒRead ObjectÓ while in the ÒObjectsÓ submenu, you again get a file browser. Select the ÒgeometryÓ directory and then scroll down to select the object Òteapot.geom,Ó which is the famous 3-D model from the University of Utah. Now a Geometry_Viewer window pops up, and you see this teapot from the top down. You actually are looking down the negative Z axis; positive X is to the right, positive Y is up, and positive Z is out of the screen towards me. What youÕre actually seeing is called a ÒsceneÓ and contains the teapot geometric primitives viewed with a bunch of default parameters set. The concept of ÒsceneÓ is at the top of a hierarchy of abstractions. To build scenes, you start at the bottom with geometric primitives in 3-D space -- points, line segments (also known as vectors), spheres, and polygons, with a few hardware-specific aggregate types such as polylines and polytriangle strips. ÒObjectsÓ are groups of primitives that are defined in a local coordinate system that is convenient for the modeler; the primitives usually are said to be provided in Òobject coordinates.Ó In AVS, you can group a bunch of primitives into an object and then set their properties together -- surface color and reflectivity, transparency, texture, etc. You can then take a bunch of these objects and transform them into Òworld coordinates,Ó using standard 3-D transformations -- rotation, translation (linear motion), scaling, perspective, and, in fact, any general matrix of the 4x4 form called Òhomogeneous.Ó (Look at Foley and Van Dam, Fundamentals of Interactive Computer Graphics, for the whole mathematical treatment.) What you end up with is a world system of objects. Then you select a camera view; rendering method (or methods); and type, position, and color of lights. And you have a Òview.Ó When you add X-Window size and position information, this ÒviewÓ becomes a Òscene.Ó You can read and save both objects and scenes in AVS. The old Ò.objÓ and Ò.sceneÓ files now are Command Language Interpreter files that end in Ò.scrÓ -- though AVS5 still reads the old files for backward- compatibility. Now IÕll review the mouse bindings in the geometry viewer. The left button selects objects in a scene. This is a very tricky option, and there are other ways to select objects that are less tricky. I recommend that you donÕt use the left mouse button in a geometry window until you know what youÕre doing. You can have plenty of fun for now with the other two buttons. If you do hit the left mouse button accidentally, hereÕs what you can do before you move anything. Notice the square gray window above the ÒReset,Ó ÒNormalize,Ó and ÒCenterÓ buttons. A small rendering of the object youÕve picked appears in this window, and the objectÕs name appears in the gray strip above that. Keep clicking in the square window until the name ÒtopÓ appears in the gray strip. Things should return to the way they were. Grab the teapot with the middle mouse button and drag. It rotates like a track ball. Moving up and down rotates about the X axis. Moving left and right rotates about the Y axis. If you can smoothly rotate the mouse in the plane of the screen, staying a uniform distance from the windowÕs center, youÕll rotate about the Z axis. With the shift key held down, the middle mouse button scales, with both right and up scaling larger, just like in the Image_Viewer. The right mouse button translates the object, which is linear algebra jargon for moving in a straight line. Moving right translates in the positive X direction and moving up translates in the positive Y direction. Holding down the shift key and moving the mouse up or right translates in the negative Z direction (into the screen). If you go into the Cameras submenu and select ÒPerspectiveÓ (you sometimes have to scroll down to find it, depending on the hardware platform), you see closer looks bigger, so translating in Z affects apparent size. One last thing about the mouse bindings in Geometry windows. Like an actual trackball, the Òvirtual trackballÓ interface has momentum. In other words, if the mouse is moving when you release a button, the transformation you were doing continues at a speed proportional to the mouseÕs speed at the time you release the button. This is very handy for spinning things; but for translating or scaling, your object can disappear quickly. So be careful. If you start AVS with the following command line, the momentum feature is disabled during the session. avs -geometry -noroll LetÕs say you translated your teapot off-screen with momentum. This is where the ÒResetÓ button below the selection window comes in handy. It will reset the currently selected object to its initial transformation when you started. If youÕve messed with the left mouse button (like I told you not to), you may have to select each object in turn and reset them all. Just keep alternately clicking in the selection window and on the ÒResetÓ button until everything is back and the ÒtopÓ object has cycled by twice. This brings me to the other two buttons -- ÒNormalizeÓ and ÒCenter.Ó We didnÕt need them to look at the teapot because it was defined in object coordinates that pretty well match the default AVS viewing transformation. But what if an object is much bigger or smaller than the viewing window? ÒNormalizeÓ will rescale it to just fit in the window, and ÒCenterÓ will ensure that it rotates and scales about its visual center (actually, to be precise, the center of its bounding box). So much for damage control. LetÕs go back to the Object submenu and select ÒEdit Property.Ó You get a new window with sliders that let you set object properties. You manually can specify all of these parameters now, or you can read in a predefined properties file, which is just a text file ending with a Ò.propÓ suffix. Click the ÒReadÓ button on the properties window and you get another File Browser: Go down to the ÒpropertiesÓ directory and you can select any of these files. LetÕs go with Òchina.propÓ since itÕs close to white. In the ÒLightsÓ submenu, select ÒEdit Light Color.Ó Notice that light #1 is selected by default. ThereÕs also a light called ÒAMÓ that is ambient -- it comes from all directions at once. If you turn that off, it looks like youÕre in space -- all the light is directional, or Òdiffuse.Ó Return to light #1, and edit its color to make it red. Also, turn on ÒShow LightsÓ (I see it as a red vector, showing the direction itÕs coming from). The teapot is rotating when you drag the middle mouse button. Go up to the top radio buttons and select ÒTransform Light,Ó and now you can spin the light. Make the red light come from the upper left. Next, select light #2, make it green, turn it on, and move it so it comes from the upper right. Lastly, select light #3, make it blue, turn it on, and move it so it comes from below. Now you might ask, who cares if you can put colored lights on teapots? Good question. As far as looking at this china teapot under colored lights, it doesnÕt take much in the way of visual cues to recognize what it is. But if we were looking at a geometry that came from a scientific visualization application -- such as a surface of constant sulfur dioxide pollution in the atmosphere -- we easily could be the first human beings ever to see this shape, and every visual cue we can use to discern its structure is going to help. In the ÒCamerasÓ submenu, press ÒCreate CameraÓ and a new view of the teapot appears. If you select ÒTransform CameraÓ up above, you can move the camera view of the object separately in each window. Now we have all of these camera views all over the screen. How do we get rid of them? Go into the ÒCamerasÓ submenu and press ÒDelete CameraÓ while the window you want to delete is active; you can tell itÕs active, because itÕs outlined in red. There are a number of other features in the Geometry_Viewer that you can learn by reading Chapter Two, ÒGeometry Viewer Tutorial,Ó in the Tutorial Guide. ThereÕs more information in Chapter Five, ÒGeometry Viewer Subsystem,Ó of the UserÕs Guide. I want to point out three more things on the Geometry_Viewer panel, and theyÕre these three little dimples next to ÒTransform Selection,Ó ÒTransform Camera,Ó and the object selection title strip. The first two let you type in precise transformations instead of depending on your coordination with the mouse. The third lets you precisely select objects in a scene from a complete list. They can be lifesavers, so learn to use your dimples! I want to continue in more detail about importing geometries into AVS. In the ÒxtermÓ window, you can make a new empty directory where you can write to and then copy in the contents of directory Ò/usr/avs/filterÓ and the contents of Ò/usr/avs/filter/exampleÓ directly below it. Here are the source files to the geom filters that preprocess geometry data so that the AVS Geometry_Viewer can read it. One particularly useful filter is mesh_to_ geom that can read a number of types of mesh files. It looks for a keyword on the first line that can be one of these. scalar vertex normal color normal_and_color It parses the file differently depending on what it finds. The first case is a scalar mesh, and all you need to provide is the Z values or altitudes. AVS makes up X and Y values for you to make a uniform mesh. This is the file Òsaddle.meshÓ from the example directory. scalar 3 3 1.0 0.0 -1.0 0.0 0.0 0.0 -1.0 0.0 1.0 ItÕs a 3x3 ÒscalarÓ mesh, and so only the nine Z values are provided. They donÕt have to be in a 3x3 array of numbers; thatÕs just for human readability. Read this in with ÒRead Object,Ó and you can see the mesh. From the top down, it looks like a square. But as you tilt the Z axis towards you, you can see the saddle shape. (Note: You should do this in a directory that you have write access to. It is a very bad idea to do anything destructive -- or creative for that matter -- in the AVS subtree. Copy files before you experiment.) A ÒvertexÓ mesh has the complete vertex definitions of X, Y, and Z values at each point in the mesh. For example, here is the same file above redone: vertex 3 3 -1.0 -1.0 1.0 -1.0 0.0 0.0 -1.0 1.0 -1.0 0.0 -1.0 0.0 0.0 0.0 0.0 0.0 1.0 0.0 1.0 -1.0 -1.0 1.0 0.0 0.0 1.0 1.0 1.0 Notice that the right column of nine numbers corresponds to the nine Z values in the first file. As you read it in, you can see it looks about the same. The ÒnormalÓ format allows you to add X, Y, and Z components of a normal or perpendicular vector at each point in the mesh. This can be handy if the data came from an algorithm and you can compute precise normals, since it improves rendering quality over letting AVS approximate the normals from adjacent vertices. (Also, you can experiment with what are called Òbump mapsÓ by varying normals on an otherwise flat surface.) The ÒcolorÓ format allows you to add red, green, and blue information to each vertex as floating-point numbers between zero and one. For example: color 3 3 -1.0 -1.0 1.0 1.0 0.0 0.0 -1.0 0.0 0.0 1.0 1.0 0.0 -1.0 1.0 -1.0 0.0 1.0 0.0 0.0 -1.0 0.0 1.0 1.0 0.0 0.0 0.0 0.0 1.0 1.0 0.0 0.0 1.0 0.0 1.0 1.0 0.0 1.0 -1.0 -1.0 0.0 1.0 0.0 1.0 0.0 0.0 1.0 1.0 0.0 1.0 1.0 1.0 1.0 0.0 0.0 This file results in the same shaped saddle, but now the flat parts are yellow, the high corners are red, and the low corners are green. If you display this in the default- rendering mode (a smooth-shading technique called ÒGouradÓ shading after the Frenchman who invented it), the colors are interpolated across the quadrilaterals, which you can see is quite striking. Lastly, normal_and_color allows you to provide all of the above in this order: X, Y, Z, NX, NY, NZ, R, G, B (where NX is the normal X component, etc.) for full control over a mesh. Another useful geom filter is sphere_to_ geom, which allows you to define multisized and multicolored spheres in 3-D space. If your graphics hardware doesnÕt support sphere primitives, AVS subdivides spheres with triangles. You control how many triangles per sphere with a ÒSubdivisionÓ slider in the ÒObjectsÓ submenu. You might not think of spheres as a great way to visualize data, but I have found them to be excellent aids to debugging your data. In my 10 years in computer graphics and five years in scientific visualization, IÕm amazed how many times my customers have found that they had some bad data -- sometimes after actively using the data for many months. Turning some data into a Ò.sphereÓ file with a simple conversion program -- or even by hand -- can help reveal where anomalous points in space or crazy data values are hiding. [Look for Part 3 of this article in an upcoming AVS Network News.] In Touch with the IAC avs@ncsc.org Email address for sending questions to the International AVS Center staff or articles for reprint in AVS Network News. avsemail@ncsc.org Email address for an automated reply containing information on the International AVS User Group, current AVS module catalog, README file on the International AVS Center, and use of standard email to obtain modules. avsorder@ncsc.org Email address for ordering AVS module source code. listserv@avsusers.ncsc.org Email address for sending any message, with HELP as the message body, for an automated reply detailing the International AVS CenterÕs various mailing lists and subscription procedures. avs.ncsc.org Anonymous ftp site address of the International AVS Center. comp.graphics.avs Newsgroup of AVS usersÕ daily postings, also available by using listserv. WHAT_IS_GOPHER WHAT_IS_WAIS Files on the International AVS CenterÕs ftp site (in the avs_readme subdirectory) for information on other tools for accessing the ftp site. Simulating ÒSmart ReadersÓ for ÒLarge DataÓ Using Existing AVS Tools Larry Gelberg, Advanced Visuals Systems Inc., Waltham, MA, USA The ÒLarge Data ProblemÓ is characterized as the problem of having data sets on disk that are too big to load into machine memory for visual processing. Currently, AVS users load in huge disk files and use DOWNSIZE, CROP, or EXTRACT_SCALAR to get the data down to a reasonable size for further processing. This has the inherent problem of having to read in the whole data set (and use up the corresponding memory) prior to reducing the size of the data set. ÒSmart ReadersÓ can be a partial solution in that they can have built-in data reduction facilities (downsize, crop, etc.), but they typically require application-specific programming. One way of simulating ÒSmart ReadersÓ is to use the READ_FIELD header to only read certain portions of the data set. These headers can be edited by hand using a text editor. For more sophisticated applications, they can be generated automatically using AVS tools. The problem of the existing READ_FIELD module is that it only provides for a single set of data strides so that you cannot always extract exactly the data you want immediately. LetÕs look at an example. Suppose you have a 10,000 pixel by 10,000 pixel image on disk and only want to load the center 512x512 area into memory. The naive AVS approach is to create a network like this: READ IMAGE (read the whole image) | CROP (minx=4744, maxx=5256, miny=4744, maxy=5256) | IMAGE VIEWER Alternatively, you could instruct the READ_ FIELD module to read only the middle 512 scanlines into memory and then CROP out the pixels you donÕt need. Here is a simple picture illustrating which areas we want to skip, read, and ignore. Here is the field file header that describes this operation. # AVS field file ndim = 2 dim1 = 10,000 dim2 = 5256 nspace = 2 veclen = 1 data = byte field = uniform variable 1 file=big_file.raw filetype=binary skip=4,744,000 The value 4,744,000 is the byte number of the first pixel weÕre interested in; skip over 4744 scanlines of 10,000 pixels per scanline. Note that dim2 = 5256, the maximum scanline weÕre interested in reading. The network for processing this is as follows. READ IMAGE | CROP (minx=4744, maxx=5256, miny=0, maxy=511) | IMAGE VIEWER The memory usage goes from 100 Mbytes to 5.12 Mbytes. You still have to read in more data than you are interested in. But it is much less than before, and reading in new areas to look at is not that expensive. In three dimensions, the process is similar except that typically you only can crop on planes (K-slices in the ORTHOGONAL_ SLICER) when reading the data in. This is because typically data is stored in contiguous, scanline order on disk. If the data is stored differently than this assumption (interleaved vector values, etc.), you may have to modify this scheme somewhat. One variation on this is to generate the header files automatically based on something like pointing to a spot in a reduced version of the image. Look at this example. READ IMAGE -> IMAGE VIEWER -> GENERATE HEADER -> READ FIELD -> CROP -> IMAGE VIEWER Here, you would use the UPSTREAM_DATA from the first IMAGE_VIEWER to specify which area of the large image you are interested in. The GENERATE_HEADER module (youÕd have to write this specifically for your application) would generate the header file and then pass the name to the READ_FIELD module that reads in the ÒnewÓ file. Eventually, AVS will have Smart Readers in it as part of the standard release. But until then, there are easy and powerful alternatives. Volunteers Needed The International AVS Center needs volunteers to assist with future AVS users international conferences. Individuals are needed to chair lecture tracks, assist with workshop tracks, schedule speakers, and prepare and coordinate panel discussions. For more information, contact International AVS Center Post Office Box 12889 3021 Cornwallis Road Research Triangle Park, NC 27709-2889 Telephone 919-248-1100 Fax 919-248-1101 Email avs.ncsc.org Articles Needed If you have articles for AVS Network News, send them to avs@ncsc.org or to the International AVS Center, Post Office Box 12889, 3021 Cornwallis Road, Research Triangle Park, NC 27709-2889. Users Group Membership and Subscription I wish to join the International AVS Users Group and enclose $36** for annual membership. With this membership, I will receive an annual subscription to AVS Network News and a copy of the latest AVS catalog of modules. I also will receive a $50 discount on registration for the AVS Õ94 International AVS Users Group Conference. These funds will help the International AVS CenterÕs efforts to support local users group activities. I wish to subscribe to the AVS Network News quarterly magazine and enclose $18* for an annual subscription. I understand this fee covers three two-color issues and one special full-color issue. Name Company Address City State Zip Country Telephone Fax Email Signature * AVS Network News subscription at $18 U.S. and $28 International. ** International AVS Users Group membership at $36 U.S. (includes AVS Network News subscription). Total enclosed Please enclose a copy of this form with your check or money order and mail to The International AVS Center Post Office Box 12889 3021 Cornwallis Road Research Triangle Park, NC 27709-2889 USA Established in 1980 as a private, nonprofit research consortium, MCNC fosters technology research and education to attract and generate technology-based industry for North Carolina. MCNC matches the strengths of major research universities with those of established and emerging industry for economic growth and development in the state. The organization provides advanced capabilities and expertise in microelectronics, communications, and high-performance computing to support research, education, and industry. The North Carolina Supercomputing Center (NCSC), a division of MCNC, makes supercomputing time and related resources available to North CarolinaÕs academic researchers and encourages nonacademic institutions to explore collaborative ventures. NCSC also facilitates research in the areas of computer science, computational science, and scientific visualization. The International AVS Center, housed at NCSC, is the worldwide clearinghouse for collecting, porting, and distributing public-domain visualization modules. These modules enable dramatic advances in the scope and speed of research in a variety of disciplines. The International AVS Center serves as a catalyst for expanding the AVS user base and for increasing AVS functionality by fostering discipline-specific module development and new AVS uses.