Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “application programming interface”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 1,315 records · Page 73

A pilot demonstration project of technology application from the aerospace industry to city management (four cities program)

The Four Cities Program has completed the first year of the planned two-year program. At the beginning of the first year, a variety of program initiation activities were accomplished. Contracts were negotiated; science and technology advisors were interviewed, selected and assigned; general indoctrination and integration of the advisors into city affairs occurred; technical needs were identified and related projects pursued; pilot projects for the second year were identified; inter-city coordination on technical problems began to emerge; and the general soundness of the four cities program seems to have been established. Above all, the inter-personal relationships between the advisors and their interfaces in city government appear to be functioning smoothly. The establishment of such mutual respect, trusts, and confidences are believed essential to the success of the program.

Ervin, G. F.↗

High resolution system for upper air (troposphere) wind and temperature profile measurements

The Jimsphere/Jimsonde system is described and some possible applications of the system for air-sea interface measurements are presented. As space vehicles became larger and more sophisticated, an improved method for obtaining wind profile data had to be found. To satisfy this need the FPS-16 radar/Jimsphere system was developed. The Jimsphere is an aluminized mylar spherical balloon, two meters in diameter. The balloon is under superpressure, and is tracked with a high precision radar system. The development of this detailed wind profile system was started in 1963, and the present design was established in 1964. To improve the system, a program was initiated in 1965 to obtain high resolution temperature data simultaneously with the wind profile data.

Camp, D. W.↗

Adhesion of Silicone Elastomer Seals for NASA's Crew Exploration Vehicle

Silicone rubber seals are being considered for a number of interfaces on NASA's Crew Exploration Vehicle (CEV). Some of these joints include the docking system, hatches, and heat shield-to-back shell interface. A large diameter molded silicone seal is being developed for the Low Impact Docking System (LIDS) that forms an effective seal between the CEV and International Space Station (ISS) and other future Constellation Program spacecraft. Seals between the heat shield and back shell prevent high temperature reentry gases from leaking into the interface. Silicone rubber seals being considered for these locations have inherent adhesive tendencies that would result in excessive forces required to separate the joints if left unchecked. This paper summarizes adhesion assessments for both as-received and adhesion-mitigated seals for the docking system and the heat shield interface location. Three silicone elastomers were examined: Parker Hannifin S0899-50 and S0383-70 compounds, and Esterline ELA-SA-401 compound. For the docking system application various levels of exposure to atomic oxygen (AO) were evaluated. Moderate AO treatments did not lower the adhesive properties of S0899-50 sufficiently. However, AO pretreatments of approximately 10(exp 20) atoms/sq cm did lower the adhesion of S0383-70 and ELA-SA-401 to acceptable levels. For the heat shield-to-back shell interface application, a fabric covering was also considered. Molding Nomex fabric into the heat shield pressure seal appreciably reduced seal adhesion for the heat shield-to-back shell interface application.

deGroh, Henry C., III↗

Application of HFE to the design and V and V of a computerized procedure system: benefits and challenges - 234

The application of Human Factors Engineering (HFE) practices to the Human Machine Interface design and subsequent Verification and Validation (V and V) is a widely applied practice when talking about the design of complete control rooms or important control room modernizations, but not so often applied to the design of computerized operator support systems. In order to overcome the challenges faced on designing a Computerized Operation Support System (COSS) that meets the process efficiency requirements and integrates seemingly with hybrid plant operation concept, the involvement of a HFE team early in the COSS design and implementation process along with operation, Instrumentation and Control (I and C) and cybersecurity experts will guarantee the project success. This paper documents the HFE process applied during the design and evaluation of a Computerized Procedure System (CPS) and how final product was shaped to ensure that the transition from paper to computerized procedures will help in meeting Delivering the Nuclear Promise (DNP) goals, improving plant efficiency. The HFE program included the following activities: 1. A review of existing operating experience 2. An analysis of functions and tasks associated to the use and maintenance of CPS 3. A design verification of the system to meet guidelines prescribed in the NUREG-0700 (Rev.2), requirements of the ISG-05 and cybersecurity criteria (NEI 08-09, IEC-62646, EPRI 1015313, these among others). 4. An integrated system validation in a full scope simulator The application of HFE practices in the design and implementation of COSS helps not only to ensure that efficiency and safety improvement requirements are met, but also to evaluate the potential return of the investment, that such tools should bring. (authors)

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

Four-Dimensional Finite-Orbit-Width Fokker-Planck Code with Sources, for Neoclassical/Anomalous Transport Simulation of Ion and Electron (Final Technical Report)

Within the US Department of Energy/Office of Fusion Energy magnetic fusion research program, there is an important whole-plasma-modeling need for a radio-frequency/neutral-beam-injection (RF/NBI) transport-oriented finite-difference Fokker-Planck (FP) code with combined capabilities for 4D (2R2V) geometry near the fusion plasma periphery, and computationally less demanding 3D (1R2V) bounce-averaged capabilities for plasma in the core of fusion devices. Demonstration of proof-of-principle achievement of this goal has been carried out in research carried out under Phase I of the SBIR award. Two DOE-sponsored codes, the CQL3D bounce-average Fokker-Planck code in which CompX has specialized, and the COGENT 4D, plasma edge-oriented Fokker-Planck code which has been constructed by Lawrence Livermore National Laboratory and Lawrence Berkeley Laboratory scientists, where coupled. Coupling was achieved by using CQL3D calculated velocity distributions including an energetic tail resulting from NBI, as boundary conditions for the COGENT code over the two-dimensional velocity space on a spatial interface (flux) surface at a given radius near the plasma periphery. The finite-orbit-width fast ions from the CQL3D distributions penetrated into the peripheral plasma modeled by the COGENT code. This combined code demonstrates the feasibility of the proposed 3D/4D code. By combining these codes, the greatest computational efficiency is achieved subject to present modeling needs in toroidally symmetric magnetic fusion devices. The more efficient 3D code can be used in its regions of applicability, coupled to the more computationally demanding 4D code in higher collisionality edge plasma regions where that extended capability is necessary for accurate representation of the plasma. More efficient code leads to greater use and utility of the model. An ancillary aim of the project is to make the combined 3D/4D code user friendly. Achievement of full-coupling of these two Fokker-Planck codes will advance computational modeling of plasma devices important to the USDOE magnetic fusion energy program, in particular the DIII-D tokamak at General Atomics, San Diego, the NSTX spherical tokamak at Princeton, New Jersey, and the MST reversed-field-pinch Madison, Wisconsin. The validation studies of the code against the experiments will improve understanding of physics important for magnetic fusion, and will increase our design capabilities for achieving the goals of the International Tokamak Experimental Reactor (ITER) project in which the US is a participant and which seeks to demonstrate at least a factor of five in fusion power production divided by input power.

70 PLASMA PHYSICS AND FUSION TECHNOLOGY↗

Reference Avionics Architecture for Lunar Surface Systems

Developing and delivering infrastructure capable of supporting long-term manned operations to the lunar surface has been a primary objective of the Constellation Program in the Exploration Systems Mission Directorate. Several concepts have been developed related to development and deployment lunar exploration vehicles and assets that provide critical functionality such as transportation, habitation, and communication, to name a few. Together, these systems perform complex safety-critical functions, largely dependent on avionics for control and behavior of system functions. These functions are implemented using interchangeable, modular avionics designed for lunar transit and lunar surface deployment. Systems are optimized towards reuse and commonality of form and interface and can be configured via software or component integration for special purpose applications. There are two core concepts in the reference avionics architecture described in this report. The first concept uses distributed, smart systems to manage complexity, simplify integration, and facilitate commonality. The second core concept is to employ extensive commonality between elements and subsystems. These two concepts are used in the context of developing reference designs for many lunar surface exploration vehicles and elements. These concepts are repeated constantly as architectural patterns in a conceptual architectural framework. This report describes the use of these architectural patterns in a reference avionics architecture for Lunar surface systems elements.

Somervill, Kevin M.↗

Cloud Computing Option for Modeling the Debris Environment

NASA’s Digital Transformation Initiative aims to promote the agency’s adoption of current and evolving digital technologies. Through agency-wide collaboration with other NASA teams, the Office of Safety and Mission Assurance (OSMA) has directed the Orbital Debris Program Office and the Meteoroid Environment Office to integrate cloud computing technologies in their publicly released software models: the Orbital Debris Engineering Model (ORDEM) and the Meteoroid Engineering Model (MEM). Decoupling the user interface from the backend processor was key for the software packages to run on a cloud computing framework. Benefits to this design include horizontal scaling of computing resources, user authentication and authorization, and automated deployment. Both models are hosted on a cloud computing platform supported by the NASA authorized IT security and compliance framework. This paper focuses on the new ORDEM web application, which includes the current features of the publicly released ORDEM software with an upgraded frontend design. The underlying ORDEM processor is run on a cloud container, allowing the user to run multiple spacecraft and telescope/radar mode simulations. Featuresexclusive to the ORDEM web application, such as importing multiple TLEs, auto-generated plotting, and the ability to check runtime progress are discussed. Comparisons between the current ORDEM software and the web application are summarized.

Andrew Vavrin↗

Cloud Computing Option for Modeling the Debris Environment

NASA’s Digital Transformation Initiative aims to promote the agency’s adoption of current and evolving digital technologies. Through agency-wide collaboration with other NASA teams, the Office of Safety and Mission Assurance (OSMA) has directed the Orbital Debris Program Office and the Meteoroid Environment Office to integrate cloud computing technologies into their publicly released software models: the Orbital Debris Engineering Model (ORDEM) and the Meteoroid Engineering Model (MEM). Decoupling the user interface from the backend processor was key for the software packages to run on a cloud computing framework. Benefits to this design include horizontal scaling of computing resources, user authentication and authorization, and automated deployment. Both models are hosted on a cloud computing platform supported by the NASA authorized IT security and compliance framework. This paper focuses on the new ORDEM web application, which includes the current features of the publicly released ORDEM software with an upgraded frontend design, although parallels between ORDEM and MEM are also discussed. The underlying ORDEM processor is run on a cloud container, allowing the user to run multiple spacecraft and telescope/radar mode simulations. Features exclusive to the ORDEM web application, such as importing multiple TLEs, auto-generated plotting, and the ability to check runtime progress are discussed. Comparisons between the current ORDEM software and the web application are summarized.

Andrew Vavrin↗

Numerical Simulation of No-Vent Chill and Fill of a Large Liquid Hydrogen Tank

To enable the design of future in-space cryogenic propellant transfer vehicles, high accuracy models of the cryogenic propellant transfer process are desired. For in-space refueling applications, accurate simulations are desired of the propellant tank chilldown and no-vent fill (NVF) process in order to estimate the amount of propellant required, to determine the maximum sustainable flow rate to fill the tank, and to establish a timeline for the filling process. NVF is a complex process that involves numerous two-phase heat and mass transfer phenomena, such as boiling at the wall and evaporation and condensation at the liquid/vapor interface. In recent years, progress has been made in developing a numerical modeling technique using the Generalized Fluid System Simulation Program (GFSSP) that has been validated against several small-scale liquid nitrogen NVF tests. This paper presents GFSSP numerical model validation against three liquid hydrogen NVF tests on a large-scale propellant tank. Comparing the GFSSP model to the data for pressure, fill level, and wall temperature, the mean absolute percentage error is below 20% across the range of simulated conditions, indicating very good predictive agreement for this large-scale hydrogen NVF test series.

Alok Majumdar↗

Numerical Simulation of No-Vent Chill and Fill of a Large Liquid Hydrogen Tank

To enable the design of future in-space cryogenic propellant transfer vehicles, high accuracy models of the cryogenic propellant transfer process are desired. For in-space refueling applications, accurate simulations are desired of the propellant tank chilldown and no-vent fill (NVF) process in order to estimate the amount of propellant required, to determine the maximum sustainable flow rate to fill the tank, and to establish a timeline for the filling process. NVF is a complex process that involves numerous two-phase heat and mass transfer phenomena, such as boiling at the wall and evaporation and condensation at the liquid/vapor interface. In recent years, progress has been made in developing a numerical modeling technique using the Generalized Fluid System Simulation Program (GFSSP) that has been validated against several small-scale liquid nitrogen NVF tests. This paper presents GFSSP numerical model validation against three liquid hydrogen NVF tests on a large-scale propellant tank. Comparing the GFSSP model to the data for pressure, fill level, and wall temperature, the mean absolute percentage error is below 20% across the range of simulated conditions, indicating very good predictive agreement for this large-scale hydrogen NVF test series.

Alok Majumdar↗

SUNDIALS Multiphysics+MPIManyVector Performance Testing

In this report we document performance test results on a SUNDIALS-based multiphysics demonstration application. We aim to assess the large-scale parallel performance of new capabilities that have been added to the SUNDIALS suite of time integrators and nonlinear solvers in recent years under funding from both the Exascale Computing Project (ECP) and the Scientific Discovery through Advanced Scientific (SciDAC) program, specifically: 1. SUNDIALS’ new MPIManyVector module, that allows extreme flexibility in how a solution "vector" is staged on computational resources. 2. ARKode’s new multirate integration module, MRIStep, allowing high-order accurate calculations that subcycle "fast" processes within "slow" ones. 3. SUNDIALS’ new flexible linear solver interfaces, that allow streamlined specification of problem-specific linear solvers. 4. SUNDIALS’ new N_Vector additions of "fused" vector operations (to increase arithmetic intensity) and separation of reduction operations into "local" and "global" versions (to reduce latency by combining multiple reductions into a single MPI_Allreduce call). We anticipate that subsequent reports will extend this work to investigate a variety of other new features, including SUNDIALS’ generic SUNNonlinearSolver interface and accelerator-enabled N Vector modules, and upcoming MRIStep extensions to support custom "fast" integrators (that leverage problem structure) and IMEX integration of the "slow" time scale (to add diffusion).

97 MATHEMATICS AND COMPUTING↗

Modeling in the State Flow Environment to Support Launch Vehicle Verification Testing for Mission and Fault Management Algorithms in the NASA Space Launch System

Analysis methods and testing processes are essential activities in the engineering development and verification of the National Aeronautics and Space Administration's (NASA) new Space Launch System (SLS). Central to mission success is reliable verification of the Mission and Fault Management (M&FM) algorithms for the SLS launch vehicle (LV) flight software. This is particularly difficult because M&FM algorithms integrate and operate LV subsystems, which consist of diverse forms of hardware and software themselves, with equally diverse integration from the engineering disciplines of LV subsystems. M&FM operation of SLS requires a changing mix of LV automation. During pre-launch the LV is primarily operated by the Kennedy Space Center (KSC) Ground Systems Development and Operations (GSDO) organization with some LV automation of time-critical functions, and much more autonomous LV operations during ascent that have crucial interactions with the Orion crew capsule, its astronauts, and with mission controllers at the Johnson Space Center. M&FM algorithms must perform all nominal mission commanding via the flight computer to control LV states from pre-launch through disposal and also address failure conditions by initiating autonomous or commanded aborts (crew capsule escape from the failing LV), redundancy management of failing subsystems and components, and safing actions to reduce or prevent threats to ground systems and crew. To address the criticality of the verification testing of these algorithms, the NASA M&FM team has utilized the State Flow environment6 (SFE) with its existing Vehicle Management End-to-End Testbed (VMET) platform which also hosts vendor-supplied physics-based LV subsystem models. The human-derived M&FM algorithms are designed and vetted in Integrated Development Teams composed of design and development disciplines such as Systems Engineering, Flight Software (FSW), Safety and Mission Assurance (S&MA) and major subsystems and vehicle elements such as Main Propulsion Systems (MPS), boosters, avionics, Guidance, Navigation, and Control (GN&C), Thrust Vector Control (TVC), liquid engines, and the astronaut crew office. Since the algorithms are realized using model-based engineering (MBE) methods from a hybrid of the Unified Modeling Language (UML) and Systems Modeling Language (SysML), SFE methods are a natural fit to provide an in depth analysis of the interactive behavior of these algorithms with the SLS LV subsystem models. For this, the M&FM algorithms and the SLS LV subsystem models are modeled using constructs provided by Matlab which also enables modeling of the accompanying interfaces providing greater flexibility for integrated testing and analysis, which helps forecast expected behavior in forward VMET integrated testing activities. In VMET, the M&FM algorithms are prototyped and implemented using the same C++ programming language and similar state machine architectural concepts used by the FSW group. Due to the interactive complexity of the algorithms, VMET testing thus far has verified all the individual M&FM subsystem algorithms with select subsystem vendor models but is steadily progressing to assessing the interactive behavior of these algorithms with LV subsystems, as represented by subsystem models. The novel SFE applications has proven to be useful for quick look analysis into early integrated system behavior and assessment of the M&FM algorithms with the modeled LV subsystems. This early MBE analysis generates vital insight into the integrated system behaviors, algorithm sensitivities, design issues, and has aided in the debugging of the M&FM algorithms well before full testing can begin in more expensive, higher fidelity but more arduous environments such as VMET, FSW testing, and the Systems Integration Lab7 (SIL). SFE has exhibited both expected and unexpected behaviors in nominal and off nominal test cases prior to full VMET testing. In many findings, these behavioral characteristics were used to correct the M&FM algorithms, enable better test coverage, and develop more effective test cases for each of the LV subsystems. This has improved the fidelity of testing and planning for the next generation of M&FM algorithms as the SLS program evolves from non-crewed to crewed flight, impacting subsystem configurations and the M&FM algorithms that control them. SFE analysis has improved robustness and reliability of the M&FM algorithms by revealing implementation errors and documentation inconsistencies. It is also improving planning efficiency for future VMET testing of the M&FM algorithms hosted in the LV flight computers, further reducing risk for the SLS launch infrastructure, the SLS LV, and most importantly the crew.

Trevino, Luis↗

Combined Numerical/Analytical Perturbation Solutions of the Navier-Stokes Equations for Aerodynamic (Ejector Nozzle) Flows

In spite of the rapid advances in both scalar and parallel computational tools, the large number and breadth of variables involved in aerodynamic systems make the use of parabolized or even boundary layer fluid flow models impractical for both preliminary design and inverse design problems. Given this restriction, we have concluded that reduced or approximate models are an important family of tools for design purposes. This study of a combined perturbation/numerical modeling methodology with an application to ejector-mixer nozzles (shown schematically in the following figure) is nearing completion. The work is being funded by a grant from the NASA Lewis Research Center to Texas A&M University. These ejector-mixer nozzle models are designed to be of use to the High Speed Civil Transport Program and may be adopted by both NASA and industry. A computer code incorporating the ejector-mixer models is under development. This code, the Differential Reduced Ejector/Mixer Analysis (DREA), can be run fast enough to be used as a subroutine or to be called by a design optimization routine. Simplified conservation equations--x-momentum, energy, and mass conservation--are used to define the model. Unlike other preliminary design models, DREA requires minimal empirical input and includes vortical mixing and a fully compressible formulation among other features. DREA is being validated by comparing it with results obtained from open literature and proprietary industry data. Preliminary results for a subsonic ejector and a supersonic ejector are shown. In addition, dedicated experiments have been performed at Texas A&M. These experiments use a hydraulic/gas flow analog to provide information about the inviscid mixing interface structure. Final validation and documentation of this work is expected by May of 1997. However, preliminary versions of DREA can be expected in early 1997. In summary, DREA provides a sufficiently detailed and realistic ejector-mixer nozzle model at a computational cost compatible with preliminary design applications.

DeChant, Lawrence J.↗

PETSc Users Manual (Rev. 3.3)

This manual describes the use of PETSc for the numerical solution of partial differential equations and related problems on high-performance computers. The Portable, Extensible Toolkit for Scientific Computation (PETSc) is a suite of data structures and routines that provide the building blocks for the implementation of large-scale application codes on parallel (and serial) computers. PETSc uses the MPI standard for all message-passing communication. PETSc includes an expanding suite of parallel linear, nonlinear equation solvers and time integrators that may be used in application codes written in Fortran, C, C++, Python, and MATLAB (sequential). PETSc provides many of the mechanisms needed within parallel application codes, such as parallel matrix and vector assembly routines. The library is organized hierarchically, enabling users to employ the level of abstraction that is most appropriate for a particular problem. By using techniques of object-oriented programming, PETSc provides enormous flexibility for users. PETSc is a sophisticated set of software tools; as such, for some users it initially has a much steeper learning curve than a simple subroutine library. In particular, for individuals without some computer science background, experience programming in C, C++ or Fortran and experience using a debugger such as gdb or dbx, it may require a significant amount of time to take full advantage of the features that enable efficient software use. However, the power of the PETSc design and the algorithms it incorporates may make the efficient implementation of many application codes simpler than “rolling them” yourself; For many tasks a package such as MATLAB is often the best tool; PETSc is not intended for the classes of problems for which effective MATLAB code can be written. PETSc also has a MATLAB interface, so portions of your code can be written in MATLAB to “try out” the PETSc solvers. The resulting code will not be scalable however because currently MATLAB is inherently not scalable; and PETSc should not be used to attempt to provide a “parallel linear solver” in an otherwise sequential code. Certainly all parts of a previously sequential code need not be parallelized but the matrix generation portion must be parallelized to expect any kind of reasonable performance. Do not expect to generate your matrix sequentially and then “use PETSc” to solve the linear system in parallel. Since PETSc is under continued development, small changes in usage and calling sequences of routines will occur. PETSc is supported; see the web site http://www.mcs.anl.gov/petsc for information on contacting support. A http://www.mcs.anl.gov/petsc/publications may be found a list of publications and web sites that feature work involving PETSc. We welcome any reports of corrections for this document.

97 MATHEMATICS AND COMPUTING↗

PETSc Users Manual (Rev. 3.4)

This manual describes the use of PETSc for the numerical solution of partial differential equations and related problems on high-performance computers. The Portable, Extensible Toolkit for Scientific Computation (PETSc) is a suite of data structures and routines that provide the building blocks for the implementation of large-scale application codes on parallel (and serial) computers. PETSc uses the MPI standard for all message-passing communication. PETSc includes an expanding suite of parallel linear, nonlinear equation solvers and time integrators that may be used in application codes written in Fortran, C, C++, Python, and MATLAB (sequential). PETSc provides many of the mechanisms needed within parallel application codes, such as parallel matrix and vector assembly routines. The library is organized hierarchically, enabling users to employ the level of abstraction that is most appropriate for a particular problem. By using techniques of object-oriented programming, PETSc provides enormous flexibility for users. PETSc is a sophisticated set of software tools; as such, for some users it initially has a much steeper learning curve than a simple subroutine library. In particular, for individuals without some computer science background, experience programming in C, C++ or Fortran and experience using a debugger such as gdb or dbx, it may require a significant amount of time to take full advantage of the features that enable efficient software use. However, the power of the PETSc design and the algorithms it incorporates may make the efficient implementation of many application codes simpler than “rolling them” yourself; For many tasks a package such as MATLAB is often the best tool; PETSc is not intended for the classes of problems for which effective MATLAB code can be written. PETSc also has a MATLAB interface, so portions of your code can be written in MATLAB to “try out” the PETSc solvers. The resulting code will not be scalable however because currently MATLAB is inherently not scalable; and PETSc should not be used to attempt to provide a “parallel linear solver” in an otherwise sequential code. Certainly all parts of a previously sequential code need not be parallelized but the matrix generation portion must be parallelized to expect any kind of reasonable performance. Do not expect to generate your matrix sequentially and then “use PETSc” to solve the linear system in parallel. Since PETSc is under continued development, small changes in usage and calling sequences of routines will occur. PETSc is supported; see the web site http://www.mcs.anl.gov/petsc for information on contacting support. A http://www.mcs.anl.gov/petsc/publications may be found a list of publications and web sites that feature work involving PETSc. We welcome any reports of corrections for this document.

97 MATHEMATICS AND COMPUTING↗

PETSc Users Manual (Rev. 3.5)

This manual describes the use of PETSc for the numerical solution of partial differential equations and related problems on high-performance computers. The Portable, Extensible Toolkit for Scientific Computation (PETSc) is a suite of data structures and routines that provide the building blocks for the implementation of large-scale application codes on parallel (and serial) computers. PETSc uses the MPI standard for all message-passing communication. PETSc includes an expanding suite of parallel linear, nonlinear equation solvers and time integrators that may be used in application codes written in Fortran, C, C++, Python, and MATLAB (sequential). PETSc provides many of the mechanisms needed within parallel application codes, such as parallel matrix and vector assembly routines. The library is organized hierarchically, enabling users to employ the level of abstraction that is most appropriate for a particular problem. By using techniques of object-oriented programming, PETSc provides enormous flexibility for users. PETSc is a sophisticated set of software tools; as such, for some users it initially has a much steeper learning curve than a simple subroutine library. In particular, for individuals without some computer science background, experience programming in C, C++ or Fortran and experience using a debugger such as gdb or dbx, it may require a significant amount of time to take full advantage of the features that enable efficient software use. However, the power of the PETSc design and the algorithms it incorporates may make the efficient implementation of many application codes simpler than “rolling them” yourself. ;For many tasks a package such as MATLAB is often the best tool; PETSc is not intended for the classes of problems for which effective MATLAB code can be written. PETSc also has a MATLAB interface, so portions of your code can be written in MATLAB to “try out” the PETSc solvers. The resulting code will not be scalable however because currently MATLAB is inherently not scalable; and PETSc should not be used to attempt to provide a “parallel linear solver” in an otherwise sequential code. Certainly all parts of a previously sequential code need not be parallelized but the matrix generation portion must be parallelized to expect any kind of reasonable performance. Do not expect to generate your matrix sequentially and then “use PETSc” to solve the linear system in parallel. Since PETSc is under continued development, small changes in usage and calling sequences of routines will occur. PETSc is supported; see the web site http://www.mcs.anl.gov/petsc for information on contacting support. A http://www.mcs.anl.gov/petsc/publications may be found a list of publications and web sites that feature work involving PETSc. We welcome any reports of corrections for this document.

97 MATHEMATICS AND COMPUTING↗

NAS Parallel Benchmark. Results 11-96: Performance Comparison of HPF and MPI Based NAS Parallel Benchmarks

High Performance Fortran (HPF), the high-level language for parallel Fortran programming, is based on Fortran 90. HALF was defined by an informal standards committee known as the High Performance Fortran Forum (HPFF) in 1993, and modeled on TMC's CM Fortran language. Several HPF features have since been incorporated into the draft ANSI/ISO Fortran 95, the next formal revision of the Fortran standard. HPF allows users to write a single parallel program that can execute on a serial machine, a shared-memory parallel machine, or a distributed-memory parallel machine. HPF eliminates the complex, error-prone task of explicitly specifying how, where, and when to pass messages between processors on distributed-memory machines, or when to synchronize processors on shared-memory machines. HPF is designed in a way that allows the programmer to code an application at a high level, and then selectively optimize portions of the code by dropping into message-passing or calling tuned library routines as 'extrinsics'. Compilers supporting High Performance Fortran features first appeared in late 1994 and early 1995 from Applied Parallel Research (APR) Digital Equipment Corporation, and The Portland Group (PGI). IBM introduced an HPF compiler for the IBM RS/6000 SP/2 in April of 1996. Over the past two years, these implementations have shown steady improvement in terms of both features and performance. The performance of various hardware/ programming model (HPF and MPI (message passing interface)) combinations will be compared, based on latest NAS (NASA Advanced Supercomputing) Parallel Benchmark (NPB) results, thus providing a cross-machine and cross-model comparison. Specifically, HPF based NPB results will be compared with MPI based NPB results to provide perspective on performance currently obtainable using HPF versus MPI or versus hand-tuned implementations such as those supplied by the hardware vendors. In addition we would also present NPB (Version 1.0) performance results for the following systems: DEC Alpha Server 8400 5/440, Fujitsu VPP Series (VX, VPP300, and VPP700), HP/Convex Exemplar SPP2000, IBM RS/6000 SP P2SC node (120 MHz) NEC SX-4/32, SGI/CRAY T3E, SGI Origin2000.

Saini, Subash↗

CoNNeCT Baseband Processor Module

A document describes the CoNNeCT Baseband Processor Module (BPM) based on an updated processor, memory technology, and field-programmable gate arrays (FPGAs). The BPM was developed from a requirement to provide sufficient computing power and memory storage to conduct experiments for a Software Defined Radio (SDR) to be implemented. The flight SDR uses the AT697 SPARC processor with on-chip data and instruction cache. The non-volatile memory has been increased from a 20-Mbit EEPROM (electrically erasable programmable read only memory) to a 4-Gbit Flash, managed by the RTAX2000 Housekeeper, allowing more programs and FPGA bit-files to be stored. The volatile memory has been increased from a 20-Mbit SRAM (static random access memory) to a 1.25-Gbit SDRAM (synchronous dynamic random access memory), providing additional memory space for more complex operating systems and programs to be executed on the SPARC. All memory is EDAC (error detection and correction) protected, while the SPARC processor implements fault protection via TMR (triple modular redundancy) architecture. Further capability over prior BPM designs includes the addition of a second FPGA to implement features beyond the resources of a single FPGA. Both FPGAs are implemented with Xilinx Virtex-II and are interconnected by a 96-bit bus to facilitate data exchange. Dedicated 1.25- Gbit SDRAMs are wired to each Xilinx FPGA to accommodate high rate data buffering for SDR applications as well as independent SpaceWire interfaces. The RTAX2000 manages scrub and configuration of each Xilinx.

Yamamoto, Clifford K↗