NCAR-TN/169+PROC

NCAR TECHNICAL NOTE

- I - -I 311 11-1 1 -I I - II I e~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~--1 ---- 3~~~~~~~~~~~

April 1981

Proceedings of the First Annual Computer Users Conference

"Planning for the 1980's"

Editor: Linda Besen

SCIENTIFIC COMPUTING DIVISION

i

NATIONAL CENTER FOR ATMOSPHERIC RESEARCH BOULDER, COLORADO

PREFMZ

ANNUAL COMPUTER USER'S CONFERENCE January 1981 The First Annual Computer User's Conference was held January 5-6, 1981 at NCAR's Mesa Laboratory in Boulder. "Planning for the 1980's" was the theme of the conference, which included the following goals. 1. To give computer users an opportunity to participate in medium- to long-range planning activities and to make recommendations concerning planning and policy documents of the Scientific Computing Division. 2. To provide a forum for introducing new ideas and to recommend hardware and software changes that would facilitate the scientific user's research.

3. To provide a forum for SCD staff in providing an improved service for

those who depend on SCD services in their research efforts. t4. To provide a forum where users may share problem solutions with other users.

5. To enable users to communicate with other users and the NCAR staff about the service in an informal and direct way. The proceedings of the conference are included in this technical report. Some of the papers prepared for the conference were included in a preDr. Macintyre's report on planning is also conference distribution. His report emphasizes the "key to successful planning-repeated. anticipating real needs and opportunities before they arise." Planning also Both scientific and assumes that the goals of the SCD are clearly defined. The scientific goal emphasizes technical goals are important considerations. service to scientific users in the area of computing at the appropriate level to support the primary goals defined by the scientific problem. The technical goals are to provide state-of-the-art facilities in computer Members of the SCD staff have prepared material on software and hardware. mass store needs, data needs, graphics and other software tools. These topics were covered in the session on SCD Issues for the 1980's. The acquisition of Delivery is an Input/Output Satellite Computer (IOS) has been completed. expected in mid-March, 1981. The conference included a discussion of the IOS and its impact on the present configuration and user services that will be enhanced by this procurement. A consulting service and SCD documentation exhibits were among the information displayed at the conference. Section 1 of the Conference Proceedings contains the Planning Document referenced above which was the keynote address of the conference. Section 2 contains the material prepared for the conference by members of the SCD staff.

Sectior 3 of the Conference Proceedings contains summnaries of the workshops The topics included which were held on research goals and comnputing needs. Physics, Mesoscale Modeling, and Astrophysics, Oceanography, Climate, Cloud other's. Research goals and the corresponding computing needs that are identified in these workshops will assist the NCAR SCD in determining its role in providing the quality and amount of computing required. The Conference Committee was chaired by Buck Frye, Assistant Manager of User Ann Cowley was responsible for' the information displays that Services. described the services provided to users of the SCD computer systems. Linda Besen prepared the documentation table and answered questions about Linda was editor of the User Services documentation during the conference. Pre-Conference Packet and is the editor for the Conference Proceedings as Cicily Ridley was responsible for invitations to participants and well. assisted with the conference planning for the workshops. Thanks should be given to the following persons who assisted the committee with arrangements for the conference: Darlene Atwood, Betty Davie, Ben Domenico, Vonda Giesey and Barb Ostermann. Special thanks go to Margaret Drake, Deputy Director of the SCD, whose ideas and guidance were invaluable to the success of the conference. We appreciate that the success of the conference was in large measure due to the enthusiastic participation of members of the scientific community who attended. The Scientific Computing Division (SCD) gratefully acknowledges the financial assistance of the Division of Atmospheric Science of the NSF for defraying part of the transportation expenses of some of the participants to this conference. Jeanne Adans Manager, User Ser'vices and Planning Buck Frye Chair, Conference Committee

ii

TABIE OF COTENTS

SECTION 1: SCIENTIFIC comI G DIVISION PLANNING

.. .... 1.1 e.. ... ... .... Planning Document SCD Planning Assumptions ......................................... 1.1

eo

oo..........................
................. 3......... 1.3
1.4

SCD Planning Objectives . ........... Appendix A: Appendix B:

Progr am Priorities ...........................................

1.15 Interactive Raster Graphics ......................... Minicomputers and Supercomputers .................... 1.17

SECTION 2: SCIENTIFIC CHPUTING DIVISION ISSUES

SCD Issues............................ 2.1

Graphics:

Options, and Plans for the 1980's .............

2.4

Introduction .................................................. 2.4

o....... 2.5 Background and Context .................................. *o Current Status of SCD Graphics Services................... .... 2.8 ...........................O.. 2.12 Future Plans and Options...
An Overview of the IBM 4341: A New Input/Output System............ 2.26

2.30 ............................. Software Tools: Plans for the 1980's . Introduction ......... ................................ ........... 2.30
Issues ............................ . ... .......................... 2.32

Current Status of SCD Software Tools............................ 2.34

.2.43 . . Externral Software Tool Collections. Conclusions ..................................................... 2 47
Plans ........................................................... 2.47

References ...................................................... 2.48 Append ix............ ...................... ....................... 2.48 Outline of Plans for the Next Several Years........................ 2.51 Introduction ...................................... ............. 2.51 Data Needs and Plans ............................................ 2.51
... 2.53 .............. .. ........ Specific Data Tasks ................ 2.56 ................. about Data ............... Access to Information Interactive Manipulation of Data............................... 2.56

Mass Storage Goals, Characteristics, Perspective and Outlook....... 2.58

Mass Storage Systems: A Brief Overview............ ............ 2.58 History and Experience with the NCAR AMPEX TBM.................. 2.61
Where Do We Go from Here?................. . 2.70 ..............

Data Recording Technology .

2.77 .....................................

iii

Workshops on Research Goal s.. Workshops on Computing Ned.3.5

,e0 .3.
O0

:a0Wa3.3
0OV

Astrophys ics and Upper Atmospher~e,..C1i'm at e.... 00&0 aO .

0
,e..O0O00*

1 ,ai00w00000000;006

~3 .6

Basic Fluid Dynamic's and Oceaograhy

*O0&0000w0

,O3.1~6
21i
6O00O0O0d

011

... Cloud Pyis.. Weather Prediction and Meso'scale Mdln.3.214

Workshop Summ-ar yo...01

0OOO60:Pa* D6'

3.31

Response to Conference. Recommend'ati-ons....-

014eO60040*O06v3.32:

iv

MONDAY, JANUARY 5 9:00 a.m. KEYNOTE SESSION Introductions Welcoming Remarks SCD Long Range Plan WORKSHOPS ON RESEARCH GOALS Astrophysics and Upper Atmosphere Basic Fluid Dynamics and Oceanography Climate Cloud Physics Weather Prediction, Mesoscale Modeling SCD ISSUES FOR THE 1980's Introduction I/O Satellite Data Needs Mass Store Graphics Software Tools WORKSHOPS ON COMPUTING NEEDS Astrophysics and Upper Atmosphere Basic Fluid Dynamica and Oceanography Climate Cloud Physics Weather Prediction, Mesoscale Modeling RECEPTION W. Macintyre W. Hess, W. Macintyre W. Macintyre D. Hummer B. Semtner T. Vonder Haar H. Orville C. Kreitzberg J. Adams D. Fulker R. Jenne P. Rotar L. Henderson R. Rew D. Hummer B. Semtner F. Baer H. Orville C. Kreitzberg

11:00 a.m.

1:30 p.m.

3:45 p.m.

5:15 p.m.

TUESDAY, JANUARY 6 9:00 a.m. SUMMARY AND CONCLUSION Introduction Workshop Summaries Overall Summary SCD Response and Concluding Remarks W. Macintyre Discussion Leaders C. Kreitzberg W. Macintyre

10:45 a.m.

LIST OF PARnCIPANIS

Dr. Richard A. Anthes Dept. of Meteorology Pennsylvania State University 503 Walker Bldg. University Park, PA 16802 Dr. Ferdinand Baer Dept. of Meteorology University of Maryland College Park, MD 20742 Dr William Blumen Astro-Geophysics Dept. University of Colorado Boulder, CO 80309 Dr. Thomas L. Crystal Mech. & Nuclear Engr. Dept. Technical Institute Northwestern University Evanston, IL 60201 Dr. Robert Gall Institute of Atmospheric Physics University of Arizona Tucson, AZ 85721 Dr. Larry Gates Dept. of Atmospheric Sciences Climatic Research Institute Oregon State University Corvallis, OR 97331 Dr. John E. Geisler Dept. of Meteorology & Physical Oceanography University of Miami 4600 Rickenbacker Causeway Miami, FL 33149 Dr. Dale Haidvogel Clark Laboratory, Room 350A Woods Hole Oceanographic Institute Woods Hole, MA 02543

Dr. David D. Houghton Dept. of Meteorology University of Wisconsin 1225 W. Dayton St. Madison, WI 53706 Dr. David G. Hummer JILA University of Colorado
Boulder, CO 80309

Dr. Glenn R. Joyce JAYCOR Dr. Carl W. Kreitzberg Dept. of Physics Drexel University Philadelphia, PA 19104 Dr. E. Rex Krueger Office of Education Systens Oregon State System of Higher Education P.O. Box 3175 Eugene, OR 97403 Dr. Larry Lee National Science Foundation
1800 - G St. N.W.

Washington, D.C.

20550

Dr. Robert Mobley Climatic Research Institute Oregon State University Corvallis, OR 97331 Dr. Harold D. Orville Dept. of Meteorology South Dakota School of Mines & Technology Rapid City, SD 57701 Dr. Richard Peskin Dept. of Mechanical & Aerospace Engineering Rutgers University New Brunswick, NJ 08903

vi

Dr. Gandikota V. Rao Dept. of Earth and Atmospheric Sciences St. Louis University Box 8099, Laclede Station St. Louis, MO 63156 Dr. M. H. Rees Geophysical Institute University of Alaska C.T. Elvey Bldg. Fairbanks, AK 99701 Dr. Thomas Seliga Atmospheric Sciences Program College of Engineering Ohio State University 2015 Neil Ave. Columbus, OH 43210 Dr. D. E. Shemansky Earth & Space Sciences Institute 3625 E. Ajo Way Tucson, AZ 85713 Dr. David Smith Dept. of Geosciences Purdue University West Lafayette, IN 47907 Dr. Richard Scmerville Ocean Research Division Mail Code A-024 Scripps Institution of Oceanography La Jolla, CA 92093 Dr. Robert L. Street Dept. of Civil Engineering Stanford University Stanford, CA 94305 Dr. Max Suarez Dept. of Atmospheric Science
UCLA

Dr. Eugene S. Takle Climatology-Meteorology 310 Curtiss Hall Iowa State University Ames, IA 50011 Dr. Andrew Vastano Dept. of Oceanography Texas A&M University College Station, TX 77843 Dr. Thomas H. Vonder Haar Dept. of Atmospheric Science Colorado State University
Fort Collins, CO 80523

Dr. Bryan C. Weare

Dept. of Land, Air,

and Water Resources Univ. of California at Davis Hoagland Hall Davis, CA 95616 NCAR People Attending Terry Clark, CSD Peter Gilman, HAO Wilmot Hess, Director, NCAR Chuck Leith, Director, AAP Jack Miller, HAO Ray Roble, AQD Ron Ruth, ATD Bert Semtner, AAP Rick Wolski, AAP SCD People Attending Jeanne Adams Ann Cowley Margaret Drake Buck Frye Roy Jenne Gary Jensen Dennis Joseph Walter Macintyre Bernie O'Lear Pete Peterson Cicely Ridley Paul Rotar

405 Hilgard Ave. Los Angeles, CA 90024 Dr. Tsutomu Takahashi Cloud Physics Observatory University of Hawaii Hilo, HI 96720

vii

PSlEaO

1: SC

IC

nnin

DIVISION PLaNln

Planning Document

SCD Planning

1.1 PHJING DOCUMET

Planning Document

by Walter M. Macintyre

SCD PLA NIG LS

IS

The key to successful planning is to anticipate real needs and opportunities before they arise. Plans to meet these needs, and to take advantage of these

opportunities, normally should involve costs that remain within the envelope of the funding that can reasonably be expected to be available. However, a

vital organization must be able to respond promptly to major new initiatives and to secure the funding required by that response even though the additional costs may be a major perturbation on the budget. has been developed with these considerations in mind. This program plan The plan will be

implemented in such a way as to enable the SCD to make a swift and credible response to any proposal to institute a major new scientific program. Planning assumes that the goals of an organization are clearly defined.

Definition of the SCD's goals involves an appreciation of the fact that the SCD serves two quite distinct publics, the NCAR scientific staff and the

atmospheric science community external to NCAR.

Since the SCD is the only is essen-

computing resource available to the majority of the NCAR staff, it

tial that the SCD provide a complete computing service to the NCAR staff. The SCD will continue to provide to the atmospheric science community at large those facilities and services that cannot reasonably be expected to be available on the various campuses. Furthermore, it is crucial that NCAR con-

tinue to be regarded as the place where atmospheric scientists can confidently expect to have access to state-of-the-art computing technology.

Planning Document

1.2

SCD Planning

Planning also involves devising a set of priorities which can be used as a guide in minimizing the effects of budgetary stringency or, conversely, maximizing the return, measured in scientific output, on normal levels of funding or on new budgetary initiatives. The priorities used in developing a

program plan should reflect national priorities in development of the various components of the atmospheric sciences. This plan assumes the priorities

defined in the report* of the National Research Council Committee on Atmospheric Sciences. As understood in the SCD, the scientific range of the computations required

by the atmospheric science community include basic atmospheric physics and fluid dynamics, the dynamics of the oceans and solar physics. The chemistry

of the atmosphere also makes a heavy demand on computing resources and is an area of steadily increasing importance to NCAR's mission. To these must be

added some elements of the biology and chemistry of the land and seas, since there is a clear interaction between biology and atmospheric science in agriculture and in the study of urban fisheries) smog. Events such as "el nine" have The absorption

economic implications (e.g.

as well as climatic.

of CO by the oceans could well affect marine life before it can affect the 2 climate. Probably the most serious deficiency in the NCAR central computing facility is the heterogeneity both in hardware and software (mainly operating systems). tion. Another serious deficiency lies in the organization of the configuraThese two deficiencies have meant in the past that in periods of fisthe Computing Facility had no way of making a mean-

cal stringency at NCAR,

T-The tmospheric Sciences: National Objectives for the 1980's", Nat. Acad. Sci., Washington, D.C. (1980).

SCD Planning ingful cut in expenditures (and, the Facility entirely.

1.3

Planning Document

of course, services) without shutting down

They have also made the NCAR system unnecessarily

complex from the user's point of view. The overriding priority that will govern the implementation of this plan, whether in the procurement of equipment or in the development of software, will be to ensure that the resulting system will be sufficiently flexible to accommodate both budgetary expansion and contraction. In the case of hard-

ware, the configuration must be capable of continuing to operate, albeit at reduced capacity, after withdrawal from service of significant components. The software similarly must be modular, and flexible enough to manage the

remaining hardware, albeit with reduced throughput. Part of that flexibility depends on a change in the SCD's procurement philosophy. The SCD must begin to lease (not lease-purchase) at least some of the

hardware, purchasing only those elements which are central to the function of the facility and whose useful life is expected to be long. Important hardware procurement criteria will be the ease with which the vendor supplied operating system can be integrated with existing systems and the degree sources. to which it provides interfaces to software derived from other

SCD PLaME

WECTL of

The scientific goal of the SCD is to develop and maintain that level

scientific expertise necessary to provide the appropriate levels of computing service required by NCAR and non-NCAR scientists in performing their

Planning Document computations.

1.4

SCD Planning

The technical goals of the SCD are to have available, in good

time, the hardware and software required to carry out these computations. The specific steps required to attain these goals are enumerated below. 1. Provision of adequate hardware capacity to meet the growing needs of atmospheric science in the 1980's. 2. Provision of appropriate general purpose software to meet the changing needs of atmospheric science in the 1980's. 3. Studies in data structures and numerical methods appropriate to the systens and the needs of the 1980's. 4. Provision of improved mechanisms to instruct the user community in the use of the SCD's evolving systems, both hardware and software. 5. Management of procurements t6 provide compatible hardware and software systems. 6. Change to lease (not lease-purchase) in procurement of certain systems.

Objectives 5 and 6 involve management procedures, and will not be addressed further in this document.

PRImEs
A. HARDWARE PRIORITIES. Provision of computer capacity adequate to the needs of the atmospheric science community.

Priority 1:

SCD Planning Priority 2:

1.5 Provision of a hierarchical,

Planning Docunent online storage system of capacity The technology is available

in the range 1013 _ 1015 bits.

currently almost to meet the lower figure; online storage of 1013 bits should be easily attainable in FY85. Priority 3: Provision of wide band-width digital communications between the SCD and remote sites. Priority 4: Provision of support for interactive vector and raster graphics both within NCAR and at remote sites. (This is a combined

hardware/software item and is discussed in Appendix A.) The order of priorities represents not only an assessment of the individual importance of the several elements to the atmospheric sciences. The order

represents a relation among the elements in that a higher priority item can be implemented without any substantial commitment to those of lower priority. However, the converse is not true, e.g. priority 4 cannot be implemented

properly until all others have been implemented. While the priorities are expressed in hardware terms, imperatives that cannot be ignored. there are software improved data

A major requirement is

management systems, for which a prerequisite is a set of highly compatible operating systems on NCAR's computers. Ideally, any user of the SCD comput-

ing facilities should be able to access all machines via a uniform control language. An important selection criterion in procurement of hardware will

be the degree to which the vendor-supplied operating system is compatible with that vendor's required ideal. system software A further criterion will be the ease with which the interfaces with commercially available software; where

is available,

SCD will purchase whenever possible, thus

Planning Document saving substantial development costs. PRIORITY 1

1.6

SCD Planning

.Ar

Ad,

__ __*-___ _

ADEQUATE COMPUTING CAPACITY

The top priority must be to provide computing capacity adequate to the needs of the atmospheric science community; this community includes individuals While no single new

whose work is supported by agencies other than the NSF.

project with major demands on our resources has been authorized at this point (11/17/80), normal growth must be provided for. Moreover, there is the real

possibility that major new initiatives may develop in the near term, particularly in oceanography; tively to these. the SCD must be able to respond promptly and effecseveral ways. One is through the in

Normal growth arises in

increase in the amount of use external recent years.

to NCAR which has been observed

The number of CCU's used by non-NCAR scientists has risen from

864 in FY79 to 1,140 in FY80--an increase of 32%. A second follows from the increase of activity in atmospheric science resulting from the recent real increase in funding levels from agencies other than NSF. and This has arisen from a renewed national interest in atmospheric science oceanography. A third is the increase in productivity of scientists interactive computing (sometimes

induced by the general misnamed time-sharing).

availability of A fourth is

the growth of computing activity as new

instruments and large cooperative programs generate increasingly large quantities of new data. Not only do these data require substantial computer

capacity simply for cleaning them up, interpreting and correlating them; in addition, the availability of new data, in increasing quantity and of

steadily improving quality, theorists.

acts as an encouragement

and challenge to the much of the

Without appropriate and adequate computers at NCAR,

SCD Planning

1.7

Planning Document

benefit of increased research in the atmospheric sciences could be lost. Of course, there are two ways to meet any supply/demand problem-the supply, or restrict demand! increase

Restricting demand can be done in two ways, All projects can be

assuming competing projects are of comparable "merit".

supported at a less than optimal level, in fact at a continuously decreasing level. This particular policy is a cop-out and simply ensures that no proIt is, therefore, unacceptable.

ject is adequately supported.

The second way of reducing demand involves selection of some projects for full support and denial of all but minimal support to the others. Employment

of such a procedure assumes that hard decisions on priorities will have been made within the atmospheric science community. Although it might well mean

denial of support for excellent work, allocation of computing resources would have to be based on such priorities if supply cannot be increased. In that

case, the priorities used will be those defined in the recent report* of the NRC Comnmittee on Atmospheric Science. It is the SCD position that the supply/demand supply. Increasing problem must be solved by

increasing

supply to meet steadily increasing

demand

means regular growth in the computer capacity of the SCD.

PRIORITY 2 - ON-LINE STORAGE

As a second priority, NCAR's current hierarchical improved and enhanced.

storage system must be

Currently, data are staged from archival storage,

usually conventional 1/2" magnetic tape, to the TBM, from the TBM to the magnetic disc storage of the relevant computer, and thence to the computer

"The Atmospheric Sciences: National Objectives for the 1980's", Nat. Acad. Sci., Washington, D.C. (1980).

Planning Document itself. i.

1.8

SCD Planning

There are several problems with the existing system.

The online capacity is low: 510 x i09 bits for the TBM. 39 x 109 bits for the CRAY discs. 20 x 109 bits for the 7600 discs.

ii.

Access to data sets is relatively slow, especially if the data are not on one of the online TBM tapes. reported, and times of one hour Access times of a few hours have been are not uncommon. Such delays are

inherent in a heavily loaded magnetic tape based system. iii. Over the next five years, the online storage needs of NCAR will increase by at least two orders of magnitude to around 1013 bits. Furthermore,

access times of the order of one hour will become utterly intolerable as system load builds. The ddmands of major new programs may push this

requirement still higher. iv. The storage system is highly heterogeneous resulting in rather complex storage access procedures for the user. Complexity leads to confusion,

confusion leads to errors, and errors lead to lost-wasted-time, human and computer. It is essential that the new hierarchical storage system Ideally, the working scien-

be as transparent to the user as possible.

tist should not need to know on which of the media his data are stored; a single command should stage his data into the computer regardless of where the data happen to be resident. Mass storage is an area of technology in which change, and progress, extremely rapid. is

As an example, today one can buy a magnetic disc system

SCD Planning

1.9

Planning Document

with the same capacity as the TBM, with data set access times of a few milliseconds and costing the same number of dollars as the TBM did five years ago. With a different technology, a magnetic strip system with ten times the

capacity of the TBM, and a maximum access time of the order of a few seconds, can also be purchased at the price of the TBM five years ago. data density of 105 bits cm.- 2 The TBM has a

The current thin film magnetic disk technolbits cm.

2

ogy has a limiting data density of

A new technology, which

should be on the market within four years, optical discs, offers a read only storage medium with data density currently at around 10 bits cm.
2

Efforts

are being made to develop a read/write capability in the optical disk systems and also to increase still further the data density. Finally, in the initial

research stages are devices, using wholly different physics, with densities of the order of 1012 bits cm7
2

These new devices are unlikely to be avail-

able in fewer than 8-10 years; however, it is interesting to note that NCAR's minimal needs in five years' time, 1013 bits, would be accommodated on ten Clearly the cost of online storage of

square centimeters of such a device!

very high volumes of data is going to decrease quite steeply over the next ten years. A strategy must be developed that will enable NCAR to take advantage of rapidly falling mass storage costs. It is crucial that the SCD have the

flexibility to move rapidly from one mass storage technology to the next as the combination of technical requirements and financial considerations permit, and to do so with minimum inconvenience to the atmospheric science community. This flexibility will require a change from purchase of hardware by It will also demand the

the SCD to relatively short team lease (2-3 years).

developnent of data handling software in which the user interface will remain

Planning D1cunent

1.10

SCD Planning

unchanged as the various storage media replace each other.

PRIORITY 3 - DIGITAL COMMUNICATIONS

The SCD computers are accessed by dial-up or leased line telephone connections from nearly 100 laboratories. Procurements in process will increase

the speed and flexibility of such access and permit a modest increase in the number of remote job entry stations. The transmission rates over data comproviding more cost-

munications lines will also increase substantially, effective use of the equipment.

It is expected that as the improvements become apparent in NCAR's facilities for providing a remote computing service, the demand will rise rapidly. increase in demand will have to be met. However, the major part of the digital communications growth will stem from other developments. Provision must be made for high band-width (5 MHz) digiSeveral developments are This

tal communications within the next five years. responsible for this: i.

A substantial increase in the flow of data coming into NCAR,

and so to

the SCD, from large, cooperative projects, including satellite data. ii. Commercial, high band-width, satellite-based digital communications systems are being launched. data rates c. 3 Mbit/sec., With these communications systems providing it becomes feasible to use the research data including interactive raster

sets located at NCAR for computations, graphics, at remote sites.

Such a development will increase by several

orders of magnitude the data base accessible to atmospheric scientists with sophisticated, mini-computer controlled graphics systems. The

SCD Planning

1.11

Planning Document

result should be a greatly enhanced productivity in these laboratories, and a substantial enhancement in the range of the work carried out should also be evident. iii. It can be anticipated that commercial digital networks may begin using systems. to At that point, the SCD its computers for its

these satellite based communications

could provide considerably improved access users by becoming a host on such a network.

At current data rates, and

with existing protocols, the SCD can. reap no advantage from the use of national digital networks.

B. i.

STAFF ASSIGNMENT PRIORITIES.

Systems

Section the maintenance of the

The highest priority in the systems section is

integrity of the current operating systems, including the software running the internal NCAR network. This is a major task given the variety Furthermore, dimin-

of equipment for which the section is responsible.

ished effort in this area will exact a price later in lost time arising from software failures. In the long term, as the older hardware is

replaced by new, mutually compatible units, some decrease in this type of activity can be expected, but the level of effort will never become small. Nevertheless, by about 1985, some reassignment of the mainte-

nance effort should be possible. ment at NCAR will not be revived.

"Ab initio" operating system develop-

Planning Document

1.12

SCD Planning

The second priority is systems support of activities in other sections, notably User Services and Data Support. An example is modification of of a

existing or projected systems software to permit implementation uniform file descriptor.

Priorities within this category will be those

set for the applications areas. ji. User Services Section The function of this Section is to facilitate the efficient use of the SCD hardware and software by all the scientists using SCD facilities. This is a tall order and one for which the Section is seriously understaffed. The first priority of this Section will be to expedite access by existing users to existing systems. This involves increased or renewed

activity in three areas: 1. 2. Formal courses offered on a regular schedule. Extension of the.Consulting Project. Heavy emphasis on user-oriented documentation of software systems.

3.

Two additional FTE have been requested in FY82 for the Consulting Project. Teaching and documentation effort will be enhanced by a redeploy-

ment of existing staff. The second priority is the development, with the Systems and Data Support Sections, of a uniform file definition procedure which, ideally, will define and/or access a file or file set regardless of the physical location of the file.

SCD Planning

1.13

Planning Document

The third priority is the development and maintenance of the community climate model in collaboration with the Atmospheric Analysis and Prediction Division. activity. The fourth priority is completion of the general data processing system, GENPRO II. This system in fact is relatively close to completion and, A further two FTE have been requested in FY82 for this

apart from maintenance activity, should not impose any demand on User Services staff beyond FY81. The fifth priority is modification and/or documentation of a number of locally developed software systems. One of these, the NCAR Graphics

System, is a batch-mode system that is well-documented and widely used. Interactive access to this system will gradually be implemented, beginning with the relatively simple provision of online pre-viewing of pictures produced in batch mode before they are recorded on film. examples are the preprocessors PP1, IFTRAN and FLOTRAN. Other

These prepro-

cessors have not received the attention in SCD they merit, and they will be developed and documented to the level where they can be easily and reliably used by the general atmospheric science community. Although these developments are ranked in five priority levels, SCD is fully committed to their completion. The priorities relate to timing

rather than intrinsic importance and reflect in a general way the number of SCD computer users associated with or affected by each one. A further development, that will require discussion, is advanced

interactive vector graphics and an NCAR interactive raster graphics system. This development is one that will require investment in hardware

Planning Document as well as software.

1.14

SCD Planning

The question here is whether standard systems

should be developed or bought by SCD or whether independent development at several different sites will proceed regardless of SCD action. ter graphics is discussed in more detail in Appendix A. iii. Numerical Methods Section The responsibilities of this Section lie in two related areas. These Ras-

are support of the community climate model development and in scrutinizing existing numerical methods in relation to the apparent architecture of tomorrow's large machines. These machines are likely to be highly

parallel in structure and it is far from clear how computations in the atmospheric sciences can best take advantage of this feature. memory on these machines is available today. This section, at two FTE, is below optimum size for its responsibilities. Two additional FTE have been requested in the FY82 budget. Central

also likely to be very much larger than is

iv. Data Support Section This section has two development priorities that are difficult to order. One is to take part in the development of new data structures and uniform data file definition in collaboration with the User Services and Systems Sections. As the collective owner of the largest collection of

data in the NCAR archives, and also in view of its ongoing responsibilities, the Section cannot ignore these developments. The second is connected to UCAR's recent statement of increased interest in and emphasis on the dynamics of the oceans. The Section will have to

SCD Planning

1.15

Planning Document

expand its activities to include certain oceanographic data. To accommodate these additional responsibilities, increased by three FTE. the staff will be

One has already been provided by internal reas-

signment; two new FTE have been requested in FY82.

APPENDIX A: The SCD at

INTERACTIVE RASTER GRAPHICS one of the finest libraries of graphics

NCAR has developed It

software in the world.

is a library that is used primarily in batch mode

and is used in generating most of the nine million frames per year of microfilm output produced at the SCD. It is primarily designed to handle vector composed by drawing a number of vecwhich are defined by specifying From the beginning, the

graphics where a diagram or picture is tors, of varying length and

orientation,

coordinates of the points at each end of the vector.

SCD has been regarded as having responsibility for developing for multi-user, portable software in the atmospheric sciences, and for setting software standards. Vector graphics is the one area where these responsibilities have It is proposed to extend the existing vector graphics system to

been met.

cover interactive raster graphics as well. In recent years raster graphics have extended the range and power of computer graphics. In raster graphics the smallest portion of the graphics CRT screen In

that can be conveniently resolved is called a picture cell, or a pixel.

the most general case, the picture is built up by contributions of the individual pixels in the array of pixels comprising the screen. Thus the posiThe con-

tion of each pixel is predefined by its coordinates in the array.

tribution of each pixel to the picture arises from two attributes of the

Planning Document pixel--intensity and color. intensity is sity is

1.16

SCD Planning

In simpler systems, color is omitted and only Usually inten-

specified, giving a "black" and white picture.

specified by 8 bits of information, corresponding to a gray scale of Color may be specified by additional bits, from 4 to 8, giving 16

256 steps.

to 256 shades of color. In modern systems, the screen resolution is 1:103, giving 106 pixels per picture. x 106 Thus to define a picture in black and white raster graphics requires 8 bits (106 bytes). For color pictures, the amount of information

required is 1.5 to 2 times larger than for black and white.

Thus an enormous

amount of information has to be stored to represent even the simplest pictures in raster graphics mode. However, the quality of the reproduction of that of the best quality domestic

the picture is very high, superior to television sets. Clearly raster graphics complements

the more economical is

vector graphics in or where a

applications where resolution of very fine detail picture contains a great deal of information.

required,

The amount of information required to generate a raster picture is enormous. Two megabytes or more are required simply to reproduce a full screen picture, yet these two megabytes may be derived from data sets hundreds of megabytes in size. It is easy to see that raster graphics terminals require dedicated

minicomputers to handle the flow of the data and some degree of manipulation of them. It is clear that one of the most important applications of minicomputers in the atmospheric sciences will be the control of raster graphics devices. (up to k$250) cannot be

However, minicomputers in modest configurations

SCD Planning

1.17

Planning Document

expected to store all the data sets from which pictorial output might be desired. These data sets must be stored in a large, appropriately organized The data may then be accessed in two ways. A prelim-

system, i.e. at NCAR.

inary selection and reorganization of the data can be carried out on the SCD computers and an appropriate subset transmitted to the remote site to be processed further by the minicomputer there and displayed on the screen. Alter-

natively, NCAR data sets may be transmitted unchanged to the remote site, and all manipulation carried out at the minicomputer there. Thus the SCD will play a crucial supporting role in the developing field of computer graphics, e.g. storage of data, organized in a form easy to access, and provision of simple utilities to reorganize those data to meet the needs of a variety of projects. The SCD will be unable to play this role without

the computing capacity, the online storage and the digital communications given as the first three hardware priorities. The alternative to providing

this capability at the SCD in NCAR will be substantial upgrading of numerous minicomputers across the country. Not only would this not be cost-effective, If each minicomputer site

but it would be scientifically counter productive.

processes, stores and organizes the same data in its own way, it won't be long before the data aren't the same anymore! The only way to ensure that several different approaches to the same problem can be compared is to ensure that they are unambiguously based on the same data. This point is crucial.

APPENDIX B:

K[NICGIPUTERS AND SIFERCONPUTEDS

No discussion of SCD plans can be complete without a mention of the role

Planning Document played by the small computer.

1.18

SCD Planning

The continuously decreasing cost of computer

hardware has made available, over the last ten years, increasingly substantial mini- and micro- computers at a price sufficiently low that they can be dedicated to the use of individuals, groups of individuals, or for the control of individual instruments. vices offered by the central These small computers complement the serimportant ways; this observation

facility in

applies both within NCAR and at the non-NCAR sites. For interactive graphics other than simple vector variety, a minicomputer is usually necessary for the generation of images; the interactive graphics terminal itself may or may not provide storage for the image currently on

display.

Such a system, with adequate main and secondary storage, may funcHowever, given a wide

tion as a stand alone interactive graphics device.

band communications link between the graphics system and the main NCAR computers, an additional dimension can be added to the graphics system. Images

generated after complex computations on the NCAR computers can be viewed at a remote site. at Alternatively, images derived from very large data sets stored a remote site and viewed thus has its capability there. The

the SCD can be transmitted to situated graphics system

remotely

considerably

enhanced by access to the very large storage and computational facilities at NCAR. A similar stand-alone capability is unlikely to be cost-effective,

particularly if the additional capacity is needed only for occasional use. A second important area where minicomputers are essential is in the execution of interactive programs How heavy is which involve is heavy computations and/or disk which

input/output.

"heavy"

a matter for

fine judgement

includes the cost of the minicomputer, trally administered interactive

the capacity of and load on the cen(whether at NCAR or the local

facility

SCD Planning campus),

1.19

Planning Docunent

the degree to which interaction with the computer is essential to

the work, and, of course, the scientific importance of the work. A third application in which dedicated computers are required is real time use--control of instruments and equipment either where a very rapid response to a signal has to be computed, or where signal averaging techniques must be used to extract the desired signal from a very noisy source. The real time

computer may or may not provide a cost effective way of processing further the collected data. Frequently the data will be transmitted to a larger

multi-prograrmed central computer for additional processing and/or interpretation. Numerous applications, e.g. the interactive editing of graphical displays,

have elements characteristic of all of the above modes of operation. Typically, centrally administered facilities are more cost- effective than minicomputers for interactive text editing and program development. However,

one condition for this statement to be valid is that the execution of user programs on the central facility at interactive priority must be carefully monitored. A few users, running from their terminals programs, at interac-

tive priority, with large CPU or I/O requirements, can seriously degrade the system's response to other interactive users. Thus the decision as to whether to provide a dedicated minicomputer for the use of one person, or a small group of people, is an extremely complex one. Quite apart from the above considerations, ignored. psychological factors cannot be

Many people simply like very much the freedom and flexibility pro-

vided by possession of their own computer, and will often insist on procurement of one where an impartial cost/benefit analysis might well indicate

Planning Document otherwise.

1.20

SCD Planning

A further point is that it doesn't take many requests for $ 3 00, 000-$ 4 00,000 small computers to add up to the equivalent cost for a rather large centrally administered system. Each application for the procurement of a minicomputer, larger ones, above. particularly the

should be evaluated dispassionately by the criteria detailed

SECITI~

FIC CaWUMG DIISION :SIEIFIC DIION

Introduction Graphics: Options, and Plans for the 1980's An Overview of the IBM 4341: A New Input/Output System Software Tools: Plans for the 1980's Outline of Plans for the Next Several Years Mass Storage Goals, Characteristics, Perspective and Outlook

-SCD Issues

2.1 SCD IS -

SCD Issues

by Jeanne Adams

One session of the conference was devoted to Scientific Computing Division (SCD) Issues for the 1980's. A number of the central issues covered at the

conference are presented by SCD staff members involved in procurements and planning for the Division; other important issues in this section are graphics tools, software tools, information about data archiving and mass storage goals. This list is not exhaustive by any means. identified that are important as well. 1. Resources and programmer A number of other issues can be

Some of these are discussed below. a

intensive effort must be allocated among

number of software projects. among the papers.

Graphics and Software Tools are covered software are not.

I/O utilities and mathematical

Consideration must be given to all of these as priorities are set. 2. It is planned that general training for SCD users will be resumed. The

plans for implementation of a training program that will satisfy user needs best must be developed. 3. Uniformity among a number of facilities on the network of computers is another topic. If the network itself is viewed as the "machine", rather

that the individual computers on the network,

then uniformity on the

network is important to consider for a Job Control Language and a file system.

SCD Issues 4.

2.2

SCD Issues If ease of

Portability of programs among computers is another issue.

moving programs from one machine to another is to be achieved, then programming language standards and protocol standards should be considered, 5. The implications of networking need consideration to achieve efficient data transfers from remote sites. cost effective as well. Each of the speakers identified other issues in their areas that were not emphasized in the pre-conference material. The first speaker was Dave Fulker, a member of the committee responsible for the procurement of the I/O Satellite Computer. The computer system selecteO The data communication service must be

is an IBM 4341, and delivery is expected some time in March. For three or four months, SCD staff will be bringing up the software and learning the various editors, files. By summer, the scientific user will be able to access the machine. At this and commands for compiling and manipulating

time staff from all of the SCD sections will be trained and ready to assist users, and the hardware and software installed will be solid. The data archive that is acquired and maintained by the Data Support Section is discussed. Included among the planning projects for the Systems Section is

a project that is attempting to provide online storage capacity at the lowest cost-per-bit supported by the current technology. There is a survey of the

graphics software currently available and planned for future support of scientific projects and a survey of the software tools available for use at NCAR. Assisting users in the production of reliable software has been the goal of

SCD Issues

2.3

SCD Issues

the library group for a long time and will continue to be a goal in future acquisitions of software tools.

Graphics GRAPHICS:

2. 4 OFPIONIS AM PLANS FOR THE 1980'S

SCD Issues

by Lofton Henderson

The Scientific Computing Division (SCD)

is

on

the verge of significant This expansion

enhancements of the graphics services offered to SCD users.

is one aspect of a general diversification of NCAR's centralized computing services.

-

Presented in this document are:

Definite plans for graphics enhancements. Goals for which plans of realization are still under consideration. Attractive options which have not yet been targeted as goals. For readers

The remainder of the document is divided into three sections.

who are intimately familiar with the current status of SCD graphics services and with recent advances in the computer graphics industry, only the third section, "Plans and Options," will be of interest. For others, a framework

for interpreting the remainder of the document will be found in the first section, "Background and Context."g The second section further develops this context by presenting the current status of NCAR's graphics services and work in progress. While this is not

the place to deal in detail with the character and current state of the system, we shall at least touch upon the major points--users are often surprised to find that facilities already exist to meet some of their immediate needs. (More system details and an interesting scenario for distributed graphics and

SCD Issues

2.5

Graphics

interactive computing may be found in the article by T. Wright in the Fall 1979 issue of Atmospheric Technology. The article by L. Henderson in tche

Proceedings of the Spring 1980 DECUS Symposium gives a thorough overview of the nature of the system.) Throughout, discussion is generally limited to those facilities under consideration as SCD centralized services. Ideally, SCD services would be a

superset of those generally useful services available on non-SCD satellites, so that those users who are reliant solely upon SCD services would have a full set of useful tools. Whether or not this superset is eventually realThe dis-

ized, we will attempt here to identify its components as options. cussion of SCD plans and options (e.g., equally well applied

for the I/O satellite) could be

to determining the requirements of general purpose SCD activities, additionally,

satellites being set up by other NCAR groups.

are opening some attractive options to users of non-SCD satellites and remote users, and these will be mentioned.

BAKODUf AND COWNEXr HISTORICAL SETINhG Since the mid-1960's NCAR has been a pioneer in the use of computer graphics to extend the power of its mainframe computers and to assist in the

comprehension of the results of complex computations.

The convenience of

online graphics devices and the resulting level of picture production at NCAR were relatively rare among similar scientific institutions. and enhance the utility of graphics display devices, To complement

NCAR has built a

software system whose richness of high-level capabilities relieves much of

Graphics

2.6

SCD Issues Concepts at

the tedium of constructing complicated and meaningful images. the heart of the modern system, independence, appeared

software portability and display device their realization here

at NCAR in the mid-1970's;

pre-dates not only other current systems of a similar nature, but appears to pre-date the earliest vestiges of the graphics standardization efforts which embody the sane central concepts.
INfX~RY TREWNS

The end of the 1970's has seen an explosion in the computer graphics industry. A vast selection of new hardware display devices is now available,

incorporating a seemingly endless variety of display format and technology. At the most expensive end of the spectrum are devices with apparent hardwired intelligence that one would formerly associate with extensive computations on large mainframes. At the other end are devices simple and cheap enough that

a hobbyist could consider having one at home. Software availability is vastly better now as well. plied by the hardware vendors themselves, Aside from software sup-

a number of general purpose pack-

ages, often based on tentative graphics standards and such successful systems as NCAR's, can now be purchased from exclusive software vendors. Special

purpose graphics and image processing software is widely available as well, often in the public domain as spin-offs from such programs as the National Space Program. The benefits to the computer user of this revolution in graphics technology are numerous: well-engineered systems provide comfortable and natural interdistributed graphics terminals, small

faces for users; in the same vein,

plotters, etc., give more personalized service and more user control of the

SCD Issues end product; and more importantly,

2.7

Graphics

the prompt return and display of results

greatly increases user productivity, much as online editors do when replacing batch editors. NEW I

The maturing of the computer graphics industry has enormously accelerated the pace of change of the state of the art. In many areas of the field, the able

state of the art has moved well beyond what NCAR's SCD chooses to or is to offer.

This recent lag is due in part to the fact that SCD's graphics

services have been closely bound to the character of the general computing environment at NCAR. For many years, the environment consisted of a few accessible in batch mode only.

large mainframes

and mass storage systems,

This has been reflected media.

in a passive graphics system directed at hardcopy

Now, however, there is a proliferation of general purpose satellite computers, both within the. SCD (e.g., the soon to be installed I/O satellite), and within other divisions. These offer convenient, fast, interactive access to Most have some

significant computing power for a growing number of users.

sort of communications link to the mainframes and mass storage, and many have now or will have fast, high-capacity links. These changes open the opportunthe graphics hardware and

ity for the SCD to partake of the benefits of

software revolution described above, and to maintain its computer graphics facilities near the state of the art through the next half-decade.

Graphics

2.8 CRENT STATES (OF SCD GRAPHICS SERVICES

SCD Issues

HARDWARE

The dd80's The first graphics devices that NCAR acquired were the dd80 microfilm recorders. These products of early-1960's technology have been generating several simulation and line

million frames of film output per year, both printer graphics, for the last decade.

They are nearing the end of their useful Although adequate for rough,

life, and may soon be impractical to maintain.

quick-look graphics, their accuracy is insufficient for much of NCAR's work and they lack flexibility in output options and film formats. The DMCMED In 1977, NCAR acquired a DICOMED COM (Computer Output Microfilm) system for The system consists of two film tranand represents the state of the art in

eventual replacement of the dd80s. sports controlled by a minicomputer, COM systems.

The recorders are very high resolution compared to the dd80, They can produce either vector or

and offer 256 gray levels instead of 2.

raster graphics, or printer simulation via a fast hardware character generator. Available film formats include 35rm or l6rnm film (sprocketted or

unsprocketted),

and 105nn microfiche (24X or 48X).

The latter format prom-

ises to be the most popular,

because of the huge number of frames one can and the cheapness of image scaling, light

easily maintain in a small space, the ease of reading adequate hardware fiche frame viewers. rotation, Other etc. options The include system's

variable use is

relatively

currently, but is growing steadily since a field upgrade last year stabilized

SCD Issues it.

2.9

Graphics

Access to the transports is still only in offline mode via tape, but the

project to complete its online connection to NCAR's hyperchannel network is nearly complete.
Other

This event will certainly lead to a big increase in usage.

With the exception of a few graphics terminals connected to the SCD satellites, the SCD itself has no other graphics display hardware. Some other

divisions have their own satellites now, with equipment such as graphics terminals (including color raster monitors), electrostatic printer/plotters, the

flatbed plotters, and color impact printer/plotters. NWP satellite, and the RSF RDSS system are examples.

The HAO satellite,

These systems and other

remote stations are linked with the SCD graphics services mainly by use of a common software system.

Functioniality Currently, the SCD is maintaining a graphics software system consisting of somewhere over 50,000 lines of code. Most of this is in the high-level utilThis

ity routines, which perform such functions as contouring, mapping, etc.

high degree of functional completeness is not found in many other scientific data representation graphics systems, and in part accounts for the popularity of NCAR's system. About 20 utility packages are now supported, and at least

3 others have been identified for addition to the system.

Characteristics

The graphics software generated and maintained by the SCD is what is called a

Graphics

2.10

SCD Issues

vector graphics system--its capabilities are oriented toward producing vector or line drawings. In fact, currently there are no facilities for producing The package

filled or shaded regions other than with half-tone simulation.

can further be characterized as primarily passive--it contains no input or picture alteration facilities per se. cannot be used interactively This does not mean that the system

(in fact there are at least two interactive

implementations within NCAR); it means that once an element of a given picture has been generated, it cannot be altered in that same picture in the

fashion of design and layout graphics systems. Two design criteria are critical to the success of a graphics software system in a distributed processing environment: sportable from one computer to another, the system should be easily tranand the user's view of the system The first

should be independent of any intended graphics display devices.

criterion is met at NCAR by using the FORTRAN language and observing good program portability and coding standards. Device independence is attained by

having the package output a file of device-independent, graphics instructions known as metacode. This metafile can then be translated at any time, locally

or remotely, to drive any given graphics device. Portabiity Status Achievement of portability of the basic level plot package is substantially complete, although some recently identified enhancements could make life

easier for implementors.

Versions now exist for all major computer models,

and one can expect relatively painless success if one undertakes to install the system on a new computer system. Indeed, in the last two years, several

hundred copies of the system have been distributed, many of them to research-

SCD Issues

2.11

Graphics

ers wishing to establish the system on computers at their home institutions. Achievement of the portability goal for the higher level utility packages is perhaps 75% complete. Many of the heaviest used packages are done, but a

substantial amount of work remains in order to make implementation of the whole system on a new computer as painless as it ought to be. Device Tndepeodence Status Work on the metacode foundation of the system is substantially complete. The

system now includes a portable "skeleton" metacode translator which allows interfacing a new device to the system with a minimum of work (a week often suffices). All SCD-supported hardware is now driveable via metacode. The

wide range of non-SCD hardware mentioned above is accessible via metacode as well. Additionally, graphics files from mainframe executions are routinely

being transnitted through RJE links for translation and display at remote sites. All that is required for this mode of operation is a display device

and a very modest amount of computing power for the metacode translation. Support Tools This brings us to the last class of graphics tools. Such tools do not generate pictures, software: graphics support

but aid in the management of

files destined for graphics devices. completed for encoding and decoding

A pair of portable programs has been binary metafiles before and after

transmission through NCAR's current RJE facilities.

Programs to prepare text

files for recording on the DICOMED fiche unit, or any other graphics device for that matter, have been completed. Work is in progress on software to aid

in transmission of metafiles and text files to graphics devices with connec-

Graphics

2.12

SCD Issues

tions to NCAR's hyperchannel network.

Finally, as mentioned, work is in an

advanced stage on a software system for the online operation of the DICOMED recorders.

FUTURE PLMANS AD OPFlONS INTERACTIVE GRAPHICS The acquisition of publicly available graphics display terminals connected to an interactive computing system is of the highest priority for the enhancement of SCD graphics services. A number of the autonomous satellite computbut the user without access to such a The frustration and lowered for film turnaround have been

ers currently have such facilities, system is

forced to rely on film production. a couple of hours

productivity of waiting

pointed out, and are probably familiar to many readers. We suspect a substantial proportion of images produced at NCAR end up in

"recycling" with one or zero viewings; wide availability of monitor viewing facilities should help alleviate such waste and somewhat reduce the demand for increasingly expensive film hardcopy. Before dealing with SCD plans to realize interactive viewing facilities, varieties of interactive graphics need to be distinguished. The the term This by the

"interactive graphics" covers an exceedingly broad range of activities. range can be divided conveniently into three groups characterized

level of user

interaction.

These are presented

in an increasing level of For is

complexity, cost to implement, each, noted. the difficulty to Additionally,

and cost of machine resources to support. with currently available SCD tools

implement

some estimate (necessarily subjective) of the current

SCD Issues utility to SCD users is given. either vector or raster

2.13 For the most part,

Graphics the comments apply to

display technologies.

The latter usually incurs

somewhat higher host machine costs; these are not too serious in the case of vector applications displayed on raster terminals that accept vector-type pseudo-raster terminals), but can be very serious where

instructions (e.g.,

the host must completely construct the pixel array for the refresh buffer. The three levels of interaction are: 1. 2. Interactive examination of batch-generated picture files. Construction of images and simultaneous viewing of the same during execution of an interactive program. 3. Construction and extensive interactive modification of displayed images themselves. In the first mode, one typically runs (locally or remotely) a batch program which generates an instruction file for a sequence of images. This is

dispatched to one's interactive display station, where one may skip around in the picture-file examining images. The file may then be discarded, or all or This

part of it may be redirected to a hardcopy device (local or remote). level of interaction is trivial to provide

in the context of the SCD's

metacode system, and would represent a quantum leap in the quality and quantity of graphics service to SCD users. Demands on machine resources for this

level are relatively light as long as picture files are kept to a reasonable size. In reality, this is not much of a restriction; NCAR's typically large in part from the current inconvenience of getting

graphics files result

graphical output, which the described mode of interaction alleviates.

Graphics

2.14

SCD Issues

.Atypical scenario for the second level has a user writing and running an interactive applications program, say a modeling calculation, and embedding graphing,

in the program calls to normal SCD graphics routines (contouring, etc). After calculating

and displaying a set of results on the graphics

screen, the user interactively tunes the controlling parameters of the model and iterates again. An important point in this scenario is that the user

does not need to alter elements of a picture under construction, but merely displays the results. Given that restriction, this service is relatively

easy to provide, requiring probably a few man-weeks to implement the full portable graphics system on the interactive machine. The gain to the general

user population is substantial, though not as great initially, we believe, as the gain when the first level is offered. This is primarily because the user

with existing batch programs gets the benefits of the first level by simply logging on the system and typing a command. For the second level, the user Demands on machine

must develop interactive applications on a new system.

resources are somewhat higher than those of the first level, because the user is doing more extensive computations at interactive priority. The highest level of interaction is characteristic of interactive design and layout systems. In this mode, the image has become, in some sense, the end There is some use for this details for publication and

goal rather than a tool supporting other goals. level of interaction for polishing picture

presentation, document construction, etc.

We believe, however,

its utility

is substantially lower to the general SCD user population than the first two levels, which are both concerned with data representation. Display hardware and the

to support this level is generally among the most expensive available, tax on host machine resources is typically quite high, particularly if

SCD Issues display technology is raster.

2.15

Graphics

As degradation of interactive response can be

a problem when such systems are available on general purpose satellites, they are often put up on special dedicated processors. The current SCD graphics and would either

software system is ill-suited to this level of interaction,

have to be substantially revised or, more wisely, supplemented with commercially available software. I/O SUITE FAC-LIT-E With the installation of the I/O satellite in the spring of 1981, for the first time be offering access to interactive computing. SCD will

A number of

terminals will be available in public areas, and some of these are destined to have graphics display capabilities. For relatively little extra cost, The consideration

other useful display devices can be added to the system.

of these additional options is still in progress, hence they are presented here as options instead of definite plans. EGraphics Terminals Display monitors available can be divided into two large classes: tube and refresh. storage

Although there is some overlap in the cost ranges, storage They are limited to line but have surprisingly good for input, but in the refresh

tube monitors are generally the least expensive. graphics display and alphanumeric resolution for the cost. information,

Cross hairs are often available available

storage terminals lack the range of facilities class.

They are well-suited for display of typical

NCAR vector graphics

images where interactive modification of the picture is not required. The refresh class of terminals includes both stroke and raster display tech-

Graphics nologies.

2.16 Although the price floor of this class is falling, it

SCD Issues is still

somewhat high due to the more complex electronics necessary to handle screen refresh from image memory. A much higher level of terminal interaction is

generally available through the use of multiple image planes, dynamic remapping of images through lookup tables, hardware scroll, zoom, highlighting and erasure, and input facilities ranging from cross hairs to lightpens and joysticks. The raster terminals allow for area fill as well, and both are availAt the high end of the price and performance range are high

able with color.

resolution highly-interactive color raster display and image processing systems. These require substantial computing and data flow support. Their

attachment to a dedicated special purpose processor is generally preferable to burdening a general public system with them. Initially, at least, most of the graphics terminals should be the less expensive storage variety, If resources permit, considered. and the similarly inexpensive pseudo-raster devices. the inclusion of a stroke refresh terminal should be

One motivation for this is that it would allow color, which adds

another dimension to line displays and thus allows clear presentation of more complex images. Another motivation is under that it allows more sophisticated control, as mentioned

incremental

picture construction

interactive

above under the second level of interaction. Pseudo-raster or raster terminals on the I/O satellite would open up data representation solid area fill. algorithms not currently available, i.e., those involving their

If they were included in the satellite's equipment,

use would have to be circumscribed to avoid the sort of system degradation previously mentioned. acceptable, Their use here as standard display monitors would be

but modes of operation which take full advantage of their unique

SCD Issues capabilities should be avoided.

2.17

Graphics

Their unique utility should not be ignored,

and we will later discuss a more preferable way for SCD to offer the services of high-quality, color raster displays.
Hardcopy

For about the cost of another modest graphics terminal, device could be added to the I/O satellite.

a simple hardcopy

Users would find such a device

very convenient, as it would allow them to immediately and cheaply obtain one or two hard plots of images of interest in an interactive session. quite a range of such devices now available, including There is

electrostatic These

printer/plotters,

impact printer/plotters,

and desktop pen plotters.

devices can be run as slaves off of a terminal or a set of terminals, and/or can be driven directly from a host processor. The effort to integrate them

into a system in the context of the current SCD graphics system is relatively trivial, as for the modest display terminals. host processor are also similar. In higher price ranges, and in some cases at the edge of the state of the The burdens they place on the

art, one finds color inkjet plotters, XEROX color copiers, terminal-driven color hardcopy (35rm slides and 8X10 glossies), programmable phototypesetters. laser printers, and graphics

These are probably inappropriate for the I/O color raster

satellite, but could find great utility at a high-performance, workstation. HTQIMPERFMAE, CXULR RASTER GI&HCE

As mentioned previously, at the top end of the price and performance range of graphics technology is the class of high-performance, color raster display

Graphics systems.

2.18

SCD Issues

The characteristics of these "terminals" include, but are not lim-

ited to, high resolution, significant hardwired intelligence, sophisticated image transformation and manipulation capabilities, multiple internal image planes, and extensive color palettes. Their use often consumes significant Their capabilities

CPU and mass storage resources of their host processors.

are clearly excessive for everyday use in the display of the type of graphics NCAR produces most of. There are applications, however, for which there is no substitute for these capabilities, and the SCD currently has no facilities to service these needs. One such application is the reconstruction and enhancement of digitally-

recorded photographic data.

Another is the interactive examination and editsystems. While tools for such data-

ing of large data sets from radar

intensive projects are the most immediate need, these graphics systems (particularly when augmented by color hardcopy) would also be useful for preparation of presentation-quality slides and graphics.

Some such facilities now exist within NCAR,

but demand

for their use is

apparently exceeding the capacity of the systems.

The SCD is currently con-

sidering how best to provide a centrally-available, color raster workstation. The utility of such a system would be greatly enhanced by a central location which permitted connection to the SCD hyperchanrpel, flow between it allowing high-speed data If the dedicated it could

and the mainframes and mass store system.

processor controlling the system had sufficient excess capacity,

even be used to handle some of the auxiliary graphics equipment discussed for the I/O satellite, if that machine were to become overburdened.

SCD Issues
CON

2.19

Graphics

The DICOMED systems should adequately handle NCAR's black-and-white COM needs for the next few years. The imminent completion of the online connection

project will relieve SCD users of a rather hazardous dependence on the aging dd8Os. One interesting option exists for future enhancement of the DICOMEDs: color.

Color capability is a purely add-on feature for the transports NCAR now has. The addition of the feature to both transports would be cost competitive with acquisition of one of the terminal-driven, color hardcopy devices mentioned above. The quality of color images that the DICOMED system can produce is If the color raster workstation discussed above is realthe color upgrade of the DICOMEDs would be an

without comparison. ized

in the near future,

attractive supplement to that system. ized, ties. Whatever form of color hardcopy is

If the system is not immediately real-

a color upgrade would provide a substitute for some of its capabili-

considered, processing.

there

is

one complication

which must be taken into account:

Currently, NCAR's film proA color processing operation

cessing facilities handle only black-and-white.

would be a large expense, and a venture into a field in which NCAR has no experience. If such hard color services are provided, a reasonable initial

approach to the problem would be to contract for periodic commercial processing service, say once or twice a week. While such a scheme may seem incon-

venient at first thought, it would in reality be much less so if a user were able to tune his/her color plots on a color monitor before shooting final productions runs on film. The expense of color film compared with black-

Graphics

2.20

SCD Issues

and-white would dictate such a modus operandi even if more frequent or inhouse processing were available. One possible technological breakthrough in the production of a color tranThere

the film industry should be watched for:

sparency film that requires no processing (as Polaroid prints do not).

have been strong rumors recently that one of the major film manufacturers is going to announce such a product within a year.
SFNARE PROJECTS

Unfinished Business As implied in earlier sections, some program portability work remains to be done on the vector graphics software system. difficult, but it is time-consuming. CRAY-1, This work is not inherently

At the time of the installation of the

a large commitment of staff was dedicated to the portability effort.

This effort led quickly to the successful implementation of most of the system on the CRAY-1. It also accomplished enough to make feasible the impleBetter understanding of por-

mentation of the system on almost any computer.

tability problems and much practical experience have been valuable side benefits, and these have made it possible to target what remains to be done so

that propagation of the entire system is easy instead of just feasible. Unfortunately, the portability project has been nearly static for the past two years, because available staff has been diverted to immediate problems. As the diversification of computing equipment and graphics devices within SCD and the rest of NCAR proceeds, it is of the highest priority to complete this project. It does not take many implementations until the extra weeks or

months of programmer effort exceed the effort which would be required to finish the project. Aside from the savings of technical talent resources, the

SCD Issues

2.21

Graphics

general user population benefits by minimization of the delay in establishing familiar software services on new computing systems. Most of the work required, and the most urgent, pertains to the utility-level software. Some rearrangements of the internals of the core-level plotting would help alleviate some of the

software, the System Plot Package (SPP),

more common implementation problems which have come to light in this part of the software package. Also mentioned earlier was some remaining work in expanding the functionality of the utilities family. touring, has been added. among them is In the last year one new member, non-gridded conTwo or three members remain to be added. minimal-options Foremost

a stripped down,

version of the automatic

graphing package for implementors on small minicomputers as well as for those larger-machine users whose program sizes create space problems. A three-

dimensional analogue of the software dashed-line

family would be useful.

There have been a nunber of requests for a histogram-drawing utility. The largest current commitments of the software effort are to the DICOMED Online Operating Software (DOOS) and graphics support tools (i.e., printer simulation support, network transmission, etc.). These projects will con-

tinue at the current level of effort until early 1981, when they will be substantially complete. New IpZlementations The arrival of the I/O satellite and the associated graphics devices will require the implementation of the standard vector graphics software system. For each display device type attached to the system, one version of the

Graphics

2.22

SCD Issues Effort here is typically a

skeleton metacode translator must be adapted. couple of man-weeks per adaptation.

Adaptations for truly raster devices,

i.e., those for which pixel arrays must be loaded into refresh memory, will require the inclusion of a vector-to-raster conversion module in the translator. This will require a little extra effort, as it has only been done in a The problem is well-solved and amply pubhardware "black

crude way so far within the SCD. lished. It is

worth noting that cheap vector-to-raster

boxes" have just started to appear commercially; these developments should be followed attentively as they promise to free the CPU of significant load

where such conversions are required. The SPP and the most popular utilities must be installed as well. The effort

here is highly dependent on the characteristics of the chosen computer and implementor's familiarity with it, but a couple of man-months should be an upper limit for accomplishing a significant amount of the required work. Development The arrival of new hardware capabilities will necessitate some software

development work in addition to the implementations mentioned above. For the vector graphics system, the most notable new factors in the future are color raster displays with its orientation toward solid areas and

interaction.

Because the metacode is easily extendable, at least some level

of service to new techniques can usually be accommodated without seriously violating the overall integrity of the system. Although this is true even

when the new techniques are somewhat alien to the foundations of the system, one must recognize that there are reasonable limits on how far the system can be stretched in these cases. The metacode vector graphics system, for

SCD Issues

2.23

Graphics

example, will never be extended to cover pattern recognition and image processing (PRIP) applications which are inherently pixel or raster oriented. Accommodation of color will require no changes. Although SCD currently has

no color devices, the options are already in place for program manipulation of color displays. Currently, the system has no way of dealing directly with solid or filled areas. This is an extension which has been in early planning stages for The first level of the planned extension is fairly straight-

several months.

forward, is not at all alien to the foundations of the current system, and will provide users with a primitive for specifying arbitrarily filled areas. This capability could then be used, in fact, to completely fill the picture with solid areas, effectively simulating a raster-type display. color in conjunction with filled areas will be no problem. The use of The chosen

approach will allow efficient use of devices with hardware fill capabilities or even raster scan capabilities, but will be usable as well with devices which can only draw lines. The second level of the planned extension will be

the incorporation of the feature into current utilities, and/or the construction of new utilities with data representation algorithms which can take advantage of an area-fill primitive (e.g., generation of isopleth maps).

This is not inherently difficult, but will be more time-consuming than stage one. True raster graphics, such as the presentation of digital photographic images on raster screens, is clearly beyond the flexibility of the vector graphics metacode system. The auxiliary software tools that one uses in conjunction

with such applications, spectrum filtering, image enhancement, etc., are even

Graphics

2.24

SCD Issues

more remote from the philosophy and direction of -the current graphics services. To provide such software, for example on a high-performance, color

raster workstation if

such were acquired, would mean starting from scratch.

To generate a complete family of such useful software in-house would require a substantial research and development effort. necessary to develop everything ourselves. Happily, it should not be

First, some such software has

already been developed within NCAR, and could possibly serve as a basis for a new system. jects, media, Additionally, as a result of various national scientific proattention lavished on the field there is by commercial

military projects,

and the efforts of vendors,

an enormous -amount of highsoftware now available. Our

quality raster display and image processing

needs could probably be reasonably met either by purchasing vendor software or by taking something from the public domain and adapting -it to our needs. As pointed out earlier, providing interactive vector graphics services at the two least complex levels of interaction can be comfortably handled with The addition to

current software with no significant developxnent required. the skeleton translator of a general purpose,

user-interaction module for

guiding interactive metafile viewing sessions would be a nice enhancement, but does not represent any significant development effort. The highest level of graphical interaction is quite beyond the capabilities of the present system. Since the general utility of this graphics mode to

the SCD users is unclear at this point, it seems most prudent to let development be driven by demand. for meeting it. If significant demand arises, two options exist

First, the present system can be extensively reworked to

include the segmentation and input facilities necessary to support high-level interaction. Second, a suitable core-level package could be obtained

SCD Issues commercially;

2.25

Graphics

there are offerings now that cost about the same as a medium-

priced terminal.

I/O System

2.26 AN OVERVIEW (F THE IIH 4341

SCD Issues

A New Input/Output System by David Fulker UCAR has contracted to purchase an Input/Output Satellite (IOS) computer from IBM. This paper contains a brief description of the functions served by the

hardware and software. The IOS is intended to serve several input/output related functions as follows: to provide a program development environment that includes capabili-

ties for editing and storing files; to provide mechanisms for submitting programs to, distributing output from, and exchanging data with other computers, such as the CRAY-1 and the 7600, that are attached to NCAR's high speed network (the Network Systems Corporation Hyperchannel); to provide access to

magnetic tapes in a variety of formats and densities; and to provide data communications facilities (including the system. In distributing output from other computers, the IOS will either print or interactive use) for remote access to

display selected portions of the standard job output, and eventually permit the perusal of graphical output on appropriate terminals. For users at NCAR,

the system will also provide limited FORTRAN test compilations and test runs with interactive debugging. large files, it is Although the IOS will be capable of managing

expected that such files will reside on the IOS only

briefly (as, for example, in transit between the 7600 and magnetic tape) and that the processing of their contents will not usually be an IOS function.

SCD Issues At the core of the IOS is Product (VM/SP) ponents. are the

2.27 an IBM 4341,

I/O System running the Virtual Machine/System Within VM/SP are four major com-

as its operating system.

Of these components, Control Program (CP)

three that are largely invisible to the user that manages the hardware resources, the

Interactive Problem Control System (IPCS) that helps identify and report system problems, and the Remote Spooling Communication Subsystem (RSCS) that

handles remote access to the system. fourth component, interactive management.

Most user activity takes place within a that provides an and file

the Conversational Monitor System (CMS), environment for program

(time-sharing)

development

In conjunction with CP enhancements permitting 4341 attachment to the Hyperchannel, the SCD will devise commands within the CMS environment that facilitate, for example, the submission of batch jobs to the CRAY-1 or other computers on the Hyperchannel. Other enhancements are under consideration and

include such subjects as online docunentation (interactive access to technical documents about the various systems in the SCD) and utilities for handling graphics files from the batch computers. The hardware configuration of the IOS is as follows: is a 4341, Model K1, The central processor

with 2 megabytes (500,000 32-bit words) of main memory.

The disk subsystem includes two 3370 drives with a total capacity of more than 1,142 megabytes of direct access storage. The magnetic tape subsystem

includes 1 7-track 556/800-bpi drive, 1 9-track 800/1600-bpi drive, and 2 9track 1600/6250-bpi drives, and all operate at tape speeds of 200 ips. record equipment comprises printer. an 800 cpm card reader and a 1200 1pm Unit line

I/O System

2.28

SCD Issues

Attached to a channel of the 4341 is a 3705 Communications Controller that will handle much of the low-level data communications activity such as error recovery. The 3705 is configured with 16 synchronous ports (8 at 4800 bps, 8 The

at 9600 bps) and 32 asynchronous ports (6 at 300 bps, 26 at 9600 bps).

number of ports and the associated speeds are easily changed by the addition of scanners and line sets to the 3705. The software in the 3705 will be the and communicates

Emulation Program (EP) that interfaces to RSCS in the 4341,

to the outside world via the common teletype (TTY) asynchronous (start-stop) protocol or via a variety of synchronous protocols from the class that IBM designates as bisynchronous (BSC) Of the EP supported protocols, protocols. three (TTY, BSC 2780, and BSC 3780) are

already familiar to some of NCAR's remote users. via the ModComnp as follows: tocol (supported at

Specifically, they are used

Any ASCII terminal may connect via the TTY probps); the BSC protocols (supported at

300/1200

2000/2400/4800 bps)

are usually used by remote computers running

software

emulation of 2780 or 3780 remote batch stations.

A fourth protocol of potenis the BSC 3270 pro-

tial value on the IOS, but not currently in use at NCAR,

tocol used for remote cluster controllers that drive IBM terminals of the 327X class. Various aspects of the data communications support are as yet unresolved and will remain so until evaluations are complete on such matters as terminals to be supported, transmission speeds for internal and external users, new comand

munications technologies (such as satellite links in the dial network),

various networking concepts such as packet switching or host-to-host protocols. The 4341, the 3705, and the available software provide a wide variety

of related options.

SCD Issues

2.29

I/O System Among

The IOS offers numerous and substantial possibilities for expansion.

these are field upgrades to a faster central processor with up to 8 megabytes of memory, storage, additional disks with up to 16,000 megabytes of direct access

additional communications controllers to support more ports (well

over 250) and/or higher transmission speeds (including ports at 50 kbps), and a variety of additional peripherals such as printers. Support is also avail-

able for configuring the system with multiple central processors.

Software Tools -(FLWAItE TO(LS:

2.30 PIIAS FOR THE 1980's

SCD Issues

by Russell Rew

INTUDXETION

A software tool is a program that facilitates the development or maintenance df other programs. effective An integrated collection of such tools can provide an environment that simplifies the complex task of

programming

developing and maintaining large scientific programs. One familiar example of a software tool is a compiler, but many other kinds of FORTRAN-oriented precompilers, editors, program for-

software tools have proven to be useful:

matters, macro-processors, standards verifiers, program analyzers, and testing aids are examples of tools that can help in producing reliable and maintainable software. The Scientific Computing Division (SCD) has accumulated a collection of various kinds of software tools over the last decade. Some of these tools have

been popular with NCAR users even though they were not supported at a very high level. The quality and quantity of tools that are available from exter-

nal sources has recently increased dramatically, due to advances in language standards, an understanding of what primitives are most appropriate to support software tools, and experience with several successful tool collections. More portable software incorporating many of the results of these recent advances will soon become widely available. This planning document will recommend an approach that emphasizes the evaluation and implementation of externally-developed software tools over locally-

SCD Issues developed tools. following:

-

2.31

Software Tools

Some advantages of the recommended approach include the

It

provides a large number of tools for program development, many more useful capabilities than could

testing, ever be

and maintenance;

locally developed or maintained.

-

It

provides a large number of tools for text manipulation, documenta-

tion, browsing, and editing.

-

It

provides an improvement in the uniformity of user interfaces with

systematized collections.
-

It

provides an environment where tool implementation, use, and mainte-

nance are simpler than in the current environments.

-

It

provides tools independent of any particular operating system so that portability is achieved without sacrificing too much effi-

relative ciency.
-

A large user and development community share the cost of developing needed tools, and this helps assure that the tools are well-tested.

The recommended approach makes it

relatively easy to add a new tool to

several computers, or to bring up all of the tools on a new computer.

-

Many future SCD users will be familiar with the tools and environment that are recommended here from experience at other computing centers that will have implemented these packages.

Good software tools are a necessity for other large projects, like the

Software Tools Graphics Project,

2.32

SCD Issues

which must maintain large multi-version packages'.

Thus, even users who do not use software tools directly will benefit from their existence.

ISSUES The basic issue raised by the present software tools situation is whether the SCD should remain committed to the support and enhancement of local tools developed at NCAR, evaluation or whether more resources should be dedicated to the The

and implementation

of externally acquired software tools.

magnitude of effort required by either approach makes it SCD can afford to do both.

unlikely that the

The remainder of this planning document will

describe existing local tools, recommend what level of future support is appropriate for each, examine some externally-developed software tools, and present some tentative conclusions and plans based on those conclusions. Choosing between the support of local tools or tools developed elsewhere involves a trade-off between providing exactly the capabilities desired by NCAR's users through local development versus acquiring widely used and well-tested tools that may not be a perfect fit to SCD user needs. The

expense of developing local tools is so high that only a small number of capabilities can be supported in this way. Although locally-developed codes were at one time the main source for almost all software tools, it is clear that acquiring and adapting available tools for local use is a much more cost effective way to provide needed capabilities. The situation is closely

analogous to the issues of local versus acquired operating system software or mathematical software. The era when computing centers wrote their own

operating systems or provided all of their own mathematical library software

SCD Issues is past.

2.33

Software Tools

This is now the case for software tools as well as will be seen

from a survey of the range and capabilities of the tools that are now available in the public domain. A recognition of this economic reality is not much solace to the user who has come to depend heavily on locally-developed tools. Adequate warning, a very

gradual withdrawal of support, and the provision of similar interfaces to equivalent capabilities in new tools are ways that a computing center can ease the transition away from locally-developed tools. The situation is

again somewhat analogous to the disruption caused by changing computers, but the future prospects of users of new tools are much better. It has recently

been demonstrated that portability of software tools is practical, and an interface for tools can be embedded in several different vendor operating systems to provide a uniform programming support environment. Thus, a better analogy is that of the user who switches from a local linear-equation solver to one on a popular commercial library that will be available as long as FORTRAN is supported. Other questions that must be tackled in evaluating options for software tools to NCAR users include: - How much support should be devoted to software tools in comparison to mathematical software libraries, graphics, or I/O utilities? - Should distinct capabilities be provided in a set of distinct tools, or should they be collected and packaged in large, multi-purpose tools? - How much effort should be dedicated to providing uniform user interfaces to tools and a uniform environment in which to use them on different providing

Software Tools computers?

2.34

SCD Issues

- What extensions and variants of FORTRAN77 should be supported by tools that accept FORTRAN text as input, or that produce FORTRAN as a target language?

RRENT STATIS OF SCD SOFTWARE TOLS Summarized below are the software tools that are currently available to SCD users, and recommendations about their future level of support. This collection has suffered from some of the same kinds of problems that occur with large miscellaneous collections of numerical software thrown together into a library: lack of portability, lack of uniformity of user interface, lack of

accessible user-oriented documentation, and the large investment in time that may be required to learn how to use the software effectively. SOF1WARE TOOLXS AVAILABIE ON BOTH THE 7600 AID CRAY-1
IFTRAN

A FORTRAN preprocessor that provides structured programing syntax,

indented

listings, conditional compilation, internal subroutines, an INCLUDE facility, character string replacement, and in-line comments. Recommendations This should probably receive continued support and enhancement since it the most widely-used preprocessor at NCAR. IFTRAN is is

the only locally-

maintained preprocessor that the SCD is committed to support at a high level. Its most serious drawback currently is its inability to handle the FORTRAN77

SCD Issues block IF statement.

2.35

Software Tools

Users will probably request that this preprocessor be Currently .25 FTE is assigned to the

made available on the IBM satellite. support and enhancement of IFTRAN. VERIFIER

A FORTRAN processor that checks FORTRAN code for conformance to a portable subset of the 1966 ANSI standards, and prints error messages describing violations of these standards, including inter-program unit communication standard violations. Recommendations This is a useful and completely portable tool that requires almost no effort to support so we should continue to make it available. When a portable FOR-

TRAN77 standards checker becomes available, the SCD should acquire and support it. The IBM FORTRAN compiler will include options for FORTRAN66 and

FORTRAN77 standards checking. FACS A FORTRAN preprocessor to instrunent FORTRAN code in order to determine how many times each statement is executed and each branch is taken during execution of the FORTRAN code. Recommendations This tool was purchased from a commercial vendor, its maintenance. but we no longer pay for FACS stands for FORTRAN Automatic Checkout System.

It cannot handle some FORTRAN77 extensions (like the block

IF statement) so its utility will decline unless some effort is put into it, but it has portability problems and appears difficult to maintain. No

Software Tools

2.36

SCD Issues This is

equivalent capability exists in any other currently-supported tool.

potentially one of the most useful software tools available for dynamic testing, but currently it is not used much. We cannot now support it at a high

level, and thus should try to eventually acquire another instrumentation tool that accepts FORTRAN77 to replace it. FAUS A FORTRAN preprocessor that instruments FORTRAN code for debugging, execution, System. Recommendations This was purchased from the same vendor as FACS, afford to support it and we probably cannot No other availand symbolic dumps. tracing

FADS stands for FORTRAN Automatic Debugging

at a high level for the same reasons.

able tool provides completely equivalent capabilities, but CFT does support symbolic dumps. This tool will become less useful as more programs use

features of FORTRAN77 that it cannot handle. FATS A FORTRAN preprocessor that instruments FORTRAN code for timing and counting the execution of FORTRAN program units. Timing System. Recommendations This was purchased from the same vendor as FACS, further support. and should not receive FATS stands for FORTRAN Automatic

The Cray CFT compiler now provides the same capabilities

with the FLOWTRACE option.

SCD Issues PP1

2.37

Software Tools

An enhanced version of the IFTRAN preprocessor that also provides FRED-like parameterized macro facilities and precompile-time expression evaluation. Recommendations This locally-developed tool is used by several groups of SCD users. never been supported as public library software because it active development. It has

has been under

PP1 is currently the only tool that facilitates conver-

sion of a program that uses FRED extensively from the 7600 to the CRAY-1, although it does not support all of FRED's features. Some effort would be Given the

needed to provide documentation independent of the FRED write-up. small user-base compared to IFTRAN, level of support of PP1, it

is hard to justify increasing the be

although several users have requested that it

fully documented and supported.

FLOTRAN

A superset of PP1 designed to facilitate the development of large finitedifference models. It includes a facility for the automatic management of storage, by

the windowing of large arrays through memory from peripheral

translating an extended set of data type declarations and operations into calls to subroutines in a run-time support library called FLOLIB. Recommendations This locally-developed tool has an even smaller user-base than PP1. SCD supis

port and maintenance for FLOTRAN has been dropped, but a version of it being maintained by a group of users.

Software Tools
MOR-T'It

2.38

SCD Issues

A pattern matching macro-preprocessor programming control structures,

for FORTRAN that provides structured alphanumeric labels, listing

free format,

indentation, and a macro definition facility for user defined extensions to FORTRAN. Recommendations This is a potentially useful tool acquired from SLAC that requires almost no effort to support so we should continue to make it very powerful macro-processor, but it available. MORTRAN is a

has not been used much because of its It may become

use of special characters that do not appear on keypunches. more popular when users have access to the character standard terminals. TRAN. SVFIWARE TO(LS AVALABE ONLY ON THE CRAY-1 The Cray-supported preprocessor

sets available from SKOL is based on MOR-

A FORTRAN preprocessor that provides Pascal-like data structures, structured control structures, pattern-matching macros, free format, and elaborate

user-defined extensions to FORTRAN.

This is the most powerful preprocessor

currently available to NCAR users, and its extensive documentation will probably help to make it popular with CRAY users. Recommend ations Cray will probably continue to support this and may use it system development language. It as their internal

is mostly portable so we might attempt to

SCD Issues install it from source on the IOS.

RATFOR

2.39

Software Tools

A FORTRAN preprocessor (originally developed at Bell Laboratories)

that is

widely-used outside of NCAR and that supports structured control flow, freeform input, in-line comments, global symbolic parameter definitions, and an source files. It is used to support an

INCLUDE statement for including

extensive collection of portable software tools developed at Lawrence Berkeley Laboratories(LBL). RATFOR has been extended in several directions: RAT-

MAC is a combination of RATFOR with a general purpose macro-processor; MOUSE4 is a "cleaned-up" version of RATFOR that has been optimized for precompilation efficiency. Recommendations Future users will probably request that this tool be made available since it is so widely-used at other labs and universities. The Software Tools Users

Group is standardizing an enhanced version of RATFOR that includes features like precompile time expression evaluation. RATFOR should probably be made is portable,

available on all systems as an alternative to IFTRAN since it and little effort is required for its support.
UPMTE

A card-oriented batch file maintenance tool that provides a means of modifying, editing, and updating source language programs and other text files. Many

This is a Cray system program not available on any other SCD computer. users have found it inadequate for use as a batch editor since it

does not

include any string replacement capabilities.

Software Tools R orm end at ions

2.40

SCD Issues

Cray will continue to support this product, but the SCD should consider support 'ing a more powerful batch editor on the CRAY-1 (e.g., the FORTRAN-

intelligent editor that will be included in the first release of Toolpack). ,9FVRE TOOLS AVYIBE ONLY OM THE CONTROL DATA 7600
FRED

A precompiler for FORTRAN programs providing conditional compilation, macros, debugging aids, evaluation of subscript expressions, reformatting capabilities. Recommend at ions This was at one time the most popular preprocessor available at NCAR, but it was intentionally not moved to the CRAY-1. not portable; it It was locally developed, and is In and extensive program

includes over 1000 lines of assembly language source.

many ways it was ahead of its time; it includes some of the novel features of the transformational preprocessor TAMPR, the FORTRAN-based macro-processor

BIGMAC as well as other capabilities that are not yet available in other preprocessors (e.g., extensive precompile time expression evaluation). Some

of its features have been incorporated in other locally-enhanced preprocessors (e.g., conditional compilation in IFTRAN, macros and globals in PP1). which is another

FRED cannot handle statements that were added to FORTRAN77, reason for its declining popularity.

The report of the Computing Facility

Working Group on Software Acquisition and Development in 1978 recommended that FRED not be moved to the CRAY-1 or further enhanced, but that it be

replaced by two other preprocessors--a simple, fast preprocessor like IFTRAN

SCD Issues and a more powerful macro-processor.

2.41

Software Tools

There are still about 25 users (includUsers have

ing the Graphics Project) who depend on FRED and thus the 7600. been warned for some time that support for FRED would not continue. 7600 SysteE Editor

A card-oriented batch editor that supports simple string replacement.

It may

be used to insert, replace, or delete records in existing text files, and to create new files. Recommend at ions This batch editor is currently used by most SCD users to maintain their program files. Before the 7600 leaves, users will have to learn to use another is provided on

editor unless a replacement with a similar user interface another SCD computer.

Many users will want to use an interactive editor on We

the IBM satellite, but there may still be some use for a batch editor.

should try to determine if there are enough users who will want a batch editor to justify the acquisition of a simple replacement for the capabilities of the 7600 System Editor. Editors that are available in the public domain will

support supersets of the capabilities of the 7600 System Editor so it

probably not be necessary to do much development to support such a batch editor. BUILDER Used to create and update binary libraries on the 7600.

Software Tools Recommendations

2.42

I. -

SCD Issues

This is only needed on the 7600 because every other computer has a loader thft supports relocatable object libraries. will disappear when the 7600 leaves. JPTOSP A'utility to aid in the conversion of FORTRAN programs written for IBM machines to Control Data machines. Handles conversion of double to single Thus, the need for this tool

precision as well as character conversion. Recommendations This tool is not used much, and is not needed for the CRAY-1 since the CFT compiler supports an option for precision conversion. INDEX A program for generating a cross-reference dictionary of all statement

numbers and all symbols in FORTRAN source programs. Recommendations This is a very old tool (1966) Control Data FORTRAN extensions. that handles an old dialect of FORTRAN with Its capabilities are duplicated in the CFT

compiler and the PFORT verifier so support could be dropped without any serious consequences. TIDY A program that reformats FORTRAN source code, renunbering statements, indent-

SCD Issues

2.43

Software Tools

ing loops, and performing other esthetic transformations. Recommendations This is an old tool that does not handle several FORTRAN77 features (e.g., block IF). Its support should be dropped when we can get a better FORTRAN

formatter (e.g., POLISH, TAMPR). ;CUST Lists the online documentation that appears as the first block of comments in most public library source files. Recommendations When library sources are moved to another machine than the 7600, something equivalent to this utility must be maintained on that machine to support

online library documentation.

EXTERNAL STOOLAE Following is a brief list

Oa CQIONS

of other tools and collections that could be made The first two collections state-of-the-art in

available if we chose to acquire and support them. deserve special attention; they represent

the current

packaging software tools, and promise to solve some of the problems with our current collections. Software Tools A large collection of utilities and programming aids that are descended from the book Software Tools, by Kernighan and Plauger. Most of the tools that

Software Tools

2.44

SCD Issues

appeared in the book have been enhanced, and several new tools have been added; the collection is currently available from LBL [1]. Implementation of

these tools results in a "virtual operating system" that provides standardized versions of a command interface, utilities, and a virtual machine to users on different underlying computers and operating systems. The utilities

provide a program development environment that emulates that found in the UNIX operating system and include a text editor, an archive file maintainer, numerous file manipulation and comparison tools, a tool to search a file for a pattern, a text formatter, a macro-processor, a mail package, online documentation, character transliteration, sorting, a tool to find spelling

errors, and a command line interpreter.

The command interpreter provides a

user interface that supports user-defined command files, redirection of I/O, filters, and pipes. The entire set of tools have been implemented on six

different operating systems, and partially implemented on 70 operating systems at about 300 sites. An active user's group exists that helps to dissem-

inate new and enhanced tools as they are developed. Recommendations Of all the currently available collections of tools, this package will probably yield the greatest benefits for the amount of effort required to implement it. SCD has already acquired the source for the LBL Software Tools, and

work is underway to install a significant subset of the tools on the CRAY-1. The feasibility of installing the system on the IBM satellite is under study. Toolpaick A collaborative, federally-funded project that has as its goal the production of a uniform and portable set of software tools which are designed to promote

SCD Issues

2.45

Software Tools

increased reliability and decrease life-cycle costs of FORTRAN programs as well as a packaging and integration environment within which tools may be added to the collection [2]. National (UCSB), Laboratory, the Purdue, of Participating University of Colorado, Bell institutions include California at Argonne

Santa Barbara International

University

Laboratories,

Mathematical and Statistical Libraries (IMSL), Jet Propulation Laboratories, and Numerical Algorithms Group (NAG). Eighteen prototype tools have been

examined for possible inclusion in an initial release, scheduled for the middle of 1983. Recommendations This is the first attempt to apply the "PACK" paradigm to software tools, but previous products of such collaborative efforts (EISPACK, ITPACK, MINPACK) LINPACK, FUNPACK,

are outstanding examples of collections of software in the

public domain resulting from federally-funded collaborations of researchers and software developers. The packaging of the implemented tool components in The SCD should

Toolpack will be, from all indications, worth waiting for.

not waste much effort in duplicating tools that will be part of Toolpack, but should investigate the possibility of having NCAR be a test site for Toolpack, since NCAR's user community and multi-machine computing environment are well-suited for such a purpose. This would have the added advantage of mak-

ing the prototype tools available to NCAR users in mid-1982 rather than 1983.
C-ercial Offerings

Softool Corporation sells a set of FORTRAN tools that are written in a highly-portable subset of FORTRAN. They include an ANSI standards checker, a documenter that converts a

two instrumenters for checking test coverage,

Software Tools

2.46

SCD Issues

documentation template and simplified documentation into commented units of source code, and cross-reference tools. Schmidt Associates sells a FORTRAN

Software Engineering Environment that provides tools for designing, coding, testing, documenting, and maintaining FORTRAN programs. Recommendations These are two of a growing number of commercial offerings in this area. A

well-defined policy is needed for the evaluation and possible procurement of such software offerings since there are more packages being offered than the SCD can realistically afford or support. SCD can probably acquire most of

the software tools its users need from the public domain, but should remain aware of any advantages commercial software has for providing its users with the benefits of integrated collections of software tools.
AIUGMENT

A FORTRAN preprocessor that supports the definition of nonstandard data types and user-defined operations on the new data types. Applications that use

AUGMENT include interval arithmetic, multiple-precision arithmetic, recursive data structures, processing,. Recommendations This package has been implemented at over 30 installations in three countries on a wide variety of computers, and has reached the status of a stable production program. It is a useful tool for preparing programs that use nonNo other preprocesAlthough analytic differentiation of FORTRAN functions, and image

standard arithmetics, and for some conversion problems.

sor with similar capabilities has found such widespread acceptance.

SCD Issues

2.47 it

Software Tools is very portable. NCAR should

the source is about 14K lines of FORTRAN,

acquire and implement AUGMENT if there is any interest in its capabilities among users since it appears to require very little effort to support.

aCONJLSIONS
It would be ideal if the software tools most used at NCAR were also the tools most used outside of NCAR, hence were well-supported, to move to new systems. well tested, and easy

The reality is that most software tools now used at Only a limited amount of resources can be

NCAR are not used anywhere else.

dedicated to providing SCD users with good software tools since users also need mathematical software, graphics software, and I/O utilities. Only the

most popular of the currently-supported tools at NCAR should receive further support; an effort should be made to replace the capabilities of other where possible. The most

locally-developed

programs with acquired tools,

cost-effective assignment of SCD Staff appears to be in evaluating the effectiveness of existing tools, and in acquiring and implementing those found to be appropriate for SCD users, rather than in developing new tools locally.

An effort that balances potential benefits with available resources would be to form a Software Tools project, with staffing levels, for example, similar to the Graphics project. project are:
-

The highest priority short-range tasks for such a

Support and enhancement of IFTRAN, the most used preprocessor in SCD.

Software Tools

2.48

SCD Issues

- Implementation of the LBL Software Tools package on the IBM satellite and the CRAY-1.
-

Establishment of NCAR as a test site for the Toolpack Project, providing early experimental versions of many of the tools and packaging to SCD users. -Evaluation and selected acquisition of other available tools (e.g., AUGMENT), if they appear to be needed, and

-Provision tools.

of publicity and local documentation for available software

1. Hall, D. E., D. K. Scherrer, and J. S. Sventek, "A Virtual Operating System," Communications of the ACM 23(9):495-500, September 1980. 2. Cowell, W. R., and W. C. Miller, "The TOOLPACK Prospectus," Technical Memorandum No. 341, Applied Mathematics Division, Argonne National Laboratory, Argonne, Illinois, September 1979. APP~ENDI Some of the tools that have been proposed for the first release of Toolpack are summarized below. DAVE A static analysis tool that detects data-flow anomalies in FORTRAN programs such as paths along which a variable is defined, but never referenced, referenced before it is defined, or vari-

ables which depend on the saving of local values between subroutine calls. This tool does an extensive static analysis of FOR-

TRAN programs, and can be used to guarantee the absence of

SCD Issues

2.49

Software Tools The ver-

certain classes of errors not detectable by compilers.

sion now under development is portable and faster than the previous version, which had been implemented on NCAR's 7600. should acquire and support DAVE when the new version We is

released. TAMPR A program transformation tool. This tool was used in the LIN-

PACK project to automatically generate tailored real and complex versions in various precisions of all of the LINPACK routines mechanically from abstract prototype programs. general program transformations (e.g., it It supports more might be used to

mechanically perform FORTRAN-to-FORTRAN vectorization transformations). Although only an IBM version currently exists, SCD

should try to acquire a portable version when it becomes available. BIGMAC POLISH BRNANL A FORTRAN language macro definer/expander. A FORTRAN program formatter. A dynamic test probe inserter.

FSCAN/CLEMSW A tokenizer/parser generator.

FIE
SEMCHK

A FORTRAN-intelligent editor developed by the NAG group.

A path-independent, static, semantic error checker.

FLOCHK
CALLGRAPH

A structure and programing convention checker.

An inter-program-unit checker based on the PFORT verifier.

Software Tools STRUCT EFL

2.50

SCD Issues

A control-flow structurer. A translator for an extended FORTRAN Language that supports

structured control flow, data structures, an INCLUDE facility. FORTLEX A FORTRAN lexer. A precision type converter.

a macro facility, and

APr-x

SCD Issues

2.51

Data Support SEVERAL YEARS

OUTLINE OF LAIS FOR THE NEX

by Roy Jenne

INTRD CTION

The Data Support Section (DSS)

maintains many large sets of analyzed grid the

data and observed data from the National Meteorological Center (NMC), National Climatic Center (NCC), (USAF). the U.S. Navy (USN),

and the U.S. Air Force The archives

Other countries and laboratories also provide data.

are still largely described in Jenne, 1975. Significant efforts are required archive and to serve user needs. meet a specific request. to simply update and maintain the data Some data is obtained for the archive to acquired in anticipation of

More often, data is

research needs by assessing the general needs of the research community in combination with specific current and past requests. There are also continu-

ing efforts toward improving the quality and accessibility of data in the archive.

DATA NEEIS AND PLAIS A brief summary of data needs for the next several years will now be given. R. Jenne has prepared a report, "Planning Guidance for the World Climate Data System," for the World Meteorological Organization requirements for research and applied climate (WMO). studies. It reviews data for

The needs

specific data activities in the following categories are considered:

- Upper air data

Data Support
- Surface data - Hydrological data - Ocean data

2.52

SCD Issues

- Radiation, clouds, chemistry, particles, solar effects

- Satellite data - Proxy data s - Geographical and economic data

The WMO report will serve as a guide for our data activities; emphasize the data needed for research rather than applications. datasets are useful for both purposes, it

NCAR will Since many

is expected that the use of our

datasets for applied research problems such as crop modeling and energy questions will increase. To support research, we will increase the amount and availability of our present sources of surface and upper-air meteorological data. Our present

ability to support ocean and climate research with satellite and conventional ocean data is poor. Because of the existing and increasing need for ocean

data, we will push to improve support for these projects. The discipline of meteorology has emphasized dynamics for about 30 years. We

expect increasing research that couples actual sensed weather and hydrology with the atmospheric dynamics. data will have to increase. This means that the archives of hydrological Some mesoscale modeling activities already have

a need for better data support. One of the main factors of uncertainty in the climate models that predict global climate changes due to increasing atmospheric CO is the cloud feed2 back question. To solve the problems, satellite and conventional cloud data

SCD Issues will be needed.

2.53

Data Support

Since some of the satellite archives are extremely large, we

hope that it will primarily be possible to obtain intermediate-sized archives that are prepared by others. National and world planning is slowly progress-

ing, and has the possibility of making this problem easier for us.

SPEC]FIC DATA TASKS The approach to increasing our data capabilities will be to accomplish number of selected projects ourselves, a

and to interact with other organizaThe big task is usually to When a set has

tions and nations to stimulate their efforts. prepare, sometimes from hard copy,

and structure datasets.

been prepared in any reasonable form, it copy to another installation.

should not be difficult to send a

Much of our time will be spent updating Some of our

datasets, handling other routine tasks, and helping customers. planned dataset development tasks follow: iPPER-IR DATA We plan to:

Finish- Continue to obtain the real time global data on tape from NMC. ing the task of preparing major subsets (i.e., raobs, aircraft, cloud winds, etc.) from 1963 will make the data easier to access. - Obtain delayed processed data from additional countries Brazil, U.S.S.R.) back to 1950, if possible. (e.g., India,

- Make available the 1940-60 data from many nations that was prepared by the USAF at Asheville, North Carolina. SURFACE DATA We plan to: - Obtain more data from NMC in real time when the need is specified by the universities.

Data Support

2.54

SCD Issues

- Continue to obtain the real time global data on tape in delayed mode. - Make available the 1900-1960 data from many nations, USAF at Asheville, North Carolina. prepared by the

Obtain the complete set of the USN land-synoptic and ship-synoptic data from 1966 when it was prepared by the USN.
-

Prepare the archive of the U.S. daily surface co-op station data that should soon be sent by NCC at Asheville, North Carolina. Obtain daily time series of precipitation and temperature from selected stations around the world. Improve the dataset of year-month station precipitation and temperature data (in cooperation with Chester Newton of the Empirical Studies Group, and the national and international groups).

I1C~AL DIATA

The daily surface data above will support some of these hydrological data
needs for the U.S.. area.
-

Work internationally to obtain better sets of data with stations spaced as close as about 70 km. Attempt to obtain sets with 100-300 km spacing first. Some of these 300 km scale data are in the USAF set above. Do not try to obtain the 5-10 km data. Obtain selected sets of compacted radar data when prepared by others, and with user agreement. Obtain selected river flow data within two years. additional datas as the user need develops. Be prepared to obtain

OCEAN DATA We plan to: An Asheville - Obtain the best present sets of ocean ship observations. and a United Kingdom set should be obtainable within a year. Progress has been slow. - Obtain the ocean temperature and salinity at depth data.
- Obtain sets of drifting buoy data.

- Continue to push for a better set of ocean bathymetry data than the one National progress has been slow degree average depths now available. and a strong need for higher resolution data is now present. Many types of satellite ocean data will involve our attention in cooperation

SCD Issues with other groups. RADIATION, CLO.UDS, STELLIT

2.55

Data Support

DATA, ETC.

The emphasis will be on obtaining intermediate-sized sets of satellite data to support cloud studies, ocean studies, and convective precipitation. Many of our tasks will be done by other groups. If a major part of the Ocean Data

User Support (ODUS) system is centered at UCAR-NCAR, then more of the processing will be done here. Sets of heat budget data will be obtained to support modeling efforts. main preparation efforts will be elsewhere. PAEOCLIMATIC DATA We are now working with Alan Hecht, NSF, and others to prepare a technical note with status and inventory information about proxy data. We plan to The

archive only a limited amount of proxy data, usually in the form of analyzed data such as ice-age conditions, to support modeling efforts or for studies of climatic change. AND ECONOMIC DATA IGEOGRAHICAL We have noted the need for ocean depth data. more strongly in applied areas, energy use, crop acreage, etc. If research interests develop

we will need datasets such as soil types, We will put a small effort into identifying

available datasets, not into preparing data.

Data Support

2.56
ACCESS TO IFOlHATION ABOIf DATA

SCD Issues

Users have a need for easy access to summary information

about datasets,

access to more detailed inventories for specific observing stations and grid point arrays, and to lists of data storage volume numbers (backup tape

numbers are not released). selection of such information.

We plan to provide online access to a large

In 1975, NCAR published "Data Sets for Meteorological Research."

We plan to

include the more recent information in the text, "The Global Data Base for Climatic Research," which should be finished information from it in 1981. NOAA is including We

in a publication which should be out in early 1981.

intend to update the 1975 publication in several years. In about 1983-84, we plan to put a number of our dataset write-ups and associated "grey literature" texts onto microfiche so that users can more easily obtain a larger fraction of: the total volume to browse through. We will continue to provide information about our computer programs that may be useful to others. There will also be some effort devoted to gathering

routines that other people have developed such as a program to plot a Skew-T diagram.

INTERACTIVE MANIPULATION OF DATA

We will emphasize the preparation of datasets that can be used for calculations, graphics output, etc. systems. They could also be used in interactive graphics

Since the development costs of such systems are high, the DSS will

not develop such systems for use at NCAR until the user need is more clear

SCD Issues than it is now. If

2.57 the need clearly develops,

Data Support as for the ODUS system or

other research, we may be able to use some of NASA's systems under development. If not, the participation of other sections of the SCD in such an

effort would be desirable.

Mass Storage

2.58

SCD Issues

MS STORAG(E GOALS, CHARACTERISTICS, PERSPECTIVE, AmD OUTWOOK

by Paul Rotar

MASS STORAGE SYSTEMS: A mass storage system (MSS)

A BRIEF OVERVIEW

attempts to provide the greatest possible online

storage capacity at the lowest cost-per-bit that the current technology will allow. host It provides access times and data transfer rates commensurate with requirements. An MSS minimizes normal media mounting/demounting so that

activity.

Through offline storage, an overflow capability exists

there is no upper limit to the amount of available storage. MSS is usually considered to be the tertiary level of storage within a

storage hierarchy, where secondary storage is a magnetic disk subsystem and primary storage is the main memory (See Figure 1, A Data Storage Hierarchy).

SCD Issues

2.59

Mass Storage

Figure 1.

A Data Storage Hierarchy

Mass Storage

2.60

SCD Issues

A mass storage system can be coupled to a given host system in several ways. Two of the most common procedures are loosely coupled and tightly coupled. A tightly coupled system exists when the MSS is host's channels. directly connected to a

A loosely coupled system exists when the MSS is connected

to a local computer Network which services the data activities of several computers connected to the Network. In both cases, data is moved between the Within the tightly

Host's staging disks and the storage medium of the MSS.

coupled environment, the host uses the staging disks as a direct extension of its own disk system. Whereas, in the loosely coupled environment, the data

moves between the host's staging disks across the Network,'s channels to the MSS. Depending upon system configuration, these two coupling methods can

have varying impacts on data migration between the MSS and host systems. Data and data migration are defined according to amount and access and are managed accordingly. Data that is accessed many times per day is not removed Data that is used infrequently migrates to Data

from a host's secondary storage.

tertiary storage which reduces the online data management requirements.

migration can reduce the requireent for more expensive secondary storage by paying the migration time penalty.
One of the criteria for selection of an MSS is the cost-per-bit of tertiary

storage.

The cost-per-bit can refer to media cost only or it can refer to The total online cost is These various views

the total cost of making a bit available online.

proportional to the number of users and their accesses.

of cost-per-bit question can seriously impact MSS comparisons.

SCD Issues

2.61
HISTORY AND EXPERIENCE WIH THE NCAR ANFEX TBM'

Mass Storage

At the time of the procurement, the TBM* and the Control Data SCROLL were the only available MSS devices. Before the end of the procurement cycle, Control Several months after the com-

Data withdrew their bid of the SCROLL system.

pletion of the procurement procedure, IBM and CDC announced cartridge storage systems. The TBM* was acquired and then expanded in three phases. TBM* Hardware Configuration, shows the current system. Figure 2, AMPEX

*TBM ^

is a registered trademark of the AMPEX Corporation

(1A
COP4TROL 0-.4 DATA 4 VYsO CIT OPERA fo CCS-. CONC-OLIF COS1clue PRINIER Cs.,moumcatrn coe"Olv Section

(/2 HCIF..
Dour OCI "me ChannelSfnwfw Data S.,'#' D ne hann.el'.I ntePame Trawacput D'.... IntwecOe D.i1 Traniport Module. T.esevps, Alut.rat Conwwctsg. TOM. D Mm DC330-1 SCU V~TO
?eatwsortve 0..

"SL

1*36
DMC

~~~~~~~~UG
DEC TAPIE RRICER

(SS Date Stn..yW S.~eon ~~~~~~~~~~~SCP SI.'..' Control P'ace~. CID Ch...wtl Interface Unet

0D. C9'mne Module

SWo'a" control Ur"I AllmvhenmgneCRT Cwmf DEC W..im, HWa Cow. Consaf Dc.', DEC Tap. u'.. Vaswn. Supply Meftf Aw Supply Mocluft

TDIF
DIM

U)0 "I (D
I'lj

CtUCaM.."..*
COCSOI U.n' Pt es..' Ch..wnI Swnufaloi

TTY AC ~~~~~~~~~~~~~~~~~~~~~~CISIM

LA36
TUSS

V SPA
'AS.'

acm

H-

til CD

CHSOM

LO~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0
UILAYSE~O Mt

DC93WI~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

III
SW

I~~~~~~~IK
AC.

Uc )
03 U)
(/

~~~~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~~~~~~S ~~~

(D
(/

CC

SCD Issues

2.63

Mass Storage This configuration provided This phase

Phase One began with a basic configuration.

enough hardware for testing, software development and system use. saw no system component redundancy. In Phase Two,

two additional dual tranAt this point, the a second channel

sport modules and a second data channel were obtained. system had some component redundancy. In Phase Three,

interface unit (CIU) was obtained. path between the 7600 and the TBM*.

The second CIU provided a redundant data This CIU was to become the data path Each phase has been accompanied by

between the CRAY1 and the TBM* in 1980.

significant software improvements which have greatly increased the usefulness of the system. Phase One (March integration and 1976 software February 1978) was devoted solely to hardware

development and testing.

Some of the problems software problems, and

encountered in Phase One were excessive head wear, operational difficulties stemming

from a 30-step tape mounting procedure.

During the acceptance test, and shortly thereafter, the TBM* was used to maximum capacity, though there was not enough hardware to handle the data load from the CDC7600. unanticipated It was hoped that overloading the TBM* would produce any Soon, subtle data failures began to occur. The

problems.

number of checksum errors on data returned from the system began to rise and the use of the system rapidly declined. This problem is illustrated in Fig-

ure 3, Bits Moved Between the 7600 and the TBM* (Total of Bits Read and Written), from May through September 1977.

15 14
13

12

x
>7 0

(n
a-

4-)4
(\Jiue3 is oe ewe he70 n h B

3 ~~~ 2u

~~~~~Ttl

fBt

edadWitn 1981

SCD Issues By the June 1, 1977,

2.65 most users were avoiding the TBM*

Mass Storage because of these

intermittent data errors.

In July, these errors were traced to a failure in

the TBM's* data channel where they occurred only in certain cases for data copied from one video tape reel to another. Once the problem was understood Over

and corrected by AMPEX engineering, use of the TBM* began to increase.

the lifetime of the system, this remains as the most serious error encountered. During Phase Two (February 1978 - August 1979), many software improvements

were made to enhance operational procedures and provide better user access to the TBM*. The head wear problem was solved when AMPEX changed the material The

used in the heads from the fastwearing alfesil heads to ferrite heads. ferrite heads provided an order of magnitude better head life. stability and restart procedures were improved. However,

The system's the number of

videotapes being mounted each day had increased and was causing operational and throughput problems. period. During Phase Three (September 1979 - January 1980), software enhancements The worst case was 90 tapes mounted in a 24-hour

reduced the number of daily mounts of videotapes to about 30 a day. A fourth software phase has recently been completed. phase was to connect the TBM* CDC7600 and the CRAY1. to the CRAY1. The objective of this

The TBM* now serves both the

The cost of equipment and maintenance to provide this

service is shown in Figure 4, Equipment Costs for the TBM* Mass Storage System.

Mass Storage

2.66

SCD Is-sues

Figure 4: Equipment Costs for the TtM* Mass Storage System

Annual

--

Items
-e _ I 1 -81 LI

Purchase
-IL s4

Maintenance
---- --Ir

Years
-- p -

Maintenance
- -

ll--I -JIL-LILC--LC-JCJ

Original acquisition (2 DTMs, DC, 2TDs) (SCP, CIU) 1st add on (2 DTMs) 2nd add on 100 reels of video tape
Total

$1 ,000,778

$143,000

'77

$143,000

237,248

183,000 155,000

183,000 54,937 parts '79 155,000 47,731 parts

'78

759,559 60,000
$2,057,585

220,000

'80-'86

1 ,540,000

Total maintenance

$2,021,0

Daily Cost = [{(2,057,585 + 2,021,000)/10}/12]/30

= $1,133

SCD Issues

2.67

Mass Storage

As use of the CRAY/TBM connection increases, the stored data can be manipulated (without user or host system intervention) so that the active data

remains online and immediately available. trollable.

The growth of stored data is coninto minimum space, TBM* storage growth

All data is properly formatted and packed and transmission times.

reducing storage requirements

and control is illustrated in Figure 5, TBM* Storage Growth and Control.

Figure 5.

TBM Storage Growth and Control

Purge rule:
t VSN's
LI)

After 90 days remove everything not read or written to TBM in the

previous 90 days.

ci)

40,000

Ui) (U)

C:)

CO)

75 VSN's/day

'00

CM.

26 VSN's/day growth rate

10,000

1))
(TiC

0 Cl)
Ef)

tf)

Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1979 1980

SCD Issues

2.69

Mass Storage

This diagram shows the disk growth and reduction with respect to time as quarterly purges of unused data are performed. tains a high percentage of active data. The TBM* library clearly con-

Catalog handling techniques are now

available which prevent data loss and allow catalogs to be dumped to the normally used areas of the storage media without requiring specially reserved blocks. The TBM* has provided valuable lessons about requirements for any new data archival system. A clearer picture has emerged about the functions required A greater appreciation exists for the Only

at both the host and archival systems.

memory and computational requirements of a future data archival system.

small amounts of these resources were available on the small mini-computer when the TBM* was purchased. Reasonable amounts of memory, I/O and computaA

tional power are required to control and manage a mass storage device. very important years. fact has become evident after using the TBM* for

several

Once data is written, most activity against the data is for readTherefore, if the

only, with only a few rewrites of the data performed. media could not be reused,

a non-rewritable storage system could be viable, Thus, the mass storage system could include

providing media costs were low.

video disk technology which uses non-rewritable media. In summary, for the efforts outlined the TBM* provides: a. b. c. d. e. An MSS which is tightly coupled to two major host systems An online capacity of 504 gigabits An effective data migration capability from a pool of 2500 gigabits Very low cost-per-bit for archival storage Good offline data management

Mass Storage f. g. Controlled storage growth

2.70

SCD Issues

Software capability to provide more host interfaces WHERE DO WE GD FROM HERE?

There are some opinions that NCAR should never again attempt to install a mass storage system that is not adequately configured and installed as a turn key system. Using this criteria, all of the development problems are assumed In the future, every effort will be made to avoid extensive At issue, however, is whether some development and

to be avoided. development

cycles.

natural system evolution can be avoided if real gains in performance and data storage capacity within the local Network are to be made in the 1980's. A replacement for the TBM* has been budgeted will allow use of both systems through FY85. for FY83. Overlapping funds

During this period, the data on

the TBM* must be offloaded onto the replacement MSS. Initial planning for a replacement MSS has been very conservative. The TBM*

technology of the mid 60's would be replaced with MSS technology of the mid 70's. Anticipated gains will be made in reduced maintenance costs and possi-

ble reduced access times for data residing on a closely coupled system. Some immediate solutions to NCAR's mass storage needs can be constructed from a group of currently available components that may be viewed as building blocks. a. b. c. These components are:

The Network Systems Corporation (NSC) Network adapters A small-scale computer to serve as MSS control processor and catalog manager Various magnetic cartridge storage devices

SCD Issues d. e.

2.71

Mass Storage

An automatic tape library device A pool of staging disks

Utilizing appropriate groupings of these items, NCAR can construct a mid-70's MSS technology to replace TBM*. A set of MSS characteristics can be selected

to match planned configurations through the mid 80's. Examples of possible MSS choices will be configured using some of the above building blocks. b, and e. A useful storage system can be configured by using items a,

This system would consist of a large disk farm with 500 gigabits Such a configuration is loosely good data transfer rates and a

of storage and would cost around $2 million. coupled, provides very rapid access times, high cost-per-bit.

Offline media would be disk packs or the data moved to This system will be referred to as Option I and is

1 1/2 1 tape and archived.

shown in Figure 6.

Mass

Storage

2.72

SCD Issues

Vtware 6.

ept1m

'Os

cl

Network

Figure 7.

OPtIon II

'Os

Cl

Network

Figure B. Option III

los

CRAYI

Network

SCD Issues

2.73 around Option I.

Mass Storage These options

Some other options have been constructed

trade off limited disk farm space for expanded magnetic cartridge or standard tape space. cases. Option II is shown in Figure 7. Library (ATL) to Option I. It This configuration adds the Automatic Tape Some disk space is still required for staging purposes in all

The ATL is an automated online tape library for stores, locates, retrieves and mounts 1/2" tape

standard 1/2" tapes.

reels under computer control. to 100 gigabits.

This option allows a reduction of disk space

The 100 gigabit capacity estimate is based on current use Option II is estimated to cost $1.3

of disk space on the CRAY1 and 7600. million.

This MSS provides a terabit of storage and can be expanded to 10 It is assumed that

terabits or more if floor space can be made available.

more than one volume or dataset will be packed onto each reel so that insofar as possible, each reel is full of information. When data management software

is developed to handle compression of data to remove obsolete data sets, this configuration would be closely analogous in function to the present TBM* system. Option III is shown in Figure 8. storage device. Such a device This configuration adds a tape cartridge provides faster access that the ATL to A 1.3 terabit system could

datasets not currently resident on the disk pool. be configured to provide:

- 300 gigabits of cartridge storage for short files requiring rapid access - 1000 gigabits of ATL storage for full tape files requiring reasonable access
- 40 gigabits of disk pool storage

This configuration is estimated to cost $1.9 million.

This system would pro-

Mass Storage

2.74

SCD Issues

vide a broader performance range than Options I or II. Figure 9, Performance and Cost Comparisons, Options I, II and III, shows performance and cost comparisons for each of the proposed options.

Figure 9. Performance and Cost Comparisons, Options I, II, and III

Option

Approx. Cost
-

Online Gigabits 500 1000 1800

Cost $/bit 4.6 x 10-6 1/4 x 6 10-6 1 x6 10- 6

Access
__

Data Rate

__

Overflow Capability
A

Expansibility
__ _ _

1 2 3

$2 3 x 10 $1 3 x 6 10 1.9 x 10

.07 sees 94 secs 19 secs

24 Mbit/sec 12 Mbit/sec Up to 12 Mbit

P G
P

E G

E = Excellent G = Good P = Poor

SCD Issues

2.75

Mass Storage The

Other variations can easily be constructed from the building blocks.

data throughput for large files provided by the ATL device in Option II is considered better than the data throughput for large files provided by the cartridge device in Option III. The data access time of Option II assumes

each reel of tape is packed with multiple volumes of data so that each access to a given volume includes search time to the desired volume. time is assumed to average out at 1/2 of the tape. If This search

the normal situation the

of one dataset per volume exists, then the access time is 20 seconds, required time to search one-fourth of a tape.

This one condition alone

changes the capacity of a maximum system from 10,000 to 630 gigabits. The one dataset/volume criteria would eliminate the need for any offline data management required by the MSS to compress obsolete information and to gather frequently used small files into optimum locations on each reel. tradeoffs exist as such systems are configured and Several more

their corresponding

software is defined. Each option outlined has been loosely coupled to various hosts through the Network. If Option III were tightly coupled to an appropriate host, signifi-

cant improvements in access times could be achieved with the cartridge device. The cartridge device/disk pool combination can be considered a virtual disk system. The host in a tightly coupled environment has random access to does to data on a

all data on the cartridge system in the same way as it storage system comprised only of disks.

The other nodes on the Network can

then be loosely coupled to the storage system via the host which is tightly coupled. A non-major vendor for a configuration discussed in Option III exists. This

vendor supplies software to couple this system via a Network into selected

Mass Storage hosts' systems. basis.

2.76

SCD Issues

The MSS provides data to the Network on a record-by-record

This method can provide a very convenient service to certain types of The data migration times across the Network for

host systems on the Network.

any significant amount of data are not expected to adequately satisfy the appetites of the class VI machines. This approach is considered inadequate

if attempted on each system within the NCAR Network. the TBM* can hold 504 gigabits online and can select data from about 2500 gigabits overall. The growth of this data has been carefully controlled by

quarterly purges but conservative estimates signify that it will reach 67,500 volumes or 4.7 terabits by the mid 80's and 107,,500 volumes or 7.5 terabits by the end of the decade. The replacement of the CDC7600 with a sixth class along with the addi-

computer and the CRAY1A with a seventh class computer,

tion of raster graphics capability and an increase in the amount of satellite data, could make these figures seem extremely conservative. This data growth

rate is one of the contributing factors pointing to the urgency of obtaining replacement equipment. The amount of TBM* data cannot rise beyond the point

which disallows off-loading to a replacement MSS in some reasonable period of time. Current plans call for a 2-year overlap of MSS funding from FY83

through FY85.

During this period a new MSS must be installed and all good Since the TBM* has been suc-

data off-loaded from the TBM* onto the new MSS.

cessful, the momentum of use will prevent easy discarding of it in favor of a less expensive more capable successor. technology improves. cost reduction. Only Option I offers easy upgrades as

Each of the above options provides for some operation

In the case of Option I, access time is also reduced.

New technology must become available in conjunction with the production of the new MSS's that can service the class VI machines' data requirement in the

SCD Issues 80's. The current CRAY1A

2.77

Mass Storage The

channels can operate up to .27 gigabits/sec.

computers to be installed as CDC7600 and CRAY1A replacements can be expected to perform at this speed. The data rates possible on today's MSS's vary from These rates are at least an order of magnitude Such rates place too great a bur-

.005 to .012 gigabits/second.

slower than those of the host's channel's. den on any migration scheme.

Further, the growth of NCAR's storage require-

ments cannot be gracefully accommodated on present devices.

DATA RECORDING TECHNOLOGY

In the mid- to late-1980's different media and recording techniques may provide significant improvements over the devices considered as immediate

replacements for the TBM*.

These future devices will use one of the follow-

ing data recording technologies:

- Laser recording on optical disks

- Photographic recording on special film

- Magnetic recording on tape or disk - Electron beam recording

Optical disks use a laser to remove metal and generate a hole to represent a data bit. Density is limited by the diffraction of visible light and up to 2

gigabits/in2 should be possible. Photographic techniques are limited both by diffraction of light and film granularity. Current systems yield .1 gigabits/in2 and up to .5 gigabits/in 2 Photographic techniques require a development process This process may eliminate use of the photo-

should be possible.

before data can be read back.

graphic techniques depending on its complexity and turnaround time for read back.

Mass Storage

2.78

SCD Issues

Magretics are limited by particle size which determines tape signal to noise ratio and coercivity which determines read energy. .01 2 gigabits/in2 . .03 2 gigabits/in2 have been Densities now approach in a laboratory

recorded

environment and

.07 gigabits/in2 may be possible.

Electron beam recording

potentially can record at the extremely small spot size of 1 to 2 angstroms as compared to the 2000-3000 angstrom limit of optical methods.

A. real density may not be as important as volumetric density. Considering the

two leading contenders for advanced recording technology, optical disks and magnetics, magnetics may produce 100 gigabits/in3 vs 50 gigabits/in3 for optical disks. Therefore, volumetric considerations allow magnetics to remain a

useful storage method in spite of advances in optical recording. For any of the above technologies to be viable contenders for the MSS market, some manufacturer must integrate the technology, hardware interfaces and

software to produce a commercially available product.

Figure 10,

Cost Com-

parisons

Among Laboratory Models,

shows some comparisons among companies The companies are unnamed since in some

which are known to have laboratory models.

the numbers given have been arrived at through unverifiable means,

cases.

SCD Issues

2.79

Mass Storage

Piwars 10.

Ceft CempelensNNoag Laboratory Models

CMPmuW

31 .edia T~ype -

Access Time

Voiwuetric Bite/Antd Mod ia Density (PI.Lkin.,. ~~~~~~Dens ity) To Any Data Block' On Mounted 150 Sec.

Medila Cost

co~t/blt

D~ata flate

Aror Wite di tn N0M

LMta P M~t Proc.

To Next Daita Block or Track etc.

___________

~~~Med ia
1.3x0 1 2 bits per reel or 6.7 Mil Bitt per in
______ _______

ihwetic

3300 to -96J per reel -depending on quantity

30. Mu l bits per sec*

I ffror unknown In 10 bits transferredTO

sitt

~~~~~~~~
10 Mil bits per sec.
__

ytn or

Video Disk

1 a-sec. track to
track______

50
5.BcC.

unknown

wunw

Video Disk

500 200 s0
a~sec.

lax

bite per disk

11

$11 to $175 per disk depending on quantity

320 Mil bite per sec.

(I ofjror In 10 bits transferred

DSC,PDP or similar

1W, POP or NSLa.' special

optical Slides

5 sec. Slide to Slide

_____ ____

200 R.sec. Block to

Block
_

29xO bits 2.9x1311 b i per.9de1er19 bin per cartridge

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

5 Mil bits per sec.

_ _ _ _

<1 eror in 10" bits transferred

_ _ _ _ _ _ _

DW.,PDP or similar
_ _ _ _ _

DB, POP or special

_ _ _

Mass Storage

2..80

SCD Issues

Figeva 10. Cutr. capse.

Laboratory Pkodels (Continued) Cost Coqetreos Awmon seed Unitst Wr.ite Uni ts Need end Writet
Uits.

Possible Systuss Con figu re tions

Posulible Systems On-Line Capacity

Possible Syeste Costs

~
A. 3. C. D. A. B C. . A. 3 C. 3

A 4drives pe r entr.

No0

No

yes

1Icon t. 4 drives

2 con t.
8 drives

3con t.
12 drives

4 conto
16 drives

5o

10 bits

IO0$2:

1 0 bit.

150Y2 10 bits

20f~

.10 bits

81.42 Nil

82.8 Nil

3,4

Nil

4.6 Nil

6 Arives Bper entr. 2 or sore 'Jukebox' eonfigN orations

Tes(9-1) 849,000

Tes(A-1) 856,000

l*q1. 10

42 Nil

Yesl

No

Yes

Need Only

Need and Write

1:101 bits

11101.. to15 1110 bits

Nil to S1 Nil

S Nil to 82 Nil

fl

2 date paths per unit

No

No

Yes

2000 slides

4000 slides

6000 slides

5.4 10

It., X 10

23.?zx 10

Not Avail.

SCD Issues

2.81

Mass Storage

None of these companies appear to be building a complete MSS prior to the mid to late 80's. Producing the laboratory device is the first step. Building

controllers, host interfaces and writing software to drive the MSS and manage the catalog comprise the other 80% of the overall effort. The market for

high performance devices is not very large and most companies prefer to build lower performance, more marketable equipment. The combination of software

apd marketing difficulties eliminate most of these devices from the realm of realization. One way for NCAR to configure an MSS and overcome some of the same problems mentioned above is to connect a controller and several drive devices from one of the above manufacturer's machine to the current TBM*. This solution offers the advantage that the necessary software currently

exists and the vendor would not need to provide anything except hardware. Used in conjunction with one of the options described earlier, a balanced

system, providing very good performance both for short datasets on front end systems and long datasets on class VI machines, is obtainable.

Workshops on Research Goals Workshops on Computing Needs Astrophysics and Upper Atmosphere Basic Fluid Dynamics and Oceanography Climate Cloud Physics Weather Prediction and Mesoscale modeling Workshop Summary Response to Conference Recommendations

Conference Recommendations

3.1
THE WOIKSHOPS

The Workshops

by Jeanne Adams and Buck Frye The agenda for the conference included workshops on research goals and computing needs in an integrated national research effort in the atmospheric sciences. The topics discussed in these workshops were Astrophysics and the

Upper Atmosphere, Basic Fluid Dynamics and Oceanography, Climate, Cloud Physics and Weather Prediction and Mesoscale Modelling. At the end of the morn-

ing session on the first day of the conference, scientists met in smaller groups on each of these topics in the atmospheric sciences. The discussion

centered around the broad research goals proposed in the report, The Atmospheric Sciences: National Objectives for the 1980's. At the end of the first day, the same workshop groups met again to identify their computing needs. These needs were estimated based on the assumption The

that their research goals and strategies for the 1980's were realized.

guidelines that were distributed to the workshop participants were published in the Pre-conference Packet sent out before the conference included in this section of the Conference Proceedings. A scientific chairman and two workshop assistants were appointed to help with the sessions. and are also

The Workshops

3.2

Conference Recommendations

Astrophysics and Upper Atmosphere Basic Fluid Dynamics and Oceanography Climate

Chairman D. Hummer B. Semtner F. Baer T. Vonder Haar H. Orville C. Kreitzberg

SCD Assistants W. Spangler P. Peterson P. Rotar B. Frye G. Jensen C. Ridley R. Jenne J. Adams B. O'Lear M. Drake D. Joseph

Cloud Physics Weather Prediction, Mesoscale Modeling

The second day of the conference was spent reviewing the workshop summaries which were presented by the chairman from each group. The conference con-

cluded with the Scientific Computing Division Response to the workshop summaries made by the SCD Division Director, Walter Macintyre. Dr. Macintyre

summarizes the conference conclusions in the last paper in this section of the proceedings.

Conference Recommendations

3.3 WCRKgOPS ON
RJ AR
aGs

Research Goals

by Buck Frye A. The three broad goals proposed in the report, The Atmospheric Sciences: National Objectives for the 1980's, are: 1. To improve our understanding and weather prediction capabilities, with emphasis on precipitation in cyclonic storms and severe storm processes. 2. To understand the climate system and its variability over periods of seasons to decades. 3. To elucidate the biogeochemical cycles and budgets and their relationships to atmospheric processes. B. Are there other goals and planning doc'uments that would be useful for the 1980's? C. Some strategies to achieve these research goals might include the fol-

lowing: 1. The increased number of weather observations and the improved

methods of communicating and analyzing such observations should be used in a focused, coordinated program to improve short-term

weather forecasts. 2. Theoretical and modeling studies as well as field experiments that use very fine-scale observing networks should aim toward improving predictions of the amounts of precipitation and the timing and

Research Goals duration of storms. 3.

3.4

Conference Recommendations

Computer modeling should be used to identify short-term,

poten-

tially predictable components of climate such as drought or severe winters, and to find their precursors such as changes in sea surface temperatures. 4. Computer modeling should be used to determine the climatic effects of alteration of the earth's surface by natural and human activities. 5. To elucidate the global atmospheric chemical cycles problem, an

effective attack must include a sharp increase in global chemical measurements, including measurements from balloons, aircraft, and

satellites; laboratory work to determine and refine chemical reaction rates; and development of combined chemical and dynamic models of the atmosphere. 6. To explore the nature and effects of regional atmospheric chemical and pollution processes, an effective effort will require surface and airborne field measurements, tinent chemical processes, laboratory work to define per-

and development of models capable of

describing regional atmospheric chemistry.

Conference Recommendations

3.5

Computing Needs

WORKSHOPS 0a C(NPUTLQNG

by Buck Frye A. To realize the research goals and strategies for the 1980's, the computing needs of the atmospheric science community must be estimated. following questions are pertinent: 1. How fast and flexible should access to data communications be? 2. What data communications transmission rates will be effective ? 3. How much computing capacity and power will be sufficient? 4. What degree of compatibility in use of computing service is necessary for effectiveness? 5. What capabilities in vector and raster graphics displays will be needed? 6. What online and archival storage and storage access will be sufficient? 7. What kind of software tools and utilities will be needed? B. The relative roles of large, centralized computing facilities and The

smaller local ones must be weighed. provide in the 1980's? Long-Range Plan?

What computing services should NCAR

To what extent are these consistent with the SCD

Astrophysics/Upper Atmosphere

3.6

Conference Recommendations HEE

ASTOPHYSICS AMD UPPER ATM

by David Hummer Participants agreed that the goals stated in the "Workshops on Research

Goals," which summarized the report The Atmospheric Sciences: National Objectives for the 1980's, should be augmented by the goals identified in three parallel studies, all sponsored by the National Academny of Sciences: 1. Solar-System Space Physics in the 1980's: A Research Strategy, by the

Committee on Solar and Space Physics, Space Science Board. 2. Solar-Terrestrial Research in the 1980's, by the Committee on Terrestrial Research of the Geophysical Research Board. 3. Astronomy in the 1980's, by the "Field" Committee of the NAS. Solar-

The thrust of recommendations in the first two of these reports is directed towards an understanding of the individual links in the chain connecting the flow of energy from the sun to various phenomena in the earth atmosphere and ultimately at its surface. In other words, the 1980's should be spent in

forging the individual links that in the 1990's can be assembled in a logical chain describing the flow of energy in considerable detail. Of particular

importance to this understanding, in the view of the workshop participants, are the numerical experiments essential to the interpretation of satellite and other observations of the upper atmosphere and the interplanetary medium. The emphasis here is on large scale numerical modeling and not on data reduction, which would be carried out, for the most part, at NASA. Examples of

the kind of activity desirable for these goals include: 1. Solar wind models, ultimately in three dimensions, interacting with magnetospheric models, again finally in three dimensions

Conference Recommendations

3.7

Astrophysics/Upper Atmosphere to .the iono-

2. General circulation models including detailed attention sphere, thermosphere and magnetosphere.

It is also evident that substantial work must be carried out in order to achieve some level of understanding of the variations of both the sun's total energy output and in the distribution of this power among various modes-radiative and partial fluxes. the likely mode of research. There remains a great deal to do in elucidating the basic hydrodynamic and plasma processes of the upper region-of the earth' s atmosphere. Of particuAgain, large scale numerical models will be

lar importance 'in the context of this meeting are continued investigations of turbulence, and MHD simulations of various kinds. Again, the premium is put

on availability of very fast processors with large rapid access storage. The success of recent spacecraft missions to Venus, Mars, Jupiter and Saturn is providing a strong impetus to a new generation of modeling of planetary atmospheres. Because of the very detailed nature of the new observations,

these new models will be characterized by a much higher degree of spatial resolution, and probably by the inclusion of many additional physical

processes as well; thus we can expect the computational load to increase many fold. The investigation of the basic physical processes, such as partial

surface interactions and atomic molecular collisions of all types, will also require large amounts of computational power. Regarding astrophysics, although astrophysical computing comprises only about 8% of the SCD's load, NCAR is the U.S. place in regarded as a crucially important facility by Solar physics has the years, and by always had a special of the

astronomic al community . NCAR 's program over

extension much

Astrophysics/Upper Atmosphere important progress occurred here. in stellar

3.8

Conference Recommendations the past decade has

atmosphere theory in

Although the report of the Field Committee will recommend the

Acquisition of some thirty VAX-class systems over the next decade by astronamy departments and institutes throughout the country, its members felt that very large numerical problems would still have to be solved with the aid of large-scale equipment at Goddard, Ames, Los Alamos, Livermore and, of course, NCAR. The expectation of the Committee is that the large data-processing generated by satellite observatories and by such devices as

requirements

diode arrays would be handled by the VAX systems just referred to. The types of problems of interest to astronomers are tending to modeling of more complex systems, i.e. those with lower degrees of symmetry than spherical, and also to higher resolution in spatial, time and frequency domains.

In particular, accretion disks are of very great interest in many contexts; the treatment of radiative transfer and gas dynamics in axial symmetry is probably the lowest order approximation that is useful. The necessity for

higher resolution in modeling is of course stimulated by major developments in observation techniques in the past decade; the prospect of Spag Telescope in the mid-1980's promises both an increased increases in resolution. volume of data and further

These developments imply that astrophysical model-

ing will be approaching the resolution and complexity of terrestrial atmospheric models, which has to imply that the computing needs for astrophysics will become closer to NCAR's main stream research. solar Modeling of both the

winds and the wide varieties of stellar winds now must account for

large deviations from spherical symmetry; a general 3-D treatment seems to be essential. Finally, IUE observations of hot stars are providing increasing

evidence that a quantitative understanding of their atmosphere involves the

Conference Recommendations

3.9

Astrophysics/Upper Atmosphere

blocking and redistribution of radiation by millions of lines, which must be treated by a rab equation approach, i.e. without assuming LTE. Thus the

needs of astrophysics for large, fast computers parallel closely the needs of the upper-atmosphere scientist. The general feeling was that quite moderate data transmission rates (300-1200 baud) would be sufficient; of more importance are efficient file management and editing facilities for use via RJE stations. It appeared that the speed

of the CRAY-1 was sufficient, but that additional fast storage was essential, either by extension of the main store or by provision of very fast secondary storage, i.e. faster than presently available disks. On the question of com-

patibility,' some of the participants stressed the necessity for 60 or 64 bit words and the enormous difficulty of coping with small dynamic ranges (i.e. + 38 instead of '300). The projected quick-look facility for graphics was such refinements as raster graphics and color

felt to be highly desirable;

were recognized as valuable for processing solar observations where enhancement of pictorial data was of major interest (this is of special interest to HAO). The need for remote access to graphics was stressed. Retrieval of

archival material in minutes rather than hours appeared to be more important than millisecond access. On software problems, the need to access CRAY-1

disk files as random access files rather than tapes was forcefully expressed; similarly the great utility and popularity of FRED strongly suggested that it be enhanced and implemented on the CRAY-1. routine packages was requested. More attention to scientific sub-

The provision of a working overlay for the

CRAY-1 is essential and will become crucial as the successive versions of the system become even larger. Finally, in reference to the question of setting

priorities in the event of insufficient computational resources, it was felt

Astrophysics/Upper Atmosphere

3.10

Conference Recommendations

that the statement in paragraph 2, page 7 of the SCD plan should be augmented to refer to the reports mentioned at the outset of the present summary.

Conference Recommendations

3.11

Fluid Dynamics/Oceanography

BASIC FLUID DYNANICS AMl OCEAAOGRAPHY

by Bert Semtner This was probably the largest workshop in terms of attendance (11 persons). The two disciplines represented have several things in common. Their comput-

ing activities involve large arrays with a relatively small amount of computing at each grid point, which makes memory size an important factor in computing; and NCAR serves as a de facto national center for their computing activities. Each field is closely related to atmospheric science, without

being recognized explicitly by NCAR as important in its own right or important to atmospheric science. Each of the disciplines uses about 10% of the

NCAR computing resources (especially the CRAY-1). Oceanography workshop, research goals were discussed during the first part of the

and the following table was constructed to summarize the major

areas in which research activities are concentrated: A. Modeling 1. Understanding the role of mesoscale eddies in the oceanic general circulation. 2. Understanding the oceanic mean state and its relation to climate (including mixed layer dynamics). 3. Process/regional dynamics (coastal, dies, jets, rings). 4. Other (tracer studies, satellite data assimilation, observational Antarctic and equatorial stu-

Fluid Dynamics/Oceanography program design).

3.12

Conference Recommendations

B. Data analysis and interpretation 1. Conventional data processing data). 2. Satellite data (NOSS, etc. in late 1980's). 3. Other data gathering systems (e.g. acoustic tomography). The basic fluid dynamics research goals were grouped into the following categories: A. Physical Problems 1. Turbulence without constraints. 2. Turbulence with constraints (rotation, boundaries, stratification, forcing). 3. Instabilities and transition to turbulence (finite amplitude waves; vacillations; laboratory experiments). 4. Coherent structures (solitary waves; modons; intermittency). (historical data, special project

5. Other theoretical problems (e.g. strange attractors; critical layer problems; internal waves). B. Mathematical Problems 1. Solutions to special equations Vries equation, etc.). (Burgers' equation, Korteweg de

Conference Recommendations 2. Algorithm development.

3.13

Fluid Dynamics/Oceanography

Regarding computing needs in oceanography, two recent studies were cited which describe and justify a need for increased resources. A workshop was under the
Results

held at NCAR in 1979 on "Ocean Models for Climate Research,"

auspices of the Climate Dynamics Panel of the U.S. GARP Committee.

of that workshop were published by the National Academy Press in 1980. report includes an informal estimate

The

that a Cray-type machine might be Another study, whose results

required for ocean modeling by the mid-1980's. have not yet been published,

was made by the ad-hoc Panel on "Computing

Resources on Ocean Circulation Modeling" for the Ocean Sciences Board of the National Academy of Sciences. That study included a detailed survey of the

modeling community and documented a conclusion similar to that of the earlier study. Based on information from the two studies, the workshop participants

estimated a percentage breakdown of computing time needed in the four broad modeling categories as follows: Eddy-resolving general circulation models Oceanic general circulation models/climate Regional and process models Other 25% 35% 25% 15%

In absolute terms, the workshop members estimated that the total ocean modeling in Cray hours/year for universities and NCAR at present is 800, which is at NCAR. The projected 1984 level is 2,000, 500 of

and the desirable 1984

level is 4,000 (-2/3 Cray).

Ocean data processing could also have a poten-

tially large requirement for the late 1980's.

Fluid Dynamics/Oceanography

3.14

Conference Recommendations

Computing needs for basic fluid dynamics were estimated on the basis of the relatively broad experience of the workshop participants. broken down as follows: A. Physical problems
1. Free turbulence 200 Cray hrs/yr

The needs were

2. 3.
4.

Turbulence with constraints Instabilities

Coherent structures

300 30
30

5. B.

Other theoretical

50

Mathematical problems

50

660 Cray hrs/yr

(a

1/10 Cray)

The estimate of one tenth of a Cray for basic fluid dynamics represents a modest increase in the fractional amount of machine resources devoted to this research area now. The majority of workshop participants seemed to feel that

more computing power will be needed for fluid dynamics, but that the natural growth rate of machine computational part. speed would be adequate for the most Workshop

However, this was not the case with regard to oceanography.

participants indicated an immediate need for a large growth in computational resources for oceanography, speed. over and above the natural growth in machine

Conference Recommendations

3.15

Fluid Dynamics/Oceanography

The workshop was able to agree on a list of priority items for implementation at NCAR. The priorities are surprisingly close to those suggested by other

workshops, and somewhat different from those suggested in the Pre-Conference Packet. In order of importance, they are as follows: CPU power - megaflops, memory, I/O bandwidth Mass storage - proportional to CPU power Vector graphics - previewing capability (highest), interactive

(highest) 1. (high) 2. 3.

features (high) 3. Software development - file management, numerical algorithms (lower) 5. 6. Raster graphics - turbulence display, ocean satellite data High-speed digital communications.

Cl imate

3.16 CLTK&1E

Conference Recommendations

by Ferdinand Baer

CONUTER NEEDS FOR (LTK&TE

HA

As part of the NCAR SCD First Annual Computer Users Conference program, the workshop on Climate met on January 5, 1981 to discuss its computing needs.

The group was able to establish its priorities from the items enumerated on page 7 of the Pre-Conference Packet. The order of item presentation to folHowever, it should be

low is consistent with the priority level assigned.

noted that the first two items, computing power and storage,

are seen as

closely linked by this workshop, and represent those items which its members consider by far the most important to climate studies.
1. Comutirng Power

The workshop noted a less than subtle observation that as a computer becomes saturated, the largest programs are gradually squeezed out. Since the NCAR

CRAY-1 is rapidly approaching saturation, the prognosis for successful computation with climate models becomes increasingly poor since those models require some of the most intense computing power. It is evident that suc-

cessful climate studies require many tests with a variety of models, some representing the largest models available. dies is the concomitant analysis. Associated with such model stu-

Analyses can be highly complex involving

comparisons with model output as well as with observational data. It is evident that extensive computations must be done at a central computing resource and that the ideal location is NCAR. However, that resource will

Conference Recommendations

3.17

Climate

become less and less available to the climate community as the demand for its capacity continues to increase at the current rate. The workshop estimates

that by 1985 climate research will legitimately saturate one CRAY-1 without the assistance of other projects. The workshop on climate therefore strongly

urges NCAR to expand is computing capacity with the addition of a machine at least as powerful as a CRAY-1, recommendation. 2. COIL Storage difficult to separate this item from computing power. and it places its principal priority on this

The workshop found it

As the capacity of the facility expands, adequate storage must be provided to make use of that capacity as efficiently as possible. In addition to this

need, the workshop recognizes the vast storage requirements the climate program requires to maintain large data bases as well as the detailed output from model calculations. Additional requirements will grow from augmented

analyses of both data and model output. Based on these anticipated needs, the workshop placed highest priority on

storage capacity and recommends that such storage procurements keep pace at least with the expansion of computing power, and possibly faster to accommo-

date the accelerated needs of climate researchers. 3. Graphics

The climate workshop found the raster graphics development interesting, but not particularly pertinent. Climate modelers and analysts do not anticipate They are also

intensive use of this highly refined tool in the near future.

hopeful that development of this technology will not divert a significant

Climate

3.18

Conference Recommendations The workshop members felt, how-

part of the computing facility's resources.

ever, that they will have continued and expanded use of vector graphics both as an aid in program checking and in assessing model output. They therefore

recommend continued development of the vector graphics package to make its use as convenient as possible. An issue of particular concern to the climate modelers is the availability of movies depicting the evolution of model fields. This product plays a large

role not only in understanding model output, but also in describing such output in a most efficient manner to others. The workshop therefore considers

as a high priority the development of movie making capability in the SCD which is not only easily accessible, but also produces a high quality product with minimal delay.

3. CcErications
Despite the rapid progress in communications links and the enthusiasm in

university circles for interactive terminals, the climate workshop found this item to be of low priority. Because most models are of substantial magnitude

requiring long computer runs, interactive potential and rapid remote access are not of great importance. Models can be sent to the central computer and

run without high priority and output can be evaluated over a reasonable time period. Since most computations would be made at NCAR and not at the member slow speed communications are adequate. Addition-

institution's computer,

ally, large data sets need not be moved from one location to the other, but can be shipped to NCAR and stored in SCD data files. Thus analysis programs

may be activated and run in the same low-priority mode as the climate models.

Conference Recommendations

3.19

Climate

The workshop did recommend that NCAR attempt to maintain state-of-the-art capability with regard to communications capability, but not to invest its limited resources too heavily in this activity.

5.

Tools and Utilization

The climate workshop encourages the continued development of software capability which makes access and computing at the SCD so convenient and efficient. Maintaining a state-of-the-art library of routines and subprograms is

essential to the effective utilization of the NCAR computer by the climate community. Of particular interest and concern to the climate group was the development of specific and well-defined details concerning the upcoming community climate model. Questions of data retention, parameters to be calculated and addressed to the entire community and concensus opinion Thus one might

stored should be

should be used to provide a standardized output and storage.

have available quantities such as transports, energetics and scale transfers as well as other parameters at regular times during an integration. Whether

such data should be retained in a historical file or made available only by recalculation must also be established. A definitive and well-conceived plan

will make the community climate model of great value to those working in the field. 6. CI patibility that compatibility should be tran-

The comment by one of the participants

sparent to the user best sums up the climate workshop's contribution to this category.

Climate

3.20

Conference Recommendations

The members of the climate workshop hope that these comments and recommendations on computing needs as outlined above will prove useful to the SCD in their future planning and look forward to a vigorous and cooperative relationship with the Division in the years to come.

Conference Recommendations

3.21 (LSXJD PH1SICE

Cloud Physics

by Harold Orville It was determined that a restatement of the research goals as they apply to problems in cloud physics would clarify the groups' discussion. are summarized in the following list: 1. By means of numerical simulations and field and laboratory observations, it is important to establish (understand) the significant microphysical, dynamic, electrical, radiative and chemical processes in clouds. 2. Scientists could then use the simulations and observations available to develop better precipitation prediction methods, effective cloud modification techniques, measures. 3. A related scientific goal is to understand the role cloud and mesoscale interactions play in modulating the amount of precipitation produced by a cloud or cloud system. There have been three major efforts in cloud physics (all aided by computers): 1. 2. Theoretical, empirical understanding from the micro to the macro scale. Data handling (from a vast new array of sensors) and transfer of data to "model" framework (applied all the way from cloud physics chambers to and useful air pollution predictions and counterThese goals

large weather systems).

Cloud Physics 3.

3.22

Conference Recommendations

Confrontation and reconciliation of the data and the theory.

The above major efforts lead to a much greater need for interactive use of the computer. A scientist-computer interface is needed. A predictive capawhen performing

bility using interactive facilities is essential. analysis,

However,

a noninteractive mode is adequate provided that an improved turA "com-

naround time is possible in order to make better use of data sets.

munity" cloud physics package or an NCAR library for cloud physics would be a significant software tool to facilitate problem solutions in this area.

Model results in the form of data bases should be available for 10-15 years after an experiment for comparing results from a variety of different experiment s. The following computing needs were determined. 1. The ability to run in inspection mode; to compile and debug, requires

fast turnaround; the ability to run in educational mode, i.e., MlcIdas (imply a large data base - would be very handy). 2. 1200 baud is adequate for now; the SCD should continue with high speed satellite communications studies. 3. the need for computational power is infinite. A class VII machine is

needed now with a factor of five in speed and storage (64 bit words). 4. A uniform JCL is desired on all machines at the user level, and portable and compatible FORTRAN is important. 5. A Research Data Support System is very important for data interpretation.

Conference Recommendations

3.23

Cloud Physics

6. 3 x 1012 bits of data per year are produced and 103 tapes by cloud physics community alone. 7. FORTRAN 77 is necessary as well as a data base management system. tocols should be simple and easy to use. Pro-

Complex facilities should be

transparent to the user and access to the machine should be easy. It was stated that an estimate of cloud radiation needs would be made in the future. A preprocessor is important for the demands that occur with the use

of a 2-D Knollenberg system.

Weather/Mesoscale Modeling

3.24

Conference Recommendations
MESOSCLE MODELI

WEATHER PREDICTION Al

by Carl Kreitzberg The workshop on Weather Prediction and Mesoscale Modeling concurs with the goals and strategies outlined in the CAS Report, The. Atmospheric Sciences: National Objectives for the 1980's. It should be noted that goals and stra-

tegies adopted by the several previous workshops are feasible because of rapid advances in computer technology. in 1970, With arrival of the CDC 7600 at NCAR

work began on developing prediction models with substantial moist

physics and work began on developing three-dimensional mesoscale dynamical models. With the arrival of the CRAY-1 at NCAR in 1978, the models that had The most urgent initial

been developed were tested on a variety of cases.

data needs for indepth tests were addressed in the regional subprogram of the SESAME '79 field program. This workshop addressed six aspects of computing requirements that must be met if the scientific strategies and goals are to be met in the 1980's. 1. 2. 3. 4. 5. 6. Large computer facilities Interface of scientists with the large facilities Data collection, archival and retrieval Software tools and numnerical methods Interactive graphics Real-time data processing.

Conference Recommendations 1. Large computer facilities.

3.25

Weather/Mesoscale Modeling

It is recognized that the data analysis and dynamic prediction problems in detailed weather prediction and mesoscale modeling exceed the requirements for simple hemispheric modeling of the past decades and are comparable to those of complex climatic modeling. The level of effort in these areas in

1980 include about 20 scientists that use one-fourth of the CRAY-i at NCAR. A comparable number of scientists work in this field at other laboratories in the U.S. To make reasonably rapid progress toward the defined national objective, the number of active scientists and the computer resources must double by the mid-1980's. Thus, one-half of a CRAY-1 and appropriate interfacing, data

handling, and display systems will be required by the mid-1980's. 2. Interface of scientists with large facilities. To meet the scientific objectives, the number of university research groups active in weather prediction and mesoscale modeling research should double in the next five years. The challenge is to provide scientists remote from NCAR Generally, the

with the capability to interface with the large facilities.

home institution will have a minicomputer for program development, communications to the main facility and interactive graphics display of four-

dimensional datasets (including model-produced analysis and prediction data). These scientists will look to the SCD for leadership in the computing science technology required to efficiently interface these users with the central facility. Special problems in data handling, software tools, graphics and real-time

Weather/Mesoscale Modeling

3.26

Conference Recommendations The major point is that a and scientists at

data processing are discussed separately below.

community-wide interface system needs to be developed,

about twenty remote sites must be trained in the appropriate use of this system. lion, The community will consume about 1200 CCU's per year costing $2.5 milplus a comparable cost per year for the scientists and associated Thus, the level of effort of the computer related research,

expenses.

independent of associated field studies, will total $5 million per year by the mid-1980's (in 1980 value dollars). It is the productivity of this

investment in support of high priority national goals in atmospheric science that they expect to have optimized by effective planning in the SCD. Communications system software and networking must be coordinated by the SCD. Rapid turn-around of test runs involving several 0.1 CCU's and data volumes of a million words at NCAR and transmission of 1 M byte output back to the user will be required. About 100 such jobs per week should be anticipated.

Major production runs will produce 50 M byte output tapes to be mailed to remote sites. The education of off-site scientists in the computer science and atmospheric science contents of these software systems will involve about twenty student weeks per year. Many of the materials must be written and published in docu-

ments, and many videotape lectures will be required. 3. Data collection, archival and retrieval. By

Four-dimensional datasets are required for selected intensive periods. the mid-1980's these

intensive periods would average about five 36-hour There would be about 20

periods per year over domains 2,000 km on a side.

variable levels on a 5 km horizontal mesh and about 200 variable levels on a

Conference Recommendations

3.27

Weather/Mesoscale Modeling Each case may be pro-

40 km horizontal mesh with hourly time resolution.

cessed 20 times with half of the results being archived for future studies, often by other scientists. Of course, many studies would be on half the

scale or twice the scale noted above, with space and time domains changed accordingly to give these same average results. The implication of this discussion is that multi-user software for data processing is required if the necessary efficiency is to be achieved. This

software must include with the datasets a clear history of the processes by which the sets were derived. 4. Software tools and numerical methods. The weather prediction and mesoscale modeling goals must be met by scientists working at about 20 remote sites who will be working with large software systems. For this strategy to be effective and efficient will require software macro processor and documentation types discussed

tools of the preprocessor,

elsewhere, in addition to the data handling and display tools. The challenge is to identify the set of tools most needed and then to determine how to assemble them and train the user community. Fundamental require-

ments include simplicity (at least uniformity), portability and durability. The scientist must learn to use many of them on the home minicomputer so that they can be used effectively on the large facility. The skills must then be

useful for a number of years and codes using these tools must be easy to maintain for five years or so. It is most urgent that decisions be made on the strategy to be adopted so work can begin as soon as possible on getting these tools to the users.

Weather/Mesoscale Modeling

3.28

Conference Recommendations

Numerical methods requirements appropriate to SCD are likely to be those that significantly improve the performance of hardware archival, at the large computer retrieval, decoding and

center or in data coding, transmission, display.

Certainly there is a desperate need for more efficient analysis and prediction algorithms. However, such algorithms may be very model dependent so

they are likely to be developed or verified by scientists close to a particular model. There is an important SCD role in monitoring techniques developed

anywhere and alerting users of the large facility of potential breakthroughs. 5. Interactive Graphics.

The data volunes discussed earlier demonstrate the necessity of interactive graphics in this field. Most likely, this software will be implemented on The

the local minicomputers except for a fraction of the preview graphics.

requirement, therefore, is first on portability and then on simplicity of the user interface. Modular software is important so that small minicomputers

can run simple inexpensive graphics and the users can easily expand into more sophisticated utilities as needs and hardware become available. Color graphics will be necessary to overlay diverse fields and to follow time changes in incremental time step displays. Of particular value would be

software to drive different inexpensive color terminals or color television terminals. Raster graphics seems beyond the immediate need of most of this user community, but this may be because they are not thinking far enough ahead. course, they would be happy to be shown that it Of

is feasible in terms of

Conference Recommendations

3.29

Weather/Mesoscale Modeling The main use would be in superTime lapse and stereo

software, hardware and communication costs.

imposing satellite and radar images on model output.

displays will be very important in utilizing the capability of raster graphics2.

An immediate requirement is for graphics tools to generate publication quality graphics. To be really efficient, the scientist will have to generate Then the

these displays interactively until the desired result is obtained.

final result would be output on microfilm or paper on a high quality system at the large facility. 6. Real-time data processing.

Weather forecasting and mesoscale modeling research to meet the national goals is intermittently linked to the four dimensional observed datasets.

Satellite and radar data are the most voluminous with basic data on 5 km grids over 2,000 km square domains at 15 minute intervals with ten observed or derived values per point. Routine observations including twelve surface

parameters every 70 km every hour and 100 rawinsonde parameters every 300 km every twelve hours with four times as much data during intensive programs. Real time data processing is important to the research community because it breaks the data handling problem into three steps, each of which is huge but manageable: a. b. c. routine real-time processing intensive program collection and processing periods post-event experimental analysis

Weather/Mesoscale Modeling

3.30

Conference Recommendations

The first step is taken by a number of universities and many other laboratories. The second step is taken by a few universities and several laboraUnless these steps are taken some-

tories on a national or regional basis.

where, the third step cannot be done in the timely manner we require. In conclusion, this report deals with a focused portion of atmospheric prediction and mesoscale modeling. Requirements for air quality modeling and

basic studies in routine 4-D assimilation for other user groups such as aviation meteorology, addressed. mesoclimatology and solar or wind energies have not been

Therefore, the estimate of 1/2 CRAY-1, 40 scientists, 20 institu-

tions is for only the highest priority research and is low by a factor of at least two.

Conference Recommendations

3.31
OERAlL WORKSOP SUIMARY

Overall Worksh~op Summary

Dr.

Kreitzberg summarized the conference.

He said he was impressed by the

magnitude of the requirements, these requirements.

and believes that the science does justify

If this is true, the computer power will be forthcoming. Computing costs

There will be the need for the equivalent of 4 or 5 Crays. would be on the order of $30 million/year.

Scientists doing research using With a 10-20% To a

these computers will require about $30 million/year also.

increase in efficiency, there could be a savings of $6-12 million. large extent, this is the challenge to the SCD.

It is important that the Substantial burWe will be operat-

planning be undertaken in the SCD for improved efficiency. dens will be placed on the SCD for guidance and learning. ing with the power of 4-5 Crays definitely, but it will be before we will acquire that capacity.

is unknown how long it

Dr. Kreitzberg stated that he

was very much impressed by the planning docunent put out by the SCD staff, and that it lenges. was extremely important to get started on work to meet the chal-

Response

3.32
RESPONSE TO COWERECE REC

Conference Recommendations
ENDTIONS

by Walter M. Macintyre The development priorities determined by the workshops do not differ substantially from those in the draft planning document. The differences are a

matter of emphasis more than of disagreement with the basic needs specified in the draft. NCAR has always prided itself on making available to its user The

community the most advanced scientific computing capability available.

principle message from this conference is that we must maintain this tradition. Furthermore, the growth in computing power and capacity required is

very much larger than the estimates made in recent years without the benefit of direct user input. It is the intention of the SCD management to press for

the provision of the computing power and capacity developed by the workshops. NCAR, and the atmospheric science community, would be very poorly served by any other policy. The hardware, software and other services required by the atmospheric science community will require a corresponding real increase in the level of funding of the SCD. I trust that the SCD management can count on the support of the

community in its effort to acquire that funding. The following specific developments can be anticipated. 1. Funding has been requested to replace the CDC 7600 in FY83 with another vector machine. 2. Funding has been requested to replace the Ampex TBM with a new mass store in FY83. The new mass store will have considerably enhanced capa-

Conference Recommendations city as compared with the TBM. 3.

3.33

Response

Steady improvement of interactive capabilities,

including vector graphA

ics, will become apparent as the new front end system is developed.

further consequence of the arrival of the IBM 4341 will be the development of a more powerful and reliable file system. Ultimately this new

file system will be in use on the mass store also, eliminating the problems inherent in the current system. 4. Discussions with commercial networks are underway with the objective of improving digital communications for the user community. Currently

there is difficulty in accommodating both synchronous and asynchronous communications in this way, but there are grounds for believing that

such a combined service could be available (at a price!) by the end of 1981. 5. Software needs are clearly recognized. Local development of software

not commercially available is severely hampered by current staffing levels in SCD, particularly in User Services. We will continue to purchase

software to meet our needs whenever possible. Finally, I would like to thank personally all of the members of the community who took the time and the trouble to travel to Boulder for the meeting. look forward to your participation next year as well. We