Concept Study Report (236K)

To download the whole report in pdf format (236K), click here.

(pdf files are read with the free program "Adobe Acrobat", which can be found at Adobe's web site.

T. W. Hill ; Rice University

F. R. Toffoletto ; Rice University

M. A. Heinemann; Phillips Laboratory

G. M. Erickson ; Boston University

Final Project Report for NSF Grant ATM-9704563. May 4, 1998

CONTENTS

EXECUTIVE SUMMARY 1

Acknowledgments

INTRODUCTION 3

Background 3

Three-Phase Implementation Plan 4

Summary Results of Community Survey 4

GGCM SCIENCE 6

Underlying GEM Objectives 6

Science Motivations for a Modular-Progressive GGCM 7

Operational Advantages of a Modular-Progressive GGCM 9

THE MODULAR-PROGRESSIVE APPROACH 12

Concept Definition 12

Code Structure 14

CODE FEASIBILITY AND DESIGN 17

Boundaries 17

Numerical Considerations 18

A Prototype GGCM 22

GGCM-COMMUNITY INTERACTIONS 28

Development/Operations Center 28

Module Development Grants 31

Oversight 32

Rules of the Road 33

TIME AND COST ESTIMATE 34

Development Time 34

Development and Operations Cost 35

CONCLUSIONS AND RECOMMENDATIONS 37

Conclusions 37

Recommendations 38

REFERENCES 40

APPENDIX: Detailed Results of Community Survey 49

Questionaire

Survey Results

Table of Contents Next SubSection > Next Section >

The Geospace Environment Modeling (GEM) Program, supported by the Magnetospheric Physics Program office of the National Science Foundation (NSF), is dedicated to the construction of a Geospace General Circulation Model (GGCM), a numerical research model that will test and advance our understanding of geospace dynamics, and will ultimately codify that understanding for the purpose of operational space environment forecasting. Three concept studies were commissioned in May 1997 to examine three possible approaches to future GGCM development and implementation. The study reported here focuses on a fully modular programming approach that we call modular-progressive – modular because the geospace system is divided for numerical modeling purposes into a set of discrete but mutually interacting numerical modules, each representing either a physical domain or a boundary between domains, and progressive because the system is designed to be adaptable to new physical insights, numerical techniques, and computer architectures as they become available.

The first step in our study was to conduct a survey of the GEM research community. The results of this survey confirmed the guidance received from the founders of the GEM program in two important respects: the GGCM must be global in scope, extending from the upstream solar wind to the conducting layers of the atmosphere, and it must be flexible, able to incorporate a wide variety of physical hypotheses as well as empirical data. Both of these attributes are included, by design, in the modular-progressive approach. A review of the fundamental scientific questions that a GGCM is expected to address reveals that most are amenable to a modular-progressive approach, and many appear to require such an approach.

A modular-progressive GGCM code requires three program elements: a collection of independently developed science modules, a control program to provide coupling among the modules and to orchestrate their simultaneous operation, and a user interface program to provide easy GGCM access to the GEM research community. We have provisionally identified an optimum set of five regional "domain" modules (magnetosheath, tail lobes, plasma sheet, ring current, and ionosphere) and a corresponding set of seven "boundary" modules (magnetopause, plasma-sheet boundary layer, tail-dipole transition region, ring-current field lines, cusp/boundary layer, polar-cap field lines, and plasma sheet field lines). Thus each domain module is coupled through a boundary module to each of its immediate neighbors as well as to the ionosphere. The boundary modules provide the mechanism not only for numerical coupling between adjacent domains but also for explicit simulation of boundary physics that is not resolved spatially or temporally by the domain modules or by the control program. For each module type we have identified at least two, and in some cases many, candidates from the published literature – existing independent models that could, with some further work, be cast in the form of modules suitable for inclusion in the modular GGCM. Thus a modular-progressive GGCM can generate a large variety of physically distinct, globally coupled geospace models within a single computational framework. This opens the possibility of controlled numerical experiments in which a single algorithm or a single parameter can be varied in a controlled fashion from one computer run to the next. This would provide an invaluable tool for unraveling the chain of cause and effect in the complex, nonlinear geospace system.

We recommend that a GGCM Development/Operations Center be set up to carry out the work of developing a control program and user-interface program, and establishing a uniform set of boundary-condition protocols for each module type. An early step in this process should be a series of workshops open to the community of potential users, to choose among various options that will affect code design. These options include the choice of an optimum set of domain and boundary module types, the content and protocol of boundary conditions for each module type, the choice of a numerical storage strategy for the control program (basis-function representations versus grids of various types), and the desired format of input and output data streams. The result of these workshops should be a set of specifications to guide the code development effort.

We estimate that the development and validation of a working modular GGCM can be accomplished in three years, including the initial workshop-mediated design phase, by a properly staffed and funded development center. We estimate the required staff to be of the order of two full-time scientific programmers, including at least one computational physicist, together with a part-time senior scientist overseeing and managing the development activity. We estimate the required funding for this center to be of the order of $400K/yr if full salaries and 50% overhead are charged. If a cooperating government laboratory were to contribute staff salaries and waive overhead, the incremental cost of GGCM center operation could be as low as the order of $60K/yr. A similar level of effort would probably be required after the development phase to maintain, operate, and upgrade the code and train others in its use.

We also recommend that a similar level of effort be devoted to module development by the GEM research community through peer-reviewed research grants. Broad-based community involvement in GGCM development and use is a good thing, both scientifically and programmatically, and the modular-progressive approach is an ideal vehicle for promoting such involvement.

Acknowledgments –

< Previous Subsection Table of Contents Next Subsection >

We are grateful to the GEM program management and the GGCM Steering Committee for their energetic efforts to initiate development of a full-scale GGCM, and for allowing us to be a part of that effort. We thank Dick Wolf for his critical reading of our draft and for his insightful suggestions and comments. This study was supported by the GEM Program under NSF Grant ATM-9704563.

Authors –

INTRODUCTION

Background

< Previous Section < Previous Subsection Table of Contents Next Subsection > Next Section >

The objective of the NSF Geospace Environment Modeling (GEM) program is to advance our scientific understanding of the dynamics of the complex, globally coupled geospace system comprising the magnetosheath, the magnetosphere, and the ionosphere/thermosphere. The Geospace General Circulation Model (GGCM) is envisioned as a mechanism both for obtaining this advanced understanding and also for codifying that understanding, once obtained, for use in space-weather forecasting and public education purposes. These three functions (research, forecasting and education) are equally important in the long run, but the second and third depend on the first: a model that does not get the physics right will have negative, if any, impact on forecasting and education. Thus, the GGCM must be designed from the outset as a research tool, but with one eye on future applications as a forecasting and education tool.

Research tools exist to test and refine hypotheses. The GGCM must be an unusually versatile research tool because it must simultaneously test and refine a wide variety of different hypotheses applied to different components of a complex, tightly coupled nonlinear system. There are fundamental unanswered questions about the dynamics even of individual geospace regions, let alone the coupled behavior of the whole system. These questions have been enumerated elsewhere (for example, in the GGCM planning document on which this study is based [Wolf et al., 1996]), and will not be repeated here. The important point is that the GGCM must accommodate a wide variety of disparate physical processes and hypotheses, some of which may not even have been formulated yet. No single scientist or co-located research group possesses all the expertise and insight that are needed to achieve a predictive understanding of geospace dynamics. By the same token, no single numerical algorithm, however sophisticated, can be expected to do the whole job. Thus the GGCM enterprise was conceived as a distributed, community-based effort requiring, therefore, a modular numerical-modeling approach.

It was originally envisioned [Roederer, 1988] that the assembly of a GGCM would be undertaken in the final stages of the GEM program, to codify the results of the preceding series of region-specific research campaigns. It soon became apparent, however, that even a rudimentary GGCM could provide a powerful tool to accelerate the progress of ongoing GEM campaigns. Thus, a GGCM working group was set up in late 1992, and was elevated to "campaign" status in late 1995 to run in parallel with ongoing and future region-specific campaigns. This GGCM campaign has fostered exploratory collaborative efforts between individual research groups (e.g., embedding the Rice Convection Model in the Dartmouth/Goddard/NRL global MHD code [Lyon et al., 1995], and coupling the Birn-Hesse 3D magnetotail MHD model to the Rice Convection Model [Toffoletto et al., 1996]), and has also taken on the larger task of guiding the development of a full-scale GGCM during, rather than after, the completion of the region-specific GEM research campaigns. Community-wide discussions at the 1995 and 1996 GEM Summer Workshops at Snowmass, CO, revealed a broad consensus that the time was right to pursue GGCM development in earnest. There was little consensus, however, on the computational form that such a GGCM should take, and in particular, the extent to which it should be modularized. The result of these community-wide discussions was a GGCM planning document [Wolf et al., 1996] that laid out the motivations and requirements for rapid deployment of a research GGCM, and called for rapid concept studies to explore alternative code structures.

Three such concept studies were funded in May, 1997. The present document is the final report for one of these studies (NSF Grant ATM-9704563) conducted at Rice University (T. W. Hill, PI) to examine the fully-modular end of the spectrum of possible code structures. Another study at Dartmouth College (J. G. Lyon, PI) has focused on the opposite end of the spectrum, in which a large-scale magnetohydrodynamic (MHD) code provides a global computational "spine", and non-MHD effects ("modules") are incorporated either as effective transport coefficients in the fluid equations, or as test particles, or as explicit over-rides of the MHD variables. The third concept study, conducted at TRW-Colorado Springs (A. E. Ronn, PI), has addressed the important issue of data-stream management, irrespective of scientific code structure.

Three-Phase Implementation Plan

< Previous Section < Previous Subsection Table of Contents Next Subsection > Next Section >

Further discussions at the Summer 1997 Snowmass GEM workshop produced an apparent consensus in favor of a three-phase GGCM implementation plan, in which the first two phases exploit existing models and the third phase comprises the planned development of a fully-coupled GGCM. Phase 1 will provide a catalog of numerical and graphical results from existing research codes for a prescribed set of representative inputs, available by Internet and/or CD-ROM to the GEM research community. Phase 2 will provide to the GEM research community the capability to run existing research codes for user-specified inputs that are not in the existing catalog. Phase 3 encompasses the development of the fully coupled GGCM. The three-phase plan is further described by Wolf and Hesse [1997].

The present concept study relates to Phase 3 of GGCM development under this three-phase plan. It is worth noting, however, that the modular-progressive approach that we discuss herein is well suited to the three-phase plan that has been adopted. The success of a modular GGCM depends on the availability of reliable stand-alone science modules, and the planned Phase 1 and 2 efforts will, among other things, accelerate the development and validation of suitable science modules.

Summary Results of Community Survey

< Previous Section < Previous Subsection Table of Contents Next Subsection > Next Section >

The first step of our concept study was to survey the needs and opinions of the GEM research community, both to validate and to expand upon the guidance provided in the GGCM planning document [Wolf et al., 1996]. In consultation with the other two study groups, we devised and conducted a World-Wide-Web survey with an announcement in the GEM Messenger email newsletter. The same survey form was circulated in hard copy at the Summer 1997 GEM workshop. We were encouraged by the strong response (63 individuals) and by the fact that the response statistics did not change noticeably when the 27 responses from the Summer workshop were added to the 36 pre-workshop responses. There is, if anything, a benign bias toward the opinions of those who are likely to actually use a GGCM, and who therefore took the time to fill out the form.

The Appendix includes the survey form and a graphical display of complete survey results. The survey results are confirmatory in that none of the GGCM attributes identified in the planning document were viewed as unimportant by a majority of respondents. The survey did, however, draw distinctions among these attributes; some are viewed as more important than others. A glance at the charts in the Appendix reveals that three GGCM attributes stand out in importance in the view of survey respondents:

Other desirable attributes (e.g., rigorous self-consistency, detailed code documentation, point-and-click user interface) were assigned a lower priority by survey respondents. Of these three paramount attributes, the first (global coverage) is equally attainable by either a modular-progressive or an MHD-spine approach. The other two attributes (flexibility and data assimilation) are included by design in a modular-progressive approach; their inclusion in an MHD-spine approach, though perhaps possible, is by no means automatic.

GGCM SCIENCE

Underlying GEM Objectives

< Previous Section < Previous Subection Table of Contents Next Subsection > Next Section >

The GGCM planning document [Wolf et al., 1996] presents an extensive, if not exhaustive, list of 41 hypotheses to be tested and 13 research challenges to be addressed by the GGCM. Most of these hypotheses and challenges fall under one of the following broad objectives of the GEM program:

These four general objectives can, in turn, be lumped under the even more general heading of

These overall goals should be kept constantly in mind during the development and operation of a GGCM. In thinking about the actual design of a GGCM code, however, it is equally necessary to look in some detail at the various specific research problems that will have to be addressed along the way to achieving the overall goals. The nature of the specific problem being addressed determines the type of numerical approach best suited to its solution.

Some problems clearly benefit from a global MHD simulation approach. A recent example is the explanation of the "sigmoid" shape of minimum-|B| contours observed near the magnetopause in a magnetotail cross section. This structure can be understood, in retrospect, as the necessary downstream signature of the antiparallel merging process at the high-latitude dayside magnetopause [Crooker, 1979], but it was first successfully simulated by the use of a global MHD code [Siscoe, 1997]. There are, no doubt, many other examples of problems in solar-wind/magnetosphere coupling that are amenable to a global MHD simulation approach. Our task here is not to enumerate them, but simply to acknowledge that they exist. Thus, a modular-progressive GGCM should not be viewed as a replacement for the global MHD simulation procedure, but rather as a complement to that procedure.

There is another class of problems, involving non-MHD effects, that may be addressable equally well through a modified MHD simulation approach or a more fully modular approach. The following list from the GGCM planning document update [Wolf and Hesse, 1997] serves to illustrate this class of problem:

Many of these effects can plausibly be included in a suitably-modified global MHD code, either by devising effective fluid transport coefficients or source/loss terms (e.g., magnetopause transfer processes, charge-exchange loss, pitch-angle scattering), or by the introduction of test particles that do not, by definition, affect the background electric and magnetic fields (e.g., radiation belts, plasmasphere, acceleration of auroral electrons and ionospheric ions), or by the introduction of appropriate boundary conditions (e.g., ionosphere and thermosphere).

There is, however, another class of fundamental magnetospheric research problems that would require explicit over-riding of the global MHD variables in certain regions of space. In other words, they require a modular numerical-modeling approach.

Science Motivations for a Modular-Progressive GGCM

<Previous Section < Previous Subsection Table of Contents Next Subsection > Next Section >

Many of the most fundamental unsolved problems in geospace dynamics will benefit from, if indeed they do not require, an explicitly modular computational approach. The following list is illustrative but not exhaustive.

•Global consequences of different hypotheses on location, geometry, and microphysics of magnetopause and magnetotail merging. In a global MHD simulation, magnetic merging at the magnetopause results from discretization (numerical noise) or from the use of non-linear switches in the code. Likewise, magnetotail merging in an MHD simulation results either from discretization or from the explicit inclusion of ohmic resistivity. The numerical resistivity cannot simply be turned off without violating conservation laws or sacrificing the numerical stability of the code. Estimates of an effective ohmic resistivity (or viscosity) may be available from independent microphysics calculations, but unless the grid resolution of the MHD simulation approaches the lengthscale of the responsible microphysics, merging and transport will still be dominated by numerical resistivity. Thus an MHD code will inevitably make a particular prediction on the geometry and strength of magnetic merging, a prediction that depends on the numerical method employed rather than on any physical considerations. By contrast, a modular-progressive approach enables one to specify on physical grounds the location, geometry, and rate of magnetic merging, either as a boundary condition or as a computed result from a microphysics module. This permits investigation of the global consequences of different hypotheses about the geometry and microphysics of merging at the magnetopause and in the tail. This capability is essential for testing at least 14 of the 41 sample hypotheses listed by Wolf et al. [1996] in the GGCM planning document (H1-12 and H40-41 on their list), and for addressing at least three of their 13 research challenges (C1-2, C5).

•Magnetospheric closure of Birkeland currents. The generation mechanisms and closure paths of the major Birkeland-current systems is another wide class of problems that requires a modular-progressive approach for its solution. In the case of the Birkeland currents that occur on open magnetic field lines (the "cusp", "mantle", and "NBZ" currents and probably the dayside portion of Region 1), the current closure paths and generation mechanisms are intimately related to the geometry of the open magnetosphere. As noted above, the open geometry is a byproduct of the numerical procedure in a global MHD simulation but is a controllable physical input (or output) in a modular-progressive approach. The Birkeland currents that flow on closed field lines (Region 2 and probably the nightside portion of Region 1) are also problematical in global MHD simulations, for different reasons. For example, Region-2 currents are typically unrealistically weak in MHD simulations. It is unclear whether this failure results from inadequate spatial resolution, or from the neglect of non-MHD particle drifts, or from a combination of these factors. Accurate representation of Region-2 Birkeland currents is critical for calculation of near-Earth drift paths, ionospheric potentials, and any scientific or space-weather application that depends on the near-Earth plasma/field configuration. Efforts are underway to incorporate the inner-magnetospheric drift physics of the Rice Convection Model (RCM) within a global MHD code, and these efforts should ultimately improve the code's performance with respect to the generation of Region-2 currents. An explicitly modular approach is likely to be required, however, to investigate and understand the intricacies of Birkeland current generation and closure. This capability is essential for testing at least three of the 41 sample hypotheses of Wolf et al. [1996] (H13-15) and for addressing at least one of their 13 research challenges (C3).

•Global consequences of finite gyroradius effects. Finite-gyroradius effects (or finite Larmor-radius (FLR) effects) are thought to be responsible for a significant fraction (~ 1 MA) of the Birkeland current flowing within the plasma-sheet boundary layer (PSBL) [Heinemann and Erickson, 1997] and perhaps also the low-latitude boundary layer (LLBL) [Wei et al., 1996]. The magnitude and global consequences of such effects in other thin magnetospheric boundary regions (e.g., magnetopause, plasma-sheet inner edge, ring-current drift boundaries, auroral arcs, the thinned, pre-onset plasma sheet) are unknown but potentially important. Finite gyroradius effects are excluded by definition in ideal MHD and are not easily incorporated within a global MHD code because they are, at least in part, dispersive rather than diffusive, and highly sensitive to the local magnetic geometry. A modular-progressive approach provides a natural avenue for investigation of these important microphysical effects and of their global consequences. This capability is essential for testing at least four of the 41 hypotheses of Wolf et al. [1996] (H11-12, H27, H41), and for addressing at least two of their 13 research challenges (C2, C5).

•Global consequences of different substorm onset hypotheses. There are many competing hypotheses for the physical cause of substorm onset, some involving explicitly non-MHD effects. Many of these hypotheses have been developed in sufficient detail to provide quantitative predictive schemes suitable for inclusion in one or more regional modules of a modular-progressive GGCM. Some (but not all) could also in principle be incorporated within a global MHD framework, but only with considerable programming effort on a case-by-case basis. As noted above, magnetotail merging occurs in global MHD models by virtue of either numerical noise or artificially imposed ohmic resistivity, with no obvious connection to the various physical onset mechanisms that have been proposed. A modular-progressive approach, by contrast, is capable of incorporating any substorm onset scenario that has been reduced to a predictive algorithm or regional simulation, and to investigate its global observable consequences. This capability is essential for testing at least 16 of the 41 sample hypotheses listed by Wolf et al. [1996] (H16-31) and for addressing at least five of their 13 research challenges (C4-8).

•Competition between ionospheric and solar-wind sources of magnetospheric plasma. Both the ionosphere and the solar wind are known to provide important sources of magnetospheric plasma. These sources are not independent; for example, the upwelling of ionospheric ions in the dayside "cleft ion fountain" and in the nightside auroral zone respond to both particle and energy inputs from the solar wind. The relative importance of the two sources is clearly a function of position as well as of magnetospheric activity. In addition, there are two potential mechanisms for solar-wind particle entry into the plasma sheet, direct field-aligned flow along open magnetic field lines coupled with E¥B drift through the mantle and tail lobes, and diffusion (turbulent or otherwise) across a low-latitude boundary layer onto closed field lines. Both the direct access route along open field lines, and the cross-field diffusion, are excluded by assumption from ideal MHD, and are included in a global MHD simulation only by virtue of numerical noise. The ionospheric source is also difficult to incorporate within a global MHD code because of the long time scale for equilibration along flux tubes. The problem of incorporating realistic plasma sources within the GGCM is greatly facilitated by the modular-progressive approach in which the physics of particle transport across boundaries and along flux tubes can be handled explicitly within regional or boundary modules. This capability is essential for testing at least four of the 41 sample hypotheses listed by Wolf et al. [1996] (H36-39) and for addressing at least four of their 13 research challenges (C10-13).

Of the 41 sample hypotheses listed in the GGCM planning document [Wolf et al., 1996], 37 (90%) have been cited above as either suggesting or requiring an explicitly modular approach to numerical modeling. Similarly, 12 of the 13 "research challenges" (92%) have been so cited. Even if we are only half right in our appraisal of these hypotheses and challenges, it is clear that a significant fraction of GGCM science will not be adequately addressed without an explicitly modular approach.

Operational Advantages of a Modular-Progressive GGCM

< Previous Section < Previous Subsection Table of Contents Next Subsection > Next Section >

Aside from the nature of the specific questions to be addressed, there are three general features of a modular-progressive approach that may be critical to the scientific success of the GGCM program.

•Inclusiveness. By definition, the modular-progressive design is an inclusive approach to GGCM development that supports, indeed requires, the participation of a broad segment of the GEM research community. The complexity of the code structure is designed to emulate the complexity of the geospace system itself. Thus, important insights about auroral field-line dynamics may come from one research effort (represented by one module) while important insights about magnetotail dynamics come from another research effort (represented by another module), and further new insight may result from the coupling of the two different modules within a global context. Even for a given region or a given boundary there are typically multiple competing hypotheses, none of which can be ruled out on physical grounds until they have been tested side by side in a modular GGCM environment.

Inclusiveness is important for two reasons: (1) by casting a wider net, one is more likely to find the right answers (and to understand why the wrong answers are wrong), and (2) by enlisting the skills and insights of a greater number of researchers, one is more likely, not only to find the right answers, but also to retain the enthusiastic support of the GEM research community, without which the GGCM program would quickly stagnate.

•Flexibility for numerical experimentation. Extensive computer experimentation is needed to unravel many of the cause-and-effect relationships in the complex geospace system. The modular-progressive approach makes it possible to focus on specific, limited physics questions such as "What is the effect of plasma-sheet temperature on inner-magnetospheric electric fields?", or "How does the density of the plasma mantle affect the plasma sheet?". Such questions are amenable to controlled computer experiments in which a specific part of geospace, comprising perhaps just a few of the available GGCM modules, is probed by repeated computer runs with controlled variations of the input parameters.

It is exceedingly unlikely that any GGCM, regardless of its code structure, will give all the right answers on the first try. A modular progressive structure provides maximum flexibility for diagnosing and fixing the weak points both in the physics and in the numerics.

•Capacity for data assimilation. The ability to assimilate observational data and empirical models is essential not only to the scientific use of the GGCM but also to its future applications in an operational forecast setting. Data assimilation implies more than a brute-force overriding of computed results by observed results. Ideally, it involves nudging the code in the right direction without upsetting the flow of the calculation. We identify three promising strategies for accomplishing this objective:

(1) Substitution of an empirical algorithm for a theoretical one in one or more of the regional or boundary modules. This is possible, by design, in the modular-progressive approach defined below. In a global MHD simulation approach, it would require bifurcating the simulation domain and inserting the empirically-determined domain, with newly-formulated boundary conditions on the simulation at the new boundaries thus created. In other words, it would require the modular-progressive approach defined below.

(2) Insertion of key observed parameters at strategic places and times. A classic example is the location of the polar-cap boundary, the ionospheric footprint of the separator surface between open and closed magnetic field lines (give or take a few degrees of geomagnetic latitude depending on one's interpretation). Experience with the Magnetospheric Specification Model [Bales et al., 1993] shows that run-time adjustments of this more-or-less readily observable boundary location go a long way toward keeping a global simulation model in touch with reality. This flexibility would be retained in the modular-progressive approach defined below. Such run-time corrections are problematical in a global MHD simulation model because they launch artificial waves that can affect the results in unpredictable and unphysical ways.

(3) Global incorporation of observational data. For some scientific applications, and for all operational space-weather applications, it is more important for the GGCM to stay close to the right answer, with respect to the global time-dependent plasma-field configuration, than to maintain rigorous mathematical self-consistency. Any numerical simulation of the magnetosphere, no matter how completely it may include the relevant physics, is subject to the inherent sensitivity of nonlinear differential equations to the details of the initial conditions, and the inherent observational uncertainties in the specification of those initial conditions. It is thus appropriate, if not essential, to allow for global-scale empirical corrections of computed results in time-dependent GGCM simulations.

Such empirical "nudging" (rhymes with "fudging") is commonplace in tropospheric weather forecasting models [Ghil and Malanotte-Rizzoli, 1991], but is largely untested in geospace modeling. The only example of which we are aware is the recent attempt to ingest geosynchronous electron flux observations into the Magnetospheric Specification Model [Garner et al., 1998], which propagates given particle distributions through the inner magnetosphere under the influence of given electric and magnetic fields. The consequences of data ingestion will undoubtedly become more profound when it is tried in a more self-consistent context, like that envisioned for the GGCM, where ingested particle data will influence the electric and magnetic field structure (or vice-versa). The task will be to make these consequences profoundly physical rather than profoundly artificial.

Some useful lessons may be learned from recent attempts to embed a particle drift algorithm based on the Rice Convection Model within a global MHD simulation code [Lyon et al., 1995; Toffoletto et al., 1997]. Here, the inner-magnetospheric pressure computed by the MHD simulation is overridden at each time step by the pressure computed in the MHD fields by the more detailed RCM drift algorithm. The "data" being ingested by the MHD code are, in these cases, generated by the embedded RCM code rather than by observations, but their effect on the overlying MHD code is analogous to the effect of observational data assimilation. In the cases cited above, the correction applied at each time step is a small fraction (few percent) of the quantity itself. It remains to be seen how large a correction can be accommodated by a global MHD code without introducing intolerable levels of artificial waves in the MHD solution.

In a modular GGCM code, the artificial waves induced by data assimilation would be limited to, at most, the adjacent regional modules, and could be suppressed altogether by the use of quasistatic regional modules. Moreover, the use of a basis-function representation of global fields in place of a grid-based representation, as described below, may provide a more graceful way of incorporating observational data into a computed solution.

THE MODULAR-PROGRESSIVE APPROACH

< Previous Section < Previous Subsection Table of Contents Next Subsection > Next Section >

Concept Definition

Geospace has a cellular structure, that is, it contains a number of distinct physical domains of large volume delineated by mutual boundaries having relatively small, albeit finite, volume. The domains are distinguishable by the physical parameters and processes that govern their dynamics. For example, the magnetosheath is largely governed by the equations of ideal MHD, while the ionosphere is governed largely by the collisional coupling between ions and neutrals. If the boundaries between domains were fixed and passive, the problem of geospace environment modeling would be reducible to a small set of much simpler (but still challenging) problems focusing on individual domains, with suitably-chosen boundary conditions representing the coupling to adjacent domains. This is the mode in which geospace modeling has largely progressed in the past; indeed such studies have laid the foundation for the proposed GGCM effort. Among many other insights, the application of these regional studies has shown that the boundaries between domains are neither fixed nor passive. Not only does the magnetosheath influence the ionosphere, but also vice-versa, and the locus of their mutual boundary (the cusp/boundary layer field lines) influences and is influenced by their mutual interaction. The behavior of the whole system is more than the linear sum of the behavior of its constituent parts. This is why a GGCM is needed for further progress in geospace modeling, and this is the central fact that must be taken into account explicitly and directly in the design of the GGCM.

Thus we have based our study of GGCM development on an approach that we call modular-progressive. It is modular in that the geospace system is divided, for modeling purposes, into a set of discrete but mutually interacting "modules", each of which represents either a distinct physical domain or a boundary between domains. It is progressive in that it is deliberately designed to evolve with time to accommodate new insights and techniques that cannot be foreseen at the time of its initial design. A modular-progressive approach is suggested, if not dictated, by the ambitious design requirements of precision, reliability, efficiency, flexibility, and user-friendliness that must characterize a successful GGCM.

Thus, the modular-progressive GGCM approach is based on the explicit division of geospace into a number of separate physical domains bounded by a suitable number of inter-domain boundaries. If there are n domains, then there are in principle n(n-1)/2 inter-domain boundaries, although some of these can perhaps be eliminated from consideration on topological or physical grounds. The key to the modular-progressive approach is to treat each physical domain and each inter-domain boundary as a separate program module within the GGCM numerical framework. The various modules are not required (nor expected) to be similar in size or structure, but they are logically equivalent program "objects" insofar as the GGCM control program is concerned. The control program is essentially a network that transfers data among the various modules and controls their execution.

The concept is illustrated in Figure 1, where we have divided geospace into five spatial domains: (1) magnetosheath, (2) magnetotail lobes, (3) magnetotail plasma sheet, (4) inner magnetosphere/ring current, and (5) ionosphere/thermosphere. Corresponding to these five domains are seven physically relevant inter-domain boundaries: (a) the magnetopause, connecting domains 1 and 2, (b) the plasma-sheet boundary layer, connecting domains 2 and 3, (c) the

magnetotail-dipole transition region, connecting domains 3 and 4, (d) the ring-current field lines, connecting domains 4 and 5, (e) the cusp and boundary layer, connecting domains 1 and 5, (f) the polar-cap field lines, connecting domains 2 and 5, and (g) the plasma-sheet field lines, connecting domains 3 and 5. Note that, of the ten boundaries that are possible in principle among these five domains, three have been eliminated on physical grounds, i.e., it has been assumed that the magnetosheath domain (1) interacts with the plasma sheet (3) and ring current (4) domains only through their mutual interactions with the intervening open field-line domain (2), and that the open-field domain (2) interacts with the inner-magnetosphere domain (4) only through the intervening plasma-sheet domain (3). The rule of thumb is that each domain interacts with its immediate neighbor(s) and with the ionosphere/thermosphere domain (5), which is the "glue" that binds the whole system together [Siscoe, 1991]. The parameters of the upstream solar wind and of the lower atmosphere are treated as input parameters, determined outside the scope of the GGCM model.

Code Structure

< Previous Section < Previous Subsection Table of Contents Next Subsection > Next Section >

A modular-progressive GGCM code requires three types of program element: a control program, a set of science modules (perhaps a dozen, as in the above example), and a user interface program. The bottom half of Figure 1 illustrates the logical GGCM code structure associated with the particular compartmentalization of geospace shown in the top half. Spatial regions ("domain modules") are indicated by numbers and their physically relevant mutual boundaries ("boundary modules") are indicated by letters, corresponding to the above designation. There are, in all, twelve program modules, including five domain modules and seven boundary modules. It is essential that the inter-domain boundaries be treated as logically equivalent to the domains themselves. These boundary modules provide not only a mechanism for explicit modeling of boundary physics, but also an orderly protocol for the transfer of boundary conditions between physical domains. The particular compartmentalization shown in Figure 1 is preliminary and is subject to revision during the course of the code development. The important point is that both the domains and their mutual boundaries are treated as independent modules.

The GGCM control program is not illustrated in Figure 1 because it lies in the third dimension. It is, however, easy to describe; it has direct links to each of the twelve science modules and it is responsible for the simultaneous execution of these modules and for the interchange of data among them. As noted above, it is neither required nor expected that each module will be of similar size in terms of physics content or in terms of computer processing requirements. Some modules, for example, may contain empirical rather than theoretical algorithms. It is, however, a critical feature of the modular-progressive GGCM approach that each module, whether it represents a domain or a boundary, be treated logically as a separate and hence interchangeable unit.

Control Program. The first thing the control program must do is to activate the user interface program to obtain needed inputs and options. It must then assemble the appropriate subroutines (science modules) from an established library, initialize the appropriate data arrays, and execute the appropriate science modules in parallel for the designated total time interval, while returning the requested output data to the user interface program at designated intervals. The data arrays will include the (time variable) boundary conditions that are shared by adjacent science modules. These boundary condition arrays are the only means of communication between different science modules, and they must be designed with careful attention to the direction of information flow as dictated by the form of the equations that are being solved within each adjacent module. In most cases, we must allow for information flow toward a boundary from both sides. In some cases a boundary science module will explicitly accommodate the information flowing toward it from both sides; for example, a magnetopause module would logically adjust the magnetopause position to equalize the pressures on the two sides, as provided by the magnetosheath module on one side and the tail lobe module on the other. In other cases it will be necessary to devise an interpolation scheme to accommodate the information flowing toward a boundary from both sides. The control program will keep track of the positions of all boundaries as well as the values of all relevant physical parameters on those boundaries.

The control program will update the boundary locations and variable arrays each control time step, namely, the smallest time step utilized by any of the science modules (which must be less than or equal to the requested time resolution of results reported to the user interface program). The time resolution required by various different science modules will probably differ from one to another, possibly by orders of magnitude, so it is important to design an "intelligent" control program that does not waste time updating a given data array unless it has been changed since the previous control time step by one of the science modules to which it is connected. For example, if one is studying MHD wave propagation effects in the cusp or in the auroral zone, having timescales of the order of a few seconds to a few minutes, one clearly does not need to update the Earth's dipole tilt at every time step.

Storage of boundary locations and variable values by the control program will require either a three-dimensional control grid or a set of basis functions with variable coefficients. The choice between these two information-storage techniques is a non-trivial one, and we devote a section to it below. In either case, the GGCM control program should be designed such that it is possible, but not mandatory, for a given science module to adopt the control grid or basis-function set as its internal computational grid or basis-function set. The control grid or basis-function set must continuously span the whole geospace region from the ionosphere to the upstream solar wind.

The control program must also provide for optional modes of GGCM execution (e.g., substitution of science modules, lumping together of adjacent modules, or deactivation of un-needed modules), as described further in a following section.

Science Modules. The actual physics calculations are carried out within the module subroutines. The design of these module algorithms is the responsibility of the individual module developer, but the GGCM design must provide adequate guidance and testing to ensure that each candidate module subroutine will actually work as intended within the overall GGCM structure. The physical variables that are calculated within each science module, and hence passed back and forth between that module and the control program, will depend on the module type. For example, a magnetosheath module would typically calculate, and hence require as input and generate as output, the first three moments of the plasma velocity distribution (density, flow velocity, and pressure) and the vector components of the magnetic field. (The electric field in this region would typically not be an independent variable but would be obtained from the ideal MHD approximation E + v¥B = 0.) A plasma-sheet boundary layer module would probably require, in addition to these, a separation between parallel and perpendicular pressures, and an inner magnetosphere/ring current module would probably divide the velocity distribution into several discrete energy steps, as in the Rice Convection Model [Wolf et al., 1991].

Thus, the boundary condition protocol may differ from one module type to another, but it must be standardized for each given module type. Each candidate magnetopause module, for example, must conform to a predetermined protocol for input and output of those parameters that are generally deemed important to magnetopause physics. It need not actually use or alter all of the supplied parameters, but it may not require or produce parameters that are not within the standardized set for that module type. A critical part of GGCM development will be to examine the physics of each domain and of each inter-domain boundary to determine a standard set of type-specific boundary conditions that is neither too restrictive (thus constraining the range of physics questions that the module type may reasonably be expected to address) nor too general (thus squandering the finite computing resources available). This will impose a burden both on the developers of the GGCM control program and on the developers of the candidate science modules. An important goal of GGCM development will be to maximize the share of this burden that falls on the control program development, which will only be done once (if it is done right), and to minimize the share that falls on the science module development, which will be done many times by many people (if the GGCM concept is to be successful).

The question of boundaries and boundary-condition protocols is further discussed in a separate section below.

User Interface Program. The GGCM is intended as a research tool available to all interested researchers. Thus a user-friendly interface is a critical element. The user interface program must perform three functions: (1) allow the user to specify which of several operational modes is desired, (2) prompt the user for required input data, and (3) provide the user with the requested output data in the requested format with the requested time resolution.

A separate section below deals with the menu of operational modes that should be made available in order to provide efficient, open use of the GGCM by the research community. The input data format obviously depends on the mode of operation, ranging from a single set of solar-wind and geomagnetic parameters for the specification of a static quasi-steady magnetospheric configuration, to a time series of such parameters, and perhaps also of empirical over-rides, for a time-dependent simulation. The format and frequency of output data should be left as flexible as possible, consistent with resource constraints, and should be established by the GGCM development/operation center with frequent input from the user community.

The World-Wide Web is the most obvious mechanism for user access to the GGCM, at least for "standard" access in which a quasi-static configuration is needed for a constant set of inputs. For time simulations, and especially for model runs involving non-standard modules, it may be more efficient to include human intervention in the process, which is one reason that a permanent GGCM development/operation center is needed, as described below.

CODE FEASIBILITY AND DESIGN

Boundaries

< Previous Section < Previous Subsection Table of Contents Next Subsection > Next Section >

One of the primary goals of GGCM development, strongly supported by the community survey (see Appendix), is to provide a community resource that enables model developers and users to easily incorporate new model algorithms into a global model. This means that users should be able to access and interface with the global model without having to first learn and conform to a predetermined numerical grid and computational scheme. Properly designed, a modular-progressive construction is ideally suited to meet this "flexibility" requirement.

The modular-progressive approach identifies physically distinct regions of geospace ("domain modules") and provides the mechanism for coupling them together. The coupling takes place within the "boundary modules". The boundary modules serve several purposes. At the simplest level, they serve as well defined transitions between distinct macroscopic physical domains. They also define the loci for information transfer between adjacent domains, thus providing for two-way feedback between regions. In addition, they provide sites for the insertion of microphysical boundary layer models. The boundaries themselves are not to be regarded as fixed, but as movable entities whose locations are determined by global constraints such as stress balance.

Communication across boundaries will be accomplished by stating boundary values on both sides of each boundary. For each boundary type, there will be a prescribed standard set of variables, with others available as a user option, and standardized protocols. The minimum set of variables to be specified at most boundaries would be the gyrotropic MHD variables: density, velocity, magnetic field, and parallel and perpendicular pressure. Some boundary types may require more information; for example, a ring-current module, which physically occupies the inner magnetosphere, may need to receive energy spectral information from the plasma sheet and provide it to the ionosphere. Dependent variables derivable from the minimum set can be provided as required, for example, the electric field from the ideal Ohm's law or the current density from Ampere's law (or from the Vasyliunas equation). In the case of passive boundary modules (those not occupied by actual microphysics algorithms), the GGCM control program must also be responsible for enforcing the continuity of the normal components of the magnetic field, mass flux, and current density and of the tangential components of the electric field across the boundary.

The location of each boundary, and the values of each variable along each boundary, will be tracked as functions of time by the control program and stored either in terms of basis functions or at points on a grid, as discussed in the following section. Irrespective of the numerical storage scheme that is adopted, it is first necessary to provide a precise physical definition of each boundary that can be translated unambiguously (and hence automatically) into a set of numbers. For some boundary types the definition is relatively simple; for example, the "top" of the ionosphere can be defined, for most geospace purposes, as a spherical shell at a fixed altitude (~500 km) above the surface. The magnetopause is somewhat more complicated (for example, it can move about in response to solar-wind pressure variations), but is still generally recognizable by a discontinuous change (on the global scale) of magnetic-field direction. The plasma-sheet boundary layer can be identified with the nightside topological boundary (separator surface) between open and closed magnetic field lines, which is straightforward to evaluate for a given field model. The plasma-sheet/ring-current boundary (called "tail-dipole transition region" in Figure 1) can be identified with the last closed drift shell circling the Earth, although the location of this shell depends on energy and pitch angle, so it will be necessary to assign representative values for these variables unless a given local boundary module tracks them explicitly. It each of the above cases, the two-dimensional surface so defined can be extended to a surrounding three-dimensional slab volume as required to accommodate explicit boundary physics modules. The remaining boundary modules labelled in Figure 1 (d, e, f, and g) are finite flux bundles of magnetic field lines that are readily defined for a given field model once the bounding regional modules are defined.

The existence of distinct regional domains, and of the corresponding network of inter-domain boundaries, is established by observations. However, the attempt to define these boundaries precisely, and to represent them numerically, is an enterprise of considerable subtlety and perhaps also some controversy. We therefore recommend that, if the decision is made to proceed with development of a modular-progressive GGCM, an early step in this process should be an open workshop where potential module developers could combine their expertise to devise a comprehensive, flexible, and as nearly as possible foolproof set of specifications and protocols for each boundary type (and indeed, as a first step, to decide if the set of boundaries listed in Figure 1 is the most appropriate set). The research community that will ultimately utilize the GGCM should thus play an active role in the earliest design phase, to insure that the GGCM will serve the needs for which it was intended.

Numerical Considerations

< Previous Section < Previous Subsection Table of Contents Next Subsection > Next Section >

The GGCM will be a large code. Although the modular-progressive approach makes it feasible to contemplate stripped-down versions for workstation research applications, it is still true that a fully global, time-dependent magnetospheric simulation is going to require a large numerical code regardless of the technique employed. The science computations will be performed within the modules, and will be the responsibility of the module developers. A variety of powerful numerical techniques have been developed by individual research groups over the past decade or two, and will no doubt be exploited in the development of GGCM modules. The linking together of these modules, however, is the responsibility of the central GGCM control program, and is itself a problem of non-trivial numerical proportions.

Computing speed is not a serious issue for the GGCM control program because the time-consuming calculations (e.g., solution of differential equations) takes place within the modules. Speed will be an issue for module developers, and may well be a decisive descriminating factor between competing algorithms for a given module, but it is unlikely to be a decisive factor in the development of the control program, which is essentially a smart data network.

Utilization of computer memory resources is, however, a serious issue for the GGCM control program because it must keep track of boundary positions, boundary values, and at least a summary form of global information on several vector and scalar fields, while leaving sufficient memory available for the various modules to do their work. A modular-progressive approach does provide some efficiency in memory utilization because the high-resolution calculations are performed in restricted regions rather than globally, but in order to exploit this efficiency it is important for the control program to make the most efficient possible use of its computer memory allocation.

The basic problem is to represent complicated three-dimensional continuous functions as faithfully as possible in terms of a finite sequence of numbers. There are two traditional approaches to this problem: (1) to store the values of the function itself at a finite set of predetermined points in space (i.e., a grid), and (2) to represent the function as a finite linear combination of predetermined basis functions and store the coefficients. Each approach has its advantages and disadvantages.

Grid-Based Approach. Storage of variables on a grid is the most familiar approach in global-scale magnetospheric modeling; for example, global MHD codes use this approach exclusively. The spatial resolution of the variables is determined both by the resolution of the grid and by the order of the finite differencing scheme. If a grid is used by the GGCM control program to store boundary locations and boundary values, it will be necessary to interpolate from this control grid to the numerical grids used by the various science modules, because the module grids will typically have much finer resolution than that of the control grid. (The opposite translation will be equally necessary but less problematic when going from a finer to a coarser grid.) Interpolating from a coarse grid to a fine grid can produce discontinuities of derivatives at the cell boundaries of the original grid, and can also cause violations of the governing equations. For example, a divergence-free magnetic field on the coarser grid may interpolate to a non-divergence-free field on the finer grid, and a plasma-field configuration that satisfies mass conservation, force balance, etc. on the coarse grid may fail to do so on the finer grid. The computational fluid dynamics (CFD) community has experience in the use of overlapping (Chimera) grids [e.g. Thompson et al, 1985, p. 69]. The use of such grids allows complex geometries to be modeled, but requires interpolating back and forth between grids. The consistency and conservation problems noted above are usually dealt with by iterative techniques [e.g., Zang and Street, 1995]. This is a complex and time-consuming technique, which may explain why the overlapping grid approach is not used very often [Ferziger and Peric, 1996, p. 28 and 206].

The text box on the next page provides an annotated glossary of various styles of numerical grids that are potentially applicable to a GGCM control grid, each with its own advantages and disadvantages. Regardless of the style of grid that is adopted, the overriding issue with any grid-based approach to GGCM bookkeeping will be interpolation between the disparate grids of the control program and the various modules.

Basis-Function Approach. The alternative to the use of a control grid is to express the functional form of all physical variables as a linear sum over a set of pre-selected basis functions that are designed to conform to the known geometrical properties of the system. These basis functions are analogous to eigenfunctions, but unlike eigenfunctions, they are not required to precisely satisfy a predetermined set of boundary conditions, and they do not necessarily form a complete orthogonal set. There are no existence proofs for this approach, which may require a great deal of trial and error to find the optimum form of the basis functions. Nevertheless, it provides a viable, tested alternative to a grid-based approach to the problem of efficient storage of global information on geospace variables.

A true eigenfunction expansion, using spherical harmonics, is practical for representing two-dimensional functions (e.g., electrostatic potential) on a spherical shell representing the ionosphere [e.g., Richmond, 1992, Weimer, 1995]. These functions, to the extent that they can be assumed to be constant along magnetic field lines (e.g. electrostatic potential in ideal MHD), can then be mapped upward into three-dimensional geospace if one has an independent 3-D model of the magnetic field configuration. This approach, though widely used, is not suitable for a GGCM control structure because (a) some variables cannot be assumed constant along B (e.g., electrostatic potential in the auroral acceleration region, or plasma density and pressure when the latter is not isotropic), and because (b) the 3-D magnetic field structure is not independently given but is itself one of the vector fields that must be represented numerically throughout geospace.

Glossary of Grid Styles (in Increasing Order of Complexity)

Grid Scheme	Advantages	Disadvantages
Cartesian grid Orthogonal with constant spacing; probably the simplest grid one can construct	Interpolation is simple and computationally inexpensive. The constant grid spacing prevents possible low-order truncation errors that can occur on a variable grid when the grid spacing changes rapidly between grid cells. However, this problem of rapidly changing grid spacing can be circumvented with the use of integral methods, such as finite element or finite volume methods [Fletcher, 1991]	Enormous storage requirements to achieve moderate resolution. Grid boundaries do not align with any natural geospace boundary. This approach is not widely used
Rectilinear grid Orthogonal with variable spacing in one or more of the coordinate directions. Utilized in the MHD codes of Ogino et al. [1994), Winglee [1994], and Raeder [1995].	Almost as simple and inexpensive to work with as a Cartesian grid, and can provide increased resolution in regions of interest and lower resolution in other regions, resulting in a moderate saving on storage requirements.	Large storage requirements, grid boundaries do not align with any natural geospace boundary. This is a popular approach, its main appeal being simplicity.
Curvilinear grid A structured grid that is topologically rectangular but is continuously distorted to match certain boundaries. This grid structure also allows the use of composite grids [Thompson et al., 1985, p. 56] so that the entire magnetosphere can be covered by several intersecting grids.	Grid lines can be made to approximately line up with natural boundaries (e.g., magnetopause, ionosphere) and grid spacing can be varied to concentrate on regions of interest [e.g., Fedder and Lyon, 1995, Toffoletto et al., 1994].	With the increased sophistication comes increased awkwardness and complexity of interpolation. Transformations from computational (grid-aligned) space to physical (x,y,z) space can be difficult and expensive. Metric singularities, where the coordinate system breaks down (e.g., the polar axis of a spherical grid) must be dealt with carefully. Interpolation on a curvilinear grid may not be as accurate as on a simple Cartesian grid. Curvilinear grids are also typically non-orthogonal, which requires the computation of a full metric. Highly skewed grids can lead to resolution difficulties in critical regions [e.g., Hoffman and Chang, 1993, p. 347]. Metric identities may not be exactly satisfied in three dimensions, resulting in spurious values when a gradient of a constant quantity is taken [e.g., Thompson et al., 1985, p. 158]. Nevertheless, this is a powerful approach when properly implemented.
Moving (Lagrangian) grid A system in which the grid boundaries move with one or more of the physical boundaries.	This approach could be ideally suited for a module that has a dynamic boundary, or a GGCM control grid that changes rapidly.	The computational overhead is likely to be considerable. Work is still in progress on the development of these methods [e.g, Oran and Boris, 1987; Shyy et al., 1996].
Cartesian-based hierarchical grid Cartesian grid whose cells can be subdivided indefinitely in regions of interest; utilized in the Univ. of Michigan MHD code [Gombosi et al., 1994].	Can be made arbitrarily fine in regions of physical interest and coarse in other regions, thus providing substantial savings in storage. The hierarchical structure allows the grid to change dynamically as the solution evolves.	The inherently rectangular boundaries do not generally line up with physical boundaries. The bookkeeping can be complex and expensive. Interpolation is necessary when refining the grid, with associated issues of consistency and conservation.
Unstructured grid Usually used with finite-element or finite-volume methods, this approach is becoming more commonplace in the computational fluid dynamics (CFD) community [e.g., Ferziger and Peric, 1996, p. 29].	The grid can be made arbitrarily fine in regions of interest and coarse in others. The inherently unstructured nature can be exploited to adjust and dynamically adapt to numerous different coordinate boundaries.	The price to be paid is that bookkeeping and grid generation can be extremely complex and expensive. The potential power of this approach for magnetospheric modeling is the subject of ongoing research [e.g., Klouek and Toffoletto, 1998].

It is possible to construct an almost-pure eigenfunction representation of the 3-D magnetosphere if the magnetopause is assumed to have a particularly simple form. For example, Voigt [1981] represents the magnetopause as a hemisphere on the dayside joined continuously to a semi-infinite circular cylinder on the nightside, and develops independent eigenfunction representations of the dayside magnetic field in terms of spherical harmonics and of the tail field in terms of cylindrical harmonics, with an interpolation scheme to smooth out the transition between the two representations. Alternatively, the magnetopause can be represented as a paraboloid of revolution and the internal field represented in terms of paraboloidal harmonics [Stern, 1985]. Although the pure eigenfunction approach is numerically efficient, it has a major shortcoming insofar as a GGCM control structure is concerned: the magnetopause shape cannot be adjusted to maintain pressure balance across it.

It is possible to eliminate these shortcomings by replacing the rigorously constrained eigenfunctions with a set of basis functions whose form still contains information about the global geometry of the system, but with less mathematical rigor (and hence more flexibility) than a pure eigenfunction expansion. This approach has been exploited by N. Tsyganenko in his highly successful series of empirical magnetospheric magnetic-field models [Tsyganenko, 1987, 1989, 1993, 1995]. The basis functions are chosen to represent the magnetic-field contributions associated with known magnetospheric current distributions (e.g., dipole, magnetopause, ring currents, and tail currents), and the expansion coefficients are determined by a multivariate least-squares fitting procedure to a very large set of satellite magnetometer data. The procedure could easily be adapted to a GGCM control structure, with the magnetic-field outputs of the various regional modules replacing the satellite magnetometer data. The result would be a smooth, analytical representation of the global magnetic field that has sufficient accuracy for global-level field-line tracing and for linkage between modules, while providing interpolation-free translation to an arbitrarily fine module grid. Although the technique has thus far only been applied to magnetic-field modeling, there is nothing in the procedure that precludes its application to other scalar and vector fields of interest [N. Tsyganenko, private communication, 1997].

The obvious advantage of the basis-function approach is that it provides continuous, analytic, differentiable and integrable functions on a global scale, while a grid-based approach provides these only piecewise within each grid cell by the use of sometimes awkward interpolation schemes. Corollary advantages include more precise enforcement of div(B) = 0, more efficient field-line tracing and field-line integrals, and more reliable specification of high-order derivatives, as may be required for the calculation of finite gyroradius effects in a low-latitude boundary-layer (LLBL) or a plasma-sheet boundary-layer (PSBL) module. However, the success of the basis-function representation depends sensitively on the right choice of basis functions for a given geometry, and the procedure for obtaining the best-fit expansion coefficients can be time-consuming. Also, just as in a grid-based approach, issues of consistency would have to be resolved, e.g., if module-generated fields satisfy force balance, to what degree do the fitted fields also satisfy force balance? Another problem that can, in principle, arise with a basis-function approach is the Gibb's phenomenon, where the basis-function representation has "overshoots" in the neighborhood of discontinuities in the original function that is being represented. This should not be a serious problem for the GGCM control program because geospace has no true discontinuities, and the regions where gradients are sharp enough to appear discontinuous on the global scale are encompassed, by design, within boundary modules that do not utilize the global representation except as a boundary condition. Thus the Gibb's phenomenon, while a potential problem to watch out for, is not likely to be an insurmountable problem.

Comparison of Approaches. The numerical storage requirements for a basis-function approach are, in principle, about the same as for a grid-based approach, for a given degree of spatial resolution, provided that the basis functions are chosen appropriately. The grid-based approach has been more extensively utilized in global geospace modeling, partly, no doubt, because it has received more generous institutional support, particularly within the NASA ISTP, SPTP, and HPCC programs. The basis-function approach has been utilized less extensively, but quite effectively, in the Tsyganenko empirical models. We recommend that both approaches be considered on an equal footing in the selection of a numerical storage mechanism for a GGCM control program.

A Prototype GGCM

< Previous Section < Previous Subsection Table of Contents Next Subection > Next Section >

The preceding description of the modular-progressive approach has been rather abstract, emphasizing the general characteristics that distinguish it from the alternative global-MHD-spine approach. One should not, however, infer from this discussion that the modular-progressive approach is a pure abstraction, an elaborate form without substance. There are, already, a number of working research models that employ the modular progressive approach to a greater or lesser degree. A familiar example is the Rice Convection Model (RCM), which contains two of the domain modules in Figure 1 (the ring current and the ionosphere) and two of the boundary modules (the ring-current field lines and the tail-dipole transition region). Thus, the approach that we advocate is not revolutionary, but evolutionary: it would build upon the significant foundation that has already been laid by existing research models.

As a concrete example we offer the "prototype" GGCM pictured in Figure 2. The format is identical to that of Figure 1 with the important exception that each of the generic module designations of Figure 1 has been replaced by a specific, existing research model that could, with minimal effort, be cast in the form of a program module if it is not already in that form. We do not mean to imply, nor should the reader infer, that the examples listed in Figure 2 are the only viable candidates, nor necessarily even the most viable candidates, for each module. Tables 1 and 2 show a longer list of existing research models that could reasonably be considered as candidates for each category of GGCM module. The specific subset listed in Figure 2 is based largely on our familiarity with these models, and our resulting conviction that a working global GGCM could readily be constructed from these existing elements with nominal additional programming effort. Most of the other models listed in Tables 1 and 2 are probably equally viable candidates, but their details are less familiar to the authors. And there are probably other, equally viable, candidates that are not listed in Tables 1 and 2 owing to our ignorance or oversight.

The purpose of Figure 2 and Tables 1 and 2 is to convince the reader that viable candidates already exist for each of the generic module elements listed in Figure 1. The lists are intended to be illustrative rather than exclusive. Indeed, the greatest strength of the modular-progressive approach is its inclusiveness; it is designed to accommodate any idea, however unconventional, provided that the idea can be cast into the form of a quantitative predictive algorithm subject to a standardized set of boundary conditions appropriate to each domain or boundary module. As discussed above, the appropriate set of boundary conditions for each module type should be established, not by fiat, but by an open workshop attended by all interested participants.

Table 1: Some existing candidates for DOMAIN modules.

Module Type	Model	Reference
Solar-Wind/Magnetosheath	Exterior Gasdynamics with Convected B Exterior MHD	Spreiter & Stahara [1980] Grabbe [1996] Wu [1992] Cairns & Lyon [1995] Spreiter & Stahara [1992]
Tail Lobes	Siscoe-Sanchez Expansion Fan   Test Particles with Mantle Source	Siscoe & Sanchez [1987] Toffoletto & Hill [1993] Pillip & Morfill [1978] Ashour-Abdalla et al. [1993]
Plasma Sheet	Magnetotail MHD           Hybrid simulations     PIC simulations   Test Particles   Empirical Model   Substorm Trigger Algorithm	Hesse & Birn [1994] Cai et al. [1994] Wiegelmann & Schindler [1995] Lee et al. [1995] Hesse et al. [1996a,1996b] Ma & Bhattacharjee [1996] Burkhart et al. [1993] Krauss-Varban & Omidi [1995] Kuznetsova et al. [1998] Pritchett & Coroniti [1995, 1997] Dreher et al. [1996] Onsager & Mukai [1996] Ashour-Abdalla et al. [1993] Tsyganenko [1989,1995] Hilmer & Voigt [1995] Klimas et al. [1991] Vassiliadas et al. [1994]
Ring Current	Rice Convection Model Magnetospheric Specification Model   Fluid Convection Model Static Equilibrium Model	Harel et al. [1981a,b] Bales et al. [1993] Wolf et al. [1996]   Peymirat & Fontaine [1994] Heinemann & Pontius [1990] Hesse & Birn [1993] Heinemann et al. [1994] Cheng [1995]

Module Type	Model	Reference
Ring Current (continued)	Ring-Current Transport/Loss                 Radiation-Belt Model                 Plasmasphere Model         Empirical Model	Sheldon & Hamilton [1993] Jordanova et al. [1994, 1997] Chen et al. [1994] Fok et al. [1995] Kozyra et al. [1995] Bishop [1996] Thorne et al. [1996] Noël [1997] Sheldon and Eastman [1997] Beutier et al. [1995] Rodgers [1995] Boscher et al. [1996] Albert [1996] Gussenhoven et al. [1996] Huston et el. [1996] Li et al. [1996] Hudson et al. [1997] Kim & Chan [1997] Gallagher et al. [1988] Rasmussen & Schunk [1990] Rasmussen et al. [1993] Weiss et al. [1997]   Tsyganenko [1989, 1993, 1995] Hilmer & Voigt [1995]
Ionosphere/Thermosphere	2-D Conductivity Tensor TIGCM   M-I Coupling Model AMIE IZMEM Empirical Conductivity Model   Empirical Potential Patterns	Wolf et al. [1991] Roble et al. [1988] Richmond et al. [1992] Kan [1993] Emery et al. [1996] Papitashvili et al. [1994] Spiro et al. [1982] Hardy et al. [1985] Heppner & Maynard [1987] Weimer [1996]

Table 2: Some existing candidates for BOUNDARY modules.

Module Type	Model	Reference
Magnetopause	Empirical Boundary     Self-consistent boundary LLBL Model   Magnetopause Reconnection       Specified Boundary Bn Kelvin-Helmholtz instability	Roelof & Sibeck [1993, 1994] Petrinec & Russell [1993,1996] Shue et al. [1997] Sotirelis [1996] Drakou et al. [1994] Wei et al. [1996] Ding et al. [1992] Fu et al. [1995] Otto [1995] Lakhina & Schindler [1996] Toffoletto & Hill [1989, 1993] Wu [1986] Miura [1992] Thomas & Winske [1993]
Plasma-Sheet Boundary Layer	Test Particles with Lobe Source         FLR Theory	Onsager et al. [1991] Onsager & Mukai [1995] Schriver & Ashour-Abdalla[1990] Ashour-Abdalla et al. [1993, 1995] Heinemann & Erickson [1997]
Tail-Dipole Transition Region	RCM with Magneto-Relaxation Current-Disruption Model	Toffoletto et al. [1996] Lui [1994]
Ring-Current Field Lines	RCM with Magneto-Relaxation Magnetic Mirror Effect	Toffoletto et al. [1996] Knight [1973]
Cusp/Boundary-Layer	Test Particles LLBL Model	Onsager et al. [1993] Wei et al. [1996]
Polar-Cap Field Lines	Controlled Penetration of IMF   Source-Surface Model Empirical Model	Toffoletto & Hill [1993] Ding et al. [1996] Schulz & McNab [1987] Tsyganenko [1995]
Plasma-Sheet Field Lines	Magnetic-Mirror Effect Empirical Model	Knight [1973] Tsyganenko [1989, 1995] Hilmer & Voigt [1995]

GGCM-COMMUNITY INTERACTIONS

In order to succeed, the GGCM must be a broadly based community effort. This is reflected in the results of the community survey (Appendix) which show a strong sentiment in favor of a flexible, transparent code structure and an open-use policy. It is equally essential, however, that this widely distributed effort be closely coordinated, and coordination implies a certain amount of institutional structure. Essential elements of this institutional structure include a center for GGCM development and operations, a grant-supported program of module development, a chain of command for agency/community oversight, and a set of "rules of the road" for GGCM use.

Development/Operations Center

< Previous Section < Previous Subsection Table of Contents Next Subsection > Next Section >

Responsibilities. The initial development and validation of a modular-progressive GGCM control program and user-interface program will require the dedicated effort of a small group of individuals with expertise both in geospace physics and in numerical modeling. Expert advice can and should be provided from other sources, including in particular the GGCM steering committee, but a single group must have the ultimate responsibility for creating a working GGCM, and sufficient funding to support the time commitment needed to carry out that responsibility. This "GGCM Development Center" should consist of a part-time senior geospace scientist (the "center director") managing the work of one or two full-time computational physicists, as well as the accumulated software assets developed or acquired in the course of GGCM development. The center director should be responsible not only for the development of these software assets but also for their secure storage and documentation, and ultimately for their on-line accessibility during the operations phase. A high-performance computer system suitable for GGCM development and execution must be continuously accessible for a nominal user fee, if not geographically co-located with the development center – the GEM program has neither the resources nor the need to own and operate its own computer system. The center personnel will, of course, have to have access to modern workstations, Internet servers, and peripheral devices, but it is to be expected that these are already available at the host institution for GGCM use at nominal charge. Bulk storage devices (e.g., hard disks, CD's) are the only equipment purchases that we foresee as being needed for GGCM development.

After the initial GGCM development and validation is complete, the GGCM Development Center should metamorphose into a GGCM Operations Center with responsibility for maintaining and upgrading the code and training others in its use. Although the nature of the day-to-day duties will change, the professional time commitment required during the operational phase will probably be about the same as during the development phase. And, although the success of the GGCM venture should never be tied too closely to a single individual or group, it is both natural and desirable that the same person(s) and institution(s) that are responsible for GGCM code development should also be responsible, at least initially, for GGCM operations. In addition to technical code maintenance and operation, the Operations Center should be responsible for providing user services and for implementing the rules of the road as established by the GGCM Steering Committee.

A working GGCM is capable of consuming enormous volumes of data as input and generating even more enormous volumes of data as output. The content and format of these data streams and other restrictions on data flow are issues that must be dealt with by the GGCM Steering Committee in consultation with both the user community and the GGCM Center. As a general rule, the GGCM operation should utilize existing graphics software wherever possible, software that is either in the public domain or is already widely accessible in the user community. The GGCM Development/Operations Center should focus its attention on geospace physics and numerical modeling, not on data-stream management. The Center will, however, be responsible for implementing the protocols and restrictions on data flow that are directed by the GGCM Steering Committee. This responsibility includes programmed warning messages to the user whenever the user's request would violate established data protocols or exceed established limits on data volume. It is neither feasible nor desirable for the Center to attempt to archive all outputs from all GGCM runs. The responsibility for storage and analysis of detailed GGCM outputs should ordinarily rest on the individual user. Certain standardized model outputs should, of course, be archived and made accessible on-line by the Development/Operations Center, to serve both as benchmark comparisons and as demonstrations of the system's functionality. (These standardized outputs would be a natural outgrowth of the present Phase 1 of the GGCM Implementation Plan [Wolf and Hesse, 1997].) The transfer of input and output data between user and Center should ordinarily take place through the Internet, although the Center should have the capability to read and write CD-roms when necessary to accommodate unusually large data streams or unusual user circumstances.

Operating Modes. Just as there are a variety of different hypotheses that can be tested by a modular-progressive GGCM, there are also a variety of ways in which a modular-progressive GGCM can be utilized. We focus here on the operating modes that are essential to the use of the GGCM as a research tool, which is its primary purpose, although we also note that the possible future applications in the realms of operational forecasting and educational outreach should always be kept in mind, and should be built into the system to the extent that is feasible without sacrificing its essential research function. We identify four operating modes that are essential to the research function:

•Default Static Configuration. For many purposes, especially in the coordinated analysis of ground-based and satellite data, it is necessary and sufficient to have a best-guess specification of the global, static plasma-field configuration corresponding to a given set of static inputs. In this mode, the GGCM would provide the type of mapping tool that has traditionally been provided, in part, by the empirical Tsyganenko magnetic-field models. For this purpose, the GGCM Development/Operations center should maintain a default GGCM model that represents, at any given time, the best available consensus view, as determined by the GGCM Steering Committee. (Thus, the work of this steering committee does not end with the development of the first-generation GGCM; it only gets more interesting!) This mode of GGCM operation represents the natural culmination of the present Phase-1 part of the GGCM Implementation Plan [Wolf and Hesse, 1997], in that it would provide outputs of existing (but now coupled) models to a wide community of users who need have no knowledge of (or interest in) the computational details of the models.

•Default Time-Dependent Execution. For some data-analysis purposes (e.g., event studies), one needs not just a best-guess static configuration, but a best-guess quasi-static dynamic evolution of the geospace system in response to given time-dependent inputs. This is another application of the default GGCM described above, and is the natural culmination of the Phase-2 part of the present GGCM Implementation Plan [Wolf and Hesse, 1997] in that it provides output of existing (but now coupled) models for any given time-dependent input data stream. This is also the mode of operation that most closely resembles the operational forecasting mode that is the ultimate, though not the immediate, goal of the GGCM effort. Widespread community use of the default GGCM in conjunction with observational campaigns and event studies will quickly reveal any shortcomings in "conventional wisdom" as codified in the default GGCM. We recommend that access to the "default" GGCM be unrestricted to legitimate scientific users, at least initially. If, at some future time, the usage level becomes so high that restrictions on use must be considered, this is an issue that the GGCM Steering Committee can deal with at that time. (It will also be a sure sign of the success of the GGCM enterprise.)

•New Module Development. A separate mode of GGCM operation is needed for the development and testing of new modules, whether they consist of theoretical algorithms or empirical models. Once the default GGCM is up and running, it should be possible to "unplug" any of the default modules and replace it with a customized module of the user's choice – this ability is the essence of the modular-progressive approach. This operation requires a different set of diagnostics compared to a production run; one is interested not so much in the detailed physical results as in the behavior of the modified code itself, including the adherence of the new module to the standardized boundary-condition protocols, and its influence on the efficiency and numerical stability of the globally-coupled code. This de-bugging mode of operation will probably require the greatest level of user support services and consultation from the GGCM Center staff. On the other hand, it may require only a truncated version of the GGCM code itself, suitable for execution on the user's home workstation. A successful outcome in this de-bugging mode should be a pre-requisite for inclusion of the new module in a full production run of the GGCM.

•Customized GGCM Execution. Once a new module has been developed and tested, it should be a simple matter for its author to assemble and execute a customized GGCM with the new module(s) replacing the corresponding default module(s) in an otherwise standard GGCM. This stage represents the culmination of the whole GGCM effort; it is in this stage that alternative hypotheses get tested against each other and against observations. Full production runs of the GGCM, either customized or default versions, would ordinarily be done by the high-performance computing system that is either located at, or continuously accessible to, the GGCM Operation Center. A password system is probably all that is required to restrict use to qualified users. If the level of use begins to tax the system resources, then it will become an issue for the GGCM Steering Committee to seek ways to increase the system capacity or, as a last resort, to ration the existing resources democratically among qualified users. (And, again, it will be a sure sign of the success of the GGCM effort.) Users who have the capacity to download and execute the full GGCM elsewhere should be encouraged to do so, in order to relieve the demand on the Center system.

Options. In each of the operating modes described above, the user should have the option to select either the maximum-resolution GGCM with all "bells and whistles", or a stripped-down, lower resolution version that is designed to be downloaded and experimented with at the individual user's workstation. The Development/Operations Center should be responsible for developing and maintaining on-line both the full version and the "smaller, faster" version of the default code. The latter version will be more efficient, and probably quite adequate for the majority of the day-to-day research use of the GGCM.

In the module de-bugging and custom-execution modes of operation, it should also be an option for the user to specify one or more "passive" modules that are not executed at each time step but are instead replaced by static algorithms or data arrays. Thus, for example, an investigation of magnetopause physics or magnetotail current-sheet physics can benefit from the global constraints provided by the coupled GGCM structure without having to tolerate the computational overhead of doing a ring-current or ionosphere-thermosphere calculation at each time step (and vice-versa). Similarly, in the module-debugging and custom-execution modes, it should be possible for the user to lump together two or more adjacent modules in case the user's algorithm already encompasses more than one of the designated domain or boundary modules. For example, as noted above, the Rice Convection Model already encompasses two domain modules and two boundary modules. As another example, a global MHD code could provide many, if not most, of the domain and boundary modules, with non-MHD effects being incorporated in just one or a few of the domain or boundary modules. Thus, the "MHD-spine" approach can be viewed, not as a separate alternative to the modular-progressive approach, but rather as a subset of a larger class of model-coupling problems that are facilitated by a modular-progressive GGCM approach. In each case, the guiding principle of the GGCM Development/Operations Center should be to facilitate, rather than to obstruct, the inclusion of pre-existing model algorithms.