Search NASA⌕ Search

SEARCH · Search NASA

Results for “PENELOPE code”

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.

6 records
All sourcesNASA NTRSDOE OSTI
NASA NTRS2005

Calculated X-ray Intensities Using Monte Carlo Algorithms: A Comparison to Experimental EPMA Data

Monte Carlo (MC) modeling has been used extensively to simulate electron scattering and x-ray emission from complex geometries. Here are presented comparisons between MC results and experimental electron-probe microanalysis (EPMA) measurements as well as phi(rhoz) correction algorithms. Experimental EPMA measurements made on NIST SRM 481 (AgAu) and 482 (CuAu) alloys, at a range of accelerating potential and instrument take-off angles, represent a formal microanalysis data set that has been widely used to develop phi(rhoz) correction algorithms. X-ray intensity data produced by MC simulations represents an independent test of both experimental and phi(rhoz) correction algorithms. The alpha-factor method has previously been used to evaluate systematic errors in the analysis of semiconductor and silicate minerals, and is used here to compare the accuracy of experimental and MC-calculated x-ray data. X-ray intensities calculated by MC are used to generate a-factors using the certificated compositions in the CuAu binary relative to pure Cu and Au standards. MC simulations are obtained using the NIST, WinCasino, and WinXray algorithms; derived x-ray intensities have a built-in atomic number correction, and are further corrected for absorption and characteristic fluorescence using the PAP phi(rhoz) correction algorithm. The Penelope code additionally simulates both characteristic and continuum x-ray fluorescence and thus requires no further correction for use in calculating alpha-factors.

Carpenter, P. K.↗
NASA NTRS1995

Introduction to Penelope

A formal program verification is a (mathematical) proof that a program executed according to its intended model meets some specification. This proves that the algorithm defined by the program is correct in the precise technical sense of being consistent with a particular specification. A program correct in this sense is free from a large and important class of errors, even though its behavior may still produce unintended results--either because the implementation of the programming language itself does not match the model of execution, or because the specification does not correctly express the user's intentions. Penelope is a prototype system for interactively developing and verifying programs that are written in a rich subset of sequential Ada. Penelope can be used to develop a program and its correctness proof incrementally, and in concert with one another. Incrementality is used in a number of ways to help make verification more tractable and more productive. For example, if an already-verified program is modified, one can attempt to prove the modified version by replaying and modifying the original verification. Penelope's specification language, Larch/Ada, belongs to the family of Larch interface languages. Larch/Ada scales up properly, in the sense that it is demonstrably sound to decompose a system hierarchically and reason locally about the implementation of each piece. Penelope has been applied in various demonstration projects--for specification (guidance control, distributed operating systems), verification (of off-the-shelf code), and formal development (by non-expert as well as expert users). Some features of Penelope have been embodied in Ada Wise, a lint-like non-interactive tool that warns of the potential for certain dynamic semantic errors in Ada programs.

Guaspari, David↗
NASA NTRS1991

Formal specification and verification of Ada software

The use of formal methods in software development achieves levels of quality assurance unobtainable by other means. The Larch approach to specification is described, and the specification of avionics software designed to implement the logic of a flight control system is given as an example. Penelope is described which is an Ada-verification environment. The Penelope user inputs mathematical definitions, Larch-style specifications and Ada code and performs machine-assisted proofs that the code obeys its specifications. As an example, the verification of a binary search function is considered. Emphasis is given to techniques assisting the reuse of a verification effort on modified code.

Hird, Geoffrey R.↗
NASA NTRS1991

Integrity and security in an Ada runtime environment

A review is provided of the Formal Methods group discussions. It was stated that integrity is not a pure mathematical dual of security. The input data is part of the integrity domain. The group provided a roadmap for research. One item of the roadmap and the final position statement are closely related to the space shuttle and space station. The group's position is to use a safe subset of Ada. Examples of safe sets include the Army Secure Operating System and the Penelope Ada verification tool. It is recommended that a conservative attitude is required when writing Ada code for life and property critical systems.

Bown, Rodney L.↗
NASA NTRS1990

Formally specifying the logic of an automatic guidance controller

The following topics are covered in viewgraph form: (1) the Penelope Project; (2) the logic of an experimental automatic guidance control system for a 737; (3) Larch/Ada specification; (4) some failures of informal description; (5) description of mode changes caused by switches; (6) intuitive description of window status (chosen vs. current); (7) design of the code; (8) and specifying the code.

Guaspari, David↗
NASA NTRS2023

The Historical Greenland Climate Network (GC-Net) Curated and Augmented Level-1 Dataset

The Greenland Climate Network (GC-Net) consists of 31 automatic weather stations (AWSs) at 30 sites across the Greenland Ice Sheet. The first site was initiated in 1990, and the project has operated almost continuously since 1995 under the leadership of the late Konrad Steffen. The GC-Net AWS measured air temperature, relative humidity, wind speed, atmospheric pressure, downward and reflected shortwave irradiance, net radiation, and ice and firn temperatures. The majority of the GC-Net sites were located in the ice sheet accumulation area (17 AWSs), while 11 AWSs were located in the ablation area, and two sites (three AWSs) were located close to the equilibrium line altitude. Additionally, three AWSs of similar design to the GC-Net AWS were installed by Konrad Steffen's team on the Larsen C ice shelf, Antarctica. After more than 3 decades of operation, the GC-Net AWSs are being decommissioned and replaced by new AWSs operated by the Geological Survey of Denmark and Greenland (GEUS). Therefore, making a reassessment of the historical GC-Net AWS data is necessary. We present a full reprocessing of the historical GC-Net AWS dataset with increased attention to the filtering of erroneous measurements, data correction and derivation of additional variables: continuous surface height, instrument heights, surface albedo, turbulent heat fluxes, and 10 m ice and firn temperatures. This new augmented GC-Net level-1 (L1) AWS dataset is now available at https://doi.org/10.22008/FK2/VVXGUT (Steffen et al., 2023) and will continue to be refined. The processing scripts, latest data and a data user forum are available at https://github.com/GEUS-Glaciology-and-Climate/GC-Net-level-1-data-processing (last access: 30 November 2023). In addition to the AWS data, a comprehensive compilation of valuable metadata is provided: maintenance reports, yearly pictures of the stations and the station positions through time. This unique dataset provides more than 320 station years of high-quality atmospheric data and is available following FAIR (findable, accessible, interoperable, reusable) data and code practices.

Greenland Climate Network↗