Search NASA⌕ Search

SEARCH · Search NASA

Results for “Software interfaces”

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 433 records · Page 24
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

CEA2022: A Modernization of NASA Glenn’s Software CEA (Chemical Equilibrium with Applications)

The software program “Chemical Equilibrium with Applications” (CEA) is used to solve chemical equilibrium, and compute thermodynamic and transport properties of the resulting mixture, and also has special solvers dedicated to rocket, shock, and detonation problems. We have recently completed a full re-write of CEA with modernization and improvements, called “CEA2022”. In this paper, we will give an overview of CEA2022’s features, and discuss some of the fundamental equations used by CEA2022, as well as the fundamental assumptions, in order to provide users with a complete understanding of the software’s methodology. Several enhancements have been made to the software, including modern software development practices, interface improvements, and additional features. The feature enhancements include: running cases in parallel with thread safe solves, thermodynamic and transport database updates, and allowing for negative and inert reactants. In terms of interface improvements, we have made CEA a reusable library by adding APIs for multiple languages, including Python, Matlab, Excel, Fortran, and C. The subroutine interface allows for integration with other applications, including flow-solver integration (i.e. with CFD). We also compare results between CEA2022 and the previous version (CEA2) as a validation of the new software.

chemical equilibrium↗
DOE OSTI2023

R “SHINY” GUI DEVELOPMENT FOR URANIUM ISOTOPIC ANALYSIS WITH MATRIX-ASSISTED IONIZATION MASS SPECTROMETRY

The international nuclear safeguards community continues to seek rapid, accurate, and precise characterization capabilities for the in-field measurement of uranium isotopic compositions in nuclear facilities. Mass spectrometry (MS) is considered the “gold standard” for analysis of relatively long-lived actinides such as uranium (U) and plutonium; however, conventional MS analysis often requires time consuming sample preparation and complex analytical methodologies that are difficult to perform in-field or in-facility. Matrix assisted ionization (MAI) is a novel ambient ionization MS technique (i.e., MAI-MS) that potentially addresses these challenges due to the relative simplicity of the ionization phenomenon and ruggedness of ambient MS instrumentation. Savannah River National Laboratory (SRNL, USA) has demonstrated this technique for nanogram-level 235U/238U isotope ratio measurements within seconds, with percent-level analytical uncertainties capable of discriminating depleted, natural, and low-enriched uranium. Current experimental work on developing MAI methods for uranium isotopic analysis has been enabled by parallel development of a comprehensive MAI-MS data analysis suite at SRNL. Development of this bespoke data analysis software was necessary because commercially available ambient MS software is poorly suited for uranium isotope ratio measurement. The effort leverages the power of R, a popular open-source programming language, and Shiny, an R package providing tools for graphical user interface (GUI) and web interface coding. This software allows researchers without any programming experience to harness and utilize R’s considerable data analysis/visualization power.

LaBone, Elizabeth D.↗
NASA NTRS1994

User Interface Technology for Formal Specification Development

Formal specification development and modification are an essential component of the knowledge-based software life cycle. User interface technology is needed to empower end-users to create their own formal specifications. This paper describes the advanced user interface for AMPHION1 a knowledge-based software engineering system that targets scientific subroutine libraries. AMPHION is a generic, domain-independent architecture that is specialized to an application domain through a declarative domain theory. Formal specification development and reuse is made accessible to end-users through an intuitive graphical interface that provides semantic guidance in creating diagrams denoting formal specifications in an application domain. The diagrams also serve to document the specifications. Automatic deductive program synthesis ensures that end-user specifications are correctly implemented. The tables that drive AMPHION's user interface are automatically compiled from a domain theory; portions of the interface can be customized by the end-user. The user interface facilitates formal specification development by hiding syntactic details, such as logical notation. It also turns some of the barriers for end-user specification development associated with strongly typed formal languages into active sources of guidance, without restricting advanced users. The interface is especially suited for specification modification. AMPHION has been applied to the domain of solar system kinematics through the development of a declarative domain theory. Testing over six months with planetary scientists indicates that AMPHION's interactive specification acquisition paradigm enables users to develop, modify, and reuse specifications at least an order of magnitude more rapidly than manual program development.

Lowry, Michael↗
NASA NTRS1991

ISE advanced technology

Information on Space Station Freedom scheduling problems and techniques are presented in viewgraph form. Topics covered include automated scheduling systems, user interface standards, benefits of interactive scheduling systems, incremental scheduling, software engineering, computer graphics interface, distributed resource management, and advanced applications.

Fox, Barry R.↗
NASA NTRS2010

Gas Flow Detection System

This system provides a portable means to detect gas flow through a thin-walled tube without breaking into the tubing system. The flow detection system was specifically designed to detect flow through two parallel branches of a manifold with only one inlet and outlet, and is a means for verifying a space shuttle program requirement that saves time and reduces the risk of flight hardware damage compared to the current means of requirement verification. The prototype Purge Vent and Drain Window Cavity Conditioning System (PVD WCCS) Flow Detection System consists of a heater and a temperature-sensing thermistor attached to a piece of Velcro to be attached to each branch of a WCCS manifold for the duration of the requirement verification test. The heaters and thermistors are connected to a shielded cable and then to an electronics enclosure, which contains the power supplies, relays, and circuit board to provide power, signal conditioning, and control. The electronics enclosure is then connected to a commercial data acquisition box to provide analog to digital conversion as well as digital control. This data acquisition box is then connected to a commercial laptop running a custom application created using National Instruments LabVIEW. The operation of the PVD WCCS Flow Detection System consists of first attaching a heater/thermistor assembly to each of the two branches of one manifold while there is no flow through the manifold. Next, the software application running on the laptop is used to turn on the heaters and to monitor the manifold branch temperatures. When the system has reached thermal equilibrium, the software application s graphical user interface (GUI) will indicate that the branch temperatures are stable. The operator can then physically open the flow control valve to initiate the test flow of gaseous nitrogen (GN2) through the manifold. Next, the software user interface will be monitored for stable temperature indications when the system is again at thermal equilibrium with the test flow of GN2. The temperature drop of each branch from its "no flow" stable temperature peak to its stable "with flow" temperature will allow the operator to determine whether a minimum level of flow exists. An alternative operation has the operator turning on the software only long enough to record the ambient temperature of the tubing before turning on the heaters and initiating GN2 flow. The stable temperature of the heated tubing with GN2 flow is then compared with the ambient tubing temperature to determine if flow is present in each branch. To help quantify the level of flow in the manifolds, each branch will be bench calibrated to establish its thermal properties using the flow detection system and different flow rates. These calibration values can then be incorporated into the software application to provide more detailed flow rate information.

Moss, Thomas↗
DOE OSTI2017

Opportunities and limits of Decay storage based on Dismantled Materials in Nuclear Power Plants - 17650

We investigate the potential of decay storage of low and intermediate radioactive waste for release procedures. We present the Safetec software tool HL3 and its application to data from the German nuclear power plant at the site in Stade. In general, during the dismantling process of nuclear power plants, waste of slightly contaminated and/or activated systems is produced in large amounts. These are in particular demolition rubble from concrete structures and ingots from the melting process of metals. If, at the time of disposal, the nuclear inventory is near or slightly above federal clearance limits, the material cannot be released as conventional waste. However, due to the decline of the nuclear inventory over time, a significant amount of that waste could qualify for the release procedure in the future. Although this concept of decay storage is well known, specific predictions of the mass flow to be released is non-trivial. The mass flow over time depends on the composition of known and assumed nuclides (nuclide vector), as well as on the underlying threshold values for release. To handle the waste stream as a function of time, the nuclide composition and specific threshold values, Safetec developed a bespoke software tool named HL3. Its primary function is to visualize and to test/analyze various nuclide vectors and its decompositions over time. For the application within German law, threshold values according to the different disposal routes can be considered. Using the batch interface in the software tool HL3, large amounts of data can be automatically analyzed in a traceable and quick way. To test both, the tool and the benefit for the concept of decay storage, we have applied our code HL3 to material from the dismantling of the pressurized-water reactor at the site in Stade, Germany. We set the focus on concrete debris and metal ingots, which in principle are best suited for decay storage over years. The assignment and the packaging of that waste from Stade were based on application documents for decommissioning of the Year 2000 and according to the state of art conditioning technique at that time. Based on the data of that waste and the appropriate disposal routes, we calculate and discuss the amount of waste releasable after decay storage. As for the situation in Germany, we find that only a negligible amount would be releasable, mainly due to other reasons. These are the deterioration of detectability of radionuclides with time, and other regulatory conditions. However, on an international scale, a different assessment can be drawn. Our results thus motivate to reconsider the option of interim decay storage to reduce radioactive waste in large amounts. (authors)

12 MANAGEMENT OF RADIOACTIVE AND NON-RADIOACTIVE W↗
NASA NTRS2003

Software for Simulating a Complex Robot

RoboSim (Robot Simulation) is a computer program that simulates the poses and motions of the Robonaut a developmental anthropomorphic robot that has a complex system of joints with 43 degrees of freedom and multiple modes of operation and control. RoboSim performs a full kinematic simulation of all degrees of freedom. It also includes interface components that duplicate the functionality of the real Robonaut interface with control software and human operators. Basically, users see no difference between the real Robonaut and the simulation. Consequently, new control algorithms can be tested by computational simulation, without risk to the Robonaut hardware, and without using excessive Robonaut-hardware experimental time, which is always at a premium. Previously developed software incorporated into RoboSim includes Enigma (for graphical displays), OSCAR (for kinematical computations), and NDDS (for communication between the Robonaut and external software). In addition, RoboSim incorporates unique inverse-kinematical algorithms for chains of joints that have fewer than six degrees of freedom (e.g., finger joints). In comparison with the algorithms of OSCAR, these algorithms are more readily adaptable and provide better results when using equivalent sets of data.

Goza, S. Michael↗
DOE OSTI2017

Data Processor 3 QASPR Project

The following discussion contains a high-level description of methods used to implement software for data processing. It describes the required directory structures and file handling required to use Excel's Visual Basic for Applications programming language and how to identify shot, test and capture types to appropriately process data. It also describes how to interface with the software.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS1972

Development of spectral analysis math models and software program and spectral analyzer, digital converter interface equipment design

Spectral analyses of angle-modulated communication systems is studied by: (1) performing a literature survey of candidate power spectrum computational techniques, determining the computational requirements, and formulating a mathematical model satisfying these requirements; (2) implementing the model on UNIVAC 1230 digital computer as the Spectral Analysis Program (SAP); and (3) developing the hardware specifications for a data acquisition system which will acquire an input modulating signal for SAP. The SAP computational technique uses extended fast Fourier transform and represents a generalized approach for simple and complex modulating signals.

Hayden, W. L.↗
NASA NTRS2007

Interfacing WIPL-D with Mechanical CAD Software

of almost any popular CAD format, e.g. IGES, Parasolid, DXF, ACIS etc. The solid models are processed (simplified) and meshed in GiD(R), and then converted into WIPL-D Pro input file by simple Fortran or Matlab code. This algorithm allows the user to control the mesh of imported geometry, and to assign electric p~perties to metalic and dielectric surfaces. Implementation of the algorithm is demonstrated by examples obtained from the NASA Discovery mission, Phoenix Lander 2008. Results for radiation pattern of Phoenix Lander UHF relay antenna with effect of Martian surface, both simulated in WIPL-D Pro and measured, are shown for comparison.

method of moments (MoM)↗
NASA NTRS2019

Mapping the User Journey: Building a User Persona and Story Repository to Improve NASA EOSDIS Application Development

Understanding the needs of the end user is vital to producing quality, usable software that solves real problems. Additionally, making sure those needs are communicated to managers, engineers, and designers at the project level is vital. On complex projects, it's important to build out resources for your team that make it easy to put yourself in the shoes of the specific user you're building for. NASA's Earth Observing System is a collection of data, applications, and a diverse user and scientific community that's trying to answer tough questions about our planet and its climate. Over the last few years, we've spoken to hundreds of users, performed many user testing sessions, and built a collection of user personas, user stories, and design assets that help guide new software and feature development within NASA EOSDIS. We've also developed methods for synthesizing this information and making it actionable for teams, and worked to foster a design first approach on new projects always starting from a core user need and working backward from interface development to software engineering. This process has allowed us to design better, more usable software and features that directly meet the needs of our user community.

Siarto, Jeff↗
NASA NTRS1981

Earth Resources Laboratory Applications Software (ELAS)

Implementation of the Earth Resources Laboratory applications software (ELAS) system is described. A Data General Eclipse model S/230 minicomputer is employed for image processing of LANDSAT data. A 16 bit word is used, and the smaller addressability necessitates reducing some of the array sizes. All INTEGER*4 variables were changed to REAL. Interfacing the ELAS software to Data General's FORTRAN callable runtime routines required rewriting the input/output routines and the subroutines that bring in the various overlays. Overlay relinking is required when a change is made in resident routines. The ELAS system and its user documentation is evaluated.

Balcerek, T. W.↗
NASA NTRS2004

Transitioning to Intel-based Linux Servers in the Payload Operations Integration Center

The MSFC Payload Operations Integration Center (POIC) is the focal point for International Space Station (ISS) payload operations. The POIC contains the facilities, hardware, software and communication interface necessary to support payload operations. ISS ground system support for processing and display of real-time spacecraft and telemetry and command data has been operational for several years. The hardware components were reaching end of life and vendor costs were increasing while ISS budgets were becoming severely constrained. Therefore it has been necessary to migrate the Unix portions of our ground systems to commodity priced Intel-based Linux servers. hardware architecture including networks, data storage, and highly available resources. This paper will concentrate on the Linux migration implementation for the software portion of our ground system. The migration began with 3.5 million lines of code running on Unix platforms with separate servers for telemetry, command, Payload information management systems, web, system control, remote server interface and databases. The Intel-based system is scheduled to be available for initial operational use by August 2004 The overall migration to Intel-based Linux servers in the control center involves changes to the This paper will address the Linux migration study approach including the proof of concept, criticality of customer buy-in and importance of beginning with POSlX compliant code. It will focus on the development approach explaining the software lifecycle. Other aspects of development will be covered including phased implementation, interim milestones and metrics measurements and reporting mechanisms. This paper will also address the testing approach covering all levels of testing including development, development integration, IV&V, user beta testing and acceptance testing. Test results including performance numbers compared with Unix servers will be included. need for a smooth transition while maintaining real-time support. An important aspect of the paper will involve challenges and lessons learned. product compatibility, implications of phasing decisions and tracking of dependencies, particularly non- software dependencies. The paper will also discuss scheduling challenges providing real-time flight support during the migration and the requirement to incorporate in the migration changes being made simultaneously for flight support. This paper will also address the deployment approach including user involvement in testing and the , This includes COTS product compatibility, implications of phasing decisions and tracking of dependencies, particularly non- software dependencies. The paper will also discuss scheduling challenges providing real-time flight support during the migration and the requirement to incorporate in the migration changes being made simultaneously for flight support.

Guillebeau, P. L.↗
DOE OSTI2024

hypredrive: high-level interface for solving linear systems with hypre

This software introduces a high-level interface designed to simplify solving linear systems using hypre, a renowned library for such computational challenges. It is crafted to be accessible and user-friendly, making the powerful capabilities of hypre available to a broader audience without requiring in-depth technical knowledge. The interface is characterized by its use of YAML for input, a format celebrated for its structured yet straightforward readability. This choice ensures that users can easily configure the software to meet their specific needs. Additionally, the software boasts an intuitive API that encapsulates hypre's functionalities, making it easier for users to interact with the process of solving linear systems. It is particularly beneficial for prototyping, offering a quick and efficient means to test various solver and preconditioner configurations. Furthermore, the software allows for the creation of an offline testing framework in which predefined linear systems are read from files and benchmarked with user-defined solution strategies. This makes it an invaluable tool for developers and researchers exploring and validating their computational models. Overall, the software serves as a bridge, bringing the advanced computational capabilities of hypre closer to users who may need more specialized technical expertise, thereby facilitating innovation and exploration in the field of numerical linear algebra.

Paludetto Magri, Victor↗
NASA NTRS2004

MER SPICE Interface

MER SPICE Interface is a software module for use in conjunction with the Mars Exploration Rover (MER) mission and the SPICE software system of the Navigation and Ancillary Information Facility (NAIF) at NASA's Jet Propulsion Laboratory. (SPICE is used to acquire, record, and disseminate engineering, navigational, and other ancillary data describing circumstances under which data were acquired by spaceborne scientific instruments.) Given a Spacecraft Clock value, MER SPICE Interface extracts MER-specific data from SPICE kernels (essentially, raw data files) and calculates values for Planet Day Number, Local Solar Longitude, Local Solar Elevation, Local Solar Azimuth, and Local Solar Time (UTC). MER SPICE Interface was adapted from a subroutine, denoted m98SpiceIF written by Payam Zamani, that was intended to calculate SPICE values for the Mars Polar Lander. The main difference between MER SPICE Interface and m98SpiceIf is that MER SPICE Interface does not explicitly call CHRONOS, a time-conversion program that is part of a library of utility subprograms within SPICE. Instead, MER SPICE Interface mimics some portions of the CHRONOS code, the advantage being that it executes much faster and can efficiently be called from a pipeline of events in a parallel processing environment.

Sayfi, Elias↗
NASA NTRS2002

CAPRI: Using a Geometric Foundation for Computational Analysis and Design

CAPRI (Computational Analysis Programming Interface) is a software development tool intended to make computerized design, simulation and analysis faster and more efficient. The computational steps traditionally taken for most engineering analysis (Computational Fluid Dynamics (CFD), structural analysis, etc.) are: Surface Generation, usually by employing a Computer Aided Design (CAD) system; Grid Generation, preparing the volume for the simulation; Flow Solver, producing the results at the specified operational point; Post-processing Visualization, interactively attempting to understand the results. It should be noted that the structures problem is more tractable than CFD; there are fewer mesh topologies used and the grids are not as fine (this problem space does not have the length scaling issues of fluids). For CFD, these steps have worked well in the past for simple steady-state simulations at the expense of much user interaction. The data was transmitted between phases via files. In most cases, the output from a CAD system could go IGES files. The output from Grid Generators and Solvers do not really have standards though there are a couple of file formats that can be used for a subset of the gridding (i.e. PLOT3D) data formats and the upcoming CGNS). The user would have to patch up the data or translate from one format to another to move to the next step. Sometimes this could take days. Instead of the serial approach to analysis, CAPRI takes a geometry centric approach. CAPRI is a software building tool-kit that refers to two ideas: (1) A simplified, object-oriented, hierarchical view of a solid part integrating both geometry and topology definitions, and (2) programming access to this part or assembly and any attached data. The connection to the geometry is made through an Application Programming Interface (API) and not a file system.

Haimes, Robert↗
NASA NTRS1978

Orbit targeting specialist function: Level C formulation requirements

A definition of the level C requirements for onboard maneuver targeting software is provided. Included are revisions of the level C software requirements delineated in JSC IN 78-FM-27, Proximity Operations Software; Level C Requirements, dated May 1978. The software supports the terminal phase midcourse (TPM) maneuver, braking and close-in operations as well as supporting computation of the rendezvous corrective combination maneuver (NCC), and the terminal phase initiation (TPI). Specific formulation is contained here for the orbit targeting specialist function including the processing logic, linkage, and data base definitions for all modules. The crew interface with the software is through the keyboard and the ORBIT-TGT display.

Dupont, A.↗
NASA NTRS1998

Integration of the Remote Agent for the NASA Deep Space One Autonomy Experiment

This paper describes the integration of the Remote Agent (RA), a spacecraft autonomy system which is scheduled to control the Deep Space 1 spacecraft during a flight experiment in 1999. The RA is a reusable, model-based autonomy system that is quite different from software typically used to control an aerospace system. We describe the integration challenges we faced, how we addressed them, and the lessons learned. We focus on those aspects of integrating the RA that were either easier or more difficult than integrating a more traditional large software application because the RA is a model-based autonomous system. A number of characteristics of the RA made integration process easier. One example is the model-based nature of RA. Since the RA is model-based, most of its behavior is not hard coded into procedural program code. Instead, engineers specify high level models of the spacecraft's components from which the Remote Agent automatically derives correct system-wide behavior on the fly. This high level, modular, and declarative software description allowed some interfaces between RA components and between RA and the flight software to be automatically generated and tested for completeness against the Remote Agent's models. In addition, the Remote Agent's model-based diagnosis system automatically diagnoses when the RA models are not consistent with the behavior of the spacecraft. In flight, this feature is used to diagnose failures in the spacecraft hardware. During integration, it proved valuable in finding problems in the spacecraft simulator or flight software. In addition, when modifications are made to the spacecraft hardware or flight software, the RA models are easily changed because they only capture a description of the spacecraft. one does not have to maintain procedural code that implements the correct behavior for every expected situation. On the other hand, several features of the RA made it more difficult to integrate than typical flight software. For example, the definition of correct behavior is more difficult to specify for a system that is expected to reason about and flexibly react to its environment than for a traditional flight software system. Consequently, whenever a change is made to the RA it is more time consuming to determine if the resulting behavior is correct. We conclude the paper with a discussion of future work on the Remote Agent as well as recommendations to ease integration of similar autonomy projects.

Dorais, Gregory A.↗