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 Centers 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 years 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 Divisions 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 Programs 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 Earths 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 modules 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. Vzina and P.K. Robertson, Proc. CGI 91, published in 
Scientific Visualisation of Physical Phenomena, Springer-
Verlag, Tokyo, 1991, pp. 163-188.
3G. Vzina, 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 dont 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 modules 
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 viewers 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 earths 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 UCLAs 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 Universitys 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, lets get 
dirty rolling around in the network editor to see just how 
much animation we can accomplish.

Before we get started, lets agree that what we mean by 
animation in AVS is changing one or more modules 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 cant 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 isnt 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, lets 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.  
Weve now used up our one coroutine module.  We can have no 
more in the network!  That means that we cant 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 cant 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 dont 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

youll 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, its 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 Users 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 
thats 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 
youre 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. Dont 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 youve picked shows 
up in the little square gray window right above the Reset 
and Normalize buttons, and the images 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 couldnt 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 Users Guide for that. The 
question now is:  How do we get rid of this window?

You could just iconify it, but thats 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_Viewers 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 doesnt 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 
Users 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 thats all they do; they dont select any submenus. The 
middle set -- Objects, Lights, Cameras, Labels, and Action 
-- select which menus appear below, and thats all they do; 
they dont cause any action. People sometimes get confused 
when theyre in the Lights submenu, have selected a light 
to move, but havent 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 youre 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 Ill 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 dont use the 
left mouse button in a geometry window until you know what 
youre doing. You can have plenty of fun for now with the 
other two buttons.

If you do hit the left mouse button accidentally, heres 
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 youve picked appears in 
this window, and the objects 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 windows center, 
youll 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 mouses 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

Lets 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 youve 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 didnt 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. Lets 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. Lets go with china.prop since its close 
to white.

In the Lights submenu, select Edit Light Color. Notice 
that light #1 is selected by default. Theres also a light 
called AM that is ambient -- it comes from all directions 
at once. If you turn that off, it looks like youre 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 its 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 doesnt 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 
its active, because its 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.  Theres more information in Chapter 
Five, Geometry Viewer Subsystem, of the Users Guide.

I want to point out three more things on the Geometry_Viewer 
panel, and theyre 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

Its a 3x3 scalar mesh, and so only the nine Z values are 
provided. They dont have to be in a 3x3 array of numbers; 
thats 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 doesnt 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, Im 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 Centers 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 Centers 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. Lets 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 dont 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 
were interested in; skip over 4744 scanlines of 10,000 
pixels per scanline. Note that dim2 = 5256, the maximum 
scanline were 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 (youd 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 Centers 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 Carolinas 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.

