Search NASA⌕ Search

SEARCH · Search NASA

Results for “Code Case”

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 163 records · Page 9
All sourcesNASA NTRSDOE OSTI
NASA NTRS1987

A new algorithm for the Navier-Stokes equations applied to transonic flows over wings

A new algorithm has been developed for the Navier-Stokes equations. For the convective terms, this algorithm employs flux vector splitting together with a locally rotated coordinate system that is aligned with the streamwise direction. The algorithm has been implemented into a Navier-Stokes code, the NASA Ames Research Center's TNS code, and several cases of steady flow have been calculated. The results show improvements over the original method in the code. First, in a case of separated flow, there is better agreement with the experimental results and also there is an absence of numerical oscillations that occur with the original method. Second, in a case with a strong supersonic to subsonic shock wave, comparisons show an improvement in the resolution of the shock wave and the reexpansion singularity.

Goorjian, Peter M.↗
NASA NTRS1993

Development of code evaluation criteria for assessing predictive capability and performance

Computational Fluid Dynamics (CFD), because of its unique ability to predict complex three-dimensional flows, is being applied with increasing frequency in the aerospace industry. Currently, no consistent code validation procedure is applied within the industry. Such a procedure is needed to increase confidence in CFD and reduce risk in the use of these codes as a design and analysis tool. This final contract report defines classifications for three levels of code validation, directly relating the use of CFD codes to the engineering design cycle. Evaluation criteria by which codes are measured and classified are recommended and discussed. Criteria for selecting experimental data against which CFD results can be compared are outlined. A four phase CFD code validation procedure is described in detail. Finally, the code validation procedure is demonstrated through application of the REACT CFD code to a series of cases culminating in a code to data comparison on the Space Shuttle Main Engine High Pressure Fuel Turbopump Impeller.

Lin, Shyi-Jang↗
NASA NTRS2014

Sinda/Fluint Stratfied Tank Modeling

A general purpose SINDA/FLUINT (S/F) stratified tank model was created and used to simulate the Ksite1 LH2 liquid self-pressurization tests as well as axial jet mixing within the liquid region of the tank. The S/F model employed the use of stratified layers, i.e. S/F lumps, in the vapor ullage as well as in the liquid region. The model was constructed to analyze a general purpose stratified tank that could incorporate the following features: Multiple or singular lumps in the liquid and vapor regions of the tank, Real gases (also mixtures) and compressible liquids, Venting, pressurizing, and draining, Condensation and evaporation/boiling, Wall heat transfer, Elliptical, cylindrical, and spherical tank geometries. Extensive user logic was used to allow for tailoring of the above features to specific cases. Most of the code input for a specific case could be done through the Registers Data Block.

Sinda/Fluint↗
NASA NTRS1999

Advanced Subsonic Technology (AST) Area of Interest (AOI) 6: Develop and Validate Aeroelastic Codes for Turbomachinery

AlliedSignal Engines, in cooperation with NASA GRC (National Aeronautics and Space Administration Glenn Research Center), completed an evaluation of recently-developed aeroelastic computer codes using test cases from the AlliedSignal Engines fan blisk and turbine databases. Test data included strain gage, performance, and steady-state pressure information obtained for conditions where synchronous or flutter vibratory conditions were found to occur. Aeroelastic codes evaluated included quasi 3-D UNSFLO (MIT Developed/AE Modified, Quasi 3-D Aeroelastic Computer Code), 2-D FREPS (NASA-Developed Forced Response Prediction System Aeroelastic Computer Code), and 3-D TURBO-AE (NASA/Mississippi State University Developed 3-D Aeroelastic Computer Code). Unsteady pressure predictions for the turbine test case were used to evaluate the forced response prediction capabilities of each of the three aeroelastic codes. Additionally, one of the fan flutter cases was evaluated using TURBO-AE. The UNSFLO and FREPS evaluation predictions showed good agreement with the experimental test data trends, but quantitative improvements are needed. UNSFLO over-predicted turbine blade response reductions, while FREPS under-predicted them. The inviscid TURBO-AE turbine analysis predicted no discernible blade response reduction, indicating the necessity of including viscous effects for this test case. For the TURBO-AE fan blisk test case, significant effort was expended getting the viscous version of the code to give converged steady flow solutions for the transonic flow conditions. Once converged, the steady solutions provided an excellent match with test data and the calibrated DAWES (AlliedSignal 3-D Viscous Steady Flow CFD Solver). However, efforts expended establishing quality steady-state solutions prevented exercising the unsteady portion of the TURBO-AE code during the present program. AlliedSignal recommends that unsteady pressure measurement data be obtained for both test cases examined for use in aeroelastic code validation.

Gardner, Kevin D.↗
NASA NTRS1988

Finite-state codes

A class of codes called finite-state (FS) codes is defined and investigated. The codes, which generalize both block and convolutional codes, are defined by their encoders, which are finite-state machines with parallel inputs and outputs. A family of upper bounds on the free distance of a given FS code is derived. A general construction for FS codes is given, and it is shown that in many cases the FS codes constructed in this way have a free distance that is the largest possible. Catastrophic error propagation (CEP) for FS codes is also discussed. It is found that to avoid CEP one must solve the graph-theoretic problem of finding a uniquely decodable edge labeling of the state diagram.

Pollara, Fabrizio↗
DOE OSTI2024

Implementing Ordinary Differential Equation Solvers in Rust Programming Language for Modeling Vehicle Powertrain Systems: Preprint

Efficient and accurate ordinary differential equation (ODE) solvers are necessary for powertrain and vehicle dynamics modeling. However, current commercial ODE solvers can be financially prohibitive, leading to a need for accessible, effective, open-source ODE solvers designed for powertrain modeling. Rust is a compiled programming language that has the potential to be used for fast and easy-to-use powertrain models, given its exceptional computational performance, robust package ecosystem, and short time required for modelers to become proficient. However, of the three commonly used (>3,000 downloads) packages in Rust with ODE solver capabilities, only one has more than four numerical methods implemented, and none are designed specifically for modeling physical systems. Therefore, the goal of the Differential Equation System Solver (DESS) was to implement accurate ODE solvers in Rust designed for the component-based problems often seen in powertrain modeling. DESS is a text-based software package that provides a flexible framework for building and solving systems of ODEs. This allows DESS to be included as a dependency for automotive powertrain models that require a variety of solvers and solver configurations. Seven explicit ODE solver methods have been implemented in DESS: Euler’s, Heun’s, midpoint, Ralston’s, classic Runge-Kutta, Bogacki-Shampine, and Cash-Karp. These represent five fixed-step methods and two adaptive-step methods. This paper shows that the solver implementations increase accuracy and computational efficiency compared to Euler's method when modeling a system of three thermal masses in Rust. DESS also includes features designed for modeling component-based physical systems. Users can define relationships between nodes in their system, which the package then translates into a system of equations, leading to simpler and more intuitive code. In the case of a three-thermal-mass system, the user can specify node thermal properties (e.g., thermal capacitance), how nodes are interconnected, and thermal conductance between nodes rather than providing a system of equations. The core contribution from this work is an open-source, text-based Rust package with ODE solvers for automotive powertrain modeling to support cost-free, fast, and accurate simulation.

ADVANCED PROPULSION SYSTEMS↗
DOE OSTI2020

Language Independent Static Analysis (LISA)

Software is becoming increasingly important in nearly every aspect of global society and therefore in nearly every aspect of national security as well. While there have been major advancements in recent years in formally proving properties of program source code during development, such approaches are still in the minority among development teams, and the vast majority of code in this software explosion is produced without such properties. In these cases, the source code must be analyzed in order to establish whether the properties of interest hold. Because of the volume of software being produced, automated approaches to software analysis are necessary to meet the need. However, this software boom is not occurring in just one language. There are a wide range of languages of interest in national security spaces, including well-known languages such as C, C++, Python, Java, Javascript, and many more. But recent years have produced a wide range of new languages, including Nim, (2008), Go (2009), Rust (2010), Dart (2011), Kotlin (2011), Elixir (2011), Red (2011), Julia (2012), Typescript (2012), Swift (2014), Hack (2014), Crystal (2014), Ballerina (2017) and more. Historically, automated software analyses are implemented as tools that intermingle both the analysis question at hand with target language dependencies throughout their code, making re-use of components for different analysis questions or different target languages impractical. This project seeks to explore how mission-relevant, static software analyses can be designed and constructed in a language-independent fashion, dramatically increasing the reusability of software analysis investments.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS1989

Correlation of Puma airloads: Evaluation of CFD prediction methods

A cooperative program was undertaken by research organizations in England, France, Australia and the U.S. to study the capabilities of computational fluid dynamics codes (CFD) to predict the aerodynamic loading on helicopter rotor blades. The program goal is to compare predictions with experimental data for flight tests of a research Puma helicopter with rectangular and swept tip blades. Two topics are studied. First, computed results from three CFD codes are compared for flight test cases where all three codes use the same partial inflow-angle boundary conditions. Second, one of the CFD codes (FPR) is iteratively coupled with the CAMRAD/JA helicopter performance code. These results are compared with experimental data and with an uncoupled CAMRAD/JA solution. The influence of flow field unsteadiness is found to play an important role in the blade aerodynamics. Alternate boundary conditions are suggested in order to properly model this unsteadiness in the CFD codes.

Strawn, Roger C.↗
NASA NTRS1989

Correlation of Puma airfoils - Evaluation of CFD prediction methods

A cooperative program was undertaken by research organizations in England, France, Australia and the U.S. to study the capabilities of computational fluid dynamics codes (CFD) to predict the aerodynamic loading on helicopter rotor blades. The program goal is to compare predictions with experimental data for flight tests of a research Puma helicopter with rectangular and swept tip blades. Two topics are studied. First, computed results from three CFD codes are compared for flight test cases where all three codes use the same partial inflow-angle boundary conditions. Second, one of the CFD codes (FPR) is iteratively coupled with the CAMRAD/JA heilcopter performance code. These results are compared with experimental data and with an uncoupled CAMRAD/JA solution. The influence of flow field unsteadiness is found to play an important role in the blade aerodynamics. Alternate boundary conditions are suggested in order to properly model this unsteadiness in the CFD codes.

Strawn, Roger C.↗
NASA NTRS1998

Evaluation of 3D Inverse Code Using Rotor 67 as Test Case

A design modification of Rotor 67 is carried out with a full 3D inverse method. The blade camber surface is modified to produce a prescribed pressure loading distribution, with the blade tangential thickness distribution and the blade stacking line at midchord kept the same as the original Rotor 67 design. Because of the inviscid-flow assumption used in the current version of the method, Rotor 67 geometry is modified for use at a design point different from the original design value. A parametric study with the prescribed pressure loading distribution yields the following results. In the subsonic section, smooth pressure loading shapes generally produce blades with well-behaved blade surface pressure distributions. In the supersonic section, the study shows that the strength and position of the passage shock correlate with the characteristics of the blade pressure loading shape. In general, "smooth" prescribed blade pressure loading distributions generate blade designs with reverse cambers which have the effect of weakening the passage shock.

Dang, T.↗
DOE OSTI2023

Porting numerical integration codes from CUDA to oneAPI: a case study

We present our experience in porting optimized CUDA implementations to oneAPI. We focus on the use case of numerical integration, particularly the CUDA implementations of PAGANI and $m$-Cubes. We faced several challenges that caused performance degradation in the oneAPI ports. These include differences in utilized registers per thread, compiler optimizations, and mappings of CUDA library calls to oneAPI equivalents. After addressing those challenges, we tested both the PAGANI and m-Cubes integrators on numerous integrands of various characteristics. To evaluate the quality of the ports, we collected performance metrics of the CUDA and oneAPI implementations on the Nvidia V100 GPU. We found that the oneAPI ports often achieve comparable performance to the CUDA versions, and that they are at most 10% slower.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2024

TokaMaker: An open-source time-dependent Grad-Shafranov tool for the design and modeling of axisymmetric fusion devices

Here, in this paper, we present a new static and time-dependent MagnetoHydroDynamic (MHD) equilibrium code, TokaMaker, for axisymmetric configurations of magnetized plasmas, based on the well-known Grad-Shafranov equation. This code utilizes finite element methods on an unstructured triangular grid to enable capturing accurate machine geometry and simple mesh generation from engineering-like descriptions of present and future devices. The new code is designed for ease of use without sacrificing capability and speed through a combination of Python, Fortran, and C/C++ components. A detailed description of the numerical methods of the code, including a novel formulation of the boundary conditions for free-boundary equilibria, and validation of the implementation of those methods using both analytic test cases and cross-code validation is shown. Results show expected convergence across tested polynomial degree for analytic and cross-code test cases.

70 PLASMA PHYSICS AND FUSION TECHNOLOGY↗
NASA NTRS1990

Performance comparison of combined ECC/RLL codes

In this paper, we present a performance comparison of several combined error correcting/run-lenth limited (ECC/RLL) codes created by concatenating a convolutional code with a run-length limited code. In each case, encoding and decoding are accomplished using a single trellis based on the combined code. Half of the codes under investigation use conventionally (d,k) run-length limited codes, where d is the minimum and k is the maximum allowable run of 0's between 1's. The other half of the combined codes use a special class of (d,k) codes known as distance preserving codes. These codes have the property that pairwise Hamming distances out of the (d,k) encoder are at least as large as the corresponding distances into the encoder (i.e., the codes preserve distance). Thus a combined code, created using a convolutional code concatenated with a distance preserving (d,k) code, will have a free distance (dfree) no smaller than the free distance of the original convolutional code. It should be noted that this does not hold if the (d,k) code was not distance preserving. A computer simulation is used to compare the performance of these two types of codes over the binary symmetric channel for various (d,k) constraints, rates, free distances, and numbers of states. Of particular interest for magnetic recording applications are codes with run-length constraints (1,3), (1,7), and (2,7).

French, C.↗
DOE OSTI2023

MARVEL Project Code of Record, COR-0011

MARVEL Project Code of Record identifies the codes, standards, and procedures necessary to design, develop, construct, and startup the Microreactor Applications Research Validation and Evaluation (MARVEL) Project. No code exceptions to construction of the MARVEL reactor in the traditional sense were identified, meaning there are no technical aspects that fail to meet a code requirement. However, due to the novel design of the MARVEL reactor, not every aspect or system can be precisely covered by the existing ASME Boiler and Pressure Vessel Code. In those cases, the document identifies (with concurrences received) how the ASME Boiler and Pressure Vessel Code is applied in an equivalent or analogous manner.

21 SPECIFIC NUCLEAR REACTORS AND ASSOCIATED PLANTS↗
NASA NTRS2003

Traceability Through Automatic Program Generation

Program synthesis is a technique for automatically deriving programs from specifications of their behavior. One of the arguments made in favour of program synthesis is that it allows one to trace from the specification to the program. One way in which traceability information can be derived is to augment the program synthesis system so that manipulations and calculations it carries out during the synthesis process are annotated with information on what the manipulations and calculations were and why they were made. This information is then accumulated throughout the synthesis process, at the end of which, every artifact produced by the synthesis is annotated with a complete history relating it to every other artifact (including the source specification) which influenced its construction. This approach requires modification of the entire synthesis system - which is labor-intensive and hard to do without influencing its behavior. In this paper, we introduce a novel, lightweight technique for deriving traceability from a program specification to the corresponding synthesized code. Once a program has been successfully synthesized from a specification, small changes are systematically made to the specification and the effects on the synthesized program observed. We have partially automated the technique and applied it in an experiment to one of our program synthesis systems, AUTOFILTER, and to the GNU C compiler, GCC. The results are promising: 1. Manual inspection of the results indicates that most of the connections derived from the source (a specification in the case of AUTOFILTER, C source code in the case of GCC) to its generated target (C source code in the case of AUTOFILTER, assembly language code in the case of GCC) are correct. 2. Around half of the lines in the target can be traced to at least one line of the source. 3. Small changes in the source often induce only small changes in the target.

Richardson, Julian↗
DOE OSTI2020

Radiation shielding analysis of the concrete hutch of a long beamline of the Advanced Photon Source Upgrade project

The radiation shielding analysis of the external concrete enclosure of a feature long beamline of the Advanced Photon Source Upgrade project is described in this work. The beamline has 2 undulators that can operate in two different configurations and the source terms are estimated for the worst configuration using the SRW code in the OASYS package as well as the STAC8 code. The shielding analysis is carried out using the STAC8 code, and for the case of pink beam, with the FLUKA code also. Effective dose rates on contact with the outside surface of the concrete walls for pink, reflected full spectrum and monochromatic beams are calculated. For the monochromatic beams, 2 sets of discrete bandwidths (BW) from the Double Crystal Monochromator (DCM) and the full reflectance of the Double Multilayer Monochromator (DMM) are used. Further, due to the size of the direct beam and the energy domain of interest in the direct and scattered fields, the importance of the equivalent dose to the lens of the eye is discussed with respect to the shielding calculations of such facilities. The dose rates outside the concrete hutch in the lateral directions calculated using STAC8 is about 50% higher than the FLUKA results for the case of pink beam but may be considered as a reasonable agreement due to the differences in the calculational methodologies. Those dose rates in the lateral and forward directions are higher for the pink beam to allow full occupancy from the radiation protection point of view. For the full spectrum after 3 reflections, the effective dose rates are less than 0.5 Sv/h in the lateral direction but is higher in the forward region below about 22° with respect to the beam direction. For the DCM beams, except for the scenario with one mirror and 0.1%BW, all dose rates are less than 0.5 Sv/h outside the concrete hutch in the lateral directions. Here, the higher harmonics are what contributes to the dose outside the shield and the bandwidths assumed to derive the photon flux thus becomes important. The dose rates with the DMM are generally lower compared to the 0.1% BW DCM beam but are higher than the results obtained with XOP calculated bandwidths.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗
DOE OSTI2026

Dataset for "A primer on forest structure measurement with lidar for ecologists"

This repository includes data and code accompanying the case study included in the manuscript "A primer on forest structure measurement with lidar for ecologists" (submitted to Ecosphere). We compiled lidar datasets from multiple platforms in a common area to: 1. Demonstrate how differences in sensor characteristics influence density and resolution of lidar data. 2. Provide open-source, co-located datasets for users to further inspect differences in lidar data. 3. Provide example code to perform basic lidar analysis. This case study is meant to allow readers to get hands-on experience with real-world data from different platforms. This case study is not meant to be a rigorous comparison of derived ecological metrics among all sensors; such comparisons can be found throughout other publications referenced throughout the main manuscript. Code includes basic functions in R commonly used to visualize and manipulate lidar data accessible with a normal laptop computer; more sophisticated algorithms for advanced users are also referenced throughout the main manuscript. Terrestrial laser scanning (TLS), mobile laser scanning (MLS), UAS laser scanning (ULS), airborne laser scanning (ALS), and spaceborne laser scanning (SLS) data were collected within the Smithsonian Environmental Research Center (SERC) forest dynamics plot in Maryland, USA. TLS, MLS, and ALS data were collected within 1 month of the 2021 growing season; ULS data were collected in November 2020 (“leaf-off” data) and July 2022 (“leaf-on” data).

54 ENVIRONMENTAL SCIENCES↗