Search NASA⌕ Search

SEARCH · Search NASA

Results for “block codes”

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.

673 records · Page 38

Method for Veterbi decoding of large constraint length convolutional codes

A new method of Viterbi decoding of convolutional codes lends itself to a pipline VLSI architecture using a single sequential processor to compute the path metrics in the Viterbi trellis. An array method is used to store the path information for NK intervals where N is a number, and K is constraint length. The selected path at the end of each NK interval is then selected from the last entry in the array. A trace-back method is used for returning to the beginning of the selected path back, i.e., to the first time unit of the interval NK to read out the stored branch metrics of the selected path which correspond to the message bits. The decoding decision made in this way is no longer maximum likelihood, but can be almost as good, provided that constraint length K in not too small. The advantage is that for a long message, it is not necessary to provide a large memory to store the trellis derived information until the end of the message to select the path that is to be decoded; the selection is made at the end of every NK time unit, thus decoding a long message in successive blocks.

Hsu, In-Shek↗

A Navier-Strokes Chimera Code on the Connection Machine CM-5: Design and Performance

We have implemented a three-dimensional compressible Navier-Stokes code on the Connection Machine CM-5. The code is set up for implicit time-stepping on single or multiple structured grids. For multiple grids and geometrically complex problems, we follow the 'chimera' approach, where flow data on one zone is interpolated onto another in the region of overlap. We will describe our design philosophy and give some timing results for the current code. A parallel machine like the CM-5 is well-suited for finite-difference methods on structured grids. The regular pattern of connections of a structured mesh maps well onto the architecture of the machine. So the first design choice, finite differences on a structured mesh, is natural. We use centered differences in space, with added artificial dissipation terms. When numerically solving the Navier-Stokes equations, there are liable to be some mesh cells near a solid body that are small in at least one direction. This mesh cell geometry can impose a very severe CFL (Courant-Friedrichs-Lewy) condition on the time step for explicit time-stepping methods. Thus, though explicit time-stepping is well-suited to the architecture of the machine, we have adopted implicit time-stepping. We have further taken the approximate factorization approach. This creates the need to solve large banded linear systems and creates the first possible barrier to an efficient algorithm. To overcome this first possible barrier we have considered two options. The first is just to solve the banded linear systems with data spread over the whole machine, using whatever fast method is available. This option is adequate for solving scalar tridiagonal systems, but for scalar pentadiagonal or block tridiagonal systems it is somewhat slower than desired. The second option is to 'transpose' the flow and geometry variables as part of the time-stepping process: Start with x-lines of data in-processor. Form explicit terms in x, then transpose so y-lines of data are in-processor. Form explicit terms in y, then transpose so z-lines are in processor. Form explicit terms in z, then solve linear systems in the z-direction. Transpose to the y-direction, then solve linear systems in the y-direction. Finally transpose to the x direction and solve linear systems in the x-direction. This strategy avoids inter-processor communication when differencing and solving linear systems, but requires a large amount of communication when doing the transposes. The transpose method is more efficient than the non-transpose strategy when dealing with scalar pentadiagonal or block tridiagonal systems. For handling geometrically complex problems the chimera strategy was adopted. For multiple zone cases we compute on each zone sequentially (using the whole parallel machine), then send the chimera interpolation data to a distributed data structure (array) laid out over the whole machine. This information transfer implies an irregular communication pattern, and is the second possible barrier to an efficient algorithm. We have implemented these ideas on the CM-5 using CMF (Connection Machine Fortran), a data parallel language which combines elements of Fortran 90 and certain extensions, and which bears a strong similarity to High Performance Fortran. We make use of the Connection Machine Scientific Software Library (CMSSL) for the linear solver and array transpose operations.

Jespersen, Dennis C.↗

DMFS: A Data Migration File System for NetBSD

I have recently developed dmfs, a Data Migration File System, for NetBSD. This file system is based on the overlay file system, which is discussed in a separate paper, and provides kernel support for the data migration system being developed by my research group here at NASA/Ames. The file system utilizes an underlying file store to provide the file backing, and coordinates user and system access to the files. It stores its internal meta data in a flat file, which resides on a separate file system. Our data migration system provides archiving and file migration services. System utilities scan the dmfs file system for recently modified files, and archive them to two separate tape stores. Once a file has been doubly archived, files larger than a specified size will be truncated to that size, potentially freeing up large amounts of the underlying file store. Some sites will choose to retain none of the file (deleting its contents entirely from the file system) while others may choose to retain a portion, for instance a preamble describing the remainder of the file. The dmfs layer coordinates access to the file, retaining user-perceived access and modification times, file size, and restricting access to partially migrated files to the portion actually resident. When a user process attempts to read from the non-resident portion of a file, it is blocked and the dmfs layer sends a request to a system daemon to restore the file. As more of the file becomes resident, the user process is permitted to begin accessing the now-resident portions of the file. For simplicity, our data migration system divides a file into two portions, a resident portion followed by an optional non-resident portion. Also, a file is in one of three states: fully resident, fully resident and archived, and (partially) non-resident and archived. For a file which is only partially resident, any attempt to write or truncate the file, or to read a non-resident portion, will trigger a file restoration. Truncations and writes are blocked until the file is fully restored so that a restoration which only partially succeed does not leave the file in an indeterminate state with portions existing only on tape and other portions only in the disk file system. We chose layered file system technology as it permits us to focus on the data migration functionality, and permits end system administrators to choose the underlying file store technology. We chose the overlay layered file system instead of the null layer for two reasons: first to permit our layer to better preserve meta data integrity and second to prevent even root processes from accessing migrated files. This is achieved as the underlying file store becomes inaccessible once the dmfs layer is mounted. We are quite pleased with how the layered file system has turned out. Of the 45 vnode operations in NetBSD, 20 (forty-four percent) required no intervention by our file layer - they are passed directly to the underlying file store. Of the twenty five we do intercept, nine (such as vop_create()) are intercepted only to ensure meta data integrity. Most of the functionality was concentrated in five operations: vop_read, vop_write, vop_getattr, vop_setattr, and vop_fcntl. The first four are the core operations for controlling access to migrated files and preserving the user experience. vop_fcntl, a call generated for a certain class of fcntl codes, provides the command channel used by privileged user programs to communicate with the dmfs layer.

Studenmund, William↗

A Multi-Disciplinary Analysis Framework for the Design of Small Launch Vehicles

Between the years of 1995 and 2014 the number of small satellites (1-500 kg) went up from 20 to 180. [1] Out of the 180 launched in 2014 66% were Nano satellites (1-10 kg). [1] With this trend of smaller satellites, one would expect a rise in number of small launch vehicles (SLVs are defined by capability to carry 1-100 kg to orbit), but this has not happened: [3] only 8% of all small satellites are launched on SLVs and the others become secondary payloads on regular launch vehicles. [1] This results in small satellites being placed into either suboptimal orbits or waiting for launch schedules to align with bigger launches, resulting in long waiting times. Dedicated SLVs could improve the responsiveness of small satellite launches, but SLV design is complicated by the large architecture space needed to be explored in order to find efficient and affordable designs. The SLV architecture trade space contains many discrete options, e.g. solid vs. liquid fuels, air launch vs. ground launch, number of stages, etc. [2][3] Performing detailed analysis for all the options at once would be prohibitive. Thus, a sizing environment/framework that is capable of providing necessary information for conceptual-level trade studies and can rapidly explore the vast SLV architecture space is necessary. The framework, illustrated in Figure 1, consists of four disciplines central to the sizing and synthesis of launch vehicles: propulsion, aerodynamics, structures, and trajectory. For the aerodynamics and trajectory disciplines, Missile DATCOM and POST2 are used, respectively. The propulsion and structures disciplines are represented in the framework with tools developed at ASDL Georgia Tech. For propulsion, the Solid Motor Analysis Code (SMAC) is a physics-based conceptual design tool for solid rocket motors. SMAC is capable of geometric burn simulation, ballistic analysis, and prediction of thrust performance. [4] For structures, Launch Vehicle Structural Analysis (LVSA) tool is a physics-based tool that focuses on structural dynamic analysis with sizing capability. These tools are integrated into the framework illustrated in Figure 1 with the corresponding connections described in Table 1. The process flow is as follows: first, SMAC sizes insulation and calculates maximum operating pressures for each vehicle stage. The MEOP and insulation thickness values from SMAC are fed to LVSA which then utilizes this information to size the motor casing. This creates a feedback loop between LVSA and SMAC that converges on the radius available for fuel, casing, and insulation thickness. Once the stage sizing is converged on SMAC creates an engine deck that is passed to POST2. Next, the data from SMAC and LVSA goes into Missile DATCOM which generates an aerodynamics database for POST2. Finally, POST2 performs a targeting optimization while maximizing the payload mass to orbit. Within the framework, POST2 is automated in order to be robust to a wide variety of possible designs by performing a Monte Carlo simulation over the initialization vector of the POST2 optimization variables. To demonstrate the capability of this framework, a sample problem of exploring the design space of an SLV capable of placing satellites into a low Earth orbit (inclination=47 deg, 196.5 by 211.3 nm) is used. This sample problem is a ground-launched SLV consisting of four in-line SRM stages. The multidisciplinary design analysis (MDA) environment is utilized to explore a design space consisting of 22 continuous and 12 discrete variables, shown by Table 1 by blocks 1,2,3. Running a full factorial design of experiments (DOE) would have been prohibitively expensive even with this reduced design space, thus a space filling design with 3,502 and then additional expansion of 2,602 cases was used. The first DOE consisted of 3,502 cases, and all of the variables were varied. These input variables are listed in blocks 1, 2, and 3 in Table 1. Most of the variables are propulsion related with stage lengths determining the delta-V split of the SLV. The expansion consisted of 2,602 cases, and the continuous variables were set to be equal to the most promising designs from the sizing of first DOE. For each set of continuous variables, the discrete variables (grain type, star points, and propellant) were to varied. The results of the DOE can be seen in Figure 2; each of the points in this plot represents a closed launch vehicle that reaches the targeted orbit. For each of the cases, there is information on flown trajectory, structural, and propulsion properties of the SLV. For example, Figure 3 shows changes in altitude and velocity with time for a particular case. The right side of Figure 3 clearly shows the coasting (slow decrease) and burning phases (sharp increase) of the SLV mission. LV mass is positively correlated with the optimized payload mass to orbit because heavier LVs carry more fuel and thus have more stored chemical energy. Furthermore, for any given payload mass to orbit, the most efficient design would result in the smallest LV. The results as visualized in Figure 2 shows this tradeoff, and the Pareto frontier of the efficient designs can be seen along the dotted line. Figure 2 can be divided into regions with the lowest mass vehicles corresponding to the minimum bound on radius, and the highest mass vehicles corresponding to the maximum bound on radius. Within a mass region, the discrete variables, such as propellant type and propellant grain arrangement, have the most effect on payload mass. This paper presents an MDA framework that can perform an automated physics-based sizing of SLV designs and a corresponding methodology to utilize the MDA to explore the design space of SLVs. The proposed methodology was applied to a perform a design space exploration for a four stage SLV. The outputs show the expected pareto frontier forming and provide detailed information about the SLV performance and staging. Using the produced data, it will be possible to select a set of pareto optimal designs that can then be further explored in subsequent design cycles. This demonstration shows that automated design space exploration should be used in the early phase design of future SLV concepts.

Nikita S Birbasov↗

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↗

Dynamic Mode Decomposition of Unsteady Pressure-Sensitive Paint Measurements for the NASA Unitary Plan Wind Tunnel Tests

This paper describes the Dynamic Mode Decomposition (DMD) of the pressures on the scale model of the Space Launch System (SLS) Block 1 cargo vehicle with the Unsteady Pressure-Sensitive Paint (uPSP) measurements, which were collected in the Ascent Transient Aerodynamics Tests with the Unitary Plan Wind Tunnel 11-by-11-foot Transonic Wind Tunnel in September 2019 at NASA Ames Research Center. The work described in this paper is a part of NASA’s development of a new state-of-the-art uPSP capability in production wind tunnels. The conventional DMD algorithm is based on the Singular Value Decomposition (SVD) of the data matrix. For the matrix of the uPSP measurements of the SLS ATAT, the number of rows is equal to the number of nodes in the grid of the scale model, and the number of columns is equal to the number of frames in the videos taken with 4 Phantom high-speed cameras. In this paper, it is verified that, for the time series with zero mean value, the DMD is equivalent to the decomposition with the Discrete Fourier Transform (DFT). Considering the uPSP is mainly used in the assessment of the unsteady, aerodynamic phenomena, the DMD of the uPSP measurements can be implemented in two steps: (1) subtract the mean value from the uPSP measurement on each of the grid nodes; (2) apply the Fast Fourier Transform (FFT) on the resulting zero-mean time series. The DMD of the uPSP measurements with FFT has two advantages: (1) the computational complexity of FFT is O(N*logN), where N is the length of the time series; (2) compared to the SVD-based DMD algorithm, the DMD with FFT can be easily implemented in parallel processing. A sample matrix of uPSP measurements, at the size of 341 grid nodes and 128 frames, is generated. Figures 1 and 2 show the eigenvalues and the ratios of the eigenvectors, respectively, of the sample matrix, without and with the mean value removed on each of the grid nodes, computed with the SVD-based DMD and the FFT. The figures demonstrate the equivalence of the SVD-based DMD and the decomposition with DFT/FFT for the time series with zero mean value. The results of DMD of the uPSP measurements of the SLS ATAT in September 2019 are presented in the paper. The DMD modes at different frequencies are shown, the aerodynamic phenomena (e.g. shockwave and vortex shedding) are demonstrated and the correlation of the DMD modes with the test configuration parameter (e.g., the Mach Number) is discussed. Figure 3 shows a software tool to visualize the DMD modes. The code to implement the algorithm described in this paper was written in C, with libraries of FFTW for FFT and MPI/OpenMP for parallel processing, and executed on the NASA Pleiades supercomputer. Funding for this research was provided by the NASA Aerosciences Evaluation and Test Capabilities Project.

Pressure-Sensitive Paint↗

Wireless Avionics Packet to Support Fault Tolerance for Flight Applications

In this protocol and packet format, data traffic is monitored by all network interfaces to determine the health of transmitter and subsystems. When failures are detected, the network inter face applies its recover y policies to provide continued service despite the presence of faults. The protocol, packet format, and inter face are independent of the data link technology used. The current demonstration system supports both commercial off-the-shelf wireless connections and wired Ethernet connections. Other technologies such as 1553 or serial data links can be used for the network backbone. The Wireless Avionics packet is divided into three parts: a header, a data payload, and a checksum. The header has the following components: magic number, version, quality of service, time to live, sending transceiver, function code, payload length, source Application Data Interface (ADI) address, destination ADI address, sending node address, target node address, and a sequence number. The magic number is used to identify WAV packets, and allows the packet format to be updated in the future. The quality of service field allows routing decisions to be made based on this value and can be used to route critical management data over a dedicated channel. The time to live value is used to discard misrouted packets while the source transceiver is updated at each hop. This information is used to monitor the health of each transceiver in the network. To identify the packet type, the function code is used. Besides having a regular data packet, the system supports diagnostic packets for fault detection and isolation. The payload length specifies the number of data bytes in the payload, and this supports variable-length packets in the network. The source ADI is the address of the originating interface. This can be used by the destination application to identify the originating source of the packet where the address consists of a subnet, subsystem class within the subnet, a subsystem unit, and the local ADI number. The destination ADI is used to route the packet to its ultimate destination. At each hop, the sending interface uses the destination address to determine the next node for the data. The sending node is the node address of the interface that is broadcasting the packet. This field is used to determine the health of the subsystem that is sending the packet. In the case of a packet that traverses several intermediate nodes, it may be the node address of the intermediate node. The target node is the node address of the next hop for the packet. It may be an intermediate node, or the final destination for the packet. The sequence number is used to identify duplicate packets. Because each interface has multiple transceivers, the same packet will appear at both receivers. The sequence number allows the interface to correlate the reception and forward a single, unique packet for additional processing. The subnet field allows data traffic to be partitioned into segregated local networks to support large networks while keeping each subnet at a manageable size. This also keeps the routing table small enough so routing can be done by a simple table lookup in an FPGA device. The subsystem class identifies members of a set of redundant subsystems, and, in a hot standby configuration, all members of the subsystem class will receive the data packets. Only the active subsystem will generate data traffic. Specific units in a class of redundant units can be identified and, if the hot standby configuration is not used, packets will be directed to a specific subsystem unit.

Block, Gary L.↗