Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “STEP file”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 37 records · Page 2
All sourcesNASA NTRSDOE OSTI
NASA NTRS2012

Rapid Process to Generate Beam Envelopes for Optical System Analysis

The task of evaluating obstructions in the optical throughput of an optical system requires the use of two disciplines, and hence, two models: optical models for the details of optical propagation, and mechanical models for determining the actual structure that exists in the optical system. Previous analysis methods for creating beam envelopes (or cones of light) for use in this obstruction analysis were found to be cumbersome to calculate and take significant time and resources to complete. A new process was developed that takes less time to complete beam envelope analysis, is more accurate and less dependent upon manual node tracking to create the beam envelopes, and eases the burden on the mechanical CAD (computer-aided design) designers to form the beam solids. This algorithm allows rapid generation of beam envelopes for optical system obstruction analysis. Ray trace information is taken from optical design software and used to generate CAD objects that represent the boundary of the beam envelopes for detailed analysis in mechanical CAD software. Matlab is used to call ray trace data from the optical model for all fields and entrance pupil points of interest. These are chosen to be the edge of each space, so that these rays produce the bounding volume for the beam. The x and y global coordinate data is collected on the surface planes of interest, typically an image of the field and entrance pupil internal of the optical system. This x and y coordinate data is then evaluated using a convex hull algorithm, which removes any internal points, which are unnecessary to produce the bounding volume of interest. At this point, tolerances can be applied to expand the size of either the field or aperture, depending on the allocations. Once this minimum set of coordinates on the pupil and field is obtained, a new set of rays is generated between the field plane and aperture plane (or vice-versa). These rays are then evaluated at planes between the aperture and field, at a desired number of steps perceived necessary to build up the bounding volume or cone shape. At each plane, the ray coordinates are again evaluated using the convex hull algorithm to reduce the data to a minimal set. When all of the coordinates of interest are obtained for every plane of the propagation, the data is formatted into an xyz file suitable for FRED optical analysis software to import and create a STEP file of the data. This results in a spiral-like structure that is easily imported by mechanical CAD users who can then use an automated algorithm to wrap a skin around it and create a solid that represents the beam.

Howard, Joseph↗
DOE OSTI2023

FUN-BioCROP model with litter decomposition parameters derived from the LIDET dataset

This repository contains the code and data necessary to run the FUN-BioCROP (Fixation and Uptake of Nitrogen-Bioenergy Carbon, Rhizosphere, Organisms, and Protection) model with litter decomposition parameters derived from a modified Monte Carlo simulation that used the Long-term Intersite Decomposition Experiment Team dataset. Related publication:Juice, S.M., Ridgeway, J.R., Hartman, M.D., Parton, W.J., Berardi, D.M., Sulman, B.N., Allen, K.E., & Brzostek, E.R. Reparameterizing litter decomposition using a simplified Monte Carlo method improves litter decay simulated by a microbial model and alters bioenergy soil carbon estimates. Description of Files: FUNBioCROP_LIDET Study.Rmd R code with FUN-BioCROP model that can be run with 10 different sets of parameters for litter decomposition (Baseline, LIDET, or eight other best parameter sets identified in the modified Monte Carlo simulation. CORPSE Functions_Bioenergy_V2.R Code with CORPSE model functions, called by FUNBioCROP_LIDET Study.Rmd Model Input Data: bulk.csv, bulk_till.csv, rhizo.csv, rhizo_till.csv, litter.csv Initial C and N (kg C or N/m2) pool values for each soil compartment, final values from spin up. All five files have the same columns: (Column - Description - Units) uFastC - Unprotected fast decomposing carbon - kg carbon/m2 uSlowC - Unprotected slow decomposing carbon - kg carbon/m2 uNecroC - Unprotected necromass carbon - kg carbon/m2 pFastC - Protected fast decomposing carbon - kg carbon/m2 pSlowC - Protected slow decomposing carbon - kg carbon/m2 pNecroC - Protected necromass carbon - kg carbon/m2 livingMicrobeC - Carbon in living microbial biomass - kg carbon/m2 uFastN - Unprotected fast decomposing nitrogen - kg nitrogen/m2 uSlowN - Unprotected slow decomposing nitrogen - kg nitrogen/m2 uNecroN - Unprotected necromass nitrogen - kg nitrogen/m2 pFastN - Protected fast decomposing nitrogen - kg nitrogen/m2 pSlowN - Protected slow decomposing nitrogen - kg nitrogen/m2 pNecroN - Protected necromass nitrogen - kg nitrogen/m2 inorganicN - Inorganic nitrogen - kg nitrogen/m2 CO2 - Carbon in carbon dioxide - kg carbon/m2 livingMicrobeN - Nitrogen in living microbial biomass - kg nitrogen/m2 Model Input Data: FluxTower_AvgSoilT.csv: Average daily soil temperature (oC) at 10 cm depth at University of Illinois Urbana-Champaign (UIUC) Energy Farm flux tower from 7/2008-3/2016. (One year of averaged data) Model Input Data: FluxTower_AvgSoilVWC.csv: Average daily soil volumetric water content (VWC) at 10 cm depth at UIUC Energy Farm flux tower from 7/2008-3/2016. (One year of averaged data) Model Input Data: input_CCS_LIDET Study.csv: This file has daily data to run FUN-BioCROP (Column - Description - Units): yr - calendar year - year doy - day of year (1 to 365) (no leap year) - day anpp - aboveground NPP (DayCent) - kg C/m2/day bnpp - belowground NPP (DayCent) - kg C/m2/day aglivc - live aboveground biomass carbon (DayCent) - kg C/m2 bglivcj - live juvenile fine root biomass carbon (DayCent) - kg C/m2 bglivcm - live mature fine root biomass carbon (DayCent) - kg C/m2 aglivn - live aboveground biomass nitrogen (DayCent) - kg N/m2 bglivnj - live juvenile fine root biomass nitrogen (DayCent) - kg N/m2 bglivnm - live mature fine root biomass nitrogen (DayCent) - kg N/m2 nyr - simulation year - year cult - indicates a cultivation event (0 or 1) crop - indicates a new crop (0 or 1) fert - indicates a fertilizer event (0 or 1) frst - indicates the first day of the growing season (0 or 1) harv - indicates a harvest event (0 or 1) last - indicates the end of the growing season (0 or 1) croptype - crop type (0=none; 1=alfalfa; 2=corn; 3=grass clover pasture; 4=soybean; 5=wheat) cropsrl - crop specific root length - mm/g root cultrhizmix - fraction of rhizosphere mixed with bulk soil during cultivation (0.0-1.0) - fraction cultlitmix - fraction of litter mixed with bulk soil during cultivation (0.0-1.0) - fraction harvremov - fraction of above ground biomass removed during harvest (0.0-1.0) - fraction fertamt - fertilization amount - g N/m2 lifehist - plant life history (0 = annual, 1 = perennial) froot_turnover_c - amount of C in fine root turnover - kg C/m2 froot_turnover_n - amount of N in fine root turnover - kg N/m2 agrd_turnover_c - amount of C in aboveground biomass turnover - kg C/m2 agrd_turnover_n - amount of N in aboveground biomass turnover - kg N/m2 leaf_litter_fastfrac - Fast decomposing fraction of leaf litter (0.0-1.0) - fraction root_litter_fastfrac - Fast decomposing fraction of root litter (0.0-1.0) - fraction root_diameter - root diameter - mm root_length - root length - mm root/m2 rhizo_frac - fraction of total soil volume that is rhizosphere (0.0 - 1.0) - fraction date - date in format YYYY-MM-DD Instructions: Save the model code ("FUN-BioCROP_LIDET Study.Rmd") and accompanything files (data streams and CORPSE function code) in the same folder. In model code "Chunk 3: Load CORPSE Data Streams" set the working directory (setwd) to the folder with the files saved in step #1. In "Chunk 5: Define LIDET parameter sets" select the litter decomposition parameter set to be used in the run, and comment out all other sets. If changing any parameter values, edit them in "Chunk 6: Load parameters." Run all chunks up to and including "Chunk 10: Prepare Data for Export." In "Chunk 11: Export Output Data" edit data frames for export and filenames, as necessary. "Chunk 12: Graph Total Soil C" makes a figure of C remaining over the model run period. Description of each model chunk (in file FUN-BioCROP_LIDET Study.Rmd): Chunk 1: Remove all functions, clear memory. Removes all functions from R environment, clears the memory. Chunk 2: Load Packages. Loads packages necessary to run the code. Chunk 3: Load CORPSE Data Streams. Sets the working directory and loads the data files necessary to run CORPSE. Chunk 4: Load CORPSE Functions. Loads the R script with CORPSE functions from the working directory, "CORPSE Functions_Bioenergy_V2.R". Chunk 5: Define LIDET parameter sets. Has ten different parameter sets for litter decomposition tested in this study: Baseline parameters, LIDET parameters, and the other 8 best performing parameter sets identified in the modified Monte Carlo. To run the model, all but one parameter set must be commented out. Chunk 6: Load Parameters. Loads all fixed parameters to run the model. Data frame with definitions of parameters is in the CORPSE function script "CORPSE Functions_Bioenergy_V2.R" Chunk 7: Prepare Data Streams. Takes data streams loaded in Chunk 3 and puts them in the format necessary to run the model. The model is coded to run at least two sites at a time, so if only one site is being run it must be run in duplicate. Individual data tables of daily values are created in this chunk from the input data file. Chunk 8: Set Initial Conditions. Creates data tables of soil C and N pools for each soil compartment (rhizo_till, rhizo, bulk_till, bulk, litter) and loads initial values into the data tables. Creates lists for each soil compartment to hold model output. Chunk 9: Load FUN Data and Set Up Matrices. Uses DayCent data to calculate FUN input data: root and leaf N demand, total N demand, plant CN, leaf N available for retranslocation, and litter production. Creates matrices for FUN model outputs. Chunk 10: Run Model. Runs the model. Chunk 11: Prepare Data for Export. Combines data from each day saved as lists into data frames for each soil compartment. Adds values from all soil compartments together to calculate total soil values, creates separate data frames for each soil C and N pool (e.g., protected slow C) for the total soil value. Adds different C and N pools together to calculate total soil C and N for all layers. Creates data frame of ratio of protected to unprotected SOC. Organizes FUN data for export. Chunk 12: Export Results. Exports CSV files of model results to the working directory. Chunk 13: Graph Total Soil C. Makes figure of C remaining over time. Related Links: Original FUN-BioCROP model: https://github.com/BrzostekEcologyLab/FUN-BioCROP LIDET dataset: https://andlter.forestry.oregonstate.edu/data/abstract.aspx?dbcode=TD023

Juice, Stephanie↗
DOE OSTI2023

Supporting information for Few-Shot Learning Enables Population-Scale Analysis of Leaf Traits in Populus trichocarpa

In this work, we use few-shot learning to segment the body and vein architecture of P. trichocarpa leaves from high-resolution scans obtained in the UC Davis common garden. Leaf and vein segmentation are formulated as separate tasks, in which convolutional neural networks (CNNs) are used to iteratively expand partial segmentations until reaching stopping criteria. Our leaf and vein segmentation approaches use just 50 and 8 manually traced images for training, respectively, and are applied to a set of 2,634 top and bottom leaf scans. We show that both methods achieve high segmentation accuracy, in some cases exceeding even human-level segmentation. The leaf and vein segmentations are subsequently used to extract 68 morphological traits using traditional open-source image processing tools, which are validated using real-world physical measurements. For a biological perspective, we perform a genome-wide association study using the vein density trait to discover novel genetic architectures associated with multiple physiological processes relating to leaf development and function. In addition to sharing all of the few-shot learning code (see https://github.com/jlager/few-shot-leaf-segmentation), we are releasing all images, manual segmentations, model predictions, 68 extracted leaf phenotypes, and a new set of SNPs called against the v4 P. trichocarpa genome for 1,419 genotypes. The data folder includes all images, ground truth segmentations, predicted segmentations, and extracted leaf traits. All images encode the sample ID in the file name by indicating the treatment, block, row, position, and leaf side, respectively. For example, the file, C_1_1_2_bot.jpeg, indicates the control treatment, block 1, row 1, position 2, and the bottom side of the leaf. Tabulated results include position IDs as well as the corresponding genotype IDs. The images folder includes the 2,906 high-resolution leaf scans taken in the field. The leaf_masks folder includes 50 ground truth segmentations used for training the leaf tracing algorithm. The leaf_preds folder includes the 2,906 predicted segmentations from the leaf tracing algorithm. The vein_masks folder includes 8 ground truth segmentations used for training the vein growing algorithm. The vein_preds folder includes the 1,453 predicted segmentations from the vein growing algorithm. The vein_probs folder includes the 1,453 predicted probability maps from the vein growing algorithm before thresholding. The genomes folder includes the set of SNPs called against the v4 P. trichocarpa genome for 1,419 genotypes with a README file detailing the steps taken. The results folder includes: (i) raw values of the 68 predicted leaf traits in digital_traits.tsv, (ii) manually measured values of petiole length and width in manual_traits.tsv, (iii) thin plate spline (TPS) adjusted values of the vein density trait in vein_density_tps_adj.tsv, (iv) best linear unbiased prediction (BLUP) adjusted values of the vein density trait in vein_density_blups.tsv, and (v) GWAS results for the vein density trait, including chromosome positions and corresponding P values, in gwas_results.csv.

09 BIOMASS FUELS↗
DOE OSTI2022

KBase Narrative - Viral Analysis End-to-End

This pipeline processes a single metagenomic dataset (downloaded from NCBI SRA) from the Global Ocean Viromes dataset, identifies the viral sequences using VirSorter, and subsequently classifies them with vConTACT2. Along the way there are several intermediary steps to convert files from one KBase object to another - and though some of these can be skipped for this particular dataset - we're explicitly doing them here as to be more easily generalized to other datasets.

Bolduc, Benjamin↗
NASA NTRS1977

User's guide for SFTRAN/360

Extension and improvements made to SFTRAN, a structured-programming language are discussed. This improved language is implemented as a precompiler that translates from SFTRAN to FORTRAN. The SFTRAN language and its use are described. Time-Sharing System (TSS) command procedures were implemented that eliminate the complications of dealing with extra files and processing steps which the use of a precompiler would otherwise require. These command procedures are described and their use is illustrated by examples.

Fessler, T. E.↗
NASA NTRS1978

User's guide to SFTRAN/1100

Extensions and improvements were made to SFTRAN, a structured programming language. This language was implemented as a precompiler that translates from SFTRAN to FORTRAN. It was available to batch and conversational users of the UNIVAC 1100 computer system. The SFTRAN language and its use are described. In addition, conversational time-sharing system command subroutines were implemented that eliminated the complications of dealing with extra files and processing steps that the use of a precompiler would otherwise require. These command subroutines are reported, and their use is illustrated by examples.

Ford, W. F.↗
NASA NTRS1998

Interfacing with Legacy using Remote Method Invocation

The assignment described was enough to make a neophyte Java developer bolt for the door: provide a remote method for use by an applet which invokes a native method that wraps a function in an existing legacy library. The purpose of the remote method is to return an instance of a class object whose contents reflect the data structure returned by the legacy function. While embroiled in implementation, I would have spent the time wading through their JNI use group archive as well, but I couldn't seem to locate one. Subsequently, I made the decision to try to document my findings in order to assist others. Before we start on the class design, let's look at what the existing legacy code does. The C function to be called, Get-Legacy-Data, consists of two steps: an ASII file is read from the local disk and its contents are parsed into a Legacy_Type structure whose address is passed as an argument by the caller. The legacy code was compiled into a shared object library, legacy. so, using the IRIX 6.2 compiler and then loaded onto the Web server, a Silicon Graphics Indy station loaded with the IRIX 6.4 operating system. As far as the class design is concerned, the first thing required is a class to act as a template for the data structure returned by the legacy function. This class, JLegacy, declares a series of public instance variables which correspond to the members of Legacy_Type and provides a parameterless constructor. This constructor is never called, not even by the native method which allocates the object for return to the remote method. Next, the remote interface declaration for the remote object must be defined. In order for JLegacyRO to implement getJLegacy, JLegacyRO must interface with the existing legacy code through a native method, getn. getn is declared in the JLegacyRO class but implemented in C, just like the legacy code. getn returns a JLegacy instance and is declared static since its implementation is the same for all instances of the JLegacyRO class.

Howard, Scott M.↗
NASA NTRS2016

Optimal Reorganization of NASA Earth Science Data for Enhanced Accessibility and Usability for the Hydrology Community

A long-standing "Digital Divide" in data representation exists between the preferred way of data access by the hydrology community and the common way of data archival by earth science data centers. Typically, in hydrology, earth surface features are expressed as discrete spatial objects (e.g., watersheds), and time-varying data are contained in associated time series. Data in earth science archives, although stored as discrete values (of satellite swath pixels or geographical grids), represent continuous spatial fields, one file per time step. This Divide has been an obstacle, specifically, between the Consortium of Universities for the Advancement of Hydrologic Science, Inc. and NASA earth science data systems. In essence, the way data are archived is conceptually orthogonal to the desired method of access. Our recent work has shown an optimal method of bridging the Divide, by enabling operational access to long-time series (e.g., 36 years of hourly data) of selected NASA datasets. These time series, which we have termed "data rods," are pre-generated or generated on-the-fly. This optimal solution was arrived at after extensive investigations of various approaches, including one based on "data curtains." The on-the-fly generation of data rods uses "data cubes," NASA Giovanni, and parallel processing. The optimal reorganization of NASA earth science data has significantly enhanced the access to and use of the data for the hydrology user community.

data rods↗
NASA NTRS1996

An Assessment of IMPAC - Integrated Methodology for Propulsion and Airframe Controls

This report documents the work done under a NASA sponsored contract to transition to industry technologies developed under the NASA Lewis Research Center IMPAC (Integrated Methodology for Propulsion and Airframe Control) program. The critical steps in IMPAC are exercised on an example integrated flight/propulsion control design for linear airframe/engine models of a conceptual STOVL (Short Take-Off and Vertical Landing) aircraft, and MATRIXX (TM) executive files to implement each step are developed. The results from the example study are analyzed and lessons learned are listed along with recommendations that will improve the application of each design step. The end product of this research is a set of software requirements for developing a user-friendly control design tool which will automate the steps in the IMPAC methodology. Prototypes for a graphical user interface (GUI) are sketched to specify how the tool will interact with the user, and it is recommended to build the tool around existing computer aided control design software packages.

Walker, G. P.↗
DOE OSTI2021

ESS-DIVE guidelines for archiving terrestrial model data

This dataset contains supporting documents and images for ESS-DIVE terrestrial model data archiving guidelines.Terrestrial models are broadly defined as numerical models that couple both land dynamics and energy, water, carbon, or nutrient fluxes. We created these guidelines based on input from the U.S. Department of Energy’s Biological and Environmental Research land modeling community. The guidelines are intended to help modelers determine which components of their terrestrial model data associated with publication should be archived. Based on input from the land modeling community, the guidelines recommend archiving both model input and testing data, as well as code, script, and metadata. The guidelines also recommend archiving model data output, depending on the limitations set by data repositories. Lastly, we provide recommendations for bundling data files for publication as well as a discussion about tools that can facilitate model data archiving and reuse.This dataset is an archive of the associated GitHub repository for our model archiving guidelines (https://github.com/ess-dive-community/essdive-model-data-archiving-guidelines). The ‘README.pdf’ file gives a general introduction to the guidelines, and the ‘instructions.pdf’ file provides more detailed steps for following the guidelines. We also provide 2 figures in this data package: 1) a decision tree (model_data_guidelines_decision_tree.png) that can help users determine which components of their model data to archive. and 2) the ‘model_data_guidelines_flmd.png’ file depicts the different files that can be archived in addition to the model data itself. Lastly, we include 3 digitized tables from our associated manuscript and 3 CSV files with anonymized input from DOE scientists about the importance of different aspects of model data archiving from which we developed the guidelines.Dataset updates for v1.1.0: We updated this data package on 2021-11-22 in response to review comments on our related manuscript. In this update we removed one figure so that the model archiving guidelines are conveyed in text rather than an image. We updated the file-level metadata (FLMD) figure to be in accord with the most recent FLMD recommendations. We made minor edits to the README file to update the recommended citation and added two co-authors. We also added 6 new data files (3 are anonymized input from DOE scientists that helped to inform guidelines, and 3 are digitized tables from our manuscript.

54 ENVIRONMENTAL SCIENCES↗
DOE OSTI2021

Sodar - PNNL Scintec MFAS, Oregon Raceway Park - Reviewed Data

These data provide measurements of wind speed and direction up to 400 m above ground level (AGL) (max). The data are stored in two forms: ASCII and raw (binary). ASCII files contain averaged data (currently: 15 min time step and 10 m range gate). Raw files can be reprocessed with sodar software (APRun by Scintec) to produce ASCII files with different time and/or height averaging settings (highest resolution is approximately 90 sec and 10 m). NOTE: Wind direction is reported with respect to magnetic North.

17 WIND ENERGY↗
DOE OSTI2023

Spatio-Temporal Surrogates for Interaction of a Jet with High Explosives: Part II - Clustering Extremely High-Dimensional Grid-Based Data

Building an accurate surrogate model for the spatio-temporal outputs of a computer simulation is a challenging task. A simple approach to improve the accuracy of the surrogate is to cluster the outputs based on similarity and build a separate surrogate model for each cluster. This clustering is relatively straightforward when the output at each time step is of moderate size. However, when the spatial domain is represented by a large number of grid points, numbering in the millions, the clustering of the data becomes more challenging. In this report, we consider output data from simulations of a jet interacting with high explosives. These data are available on spatial domains of different sizes, at grid points that vary in their spatial coordinates, and in a format that distributes the output across multiple files at each time step of the simulation. We first describe how we bring these data into a consistent format prior to clustering. Borrowing the idea of random projections from data mining, we reduce the dimension of our data by a factor of thousand, making it possible to use the iterative k-means method for clustering. We show how we can use the randomness of both the random projections, and the choice of initial centroids in k-means clustering, to determine the number of clusters in our data set. Our approach makes clustering of extremely high dimensional data tractable, generating meaningful cluster assignments for our problem, despite the approximation introduced in the random projections.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2026

Topsoil bulk geochemical compositions - An updated harmonized global dataset

Mineral weathering is a key biogeochemical process because of the capacity of minerals to stabilize organic matter. However, predicting soil weathering status across large spatial areas still isn’t possible due to a lack of global data and theoretical frameworks. To address this knowledge gap, multiple global datasets of bulk topsoil geochemical compositions have been harmonized using R. These datasets document topsoil bulk geochemical compositions across five continents (n = ~16,000 observations). Source data for these observations include the EuroGEOSurveys Geochemical Baseline Database (FOREGS), the US Geological Survey National Geochemical Database (NASGLP), the Geochemical Atlas of Australia (GAA), the US Geological Survey Alaska Geochemical Database (AGD84), the National Cooperative Soil Survey (NCSS), the European Geochemical Mapping of Agricultural Soil (GEMAS), Ecorespira-Amazon (ERA), the New Zealand Geochemical Baseline Survey (NZ_GBS), and the African Soil Information Service (AFSIS). Major elements observed include Aluminum (Al), Calcium (Ca), Iron (Fe), Potassium (K), Magnesium (Mg), Sodium (Na), Titanium (Ti), Manganese (Mn), Phosphorus (P), Carbon (C), and Sulfur (S). This data package includes the harmonized dataset itself, and the R scripts necessary to harmonize these datasets, in addition to metadata that describes all columns, files, and databases used in this project. Methods & Sampling Step 1 – Databases of geochemical data identified This study aimed to leverage existing measurements of topsoil geochemical data. Databases were first identified and deemed appropriate for inclusion if they were measuring soils and performed these measurements on the <2mm soil fraction. Databases such as NCSS and AGD84 needed more post processing to include in the database and this was done using the NCSS_datamerge_031626 R file and Alaska_USGSmerge_031626 R file, respectively. Step 2 – Database harmonization Once appropriate databases were identified, they were harmonized for ease of analysis using the R script Database_Harmonization_031826. This included removing columns from original datasets that would not be used in analysis (removed columns are noted in the code). Then, data cleaning procedures specific to each dataset were undertaken. This includes standardizing columns to include units and adding metadata columns regarding procedures for analyzing specific elements. Functions for standardizing measurements and units are outline in R files: calculate element_mg_kg_031626, calculate_oxide_wt_perc_031626, change_oxide_caps_031626, and conv_2_numeric_031626. This also included adding a unique identifier for each sample to identify it with its respective database (see CD_ID in data dictionary). Geographic information: Data reflect a compilation of datasets collected globally. Geographic areas covered by each of the datasets include: - EuroGEOSurveys Geochemical Baseline Database (FOREGS) - European continent - North American Soil Geochemical Landscapes (NASGLP) - continental United States and limited parts of Canada (see database key for more details) - National Geochemical Survey of Australia (GAA) - Australia - Alaska geochemical database (AGDB4) - Alaska - National Cooperative Soil Survey (NCSS) - Global measurements, but concentrated in the continental United States - Geochemical data for arable land and land under permanent grass cover in continental Europe (GEMAS) - continental Europe - Ecorespira-Amazon (ERA) - Geochemical data from the Amazon basin - Geochemical baseline data for New Zealand (NZGBS) - New Zealand - Geochemical data collected across continental Africa (AfSIS) - Measurements across Africa

EARTH SCIENCE > LAND SURFACE > SOILS↗
DOE OSTI2023

Code for BALDR Study 07.05 v.1.0.0

SAND2024-01293O The Code for BALDR Study 07.05 software reproduces results from the BALDR study concerning "A Semi-Supervised Learning Method to Produce Explainable Radioisotope Proportion Estimates for NaI-based Synthetic and Measured Gamma Spectra." The code for BALDR Study 07.05 can reproduce a scientific study following the step numbers within the file names. Using synthetic and measured data to find the best model for the radioisotope proportion estimation task of interest, the study generated results for inclusion in a paper. The high-level methods involved are neural networks, semi-supervised learning, and out-of-distribution detection. Sandia National Laboratories is a multimission laboratory managed and operated by National Technology & Engineering Solutions of Sandia, LLC, a wholly owned subsidiary of Honeywell International Inc., for the U.S. Department of Energy’s National Nuclear Security Administration under contract DE-NA0003525.

Morrow, Tyler↗
NASA NTRS1995

Visualization and Tracking of Parallel CFD Simulations

We describe a system for interactive visualization and tracking of a 3-D unsteady computational fluid dynamics (CFD) simulation on a parallel computer. CM/AVS, a distributed, parallel implementation of a visualization environment (AVS) runs on the CM-5 parallel supercomputer. A CFD solver is run as a CM/AVS module on the CM-5. Data communication between the solver, other parallel visualization modules, and a graphics workstation, which is running AVS, are handled by CM/AVS. Partitioning of the visualization task, between CM-5 and the workstation, can be done interactively in the visual programming environment provided by AVS. Flow solver parameters can also be altered by programmable interactive widgets. This system partially removes the requirement of storing large solution files at frequent time steps, a characteristic of the traditional 'simulate (yields) store (yields) visualize' post-processing approach.

Vaziri, Arsi↗
NASA NTRS2005

Java-based Graphical User Interface for MAVERIC-II

A computer program entitled "Marshall Aerospace Vehicle Representation in C II, (MAVERIC-II)" is a vehicle flight simulation program written primarily in the C programming language. It is written by James W. McCarter at NASA/Marshall Space Flight Center. The goal of the MAVERIC-II development effort is to provide a simulation tool that facilitates the rapid development of high-fidelity flight simulations for launch, orbital, and reentry vehicles of any user-defined configuration for all phases of flight. MAVERIC-II has been found invaluable in performing flight simulations for various Space Transportation Systems. The flexibility provided by MAVERIC-II has allowed several different launch vehicles, including the Saturn V, a Space Launch Initiative Two-Stage-to-Orbit concept and a Shuttle-derived launch vehicle, to be simulated during ascent and portions of on-orbit flight in an extremely efficient manner. It was found that MAVERIC-II provided the high fidelity vehicle and flight environment models as well as the program modularity to allow efficient integration, modification and testing of advanced guidance and control algorithms. In addition to serving as an analysis tool for techno logy development, many researchers have found MAVERIC-II to be an efficient, powerful analysis tool that evaluates guidance, navigation, and control designs, vehicle robustness, and requirements. MAVERIC-II is currently designed to execute in a UNIX environment. The input to the program is composed of three segments: 1) the vehicle models such as propulsion, aerodynamics, and guidance, navigation, and control 2) the environment models such as atmosphere and gravity, and 3) a simulation framework which is responsible for executing the vehicle and environment models and propagating the vehicle s states forward in time and handling user input/output. MAVERIC users prepare data files for the above models and run the simulation program. They can see the output on screen and/or store in files and examine the output data later. Users can also view the output stored in output files by calling a plotting program such as gnuplot. A typical scenario of the use of MAVERIC consists of three-steps; editing existing input data files, running MAVERIC, and plotting output results.

Seo, Suk Jai↗
NASA NTRS1997

A Geometry Based Infra-structure for Computational Analysis and Design

The computational steps traditionally taken for most engineering analysis (CFD, structural analysis, and etc.) are: Surface Generation - usually by employing a CAD system; Grid Generation - preparing the volume for the simulation; Flow Solver - producing the results at the specified operational point; and Post-processing Visualization - interactively attempting to understand the results For structural analysis, integrated systems can be obtained from a number of commercial vendors. 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. 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. (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. (3) One-Way communication. All information travels on from one phase to the next. Until this process can be automated, more complex problems such as multi-disciplinary analysis or using the above procedure for design becomes prohibitive.

Haimes, Robert↗
NASA NTRS2001

HITEMP Material and Structural Optimization Technology Transfer

The feasibility of adding viscoelasticity and the Generalized Method of Cells (GMC) for micromechanical viscoelastic behavior into the commercial HyperSizer structural analysis and optimization code was investigated. The viscoelasticity methodology was developed in four steps. First, a simplified algorithm was devised to test the iterative time stepping method for simple one-dimensional multiple ply structures. Second, GMC code was made into a callable subroutine and incorporated into the one-dimensional code to test the accuracy and usability of the code. Third, the viscoelastic time-stepping and iterative scheme was incorporated into HyperSizer for homogeneous, isotropic viscoelastic materials. Finally, the GMC was included in a version of HyperSizer. MS Windows executable files implementing each of these steps is delivered with this report, as well as source code. The findings of this research are that both viscoelasticity and GMC are feasible and valuable additions to HyperSizer and that the door is open for more advanced nonlinear capability, such as viscoplasticity.

Collier, Craig S.↗