SEARCH · Engineering Papers
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.
NasGen provides a path for migration of structural models from Nastran bulk data format (BDF) into both an Exodus mesh file and an ASCII input file for Sierra Structural Dynamics (Salinas) and Solid Mechanics (Adagio). Many tools at Sandia National Labs (SNL) use the Exodus format. This document describes capabilities and limitations of the NasGen translation software.
NasGen provides a path for migration of structural models from NASTRAN bulk data format (BDF) into both an Exodus mesh file and an ASCII input file for Sierra Structural Dynamics (Salinas) and Solid Mechanics (Presto). Many tools at Sandia National Labs (SNL) use the Exodus format. NasGen was written specifically for Salinas and Presto but should be usable with a number of these packages.
NasGen provides a path for migration of structural models from Nastran bulk data format (BDF) into both an Exodus mesh file and an ASCII input file for Sierra Structural Dynamics (Salinas) and Solid Mechanics (Adagio). Many tools at Sandia National Labs (SNL) use the Exodus format. This document describes capabilities and limitations of the NasGen translation software.
NasGen provides a path for migration of structural models from Nastran bulk data format (BDF) into both an Exodus mesh file and an ASCII input file for Sierra Structural Dynamics (Salinas) and Solid Mechanics (Adagio). Many tools at Sandia National Labs (SNL) use the Exodus format. This document describes capabilities and limitations of the NasGen translation software.
NasGen provides a path for migration of structural models from Nastran bulk data format (BDF) into both an Exodus mesh file and an ASCII input file for Sierra Structural Dynamics (Salinas) and Solid Mechanics (Adagio). Many tools at Sandia National Labs (SNL) use the Exodus format. This document describes capabilities and limitations of the NasGen translation software.
NasGen provides a path for migration of structural models from Nastran bulk data format (BDF) into both an Exodus mesh file and an ASCII input file for Sierra Structural Dynamics (Salinas) and Solid Mechanics (Adagio). Many tools at Sandia National Labs (SNL) use the Exodus format. This document describes capabilities and limitations of the NasGen translation software.
NasGen provides a path for migration of structural models from NASTRAN bulk data format (BDF) into both an Exodus mesh file and an ASCII input file for Sierra Structural Dynamics (Salinas) and Solid Mechanics (Presto). Many tools at Sandia National Labs use the Exodus format. NasGen was written specifically for Salinas and Presto but should be usable with a number of these packages.
Here, a line list for the N second positive system, $B^3Π_g—C^3Π_u$, has been compiled using the PGOPHER spectral simulation software. The line list extends the number of vibrational states of the $B^3Π_g$ up to v=29 and a maximum rotational state of J=150 for simulation temperatures up to 7000 K. New electronic–vibrational transition moments were calculated using refined potential energy curves and a transition dipole moment with the DUO software. Comparisons to experimental data and the SPECAIR software have been used to validate the new line list. The results are available in ASCII ExoMol .state and .trans files and as a PGOPHER input file for use in spectral analysis.
This datastream is made by kasacrcfrcorppiv VAP from kasacrcfrqc.b1 by applying an attenuation algorithm. It has (time, range) Ka-band PPI radial radar data. A c1 level output file is created for each input kasacrcfrq1.b1 input file in PPI mode. This DOD is the same as kasacrcfrq1.b1 except for an attenuation algorithm field (reflectivity_at_cor) being added to it.
Two new data management features are installed in the April 1984 release of NASTRAN. These two features are the Rigid Format Data Base and the READFILE capability. The Rigid Format Data Base is stored on external files in card image format and can be easily maintained and expanded by the use of standard text editors. This data base provides the user and the NASTRAN maintenance contractor with an easy means for making changes to a Rigid Format or for generating new Rigid Formats without unnecessary compilations and link editing of NASTRAN. Each Rigid Format entry in the data base contains the Direct Matrix Abstraction Program (DMAP), along with the associated restart, DMAP sequence subset and substructure control flags. The READFILE capability allows an user to reference an external secondary file from the NASTRAN primary input file and to read data from this secondary file. There is no limit to the number of external secondary files that may be referenced and read.
During early conceptual design of complex systems, speed and accuracy are often at odds with one another. While many characteristics of the design are fluctuating rapidly during this phase there is nonetheless a need to acquire accurate data from which to down-select designs as these decisions will have a large impact upon program life-cycle cost. Therefore enabling the conceptual designer to produce accurate data in a timely manner is tantamount to program viability. For conceptual design of launch vehicles, trajectory analysis and optimization is a large hurdle. Tools such as the industry standard Program to Optimize Simulated Trajectories (POST) have traditionally required an expert in the loop for setting up inputs, running the program, and analyzing the output. The solution space for trajectory analysis is in general non-linear and multi-modal requiring an experienced analyst to weed out sub-optimal designs in pursuit of the global optimum. While an experienced analyst presented with a vehicle similar to one which they have already worked on can likely produce optimal performance figures in a timely manner, as soon as the "experienced" or "similar" adjectives are invalid the process can become lengthy. In addition, an experienced analyst working on a similar vehicle may go into the analysis with preconceived ideas about what the vehicle's trajectory should look like which can result in sub-optimal performance being recorded. Thus, in any case but the ideal either time or accuracy can be sacrificed. In the authors' previous work a tool called multiPOST was created which captures the heuristics of a human analyst over the process of executing trajectory analysis with POST. However without the instincts of a human in the loop, this method relied upon Monte Carlo simulation to find successful trajectories. Overall the method has mixed results, and in the context of optimizing multiple vehicles it is inefficient in comparison to the method presented POST's internal optimizer functions like any other gradient-based optimizer. It has a specified variable to optimize whose value is represented as optval, a set of dependent constraints to meet with associated forms and tolerances whose value is represented as p2, and a set of independent variables known as the u-vector to modify in pursuit of optimality. Each of these quantities are calculated or manipulated at a certain phase within the trajectory. The optimizer is further constrained by the requirement that the input u-vector must result in a trajectory which proceeds through each of the prescribed events in the input file. For example, if the input u-vector causes the vehicle to crash before it can achieve the orbital parameters required for a parking orbit, then the run will fail without engaging the optimizer, and a p2 value of exactly zero is returned. This poses a problem, as this "non-connecting" region of the u-vector space is far larger than the "connecting" region which returns a non-zero value of p2 and can be worked on by the internal optimizer. Finding this connecting region and more specifically the global optimum within this region has traditionally required the use of an expert analyst.
Overview This dataset contains XML input files for the IM3 Phase 2 version of GCAM-USA. The files are organized into two categories: Scenario-specific inputs represent hydroclimate and socioeconomic effects on water availability, heating and cooling degree-hours, and agricultural productivity. They support eight IM3 canonical scenarios: rcp45cooler_ssp3 rcp45cooler_ssp5 rcp45hotter_ssp3 rcp45hotter_ssp5 rcp85cooler_ssp3 rcp85cooler_ssp5 rcp85hotter_ssp3 rcp85hotter_ssp5 Model-improvement inputs extend GCAM-USA v5.3 with updated representations of coal and nuclear power plant retirements, electricity trade among U.S. interconnections, offshore carbon storage costs, and groundwater depletion constraints. Data structure Scenario-specific inputs rcp45_runoff/ and rcp85_runoff/XML files describing water availability by HUC2 basin under the RCP 4.5 and RCP 8.5 scenarios. rcp45_hdcd/ and rcp85_hdcd/XML files containing monthly-day and monthly-night heating and cooling degree-hours at the U.S. state level for different RCP-SSP combinations. rcp45_agyields/ and rcp85_agyields/XML files describing changes in agricultural productivity at the intersection of GCAM regions and HUC2 water basins for different RCP-SSP combinations. rcp45_emissions_pathway/The emissions-constraint XML file used to represent the RCP 4.5 pathway. Model-improvement inputs core_retire/Updates coal-fired power plant retirement schedules based on New England ISO. GCAMUSA_IM3_elec_trade_interconnect.xmlRestricts electricity trade to occur within the ERCOT, WECC, and IE interconnections. nuclear_USA.xmlUpdates the retirement schedules of the Diablo Canyon and Palisades nuclear power plants. high_cost_offshore_carbon.xmlUpdates the assumed cost of offshore carbon storage. water_supply_constrained_gleeson_5pct.xmlReplaces WaterGAP historical groundwater-depletion estimates with data from the Gleeson dataset and limits groundwater extraction to 5% of the available groundwater in each Superwell grid cell. How to use the data This dataset is designed for use with the IM3 version of GCAM-USA. Download or clone GCAM-USA from the IM3 GCAM GitHub repository at https://github.com/IMMM-SFA/gcam-core and check out the gcam-usa-im3 branch. Place the downloaded folder im3scenarios in the gcam-core/input directory while preserving the provided folder structure.
During my internship at NASA Johnson Space Center, I worked in the Space Radiation Analysis Group (SRAG), where I was tasked with a number of projects focused on the automation of tasks and activities related to the operation of the International Space Station (ISS). As I worked on a number of projects, I have written short sections below to give a description for each, followed by more general remarks on the internship experience. My first project is titled "General Exposure Representation EVADOSE", also known as "GEnEVADOSE". This project involved the design and development of a C++/ ROOT framework focused on radiation exposure for extravehicular activity (EVA) planning for the ISS. The utility helps mission managers plan EVAs by displaying information on the cumulative radiation doses that crew will receive during an EVA as a function of the egress time and duration of the activity. SRAG uses a utility called EVADOSE, employing a model of the space radiation environment in low Earth orbit to predict these doses, as while outside the ISS the astronauts will have less shielding from charged particles such as electrons and protons. However, EVADOSE output is cumbersome to work with, and prior to GEnEVADOSE, querying data and producing graphs of ISS trajectories and cumulative doses versus egress time required manual work in Microsoft Excel. GEnEVADOSE automates all this work, reading in EVADOSE output file(s) along with a plaintext file input by the user providing input parameters. GEnEVADOSE will output a text file containing all the necessary dosimetry for each proposed EVA egress time, for each specified EVADOSE file. It also plots cumulative dose versus egress time and the ISS trajectory, and displays all of this information in an auto-generated presentation made in LaTeX. New features have also been added, such as best-case scenarios (egress times corresponding to the least dose), interpolated curves for trajectories, and the ability to query any time in the EVADES output. As mentioned above, GEnEVADOSE makes extensive use of ROOT version 6, the data analysis framework developed at the European Organization for Nuclear Research (CERN), and the code is written to the C++11 standard (as are the other projects). My second project is the Automated Mission Reference Exposure Utility (AMREU).Unlike GEnEVADOSE, AMREU is a combination of three frameworks written in both Python and C++, also making use of ROOT (and PyROOT). Run as a combination of daily and weekly cron jobs, these macros query the SRAG database system to determine the active ISS missions, and query minute-by-minute radiation dose information from ISS-TEPC (Tissue Equivalent Proportional Counter), one of the radiation detectors onboard the ISS. Using this information, AMREU creates a corrected data set of daily radiation doses, addressing situations where TEPC may be offline or locked up by correcting doses for days with less than 95% live time (the total amount time the instrument acquires data) by averaging the past 7 days. As not all errors may be automatically detectable, AMREU also allows for manual corrections, checking an updated plaintext file each time it runs. With the corrected data, AMREU generates cumulative dose plots for each mission, and uses a Python script to generate a flight note file (.docx format) containing these plots, as well as information sections to be filled in and modified by the space weather environment officers with information specific to the week. AMREU is set up to run without requiring any user input, and it automatically archives old flight notes and information files for missions that are no longer active. My other projects involve cleaning up a large data set from the Charged Particle Directional Spectrometer (CPDS), joining together many different data sets in order to clean up information in SRAG SQL databases, and developing other automated utilities for displaying information on active solar regions, that may be used by the space weather environment officers to monitor solar activity. I consulted my mentor Dr. Ryan Rios and Dr. Kerry Lee for project requirements and added features, and ROOT developer Edmond Offermann for advice on using the ROOT library. I also received advice and feedback from Dr. Janet Barzilla of SRAG, who tested my code. Besides these inputs, I worked independently, writing all of the code by myself. The code for all these projects is documented throughout, and I have attempted to write it in a modular format. Assuming that ROOT is updated accordingly, these codes are also Y2038-compliant (and Y10K-compliant). This allows the code to be easily referenced, modified and possibly repurposed for non-ISS missions in the future, should the necessary inputs exist. These projects have taught me a lot about coding and software design - I have become a much more skilled C++ programmer and ROOT user, and I also learned to code in Python and PyROOT (and its advantages and disadvantages compared to C++/ ROOT). Furthermore, I have learned about space radiation and radiation modeling, topics that greatly interest me as I pursue a degree in physics. Working alongside experimental physicists like Dr. Rios, I have developed a greater understanding and appreciation for experimental science, something I have always leaned towards but to which I lacked significant exposure. My work in SRAG has also given me the invaluable opportunity to witness the work environment for physicists at NASA, and what a career in academia may look like at a government laboratory such as NASA Johnson Space Center. As I continue my studies and look forward to graduate school and a future career, this experience at NASA has given me a meaningful and enjoyable opportunity to put my skills to use and see what my future career path might hold.
Simulation input and output files, post-processed figures and excel tables, and tecplot layout files for generating figures. These simulations were run with TOUGHREACT V4.12 by Lawrence Berkeley National Laboratory in 2021. This work was completed as part of the geologic thermal energy storage (GeoTES) research project reported in the final report for Phase I of this work, which is linked below.
"Kinetic simulations of microstructural evolution" (KSOME) is an object Kinetic Monte Carlo (OMKC) simulation code. It is developed to simulate microstructural evolution in materials during irradiation. KSOME is developed from ground up with priority given to the flexibility, ease of upgradability, and computation efficiency, in that order. With previously developed simulation codes, various processes (more precisely, the diffusion-reaction processes) that can occur in a system were hardwired into the code. Hence, to perform higher fidelity simulations, a significant coding effort was required every time to incorporate either a more accurate description of existing processes or new processes. With KSOME, the necessity for frequent code upgrades whenever there is a need to perform higher fidelity simulations is either eliminated or reduced significantly. In KSOME, the categories of various diffusion-reaction processes and the data-management system are hardwired, while the execution of the diffusion-reaction processes specific to a system is specified via input files. In the present version of KSOME, the analytical expression required to calculate defect interaction radii are inputted via a text file. However, the ability to parse mathematical expressions from a text file can be extended to input the analytical expression to calculate other defect properties; including the expressions to calculate the change in the migration barriers of mobile defects due to long-range interaction with extended defects
A set of 24 protein structures/complexes from the SARS CoV-2 proteome and inputs prepared for simulation using the CHARMM36m forcefield in PDB and gromacs formats. Each system contains a pdb and gromacs top and related input files necessary for running a temperature replica-exchange simulation. In addition, we also include: charmm PSF files (generated from the gromacs topology), a list of temperatures at which replica-exchange simulations were done (tempRamp), example gromacs run input mdp files, and initial minimized structures where available (minimized.pdb).
An analytically linearized model for helicopter flight response including rotor blade dynamics and dynamic inflow, that was recently developed, was studied with the objective of increasing the understanding, the ease of use, and the accuracy of the model. The mathematical model is described along with a description of the UH-60A Black Hawk helicopter and flight test used to validate the model. To aid in utilization of the model for sensitivity analysis, a new, faster, and more efficient implementation of the model was developed. It is shown that several errors in the mathematical modeling of the system caused a reduction in accuracy. These errors in rotor force resolution, trim force and moment calculation, and rotor inertia terms were corrected along with improvements to the programming style and documentation. Use of a trim input file to drive the model is examined. Trim file errors in blade twist, control input phase angle, coning and lag angles, main and tail rotor pitch, and uniform induced velocity, were corrected. Finally, through direct comparison of the original and corrected model responses to flight test data, the effect of the corrections on overall model output is shown.
Interactive Data Display System (IDDS) computer program is graphical-display program designed to assist in visualization of three-dimensional flow in turbomachinery. Grid and simulation data files in PLOT3D format required for input. Able to unwrap volumetric data cone associated with centrifugal compressor and display results in easy-to-understand two- or three-dimensional plots. IDDS provides majority of visualization and analysis capability for Integrated Computational Fluid Dynamics and Experiment (ICE) system. IDDS invoked from any subsystem, or used as stand-alone package of display software. Generates contour, vector, shaded, x-y, and carpet plots. Written in C language. Input file format used by IDDS is that of PLOT3D (COSMIC item ARC-12782).