Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Syntax”

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 37 records · Page 2
All sourcesNASA NTRSDOE OSTI
NASA NTRS1992

Fortran for the nineties

Fortran has largely enjoyed prominence for the past few decades as the computer programming language of choice for numerically intensive scientific, engineering, and process control applications. Fortran's well understood static language syntax has allowed resulting parsers and compiler optimizing technologies to often generate among the most efficient and fastest run-time executables, particularly on high-end scalar and vector supercomputers. Computing architectures and paradigms have changed considerably since the last ANSI/ISO Fortran release in 1978, and while FORTRAN 77 has more than survived, it's aged features provide only partial functionality for today's demanding computing environments. The simple block procedural languages have been necessarily evolving, or giving way, to specialized supercomputing, network resource, and object-oriented paradigms. To address these new computing demands, ANSI has worked for the last 12-years with three international public reviews to deliver Fortran 90. Fortran 90 has superseded and replaced ISO FORTRAN 77 internationally as the sole Fortran standard; while in the US, Fortran 90 is expected to be adopted as the ANSI standard this summer, coexisting with ANSI FORTRAN 77 until at least 1996. The development path and current state of Fortran will be briefly described highlighting the many new Fortran 90 syntactic and semantic additions which support (among others): free form source; array syntax; new control structures; modules and interfaces; pointers; derived data types; dynamic memory; enhanced I/O; operator overloading; data abstraction; user optional arguments; new intrinsics for array, bit manipulation, and system inquiry; and enhanced portability through better generic control of underlying system arithmetic models. Examples from dynamical astronomy, signal and image processing will attempt to illustrate Fortran 90's applicability to today's general scalar, vector, and parallel scientific and engineering requirements and object oriented programming paradigms. Time permitting, current work proceeding on the future development of Fortran 2000 and collateral standards will be introduced.

Himer, J. T.↗
NASA NTRS1994

Use of data description languages in the interchange of data

The Consultative Committee for Space Data Systems (CCSDS) is developing Standards for the interchange of information between systems, including those operating under different environments. The objective is to perform the interchange automatically, i.e. in a computer interpretable manner. One aspect of the concept developed by CCSDS is the use of a separate data description to specify the data being transferred. Using the description, data can then be automatically parsed by the receiving computer. With a suitably expressive Data Description Language (DDL), data formats of arbitrary complexity can be handled. The advantages of this approach are: (1) that the description need only be written and distributed once to all users, and (2) new software does not need to be written for each new format, provided generic tools are available to support writing and interpretation of descriptions and the associated data instances. Consequently, the effort of 'hard coding' each new format is avoided and problems of integrating multiple implementations of a given format by different users are avoided. The approach is applicable in any context where computer parsable description of data could enhance efficiency (e.g. within a spacecraft control system, a data delivery system or an archive). The CCSDS have identified several candidate DDL's: EAST (Extended Ada Subset), TSDN (Transfer Syntax Data Notation) and MADEL (Modified ASN.1 as a Data Description Language -- a DDL based on the Abstract Syntax Notation One - ASN.1 - specified in the ISO/IEC 8824). This paper concentrates on ESA's development of MADEL. ESA have also developed a 'proof of concept' prototype of the required support tools, implemented on a PC under MS-DOS, which has successfully demonstrated the feasibility of the approach, including the capability within an application of retrieving and displaying particular data elements, given its MADEL description (i.e. a data description written in MADEL). This paper outlines the work done to date and assesses the applicability of this modified ASN.1 as a DDL. The feasibility of the approach is illustrated with several examples.

Pignede, M.↗
NASA NTRS1997

A Categorization of Dynamic Analyzers

Program analysis techniques and tools are essential to the development process because of the support they provide in detecting errors and deficiencies at different phases of development. The types of information rendered through analysis includes the following: statistical measurements of code, type checks, dataflow analysis, consistency checks, test data,verification of code, and debugging information. Analyzers can be broken into two major categories: dynamic and static. Static analyzers examine programs with respect to syntax errors and structural properties., This includes gathering statistical information on program content, such as the number of lines of executable code, source lines. and cyclomatic complexity. In addition, static analyzers provide the ability to check for the consistency of programs with respect to variables. Dynamic analyzers in contrast are dependent on input and the execution of a program providing the ability to find errors that cannot be detected through the use of static analysis alone. Dynamic analysis provides information on the behavior of a program rather than on the syntax. Both types of analysis detect errors in a program, but dynamic analyzers accomplish this through run-time behavior. This paper focuses on the following broad classification of dynamic analyzers: 1) Metrics; 2) Models; and 3) Monitors. Metrics are those analyzers that provide measurement. The next category, models, captures those analyzers that present the state of the program to the user at specified points in time. The last category, monitors, checks specified code based on some criteria. The paper discusses each classification and the techniques that are included under them. In addition, the role of each technique in the software life cycle is discussed. Familiarization with the tools that measure, model and monitor programs provides a framework for understanding the program's dynamic behavior from different, perspectives through analysis of the input/output data.

Lujan, Michelle R.↗
NASA NTRS2004

Software for Checking Statecharts

HiVy is a software tool set that enables verification through model checking of designs represented as finite-state machines or statecharts. HiVy provides automated translation of (1) statecharts created by use of the MathWorks Stateflow program to (2) Promela, the input language of the Spin model checker, which can then be used to verify, or trace logical errors in, distributed software systems. HiVy can operate directly on Stateflow models, or its abstract syntax of hierarchical sequential automata (HSA) can be used independently as an intermediate format for translation to Promela. In a typical design application, HiVy parses and reformats Stateflow model file data using the programs SfParse and sf2hsa, respectively. If the parsing effort is successful, an abstract syntax tree is delivered into a file named with the extension .hsa. If the design comprises several model files, they may be merged into one .hsa file before translation into Promela. Stateflow scope is preserved, and name clashes are avoided in the merge process. The HiVy program hsa2pr translates the model from the intermediate HSA format into Promela. Additionally, HiVy provides through translation a list of all statechart model propositions that are the means for formalizing linear temporal logic (LTL) properties about the model for Spin verification.

Pingree, Paula↗
NASA NTRS2011

MSLICE Sequencing

MSLICE Sequencing is a graphical tool for writing sequences and integrating them into RML files, as well as for producing SCMF files for uplink. When operated in a testbed environment, it also supports uplinking these SCMF files to the testbed via Chill. This software features a free-form textural sequence editor featuring syntax coloring, automatic content assistance (including command and argument completion proposals), complete with types, value ranges, unites, and descriptions from the command dictionary that appear as they are typed. The sequence editor also has a "field mode" that allows tabbing between arguments and displays type/range/units/description for each argument as it is edited. Color-coded error and warning annotations on problematic tokens are included, as well as indications of problems that are not visible in the current scroll range. "Quick Fix" suggestions are made for resolving problems, and all the features afforded by modern source editors are also included such as copy/cut/paste, undo/redo, and a sophisticated find-and-replace system optionally using regular expressions. The software offers a full XML editor for RML files, which features syntax coloring, content assistance and problem annotations as above. There is a form-based, "detail view" that allows structured editing of command arguments and sequence parameters when preferred. The "project view" shows the user s "workspace" as a tree of "resources" (projects, folders, and files) that can subsequently be opened in editors by double-clicking. Files can be added, deleted, dragged-dropped/copied-pasted between folders or projects, and these operations are undoable and redoable. A "problems view" contains a tabular list of all problems in the current workspace. Double-clicking on any row in the table opens an editor for the appropriate sequence, scrolling to the specific line with the problem, and highlighting the problematic characters. From there, one can invoke "quick fix" as described above to resolve the issue. Once resolved, saving the file causes the problem to be removed from the problem view.

Crockett, Thomas M.↗
NASA NTRSDate not supplied

Kamodo’s Satellite Constellation Mission Planning Tool

Kamodo provides a functional model-agnostic interface to a growing collection of Heliophysics model outputs. The CCMC, in collaboration with the Geospace Dynamics Constellation Science Team, has recently developed Kamodo’s satellite constellation mission planning tool to perform reconstructions in any pair of dimensions, including time. The ‘reconstruction’ tool enables users to fly any 4-dimensional grid of satellites through a given model data set, reconstructing what the given constellation would observe during the mission. This capability facilitates determination of what satellite configuration is best for a given science question, even allowing comparison across multiple models. This tool, written in Python, is built upon Kamodo’s flythrough tool, which in turn depends on a growing network of model-specific interfaces. Since each model interface is designed with model-agnostic syntax, the flythrough tool and the satellite constellation mission planning tool also feature model-agnostic syntax. In this work, we will describe the basic analysis choices available in the tool and provide a variety of sample workflows. The tool is freely available at https://github.com/nasa/Kamodo for the public. We invite the community to use the reconstruction tool and adapt the provided workflows for their mission planning, and to contribute their own workflows to share with others.

software↗
NASA NTRSDate not supplied

SM25C-2002: Kamodo’s Satellite Constellation Mission Planning Tool

Kamodo provides a functional model-agnostic interface to a growing collection of Heliophysics model outputs. The CCMC, in collaboration with the Geospace Dynamics Constellation Science Team, has recently developed Kamodo’s satellite constellation mission planning tool to perform reconstructions in any pair of dimensions, including time. The ‘reconstruction’ tool enables users to fly any 4-dimensional grid of satellites through a given model data set, reconstructing what the given constellation would observe during the mission. This capability facilitates determination of what satellite configuration is best for a given science question, even allowing comparison across multiple models. This tool, written in Python, is built upon Kamodo’s flythrough tool, which in turn depends on a growing network of model-specific interfaces. Since each model interface is designed with model-agnostic syntax, the flythrough tool and the satellite constellation mission planning tool also feature model-agnostic syntax. In this work, we will describe the basic analysis choices available in the tool and provide a variety of sample workflows. The tool is freely available at https://github.com/nasa/Kamodo for the public. We invite the community to use the reconstruction tool and adapt the provided workflows for their mission planning, and to contribute their own workflows to share with others.

python↗
NASA NTRS1964

Linguistics

Phonology, morphology, syntax, language learning & disturbances, linguistic change, semantics, and logical foundations of language theory

LANGUAGE↗
NASA NTRS1969

JFLIP-JPL FORTRAN language with interval pre-processor

FLIP and TMG are a FORTRAN pre-processor and a Syntax-Directed-Compiler used to describe the language in which the former is written. They provide those who write in FORTRAN 4 with greater language flexibility and power.

Germann, D. A.↗
NASA NTRS1971

Architectural design of an Algol interpreter

The design of a syntax-directed interpreter for a subset of Algol is described. It is a conceptual design with sufficient details and completeness but as much independence of implementation as possible. The design includes a detailed description of a scanner, an analyzer described in the Floyd-Evans productions, a hash-coded symbol table, and an executor. Interpretation of sample programs is also provided to show how the interpreter functions.

Jackson, C. K.↗
NASA NTRS1973

Ground Operations Aerospace Language (GOAL) textbook

The textbook provides a semantical explanation accompanying a complete set of GOAL syntax diagrams, system concepts, language component interaction, and general language concepts necessary for efficient language implementation/execution.

Dickison, L. R.↗
NASA NTRS1973

NASTRAN distribution through COSMIC

The NASTRAN program package is one of the most important in terms of size and use in the COSMIC inventory at the University of Georgia. A brief history of the COSMIC facility as it relates to the NASTRAN program package is presented, followed by a discussion of the NASTRAN disseminations. COSMIC, which is the acronym for the Computer Software Management and Information Center, is operated by the University of Georgia's Computer Center under contract to NASA. The purpose of COSMIC is to make available to the public the computer software and documentation developed as part of the NASA program. It is, perhaps, best described as a clearinghouse for the NASA-sponsored computer software, although the functions specified under the contract go much further than simply duplicating the programs and documentation for distribution. A sizeable portion of the workscope involves screening the programs to insure that they are free of syntax errors, that all necessary subroutines are present, and that the documentation includes sufficiently detailed instructions to allow purchasers to install and operate the program or system.

Park, M. K.↗
NASA NTRS1973

Ground Operations Aerospace Language (GOAL). Volume 2: Compiler

The principal elements and functions of the Ground Operations Aerospace Language (GOAL) compiler are presented. The technique used to transcribe the syntax diagrams into machine processable format for use by the parsing routines is described. An explanation of the parsing technique used to process GOAL source statements is included. The compiler diagnostics and the output reports generated during a GOAL compilation are explained. A description of the GOAL program package is provided.

Source record↗
NASA NTRS1973

Ground Operations Aerospace Language (GOAL). Volume 5: Application Studies

The Ground Operations Aerospace Language (GOAL) was designed to be used by test oriented personnel to write procedures which would be executed in a test environment. A series of discussions between NASA LV-CAP personnel and IBM resulted in some peripheral tasks which would aid in evaluating the applicability of the language in this environment, and provide enhancement for future applications. The results of these tasks are contained within this volume. The GOAL vocabulary provides a high degree of readability and retainability. To achieve these benefits, however, the procedure writer utilizes words and phrases of considerable length. Brief form study was undertaken to determine a means of relieving this burden. The study resulted in a version of GOAL which enables the writer to develop a dialect suitable to his needs and satisfy the syntax equations. The output of the compiler would continue to provide readability by printing out the standard GOAL language. This task is described.

Source record↗
NASA NTRS1973

Software approach to automatic patching of analog computer

The Automatic Patching Verification program (APV) is described which provides the hybrid computer programmer with a convenient method of performing a static check of the analog portion of his study. The static check insures that the program is patched as specified, and that the computing components being used are operating correctly. The APV language the programmer uses to specify his conditions and interconnections is similar to the FORTRAN language in syntax. The APV control program reads APV source program statements from an assigned input device. Each source program statement is processed immediately after it is read. A statement may select an analog console, set an analog mode, set a potentiometer or DAC, or read from the analog console and perform a test. Statements are read and processed sequentially. If an error condition is detected, an output occurs on an assigned output device. When an end statement is read, the test is terminated.

Source record↗
NASA NTRS1974

HAL/S programmer's guide

This programming language was developed for the flight software of the NASA space shuttle program. HAL/S is intended to satisfy virtually all of the flight software requirements of the space shuttle. To achieve this, HAL/s incorporates a wide range of features, including applications-oriented data types and organizations, real time control mechanisms, and constructs for systems programming tasks. As the name indicates, HAL/S is a dialect of the original HAL language previously developed. Changes have been incorporated to simplify syntax, curb excessive generality, or facilitate flight code emission.

Newbold, P. M.↗