SEARCH · Engineering Papers

Results for “User interaction”

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.

SourceResearch connectionFrom yearThrough year

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

At least 91 records · Page 5

All sources NASA NTRS DOE OSTI

NASA NTRS1992

Display of scientific data structures for algorithm visualization

We present a technique for defining graphical depictions for all the data types defined in an algorithm. The ability to display arbitrary combinations of an algorithm's data objects in a common frame of reference, coupled with interactive control of algorithm execution, provides a powerful way to understand algorithm behavior. Type definitions are constrained so that all primitive values occurring in data objects are assigned scalar types. A graphical display, including user interaction with the display, is modeled by a special data type. Mappings from the scalar types into the display model type provide a simple user interface for controlling how all data types are depicted, without the need for type-specific graphics logic.

Hibbard, William↗

NASA NTRS1975

CARETS: A prototype regional environmental information system. Volume 12: User evaluation of experimental land use maps and related products from the central Atlantic test site

The user interaction and evaluation phase of the USGS/NASA Central Atlantic Regional Ecological Test Site was designed to obtain the input of local, regional, State, and Federal agency users of land-resource information into the development, of a regional information system; to provide users with assistance and data resulting from CARETS research; and to have user. organizations evaluate to what extent the CARETS products meet their needs. The evaluation of CARETS land use and related products revealed that most user agencies interviewed, at all governmental levels, require more detailed data than that provided by the CARETS project. Few agencies found utility in the generalized ERTS Level I land--use maps. Level II data, though reported valuable by several users, was generally considered of secondary utility by most users. The products considered most useful by users at all levels were the high--altitude color-infrared photographs and the USGS orthophotoquads. Recommendations resulting from the evaluation reflect the need to establish a flexible and reliable system for providing more detailed raw and processed land-resource information as well as the need to improve the methods of making information available to users.

Land-use planning↗

NASA NTRS1992

NASA Lewis steady-state heat pipe code users manual

The NASA Lewis heat pipe code was developed to predict the performance of heat pipes in the steady state. The code can be used as a design tool on a personal computer or with a suitable calling routine, as a subroutine for a mainframe radiator code. A variety of wick structures, including a user input option, can be used. Heat pipes with multiple evaporators, condensers, and adiabatic sections in series and with wick structures that differ among sections can be modeled. Several working fluids can be chosen, including potassium, sodium, and lithium, for which monomer-dimer equilibrium is considered. The code incorporates a vapor flow algorithm that treats compressibility and axially varying heat input. This code facilitates the determination of heat pipe operating temperatures and heat pipe limits that may be encountered at the specified heat input and environment temperature. Data are input to the computer through a user-interactive input subroutine. Output, such as liquid and vapor pressures and temperatures, is printed at equally spaced axial positions along the pipe as determined by the user.

Tower, Leonard K.↗

NASA NTRS2013

Athena in 2013 and Beyond

TRISA, the U.S. Army TRADOC G2 Intelligence Support Activity, received Athena 1 in 2009. They first used Athena 3 to support studies in 2011. This paper describes Athena 4, which they started using in October 2012. A final section discusses issues that are being considered for incorporation into Athena 5 and later. Athena's objective is to help skilled intelligence analysts anticipate the likely consequences of complex courses of action that use our country's entire power base, not just our military capabilities, for operations in troubled regions of the world. Measures of effectiveness emphasize who is in control and the effects of our actions on the attitudes and well-being of civilians. The planning horizon encompasses not weeks or months, but years. Athena is a scalable, laptop-based simulation with weekly resolution. Up to three months of simulated time can pass between game turns that require user interaction. Athena's geographic scope is nominally a country, but can be a region within a county. Geographic resolution is "neighborhoods", which are defined by the user and may be actual neighborhoods, provinces, or anything in between. Models encompass phenomena whose effects are expected to be relevant over a medium-term planning horizon-three months to three years. The scope and intrinsic complexity of the problem dictate a spiral development process. That is, the model is used during development and lessons learned are used to improve the model. Even more important is that while every version must consider the "big picture" at some level of detail, development priority is given to those issues that are most relevant to currently anticipated studies. For example, models of the delivery and effectiveness of information operations messaging were among the additions in Athena 4.

Chamberlain, Robert G.↗

NASA NTRS2013

Athena in 2013 and Beyond

TRISA, the U.S. Army TRADOC G2 Intelligence Support Activity, received Athena 1 in 2009. They first used Athena 3 to support studies in 2011. This paper describes Athena 4, which they started using in October 2012. A final section discusses issues that are being considered for incorporation into Athena 5 and later. Athena's objective is to help skilled intelligence analysts anticipate the likely consequences of complex courses of action that use our country's entire power base, not just our military capabilities, for operations in troubled regions of the world. Measures of effectiveness emphasize who is in control and the effects of our actions on the attitudes and well being of civilians. The planning horizon encompasses not weeks or months, but years.Athena is a scalable, laptop-based simulation with weekly resolution. Up to three months of simulated time can pass between game turns that require user interaction. Athena's geographic scope is nominally a country, but can be a region within a county. Geographic resolution is "neighborhoods", which are defined by the user and may be actual neighborhoods, provinces, or anything in between. Models encompass phenomena whose effects are expected to be relevant over a medium-term planning horizon--three months to three years.The scope and intrinsic complexity of the problem dictate a spiral development process. That is, the model is used during development and lessons learned are used to improve the model. Even more important is that while every version must consider the "big picture" at some level of detail, development priority is given to those issues that are most relevant to currently anticipated studies. For example, models of the delivery and effectiveness of information operations messaging were among the additions in Athena 4.

Diplomatic, Informational, Military, Economic (DIM↗

NASA NTRS1982

Program Structure Combines Segmentation and Dynamic Storage

Programing techniques incorporate advantages of overlaying into segmented loads while retaining all dynamic load advantages of segmentation, employing those capabilities that best suit mode of operation, whether batch or interactive. User is allowed to load a program automatically in a variable manner, based solely on a single data input to the program, to maintain minimal field lengths for interactive use.

Tiffany, S. H.↗

NASA NTRS1979

Man-machine interfaces in LACIE/ERIPS

One of the most important aspects of the interactive portion of the LACIE/ERIPS software system is the way in which the analysis and decision-making capabilities of a human being are integrated with the speed and accuracy of a computer to produce a powerful analysis system. The three major man-machine interfaces in the system are (1) the use of menus for communications between the software and the interactive user; (2) the checkpoint/restart facility to recreate in one job the internal environment achieved in an earlier one; and (3) the error recovery capability which would normally cause job termination. This interactive system, which executes on an IBM 360/75 mainframe, was adapted for use in noninteractive (batch) mode. A case study is presented to show how the interfaces work in practice by defining some fields based on an image screen display, noting the field definitions, and obtaining a film product of the classification map.

Duprey, B. B.↗

NASA NTRS1998

A Geometry Based Infra-Structure for Computational Analysis and Design

The computational steps traditionally taken for most engineering analysis suites (computational fluid dynamics (CFD), structural analysis, heat transfer and etc.) are: (1) Surface Generation -- usually by employing a Computer Assisted Design (CAD) system; (2) Grid Generation -- preparing the volume for the simulation; (3) Flow Solver -- producing the results at the specified operational point; (4) Post-processing Visualization -- interactively attempting to understand the results. For structural analysis, integrated systems can be obtained from a number of commercial vendors. These vendors couple directly to a number of CAD systems and are executed from within the CAD Graphical User Interface (GUI). It should be noted that the structural analysis 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 to Initial Graphics Exchange Specification (IGES) or Standard Exchange Program (STEP) 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). 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. Specifically the problems with this procedure are:(1) File based -- Information flows from one step to the next via data files with formats specified for that procedure. File standards, when they exist, are wholly inadequate. For example, geometry from CAD systems (transmitted via IGES files) is defined as disjoint surfaces and curves (as well as masses of other information of no interest for the Grid Generator). This is particularly onerous for modern CAD systems based on solid modeling. The part was a proper solid and in the translation to IGES has lost this important characteristic. STEP is another standard for CAD data that exists and supports the concept of a solid. The problem with STEP is that a solid modeling geometry kernel is required to query and manipulate the data within this type of file. (2) 'Good' Geometry. A bottleneck in getting results from a solver is the construction of proper geometry to be fed to the grid generator. With 'good' geometry a grid can be constructed in tens of minutes (even with a complex configuration) using unstructured techniques. Adroit multi-block methods are not far behind. This means that a million node steady-state solution can be computed on the order of hours (using current high performance computers) starting from this 'good' geometry. Unfortunately, the geometry usually transmitted from the CAD system is not 'good' in the grid generator sense. The grid generator needs smooth closed solid geometry. It can take a week (or more) of interaction with the CAD output (sometimes by hand) before the process can begin. One way Communication. (3) One-way Communication -- All information travels on from one phase to the next. This makes procedures like node adaptation difficult when attempting to add or move nodes that sit on bounding surfaces (when the actual surface data has been lost after the grid generation phase). Until this process can be automated, more complex problems such as multi-disciplinary analysis or using the above procedure for design becomes prohibitive. There is also no way to easily deal with this system in a modular manner. One can only replace the grid generator, for example, if the software reads and writes the same files. Instead of the serial approach to analysis as described above, CAPRI takes a geometry centric approach. This makes the actual geometry (not a discretized version) accessible to all phases of the analysis. The connection to the geometry is made through an Application Programming Interface (API) and NOT a file system. This API isolates the top-level applications (grid generators, solvers and visualization components) from the geometry engine. Also this allows the replacement of one geometry kernel with another, without effecting these top-level applications. For example, if UniGraphics is used as the CAD package then Parasolid (UG's own geometry engine) can be used for all geometric queries so that no solid geometry information is lost in a translation. This is much better than STEP because when the data is queried, the same software is executed as used in the CAD system. Therefore, one analyzes the exact part that is in the CAD system. CAPRI uses the same idea as the commercial structural analysis codes but does not specify control. Software components of the CAD system are used, but the analysis suite, not the CAD operator, specifies the control of the software session. This also means that the license issues (may be) minimized and individuals need not have to know how to operate a CAD system in order to run the suite.

Haimes, Robert↗

NASA NTRS2024

Creating Camera Controls for First-Person Camera in VulkanSceneGraph

The way users interact with a virtual, three-dimensional (3D) scene is heavily influenced by the way the camera used to view the scene is controlled. A first-person camera is a common form of camera control for computer programs. Its role is to create an immersive viewer experience, which allows users to traverse a scene as they might in the real world. Allowing for the implementation of the first-person camera makes for a more holistic, well-rounded way to interact with the visualization program. Accomplishing this involves mathematical calculations that define how the camera should be moved for the computer system. These movements equate to the rotation, translation, and scale of the changes. It should be noted that a computer does not inherently process what movement directions (left, right, up, or down) mean. The mathematical equations used define these principles in a way the computer can process. Further aspects to consider are detecting when the camera has moved and how far. This is most frequently accomplished through user |input through external devices. These devices, for the purpose of this report, include mouse input and keyboard input. Additionally, the in-development program this report is referencing works with the VulkanSceneGraph (VSG) library to create the scene and build the base of the camera controls. Although VSG is a powerful library with many capabilities, additional Application Programming Interfaces (APIs) might be needed during development to produce the desired results, as is the case in this program. Through combining proper mathematical calculations, utilizing additional APIs, and implementing the existing VSG library capabilities, implementing first-person camera controls is possible in a 3D scene.

Kristie O'Brien↗

NASA NTRS1984

A microprocessor-based control system for the Vienna PDS microdensitometer

The Motorola Exorset 30 system, based on a Motorola 6809 microprocessor which serves as control processor for the microdensitometer is presented. User communication and instrument control are implemented in this syatem; data transmission to a host computer is provided via standard interfaces. The Vienna PDS system (VIPS) software was developed in BASIC and M6809 assembler. It provides efficient user interaction via function keys and argument input in a menu oriented environment. All parameters can be stored on, and retrieved from, minifloppy disks, making it possible to set up large scanning tasks. Extensive user information includes continuously updated status and coordinate displays, as well as a real time graphic display during scanning.

Jenkner, H.↗

NASA NTRS1987

State-space formulation of multi-shaker modal analysis

As modal testing techniques have improved in recent years, the demands placed on the accuracy of modal test results have increased. This paper describes a new multi-input, multi-output modal parameter estimation algorithm suitable for the identification of reduced-order models of structures. The method described is a frequency-domain method based on excitation and response spectra. The principal features of the algorithm are: (1) applicability to general linear, time-invariant systems, (2) direct use of multiple input and multiple response data, (3) identification of reduced-order models with minimum user interaction through the use of two automatic model-reduction techniques, (4) identification of a consistent set of modal parameters through the use of numerically stable least-squares techniques, and (5) complete user documentation.

Craig, Roy R., Jr.↗

NASA NTRS1998

How Human Factors Drove the Design and Implementation of the Virtual Windtunnel

This viewgraph presentation describes decisions made at the NASA Ames Research Center during its development of a virtual windtunnel to assist humans in visualizing computational fluid dynamics simulations. User requirements for the system include the simulation of vortical structure, pressure distribution, and overall sense of flow. In addition, the system needs to support a variety of interfaces, excluding head mounts, and needs to use an object oriented approach. Direct manipulation of the system is most user-friendly when limited to only grab and point gestures. 'Visualization control tools' (vtools) improve the realism of the system. The necessary object oriented programming is in C++ and openGL. Users interact with objects called 'tools', which include vtools and tools which control the virtual wind tunnel environment. Other objects include data objects accessed by the visualizations. Visualizations can be added to the system by the user. The presentation includes a discussion of run-time architecture, and issues related to computation and implementation.

Bryson, Steve↗

NASA NTRS1993

Designers' models of the human-computer interface

Understanding design models of the human-computer interface (HCI) may produce two types of benefits. First, interface development often requires input from two different types of experts: human factors specialists and software developers. Given the differences in their backgrounds and roles, human factors specialists and software developers may have different cognitive models of the HCI. Yet, they have to communicate about the interface as part of the design process. If they have different models, their interactions are likely to involve a certain amount of miscommunication. Second, the design process in general is likely to be guided by designers' cognitive models of the HCI, as well as by their knowledge of the user, tasks, and system. Designers do not start with a blank slate; rather they begin with a general model of the object they are designing. The author's approach to a design model of the HCI was to have three groups make judgments of categorical similarity about the components of an interface: human factors specialists with HCI design experience, software developers with HCI design experience, and a baseline group of computer users with no experience in HCI design. The components of the user interface included both display components such as windows, text, and graphics, and user interaction concepts, such as command language, editing, and help. The judgments of the three groups were analyzed using hierarchical cluster analysis and Pathfinder. These methods indicated, respectively, how the groups categorized the concepts, and network representations of the concepts for each group. The Pathfinder analysis provides greater information about local, pairwise relations among concepts, whereas the cluster analysis shows global, categorical relations to a greater extent.

Gillan, Douglas J.↗

NASA NTRS1982

Report of the Subpanel on Error Characterization and Error Budgets

The state of knowledge of both user positioning requirements and error models of current and proposed satellite systems is reviewed. In particular the error analysis models for LANDSAT D are described. Recommendations are given concerning the geometric error model for the thematic mapper; interactive user involvement in system error budgeting and modeling and verification on real data sets; and the identification of a strawman mission for modeling key error sources.

Source record↗

NASA NTRS2009

Quantifying Therapeutic and Diagnostic Efficacy in 2D Microvascular Images

VESGEN is a newly automated, user-interactive program that maps and quantifies the effects of vascular therapeutics and regulators on microvascular form and function. VESGEN analyzes two-dimensional, black and white vascular images by measuring important vessel morphology parameters. This software guides the user through each required step of the analysis process via a concise graphical user interface (GUI). Primary applications of the VESGEN code are 2D vascular images acquired as clinical diagnostic images of the human retina and as experimental studies of the effects of vascular regulators and therapeutics on vessel remodeling.

Parsons-Wingerter, Patricia↗

NASA NTRS2011

Automated Test Case Generation for an Autopilot Requirement Prototype

Designing safety-critical automation with robust human interaction is a difficult task that is susceptible to a number of known Human-Automation Interaction (HAI) vulnerabilities. It is therefore essential to develop automated tools that provide support both in the design and rapid evaluation of such automation. The Automation Design and Evaluation Prototyping Toolset (ADEPT) enables the rapid development of an executable specification for automation behavior and user interaction. ADEPT supports a number of analysis capabilities, thus enabling the detection of HAI vulnerabilities early in the design process, when modifications are less costly. In this paper, we advocate the introduction of a new capability to model-based prototyping tools such as ADEPT. The new capability is based on symbolic execution that allows us to automatically generate quality test suites based on the system design. Symbolic execution is used to generate both user input and test oracles user input drives the testing of the system implementation, and test oracles ensure that the system behaves as designed. We present early results in the context of a component in the Autopilot system modeled in ADEPT, and discuss the challenges of test case generation in the HAI domain.

Giannakopoulou, Dimitra↗

NASA NTRS1997

A Geometry Based Infra-structure for Computational Analysis and Design

The computational steps traditionally taken for most engineering analysis (CFD, structural analysis, and etc.) are: Surface Generation - usually by employing a CAD system; Grid Generation - preparing the volume for the simulation; Flow Solver - producing the results at the specified operational point; and Post-processing Visualization - interactively attempting to understand the results For structural analysis, integrated systems can be obtained from a number of commercial vendors. 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. Specifically the problems with this procedure are: (1) File based. Information flows from one step to the next via data files with formats specified for that procedure. (2) 'Good' Geometry. A bottleneck in getting results from a solver is the construction of proper geometry to be fed to the grid generator. With 'good' geometry a grid can be constructed in tens of minutes (even with a complex configuration) using unstructured techniques. (3) One-Way communication. All information travels on from one phase to the next. Until this process can be automated, more complex problems such as multi-disciplinary analysis or using the above procedure for design becomes prohibitive.

Haimes, Robert↗

NASA NTRS1999

Automated Flight Dynamics Product Generation for the EOS AM-1 Spacecraft

As part of NASA's Earth Science Enterprise, the Earth Observing System (EOS) AM-1 spacecraft is designed to monitor long-term, global, environmental changes. Because of the complexity of the AM-1 spacecraft, the mission operations center requires more than 80 distinct flight dynamics products (reports). To create these products, the AM-1 Flight Dynamics Team (FDT) will use a combination of modified commercial software packages (e.g., Analytical Graphic's Satellite ToolKit) and NASA-developed software applications. While providing the most cost-effective solution to meeting the mission requirements, the integration of these software applications raises several operational concerns: (1) Routine product generation requires knowledge of multiple applications executing on variety of hardware platforms. (2) Generating products is a highly interactive process requiring a user to interact with each application multiple times to generate each product. (3) Routine product generation requires several hours to complete. (4) User interaction with each application introduces the potential for errors, since users are required to manually enter filenames and input parameters as well as run applications in the correct sequence. Generating products requires some level of flight dynamics expertise to determine the appropriate inputs and sequencing. To address these issues, the FDT developed an automation software tool called AutoProducts, which runs on a single hardware platform and provides all necessary coordination and communication among the various flight dynamics software applications. AutoProducts, autonomously retrieves necessary files, sequences and executes applications with correct input parameters, and deliver the final flight dynamics products to the appropriate customers. Although AutoProducts will normally generate pre-programmed sets of routine products, its graphical interface allows for easy configuration of customized and one-of-a-kind products. Additionally, AutoProducts has been designed as a mission-independent tool, and can be easily reconfigured to support other missions or incorporate new flight dynamics software packages. After the AM-1 launch, AutoProducts will run automatically at pre-determined time intervals . The AutoProducts tool reduces many of the concerns associated with the flight dynamics product generation. Although AutoProducts required a significant effort to develop because of the complexity of the interfaces involved, its use will provide significant cost savings through reduced operator time and maximum product reliability. In addition, user satisfaction is significantly improved and flight dynamics experts have more time to perform valuable analysis work. This paper will describe the evolution of the AutoProducts tool, highlighting the cost savings and customer satisfaction resulting from its development. It will also provide details about the tool including its graphical interface and operational capabilities.

Matusow, Carla↗