Conference on the Programming Environment for Development of Numerical Software
Systematic approaches to numerical software development and testing are presented.
SEARCH · Engineering Papers
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.
Systematic approaches to numerical software development and testing are presented.
Existing languages for numerical software are not altogether satisfactory. FORTRAN, even preprocessed, has troublesome limitations. Unfortunately, proposed replacements are discouragingly large, or omit essential features like variably dimensioned arrays and FORTRAN capability. A new language was designed to include such crucial features, but otherwise be as small as possible. This language, called T, includes: indention to indicate block structure, novel loop syntax, and engineering format for real constants. By preprocessing into PL/1, implementation cost was kept low.
Final Technical Report for Award SC0020286.
DAHCS Demo day poster for LDRD 25-0103
The UNIX operating system supports a number of software tools; a mathematical equation-setting language, a phototypesetting language, a FORTRAN preprocessor language, a text editor, and a command interpreter. The design, implementation, documentation, and maintenance of a portable FORTRAN test of the floating-point arithmetic unit of a computer is used to illustrate these tools at work.
Numerical modeling of permafrost dynamics requires adequate representation of atmospheric and surface processes, a reasonable parameter estimation strategy, and site-specific model development. The three main research objectives of the study are: (i) to propose a novel methodology that determines the required level of surface process complexity of permafrost models by conducting parameter sensitivity and calibration, (ii) to design and compare three numerical models of increasing surface process complexity, and (iii) to calibrate and validate the numerical models at the Yakou catchment on the Qinghai-Tibet Plateau as an exemplary study site. The calibration was carried out by coupling the Advanced Terrestrial Simulator (numerical model) and PEST (calibration tool). Simulation results showed that (i) A simple numerical model that considers only subsurface processes can simulate active layer development with the same accuracy as other more complex models that include surface processes. (ii) Peat and mineral soil layer permeability, Van Genuchten alpha, and porosity are highly sensitive. (iii) Liquid precipitation aids in increasing the rate of permafrost degradation. (iv) Deposition of snow insulated the subsurface during the thaw initiation period. We have developed and released an integrated code that couples the numerical software ATS to the calibration software PEST. The numerical model can be further used to determine the impacts of climate change on permafrost degradation.
Developers working in Computational Science & Engineering (CSE)/High Performance Computing (HPC) must contend with constant change due to advances in computing technology and science. Test Driven Development (TDD) is a methodology that mitigates software development risks due to change at the cost of adding comprehensive and continuous testing to the development process. Testing frameworks tailored for CSE/HPC, like pFUnit, can lower the barriers to such testing, yet CSE software faces unique constraints foreign to the broader software engineering community. Effective testing of numerical software requires a comprehensive suite of oracles, i.e., use cases with known answers, as well as robust estimates for the unavoidable numerical errors associated with implementation with finite-precision arithmetic. At first glance these concerns often seem exceedingly challenging or even insurmountable for real-world scientific applications. However, we argue that this common perception is incorrect and driven by (1) a conflation between model validation and software verification and (2) the general tendency in the scientific community to develop relatively coarse-grained, large procedures that compound numerous algorithmic steps.We believe TDD can be applied routinely to numerical software if developers pursue fine-grained implementations that permit testing, neatly side-stepping concerns about needing nontrivial oracles as well as the accumulation of errors. We present an example of a successful, complex legacy CSE/HPC code whose development process shares some aspects with TDD, which we contrast with current and potential capabilities. A mix of our proposed methodology and framework support should enable everyday use of TDD by CSE-expert developers.
APT (Automatically Programmable Tools) system represents an adaptation, with enhancements, of public-domain version of APT IV/SSX8 to DEC VAX-11/780 computer for use by Engineering Services Division of NASA Goddard Space Flight Center. Enhancements include super pocket feature, which allows concave polygon pockets. Recent modifications include expansion of sizes of arrays and buffers to accommodate larger part programs, insertion of user-friendly error messages, and correction of programming errors that affect POCKET command and some of sculptured-surface commands (notably SSURF and SCURV). Consists of four components: translator, execution complex, subroutine library, and CL editor. Written in FORTRAN 77.
P-APT, Portable APT, is revised version of APT written to conform to FORTRAN 77 standard. Machine-dependent code replaced or isolated and documented.
Program verified by comparisons with both experimental and numerical studies. GEOSIM implements numerical model simulating geophysical fluid flow for wide range of problems. Allows for more accurate control over experimental conditions and provides complete data source for performing diagnostic studies. Used by experienced and/or professional fluid dynamicists. Written in FORTRAN 77.
It has been estimated that NASA expends anywhere from 6 to 10 percent of its annual budget on the acquisition, implementation and maintenance of computer software. Although researchers have produced numerous software engineering approaches over the past 5-10 years; each claiming to be more effective than the other, there is very limited quantitative information verifying the measurable impact htat any of these technologies may have in a production environment. At NASA/GSFC, an extended research effort aimed at identifying and measuring software techniques that favorably impact productivity of software development, has been active over the past 8 years. Specific, measurable, software development technologies have been applied and measured in a production environment. Resulting software development approaches have been shown to be effective in both improving quality as well as productivity in this one environment.
Two proposals for expressing the dependence of numerical software on the environment are examined. The approaches are briefly summarized and the differences and similarities are discussed. One proposal characterizes the dependence of the software on the machine architecture essentially in terms of the representation of floating point entities in the machine. The second characterizes the dependence of the software on the environment in terms of models both of the floating point numbers and of the behavior of the arithmetic unit of the machine.
The Morbiter software numerically averages an osculating orbit s equations of motion (EOM) to arrive at the mean orbit s EOMs, which are then numerically propagated to obtain the long-term orbital ephemerides. The long-term evolution characteristics, and stability, of an orbit are best characterized using a mean element propagation of the perturbed, two-body variational equations of motion. The average process eliminates short period terms, leaving only secular and long period effects. Doing this avoids the Fourier series expansions and truncations required by the traditional analytic methods.
A feedback position-control system has been developed for maintaining the concentricity of a turbofan with respect to a nacelle during acoustic and flow tests in a wind tunnel. The system is needed for the following reasons: Thermal and thrust loads can displace the fan relative to the nacelle; In the particular test apparatus (see Figure 1), denoted as a rotor-only nacelle (RAN), the struts, vanes, and other stator components of a turbofan engine that ordinarily maintain the required concentricity in the face of thermal and thrust loads are not present; and The struts and stator components are not present because it is necessary to provide a flow path that is acoustically clean in the sense that the measured noise can be attributed to the fan alone. The system is depicted schematically in Figure 2. The nacelle is supported by two struts attached to a two-axis traverse table located outside the wind-tunnel wall. Two servomotors acting through 100:1 gearboxes drive the table along the Y and Z axes, which are perpendicular to the axis of rotation. The Y and Z components of the deviation from concentricity are measured by four laser displacement sensors mounted on the nacelle and aimed at reflective targets on the center body, which is part of the fan assembly. The outputs of the laser displacement sensors are digitized and processed through a personal computer programmed with control software. The control output of the computer commands the servomotors to move the table as needed to restore concentricity. Numerous software and hardware travel limits and alarms are provided to maximize safety. A highly ablative rub strip in the nacelle minimizes the probability of damage in the event that a deviation from concentricity exceeds the radial clearance [<0.004 in. (<0.1 mm)] between the inner surface of the nacelle and the tips of the fan blades. To be able to prevent an excursion in excess of the tip clearance, the system must be accurate enough to control X and Y displacements to within 0.001 in. (.0.025 mm). One characteristic essential to such accuracy is sufficient rigidity in the mechanical components of the system to prevent excitation of vibrations in the strut/ nacelle subsystem. The need for such a high degree of accuracy prompted a comprehensive analysis of sources of measurement and control errors, followed by rigorous design efforts to minimize these errors. As a result, the design of the system incorporates numerous improvements in hardware, software, and operational procedures.
X-ray beamlines are essential components of all synchrotron light sources. Practical operations involve frequent variation in beamline component positions and orientation, particularly when photon beam parameters shift due to experimental needs, or due to variations in the incoming photon beam. The alignment process can be time consuming and takes away from valuable beam time for experimental data collection. We describe progress in the automation of certain alignment tasks on the tender-energy X-ray spectroscopy (TES) beamline at the National Synchrotron Light Source II (NSLS-II). The beamline is controlled using the BlueSky software in which high level experimental plans guide the beamline components during an experiment. Numerous software packages exist for beamline modeling, and they may be tied to the beamline control system using a package we are continuing to develop called Sirepo-Bluesky. The photon beam distribution may be measured with fluorescent screens, and a relation between beam and machine state can be found by varying the mirror and aperture settings over a multi-dimensional range. We describe the results of such parameter varying measurements and how we are combining Sirepo-Bluesky with machine learning methods and reduced models to automate mirror alignment on the TES beamline.
The International Space Station global positioning systems (GPS) receiver was activated in April 2002. Since that time, numerous software anomalies surfaced that had to be worked around. Some of the software problems required waivers, such as the time function, while others required extensive operator intervention, such as numerous power cycles. Eventually, enough anomalies surfaced that the three pieces of code included in the GPS unit have been re-written and the GPS units were upgraded. The technical aspects of the problems are discussed, as well as the underlying causes that led to the delivery of a product that has had numerous problems. The technical aspects of the problems included physical phenomena that were not well understood, such as the affect that the ionosphere would have on the GPS measurements. The underlying causes were traced to inappropriate use of legacy software, changing requirements, inadequate software processes, unrealistic schedules, incorrect contract type, and unclear ownership responsibilities.
The International Space Station global positioning system (GPS) receiver was activated in April 2002. Since that time, numerous software anomalies surfaced that had to be worked around. Some of the software problems required waivers, such as the time function, while others required extensive operator intervention, such as numerous power cycles. Eventually enough anomalies surfaced that the three pieces of code included in the GPS unit have been re-written and the GPS units upgraded. The technical aspects of the problems are discussed, as well as the underlying causes that led to the delivery of a product that has had so many problems. The technical aspects of the problems included physical phenomena that were not well understood, such as the affect that the ionosphere would have on the GPS measurements. The underlying causes were traced to inappropriate use of legacy software, changing requirements, inadequate software processes, unrealistic schedules, incorrect contract type, and unclear ownership responsibilities..
Progress in mass spectrometry lipidomics has led to a rapid proliferation of studies across biology and biomedicine. These generate extremely large raw datasets requiring sophisticated solutions to support automated data processing. To address this, numerous software tools have been developed and tailored for specific tasks. However, for researchers, deciding which approach best suits their application relies on ad hoc testing, which is inefficient and time consuming. Here we first review the data processing pipeline, summarizing the scope of available tools. Next, to support researchers, LIPID MAPS provides an interactive online portal listing open-access tools with a graphical user interface. This guides users towards appropriate solutions within major areas in data processing, including (1) lipid-oriented databases, (2) mass spectrometry data repositories, (3) analysis of targeted lipidomics datasets, (4) lipid identification and (5) quantification from untargeted lipidomics datasets, (6) statistical analysis and visualization, and (7) data integration solutions. Detailed descriptions of functions and requirements are provided to guide customized data analysis workflows.