Results for “input files” — Page 25

NASA NTRS2000

Developing CORBA-Based Distributed Scientific Applications from Legacy Fortran Programs

Recent progress in distributed object technology has enabled software applications to be developed and deployed easily such that objects or components can work together across the boundaries of the network, different operating systems, and different languages. A distributed object is not necessarily a complete application but rather a reusable, self-contained piece of software that co-operates with other objects in a plug-and-play fashion via a well-defined interface. The Common Object Request Broker Architecture (CORBA), a middleware standard defined by the Object Management Group (OMG), uses the Interface Definition Language (IDL) to specify such an interface for transparent communication between distributed objects. Since IDL can be mapped to any programming language, such as C++, Java, Smalltalk, etc., existing applications can be integrated into a new application and hence the tasks of code re-writing and software maintenance can be reduced. Many scientific applications in aerodynamics and solid mechanics are written in Fortran. Refitting these legacy Fortran codes with CORBA objects can increase the codes reusability. For example, scientists could link their scientific applications to vintage Fortran programs such as Partial Differential Equation(PDE) solvers in a plug-and-play fashion. Unfortunately, CORBA IDL to Fortran mapping has not been proposed and there seems to be no direct method of generating CORBA objects from Fortran without having to resort to manually writing C/C++ wrappers. In this paper, we present an efficient methodology to integrate Fortran legacy programs into a distributed object framework. Issues and strategies regarding the conversion and decomposition of Fortran codes into CORBA objects are discussed. The following diagram shows the conversion and decomposition mechanism we proposed. Our goal is to keep the Fortran codes unmodified. The conversion- aided tool takes the Fortran application program as input and helps programmers generate C/C++ header file and IDL file for wrapping the Fortran code. Programmers need to determine by themselves how to decompose the legacy application into several reusable components based on the cohesion and coupling factors among the functions and subroutines. However, programming effort still can be greatly reduced because function headings and types have been converted to C++ and IDL styles. Most Fortran applications use the COMMON block to facilitate the transfer of large amount of variables among several functions. The COMMON block plays the similar role of global variables used in C. In the CORBA-compliant programming environment, global variables can not be used to pass values between objects. One approach to dealing with this problem is to put the COMMON variables into the parameter list. We do not adopt this approach because it requires modification of the Fortran source code which violates our design consideration. Our approach is to extract the COMMON blocks and convert them into a structure-typed attribute in C++. Through attributes, each component can initialize the variables and return the computation result back to the client. We have tested successfully the proposed conversion methodology based on the f2c converter. Since f2c only translates Fortran to C, we still needed to edit the converted code to meet the C++ and IDL syntax. For example, C++/IDL requires a tag in the structure type, while C does not. In this paper, we identify the necessary changes to the f2c converter in order to directly generate the C++ header and the IDL file. Our future work is to add GUI interface to ease the decomposition task by simply dragging and dropping icons.

Sang, Janche↗

NASA NTRS2007

ISPATOM: A Generic Real-Time Data Processing Tool Without Programming

Information Sharing Protocol Advanced Tool of Math (ISPATOM) is an application program allowing for the streamlined generation of comps, which subscribe to streams of incoming telemetry data, perform any necessary computations on the data, then send the data to other programs for display and/or further processing in NASA mission control centers. Heretofore, the development of comps was difficult, expensive, and time-consuming: Each comp was custom written manually, in a low-level computing language, by a programmer attempting to follow requirements of flight controllers. ISPATOM enables a flight controller who is not a programmer to write a comp by simply typing in one or more equation( s) at a command line or retrieving the equation(s) from a text file. ISPATOM then subscribes to the necessary input data, performs all of necessary computations, and sends out the results. It sends out new results whenever the input data change. The use of equations in ISPATOM is no more difficult than is entering equations in a spreadsheet. The time involved in developing a comp is thus limited to the time taken to decide on the necessary equations. Thus, ISPATOM is a real-time dynamic calculator.

Dershowitz, Adam↗

NASA NTRS2017

The Profile Envision and Splice Tool (PRESTO): Developing an Atmospheric Wind Analysis Tool for Space Launch Vehicles Using Python

Tropospheric winds are an important driver of the design and operation of space launch vehicles. Multiple types of weather balloons and Doppler Radar Wind Profiler (DRWP) systems exist at NASA's Kennedy Space Center (KSC), co-located on the United States Air Force's (USAF) Eastern Range (ER) at the Cape Canaveral Air Force Station (CCAFS), that are capable of measuring atmospheric winds. Meteorological data gathered by these instruments are being used in the design of NASA's Space Launch System (SLS) and other space launch vehicles, and will be used during the day-of-launch (DOL) of SLS to aid in loads and trajectory analyses. For the purpose of SLS day-of-launch needs, the balloons have the altitude coverage needed, but take over an hour to reach the maximum altitude and can drift far from the vehicle's path. The DRWPs have the spatial and temporal resolutions needed, but do not provide complete altitude coverage. Therefore, the Natural Environments Branch (EV44) at Marshall Space Flight Center (MSFC) developed the Profile Envision and Splice Tool (PRESTO) to combine balloon profiles and profiles from multiple DRWPs, filter the spliced profile to a common wavelength, and allow the operator to generate output files as well as to visualize the inputs and the spliced profile for SLS DOL operations. PRESTO was developed in Python taking advantage of NumPy and SciPy for the splicing procedure, matplotlib for the visualization, and Tkinter for the execution of the graphical user interface (GUI). This paper describes in detail the Python coding implementation for the splicing, filtering, and visualization methodology used in PRESTO.

Orcutt, John M.↗

NASA NTRS2007

Predicting Rocket or Jet Noise in Real Time

A semi-empirical theoretical model and a C++ computer program that implements the model have been developed for use in predicting the noise generated by a rocket or jet engine. The computer program, entitled the Realtime Rocket and Jet Engine Noise Analysis and Prediction Software, is one of two main subsystems of the Acoustic Prediction/Measurement Tool, which comprises software, acoustic instrumentation, and electronic hardware combined to afford integrated capabilities for real-time prediction and measurement of noise emitted by rocket and jet engines. [The other main subsystem, consisting largely of acoustic instrumentation and electronic hardware, is described in Wireless Acoustic Measurement System, which appears elsewhere in this section.] The theoretical model was derived from the fundamental laws of fluid mechanics, as first was done by M. J. Lighthill in his now famous theory of aerodynamically generated sound. The far-field approximation of the Lighthill theory is incorporated into this model. Many other contributions from various researchers have also been introduced into the model. The model accounts for two noise components: shear noise and self noise. The final result of the model is expressed in terms of a volume integral of the acoustic intensities attributable to these two components, subject to various directivity coefficients. The computer program was written to solve the volume integral. The inputs required by the program are two data files from a computational fluid dynamics (CFD) simulation of the flow of interest: the computational-grid file and the solution file. The CFD solution should be one that has been obtained for conditions that closely approximate those of an experimental test that is yet to be performed. In the current state of development of the model and software, it is recommended that the observation points lie along a radius at an angle >60 from the jet axis. The software provides, and is driven via, a graphical user interface, which facilitates its use. Optionally, the program accepts additional input in the form of data on the measured sound pressure level as a function of frequency at a given far-field location, preferably at an angle of 90 from the jet axis. The user is prompted to use default empirical constants or to choose constants based the measurement data. The user can view the results and compare them with other computational or experimental data. Once satisfied with the results, the user can save a graph of the results in a file that can be imported into documents.

Frendi, Kader↗

NASA NTRS2000

Mars Global Reference Atmospheric Model 2000 Version (Mars-GRAM 2000): Users Guide

This report presents Mars Global Reference Atmospheric Model 2000 Version (Mars-GRAM 2000) and its new features. All parameterizations for temperature, pressure, density, and winds versus height, latitude, longitude, time of day, and L(sub s) have been replaced by input data tables from NASA Ames Mars General Circulation Model (MGCM) for the surface through 80-km altitude and the University of Arizona Mars Thermospheric General Circulation Model (MTGCM) for 80 to 170 km. A modified Stewart thermospheric model is still used for higher altitudes and for dependence on solar activity. "Climate factors" to tune for agreement with GCM data are no longer needed. Adjustment of exospheric temperature is still an option. Consistent with observations from Mars Global Surveyor, a new longitude-dependent wave model is included with user input to specify waves having 1 to 3 wavelengths around the planet. A simplified perturbation model has been substituted for the earlier one. An input switch allows users to select either East or West longitude positive. This memorandum includes instructions on obtaining Mars-GRAM source code and data files and for running the program. It also provides sample input and output and an example for incorporating Mars-GRAM as an atmospheric subroutine in a trajectory code.

Justus, C. G.↗

NASA NTRS2008

Converting from DDOR SASF to APF

A computer program called ddor_sasf2apf converts delta-door (delta differential one-way range) request from an SASF (spacecraft activity sequence file) format to an APF (apgen plan file) format for use in the Mars Reconnaissance Orbiter (MRO) missionplanning- and-sequencing process. The APF is used as an input to APGEN/AUTOGEN in the MRO activity- planning and command-sequencegenerating process to sequence the delta-door (DDOR) activity. The DDOR activity is a spacecraft tracking technique for determining spacecraft location. The input to ddor_sasf2apf is an input request SASF provided by an observation team that utilizes DDOR. ddor_sasf2apf parses this DDOR SASF input, rearranging parameters and reformatting the request to produce an APF file for use in AUTOGEN and/or APGEN. The benefit afforded by ddor_sasf2apf is to enable the use of the DDOR SASF file earlier in the planning stage of the command-sequence-generating process and to produce sequences, optimized for DDOR operations, that are more accurate and more robust than would otherwise be possible.

Gladden, Roy E.↗

NASA NTRS2012

MPST Software: MoonKommand

This software automatically processes Sally Ride Science (SRS) delivered MoonKAM camera control files (ccf) into uplink products for the GRAIL-A and GRAIL-B spacecraft as part of an education and public outreach (EPO) extension to the Grail Mission. Once properly validated and deemed safe for execution onboard the spacecraft, MoonKommand generates the command products via the Automated Sequence Processor (ASP) and generates uplink (.scmf) files for radiation to the Grail-A and/or Grail-B spacecraft. Any errors detected along the way are reported back to SRS via email. With Moon Kommand, SRS can control their EPO instrument as part of a fully automated process. Inputs are received from SRS as either image capture files (.ccficd) for new image requests, or downlink/delete files (.ccfdl) for requesting image downlink from the instrument and on-board memory management. The Moon - Kommand outputs are command and file-load (.scmf) files that will be uplinked by the Deep Space Network (DSN). Without MoonKommand software, uplink product generation for the MoonKAM instrument would be a manual process. The software is specific to the Moon - KAM instrument on the GRAIL mission. At the time of this writing, the GRAIL mission was making final preparations to begin the science phase, which was scheduled to continue until June 2012.

Kwok, John H.↗

NASA NTRS1986

Development of a ROT22 - DATAMAP interface

This report (Contract NAS2-10331- Mod 10), outlines the development and validation of an interface between the three-dimensional transonic analysis program ROT22 and the Data from Aeromechanics Test and Analytics-Management and Analysis Package (DATAMAP). After development of the interface, the validation is carried out as follows. First, the DATAMAP program is used to analyze a portion of the Tip Aerodynamics and Acoustics Test (TAAT) data. Specifically, records 2872 and 2873 are analyzed at an azimuth of 90 deg, and record 2806 is analyzed at 60 deg. Trim conditions for these flight conditions are then calculated using the Bell performance prediction program ARAM45. Equivalent shaft, pitch, and twist angles are calculated from ARAM45 results and used as input to the ROT22 program. The interface uses the ROT22 results and creates DATAMAP information files from which the surface pressure contours and sectional pressure coefficients are plotted. Twist angles input to ROT22 program are then iteratively modified in the tip region until the computed pressure coefficients closely match the measurements. In all cases studied, the location of the shock is well predicted. However, the negative pressure coefficients were underpredicted. This could be accounted for by blade vortex interaction effects.

Shenoy, K. R.↗

NASA NTRS1977

Interactive LORAN-C to geographic and geographic-to-LORAN-C computation

The LORAN program is stored in CMS disk files for use by Avionics Engineering Center terminal users. A CMS EXEC file named LORAN controls program operation. The user types LORAN and the program then prompts for data input and produces output on the terminal. The FORTRAN program refers to a disk file of LORAN master data giving station locations, coding delays, repetition rate and station pair identification letters. For Geographic-to-LORAN conversion, no iterative computations are required; the program is a straightforward coordinate conversion based upon the techniques described by the Navy. For LORAN-to-Geographic conversion, the original Navy program required a dead-reckoned position, near the actual unknown fix, to begin computations. No iteration was performed to obtain the LORAN fix, but internal program errors occurred at execution time if the dead-reckoned fix were displaced from the actual fix by more than a few minutes of latitude or longitude. In order to enhance usefulness of the program for the terminal user, an iterative routine was added which allows a single dead-reckoned position to be entered from the master data file for each LORAN chain. The results compare exactly with the LORAN-C navigation chart, and provide adequate benchmark data for general aviation flight planning and data analysis.

Piecuch, L. M.↗

NASA NTRS1982

Flight dynamics analysis and simulation of heavy lift airships, volume 4. User's guide: Appendices

This table contains all of the input variables to the three programs. The variables are arranged according to the name list groups in which they appear in the data files. The program name, subroutine name, definition and, where appropriate, a default input value and any restrictions are listed with each variable. The default input values are user supplied, not generated by the computer. These values remove a specific effect from the calculations, as explained in the table. The phrase "not used' indicates that a variable is not used in the calculations and are for identification purposes only. The engineering symbol, where it exists, is listed to assist the user in correlating these inputs with the discussion in the Technical Manual.

Emmen, R. D.↗

NASA NTRS1982

PKI solar thermal plant evaluation at Capitol Concrete Products, Topeka, Kansas

A system feasibility test to determine the technical and operational feasibility of using a solar collector to provide industrial process heat is discussed. The test is of a solar collector system in an industrial test bed plant at Capitol Concrete Products in Topeka, Kansas, with an experiment control at Sandia National Laboratories, Albuquerque. Plant evaluation will occur during a year-long period of industrial utilization. It will include performance testing, operability testing, and system failure analysis. Performance data will be recorded by a data acquisition system. User, community, and environmental inputs will be recorded in logs, journals, and files. Plant installation, start-up, and evaluation, are anticipated for late November, 1981.

Hauger, J. S.↗

NASA NTRS1991

A distributed Petri Net controller for a dual arm testbed

This thesis describes the design and functionality of a Distributed Petri Net Controller (DPNC). The controller runs under X Windows to provide a graphical interface. The DPNC allows users to distribute a Petri Net across several host computers linked together via a TCP/IP interface. A sub-net executes on each host, interacting with the other sub-nets by passing a token vector from host to host. One host has a command window which monitors and controls the distributed controller. The input to the DPNC is a net definition file generated by Great SPN. Thus, a net may be designed, analyzed and verified using this package before implementation. The net is distributed to the hosts by tagging transitions that are host-critical with the appropriate host number. The controller will then distribute the remaining places and transitions to the hosts by generating the local nets, the local marking vectors and the global marking vector. Each transition can have one or more preconditions which must be fulfilled before the transition can fire, as well as one or more post-processes to be executed after the transition fires. These implement the actual input/output to the environment (machines, signals, etc.). The DPNC may also be used to simulate a Great SPN net since stochastic and deterministic firing rates are implemented in the controller for timed transitions.

Bjanes, Atle↗

NASA NTRS1994

Manual for automatic generation of finite element models of spiral bevel gears in mesh

The goal of this research is to develop computer programs that generate finite element models suitable for doing 3D contact analysis of faced milled spiral bevel gears in mesh. A pinion tooth and a gear tooth are created and put in mesh. There are two programs: Points.f and Pat.f to perform the analysis. Points.f is based on the equation of meshing for spiral bevel gears. It uses machine tool settings to solve for an N x M mesh of points on the four surfaces, pinion concave and convex, and gear concave and convex. Points.f creates the file POINTS.OUT, an ASCI file containing N x M points for each surface. (N is the number of node points along the length of the tooth, and M is nodes along the height.) Pat.f reads POINTS.OUT and creates the file tl.out. Tl.out is a series of PATRAN input commands. In addition to the mesh density on the tooth face, additional user specified variables are the number of finite elements through the thickness, and the number of finite elements along the tooth full fillet. A full fillet is assumed to exist for both the pinion and gear.

Bibel, G. D.↗

NASA NTRS2011

Automation of PCXMC and ImPACT for NASA Astronaut Medical Imaging Dose and Risk Tracking

To automate astronaut organ and effective dose calculations from occupational X-ray and computed tomography (CT) examinations incorporating PCXMC and ImPACT tools and to estimate the associated lifetime cancer risk per the National Council on Radiation Protection & Measurements (NCRP) using MATLAB(R). Methods: NASA follows guidance from the NCRP on its operational radiation safety program for astronauts. NCRP Report 142 recommends that astronauts be informed of the cancer risks from reported exposures to ionizing radiation from medical imaging. MATLAB(R) code was written to retrieve exam parameters for medical imaging procedures from a NASA database, calculate associated dose and risk, and return results to the database, using the Microsoft .NET Framework. This code interfaces with the PCXMC executable and emulates the ImPACT Excel spreadsheet to calculate organ doses from X-rays and CTs, respectively, eliminating the need to utilize the PCXMC graphical user interface (except for a few special cases) and the ImPACT spreadsheet. Results: Using MATLAB(R) code to interface with PCXMC and replicate ImPACT dose calculation allowed for rapid evaluation of multiple medical imaging exams. The user inputs the exam parameter data into the database and runs the code. Based on the imaging modality and input parameters, the organ doses are calculated. Output files are created for record, and organ doses, effective dose, and cancer risks associated with each exam are written to the database. Annual and post-flight exposure reports, which are used by the flight surgeon to brief the astronaut, are generated from the database. Conclusions: Automating PCXMC and ImPACT for evaluation of NASA astronaut medical imaging radiation procedures allowed for a traceable and rapid method for tracking projected cancer risks associated with over 12,000 exposures. This code will be used to evaluate future medical radiation exposures, and can easily be modified to accommodate changes to the risk calculation procedure.

Bahadori, Amir↗

NASA NTRS2013

Next Generation Lightweight Mirror Modeling Software

The advances in manufacturing techniques for lightweight mirrors, such as EXELSIS deep core low temperature fusion, Corning's continued improvements in the Frit bonding process and the ability to cast large complex designs, combined with water-jet and conventional diamond machining of glasses and ceramics has created the need for more efficient means of generating finite element models of these structures. Traditional methods of assembling 400,000 + element models can take weeks of effort, severely limiting the range of possible optimization variables. This paper will introduce model generation software developed under NASA sponsorship for the design of both terrestrial and space based mirrors. The software deals with any current mirror manufacturing technique, single substrates, multiple arrays of substrates, as well as the ability to merge submodels into a single large model. The modeler generates both mirror and suspension system elements, suspensions can be created either for each individual petal or the whole mirror. A typical model generation of 250,000 nodes and 450,000 elements only takes 5-10 minutes, much of that time being variable input time. The program can create input decks for ANSYS, ABAQUS and NASTRAN. An archive/retrieval system permits creation of complete trade studies, varying cell size, depth, and petal size, suspension geometry with the ability to recall a particular set of parameters and make small or large changes with ease. The input decks created by the modeler are text files which can be modified by any editor, all the key shell thickness parameters are accessible and comments in deck identify which groups of elements are associated with these parameters. This again makes optimization easier. With ANSYS decks, the nodes representing support attachments are grouped into components; in ABAQUS these are SETS and in NASTRAN as GRIDPOINT SETS, this make integration of these models into large telescope or satellite models possible.

Arnold, William↗

NASA NTRS2013

Next-Generation Lightweight Mirror Modeling Software

The advances in manufacturing techniques for lightweight mirrors, such as EXELSIS deep core low temperature fusion, Corning's continued improvements in the Frit bonding process and the ability to cast large complex designs, combined with water-jet and conventional diamond machining of glasses and ceramics has created the need for more efficient means of generating finite element models of these structures. Traditional methods of assembling 400,000 + element models can take weeks of effort, severely limiting the range of possible optimization variables. This paper will introduce model generation software developed under NASA sponsorship for the design of both terrestrial and space based mirrors. The software deals with any current mirror manufacturing technique, single substrates, multiple arrays of substrates, as well as the ability to merge submodels into a single large model. The modeler generates both mirror and suspension system elements, suspensions can be created either for each individual petal or the whole mirror. A typical model generation of 250,000 nodes and 450,000 elements only takes 5-10 minutes, much of that time being variable input time. The program can create input decks for ANSYS, ABAQUS and NASTRAN. An archive/retrieval system permits creation of complete trade studies, varying cell size, depth, and petal size, suspension geometry with the ability to recall a particular set of parameters and make small or large changes with ease. The input decks created by the modeler are text files which can be modified by any editor, all the key shell thickness parameters are accessible and comments in deck identify which groups of elements are associated with these parameters. This again makes optimization easier. With ANSYS decks, the nodes representing support attachments are grouped into components; in ABAQUS these are SETS and in NASTRAN as GRIDPOINT SETS, this make integration of these models into large telescope or satellite models possible

Arnold, William R., Sr.↗

NASA NTRS2013

Next Generation Lightweight Mirror Modeling Software

The advances in manufacturing techniques for lightweight mirrors, such as EXELSIS deep core low temperature fusion, Corning's continued improvements in the Frit bonding process and the ability to cast large complex designs, combined with water-jet and conventional diamond machining of glasses and ceramics has created the need for more efficient means of generating finite element models of these structures. Traditional methods of assembling 400,000 + element models can take weeks of effort, severely limiting the range of possible optimization variables. This paper will introduce model generation software developed under NASA sponsorship for the design of both terrestrial and space based mirrors. The software deals with any current mirror manufacturing technique, single substrates, multiple arrays of substrates, as well as the ability to merge submodels into a single large model. The modeler generates both mirror and suspension system elements, suspensions can be created either for each individual petal or the whole mirror. A typical model generation of 250,000 nodes and 450,000 elements only takes 5-10 minutes, much of that time being variable input time. The program can create input decks for ANSYS, ABAQUS and NASTRAN. An archive/retrieval system permits creation of complete trade studies, varying cell size, depth, and petal size, suspension geometry with the ability to recall a particular set of parameters and make small or large changes with ease. The input decks created by the modeler are text files which can be modified by any editor, all the key shell thickness parameters are accessible and comments in deck identify which groups of elements are associated with these parameters. This again makes optimization easier. With ANSYS decks, the nodes representing support attachments are grouped into components; in ABAQUS these are SETS and in NASTRAN as GRIDPOINT SETS, this make integration of these models into large telescope or satellite models easier.

Arnold, William R., Sr.↗

NASA NTRS2024

Discrete Event Simulation-Based Timeline Validation Using R2U2

The Gateway Vehicle Systems Manager (VSM), the top-level software control system in a distributed, hierarchical Autonomous System Management Architecture is, like most modern spacecraft software control systems, heavily data-driven. For example, schedules (timelines) will be developed on the ground and, due to the high degree of autonomy, contain complex procedures involving conditional branching, variable timing, and resource contention resolution. In order to verify that an uploaded timeline will function correctly, it is necessary to explore the feasible set of possible executions. While it is possible to test a timeline using a mission simulation, the complexity of the system and duration of a timeline limits the number of trials and therefore the test coverage. To address this problem, the VSM team is using a discrete event system model that can rapidly generate from a timeline sets of event sequences using Monte Carlo techniques. To achieve rapid and trustworthy checking of the event sequences, we use an offline version of the runtime model checking tool R2U2. This presentation describes the approach the VSM team is using to implement the discrete event simulation and evaluate event sequences using R2U2. The presentation will discuss: 1. Description of the timelines by VSM in the context of VSM operations 2. Expansion of a timeline into a sequence of atomic events 3. Adjustment, in the Monte Carlo environment, of an event sequence to account for uncertainty, external events, and failures 4. Definition of R2U2 input and mission-time linear temporal logic files 5. Generation and use of R2U2 verdict sequences 6. Lessons learned and future work

Verification↗