Search NASA⌕ Search

SEARCH · Search NASA

Results for “file format”

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 73 records · Page 4
All sourcesNASA NTRSDOE OSTI
DOE OSTI2026

Precision of ENDF and ENDL Formatted Data Files

The purpose is to ensure that today’s processing codes produced output to meet today’s accuracy needs. Since 1958 ENDL and about 1965 ENDF have each used a text format to define nuclear and atomic data in 11 columns for each data field. When these formats originated this was judged to be adequate to reproduce the accuracy of data at the time and to meet the needs of our applications. When these formats originated the dominant computer language of the day was FORTRAN and if written using an E11.4 format it would include only 4 or 5 digits of precision, e.g., 0.1234E-03 or 1.2345E-02, varying from one computer/system to another the result was not even unique. In the case of ENDF the 4 digit precision was not even adequate to uniquely define the atomic weight of the target, e.g., U238 = 92238 = 0.9224E+5 = WRONG! From its inceptions the ENDF format had a precision problem. One of my first tasks when in 1967 fresh out of graduate school I joined what later became the National Nuclear Data Center (NNDC), was to address this precision problem. By working with ENDF producers and users throughout the U.S. we verified, 1) E or D is not required to define FORTRAN readable numbers, e.g., E+4 or +4 are both o.k. 2) With ENDF energy eV and cross section in barns, 2 digit exponents are almost never required. 3) Since energy is never negative we could use the first of the 11 columns for a digit. Knowing this allowed us to produce ENDF/B-II to 6 or 7 digit precision, e.g., blank, decimal point, 2 or 3 digit exponent, e.g., ^1.23456-12 or ^1.234567-3. Below is an example of the actual ENDF/B-II data released. Note, the date 1970 and the atomic weight, ZA, uniquely defined to 6-digit accuracy, ^9.22350+ 4.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗
NASA NTRSDate not supplied

Blast from the Past: ASDC Curation for NASA Suborbital Legacy Missions to Promote Data Discovery and Accessibility

NASA has an extensive history of conducting suborbital field campaigns to further advances in atmospheric sciences. Beginning with the Chemical Instrument Test and Evaluation (CITE) conducted in 1983-1984, NASA has completed many suborbital campaigns over the past three decades. Since the early 2010s, suborbital missions are typically assigned to a NASA Distributed Active Archive Center (DAAC) prior to the mission for long-term archival and distribution. Efforts are being made by NASA’s Earth Science Data and Information System (ESDIS) Project and the Airborne Data Management Group (ADMG) to assign legacy missions to DAACs for permanent archival and distribution, so that these valuable datasets remain to be available to the scientific community. NASA’s Atmospheric Science Data Center (ASDC) has been named the assigned DAAC for nearly 20 atmospheric composition legacy missions, including missions conducted as part of the Global Tropospheric Experiment (GTE) and expects to be named the assigned DAAC for more of these missions over the next few years. The primary goal of the ASDC is to provide access to the datasets as they are currently formatted to the broad user community and enhance their findability and accessibility. However, data reporting standards have evolved significantly since 1983 and the datasets span a wide variety of file formats, including text, Ames, GTE, and ICARTT (International Consortium for Atmospheric Research on Transport and Transformation), and the amount of metadata and relevant information included in the files also varies greatly and can not be readily extracted without subject matter knowledge. This has caused challenges for the ASDC’s suborbital metadata extraction pipeline in ensuring that accurate and necessary metadata is being provided for the missions by all the ASDC’s existing search mechanisms. To make the data more findable and accessible, the ASDC has begun researching ways to further enhance the datasets, including distributing value-added products (i.e. consistent file format such as ICARTT or netCDF), adding standard names from the ESDIS Standards Coordination Office (ESCO)-approved Atmospheric Composition Variable Standard Names Convention (ACVSNC), and creating outreach materials such as ArcGIS StoryMaps, User Guides, and Micro Articles, providing overviews of the missions and what type of data was collected during the missions. These efforts also help support NASA’s Open-Source Science by enhancing the FAIRness of the legacy data products. This presentation will review the ASDC’s ongoing efforts, progress made, and future plans for legacy missions.

Megan Buzanowicz↗
DOE OSTI2024

Processing MCNP Elemental Edit Outputs

The Monte Carlo N-Particle (MCNP) transport code version 6 (also known as MCNP6) has the capability for tracking particles on unstructured mesh (UM) geometry models embedded into constructive solid geometry (CSG) cells. A UM geometry is a collection of elements representing a solid geometry. The first step of MCNP UM modeling is using other software packages to create a finite element mesh representation of a solid 3D geometry. Computer-aided design (CAD) or computer-aided manufacturing (CAM) software is typically used to create a solid geometry model, which is later imported into mesh generation software to create a UM model. The MCNP UM feature was originally designed for models generated by the Abaqus/CAE software. The MCNP code version 6.0 and later can process UM models formatted as Abaqus input files. MCNP can process a UM model consisting of several different element types including linear tetrahedral or hexahedral elements and calculate quantities of interest such as flux and energy deposition at elements. An MCNP UM simulation provides high-fidelity elemental edit (i.e., tally) outputs, which can be further used in multiphysics calculations. The MCNP UM feature was used for multiphysics simulations where quantities of interest calculated by MCNP are used as inputs for heat transfer calculations in Abaqus. MCNP6.3 can produce two types of elemental edit output (EEOUT) file formats: ASCII and HDF5. An EEOUT file type must be requested on an EMBED card while output type (flux or energy deposition) must be requested on an EMBEE card. We wrote Python3 scripts to extract energy deposition values in an ASCII or HDF5 EEOUT file and compute a heat flux profile for an Abaqus heat transfer calculation.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗
NASA NTRS2018

Internship in Augmented and Virtual Reality - Rapid Model Import Tool

The integration of virtual and augmented reality, sometimes called mixed reality, is an emerging technology which will likely skyrocket overnight much in the way smartphones did a decade ago. Kennedy Space Center's Augmented and Virtual Reality (AVR) Lab is developing a Rapid Model Import Tool (RMIT) to create a quick and efficient way to bring NASA's complex engineering 3D models into virtual and augmented environments. The long-term objective is to create a tool that will ultimately benefit KSC engineers. Its various uses within NASA can potentially span from astronaut training, to marketing, to public outreach, to name a few. Unity is a prolific cross-platform game engine that allows users to build high quality 2D and 3D games for desktop, mobile, web, and game console platforms. It is perhaps also the most widely used software for virtual reality game development. At the AVR lab, we are looking at alternative uses of Unity to build tools for NASA engineers to perform design, development, testing, and training on spacecraft, rocket delivery systems, ground support equipment, and facilities at KSC. As an intern for the RMIT project, I am charged with the task of performing research on Unity-compatible file types to develop an efficient, affordable, preservative process to bring models from CATIA 3D engineering software into the Unity environment. With a tool called the NASA Enterprise Visualization Application (NEVA), developed by the Boeing Design Visualization group at KSC, we are able to easily convert CATIA's design models to. DAE (also known as COLLADA) and .OBJ file formats. I first reduce the polygon count of the model within CATIA itself, make any necessary tweaks to reduce the model further, and then export using NEVA. The .OBJ or. DAE files that I am left with are then converted by another intern to a Unity-compatible file format using a custom Python script. I have generated extensive documentation of this process in a NEVA User Guide. By the end of this semester, we will have built a solid framework for RMIT based on a thorough understanding of virtual reality specifications and file requirements, allowing future software development teams to go forward with development on the custom tool.

Leap Motion↗
NASA NTRS2000

Pre-Launch Algorithm and Data Format for the Level 1 Calibration Products for the EOS AM-1 Moderate Resolution Imaging Spectroradiometer (MODIS)

The Moderate Resolution Imaging Spectroradiometer (MODIS) radiometric calibration product is described for the thermal emissive and the reflective solar bands. Specific sensor design characteristics are identified to assist in understanding how the calibration algorithm software product is designed. The reflected solar band software products of radiance and reflectance factor both are described. The product file format is summarized and the MODIS Characterization Support Team (MCST) Homepage location for the current file format is provided.

Guenther, Bruce W.↗
NASA NTRS1992

Programs Handle PostScript Files

PSTOOLS is package of four programs to interpret and format files in PostScript language. PSIRIS, PSMATRIX, and PSTEK interpret PostScript language and send graphical results to device. PSPRETTY formats PostScript files by appropriately indenting procedures and code delimited by "saves" and "restores". Written in C.

Choi, Diana↗
DOE OSTI2025

IM3 + EPRI Data Center Load Projections

This dataset contains scenarios of hourly total electricity demand with and without projected loads from data centers over the period 2022-2040. The root projections without data center demands are identical to those documented in Burleyson et al. 2024. In short, those projections encompass hourly electricity demands for 54 Balancing Authorities (BAs) in the United States across a range of eight of weather and socioeconomic scenarios. Refer to the root dataset and accompanying publication, Burleyson et al. 2025, for information about how those projections were generated. For this derivative dataset we used the base loads from the following scenarios: rcp45hotter_ssp3 rcp45hotter_ssp5 rcp85hotter_ssp3 rcp85hotter_ssp5 The root load projections did not reflect the drastic expansion of data centers that has occurred in the last several years to support artificial intelligence and cloud computing. To reflect growth in data center demand, a second set of load projections were created in which we layered in additional data center load projections based on the data center load growth scenarios described in a 2024 report by the Electric Power Research Institute (EPRI): "Powering Intelligence: Analyzing Artificial Intelligence and Data Center Energy Consumption". The EPRI projections from the report are included in this dataset (EPRI_2024_Projections.xlsx). That report contained annual state-level data center load projections for four year-over-year growth rates for data center demands: Low (3.71% annual growth) Moderate (5% annual growth) High (10% annual growth) Higher (15% annual growth) To homogenize the load projections with and without data centers we had to get them to a common scale. The first step was to take the EPRI annual state-level data center energy consumption values and convert them to 8760-hr loads for each year. We did that by assuming a flat (e.g., not weather- or time-sensitive) load profile and distributing the data center loads in each state evenly across all hours in a year. From there the loads were downscaled from the state-level to the county-level using 2019 county-level populations as weights. Finally, the county-level hourly data center loads were summed to the BA-level using the county-to-BA mapping underpinning the root load projections. The net result is 16 (4 weather and socioeconomic scenarios crossed with 4 data center load growth scenarios) unique load projections for the period 2022-2040. The file format follows that of the root dataset with a single additional column "Scaled_TELL_BA_Load_with_DC_MWh" that contains the hourly loads with the added data center loads for a given BA-year-scenario combination. Please refer to the readme file in the root dataset for more information on the file format.

Burleyson, Casey [Pacific Northwest National Labor↗
DOE OSTI2025

Release of ENDF81SaB: ENDF/B-VIII.1-Based ACE Data Files for Thermal Scattering

On August 30, 2024, the National Nuclear Data Center (NNDC) released the ENDF/B-VIII.1 nuclear data library. The library was released in the standard Evaluated Nuclear Data File (ENDF) format. These files can be accessed on the NNDC's website (www.nndc.bnl.gov). The files provided in the thermal neutron scattering sublibrary were processed into A Compact ENDF (ACE)-formatted files, verified, and validated by the XCP-5 Nuclear Data Team, resulting in the ENDF81SaB application library. This report details the processing of these files and the quality assurance approach taken. This is not intended to be a full validation effort; rather, this library is intended to simply reproduce the released files for further validation testing by the community. The validation basis and details of the evaluations are documented in the forthcoming ``Big Paper''.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗
NASA NTRS1994

Image tools for UNIX

This talk features two simple and useful tools for digital image processing in the UNIX environment. They are xv and pbmplus. The xv image viewer which runs under the X window system reads images in a number of different file formats and writes them out in different formats. The view area supports a pop-up control panel. The 'algorithms' menu lets you blur an image. The xv control panel also activates the color editor which displays the image's color map (if one exists). The xv image viewer is available through the internet. The pbmplus package is a set of tools designed to perform image processing from within a UNIX shell. The acronym 'pbm' stands for portable bit map. Like xv, the pbm plus tool can convert images from and to many different file formats. The source code and manual pages for pbmplus are also available through the internet. This software is in the public domain.

Banks, David C.↗
NASA NTRS1998

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↗
DOE OSTI2025

The git based ATLAS data acquisition configuration service in LHC Run 3

The ATLAS experiment at the LHC at CERN uses a large, distributed trigger and data acquisition system composed of many computing nodes, networks, and hardware modules. Its configuration service is used to provide descriptions of control, monitoring, diagnostic, recovery, dataflow and data quality configurations, interconnections, and parameters for modules, chips, and channels of various online systems, detectors, and the whole ATLAS experiment. Those descriptions have historically been stored in more than one thousand interconnected XML files, which are updated by various experts many times per day. Maintaining error-free and consistent sets of such files and providing reliable and fast access to current and historical configurations is a major challenge. This paper gives details of the configuration service upgrade on the modern Git version control system backend for LHC Run 3 and its exploitation experience. It may be interesting for developers using human-readable file formats, where consistency of the files, performance, access control, traceability of modifications, and effective archiving are key requirements.

Soloviev, Igor [Univ. of California, Irvine, CA (U↗
NASA NTRSDate not supplied

High Performance Access to Archival Data Stored in HDF4 and HDF5 on Cloud Object Stores Without Reformatting the Files

Cloud computing offers numerous advantages for users of extensive Earth science data collections. These benefits encompass direct online access to data files and granules from any location, scalable access supporting parallel computing workflows, and flexible computing tools enabling innovative experimentation with processing techniques. However, older archival file formats designed for distinct computing systems hinder efficient access to decade-long time-series data when compared to data stored in modern cloud-optimized formats like Web Object Stores (WOS), exemplified by Amazon Web Services’ Simple Storage Service (S3). We describe DMR++ (Dataset Metadata Response plus plus), a technology facilitating efficient access to HDF5 (Hierarchical Data Format, version 5) and HDF4 files stored on WOS systems without requiring data reformatting. DMR++ achieves performance comparable to technologies like Zarr while preserving the original file structure, a substantial benefit considering the vast quantity of archival files held by organizations such as NASA. Moreover, DMR++ typically outperforms cloud-optimized versions of HDF5. Essentially an XML (Extensible Markup Language) document usually stored alongside the described data, DMR++ can also be generated on-the-fly but is generally created during data staging to the WOS. Archival files that use HDF4/5 often store large arrays of numerical data. The data in these files is often compressed, typically reducing their size by a factor of four or more. To achieve efficient access to portions of those arrays, they are 'chunked' into smaller sub-arrays, each individually compressed. The chunk size is a compromise, where spinning disks can efficiently access data in smaller chunks while S3 favors larger chunks. A simple optimization of aggregating smaller chunks that are stored adjacently, transferring them in a single access and then individually decompressing them will improve performance. NASA data pose an additional challenge: special Application Programmer Interface (API) libraries are often needed to compute some variables. These libraries are incompatible with WOS environments. Our solution involves storing computed values in the DMR++ document or a companion file, making them accessible like other variables and eliminating the need for specialized APIs. We outline specific optimizations for both satellite grid and swath data stored in HDF4-EOS2 (Earth Observing System).

James Gallagher↗
NASA NTRS2018

GMI-IPS: Python Processing Software for Aircraft Campaigns

NASA's Atmospheric Tomography Mission (ATom) seeks to understand the impact of anthropogenic air pollution on gases in the Earth's atmosphere. Four flight campaigns are being deployed on a seasonal basis to establish a continuous global-scale data set intended to improve the representation of chemically reactive gases in global atmospheric chemistry models. The Global Modeling Initiative (GMI), is creating chemical transport simulations on a global scale for each of the ATom flight campaigns. To meet the computational demands required to translate the GMI simulation data to grids associated with the flights from the ATom campaigns, the GMI ICARTT Processing Software (GMI-IPS) has been developed and is providing key functionality for data processing and analysis in this ongoing effort. The GMI-IPS is written in Python and provides computational kernels for data interpolation and visualization tasks on GMI simulation data. A key feature of the GMI-IPS, is its ability to read ICARTT files, a text-based file format for airborne instrument data, and extract the required flight information that defines regional and temporal grid parameters associated with an ATom flight. Perhaps most importantly, the GMI-IPS creates ICARTT files containing GMI simulated data, which are used in collaboration with ATom instrument teams and other modeling groups. The initial main task of the GMI-IPS is to interpolate GMI model data to the finer temporal resolution (1-10 seconds) of a given flight. The model data includes basic fields such as temperature and pressure, but the main focus of this effort is to provide species concentrations of chemical gases for ATom flights. The software, which uses parallel computation techniques for data intensive tasks, linearly interpolates each of the model fields to the time resolution of the flight. The temporally interpolated data is then saved to disk, and is used to create additional derived quantities. In order to translate the GMI model data to the spatial grid of the flight path as defined by the pressure, latitude, and longitude points at each flight time record, a weighted average is then calculated from the nearest neighbors in two dimensions (latitude, longitude). Using SciPya's Regular Grid Interpolator, interpolation functions are generated for the GMI model grid and the calculated weighted averages. The flight path points are then extracted from the ATom ICARTT instrument file, and are sent to the multi-dimensional interpolating functions to generate GMI field quantities along the spatial path of the flight. The interpolated field quantities are then written to a ICARTT data file, which is stored for further manipulation. The GMI-IPS is aware of a generic ATom ICARTT header format, containing basic information for all flight campaigns. The GMI-IPS includes logic to edit metadata for the derived field quantities, as well as modify the generic header data such as processing dates and associated instrument files. The ICARTT interpolated data is then appended to the modified header data, and the ICARTT processing is complete for the given flight and ready for collaboration. The output ICARTT data adheres to the ICARTT file format standards V1.1. The visualization component of the GMI-IPS uses Matplotlib extensively and has several functions ranging in complexity. First, it creates a model background curtain for the flight (time versus model eta levels) with the interpolated flight data superimposed on the curtain. Secondly, it creates a time-series plot of the interpolated flight data. Lastly, the visualization component creates averaged 2D model slices (longitude versus latitude) with overlaid flight track circles at key pressure levels. The GMI-IPS consists of a handful of classes and supporting functionality that have been generalized to be compatible with any ICARTT file that adheres to the base class definition. The base class represents a generic ICARTT entry, only defining a single time entry and 3D spatial positioning parameters. Other classes inherit from this base class; several classes for input ICARTT instrument files, which contain the necessary flight positioning information as a basis for data processing, as well as other classes for output ICARTT files, which contain the interpolated model data. Utility classes provide functionality for routine procedures such as: comparing field names among ICARTT files, reading ICARTT entries from a data file and storing them in data structures, and returning a reduced spatial grid based on a collection of ICARTT entries. Although the GMI-IPS is compatible with GMI model data, it can be adapted with reasonable effort for any simulation that creates Hierarchical Data Format (HDF) files. The same can be said of its adaptability to ICARTT files outside of the context of the ATom mission. The GMI-IPS contains just under 30,000 lines of code, eight classes, and a dozen drivers and utility programs. It is maintained with GIT source code management and has been used to deliver processed GMI model data for the ATom campaigns that have taken place to date.

Damon, M. R.↗
DOE OSTI2025

NGEE Arctic Phase 4 Plant Functional Type Framework for Pan-Arctic Vegetation

The NGEE-Arctic research team identified a common set of hierarchical plant functional types (PFTs) for pan-arctic vegetation that we will use across our research activities. Interdisciplinary work within a large team requires agreement regarding levels of functional organization so that knowledge, data, and technologies can be shared and combined effectively. The team has identified plant functional types as a crucial area where such interoperability is needed. PFTs are used to represent plant pools and fluxes within models, summarize observational data, and map vegetation across the landscape. Within each of these applications, varying levels of PFT specificity are needed according to the specific scientific research goal, computational limitations, and data availability. By agreeing on a specific hierarchical framework for grouping variables in our vegetation data, we ensure the resulting research products will be robust, flexible, and scalable. In this document, we lay out the agreed upon PFT framework with definitions and references to existing literature. Table 1 included in the "NGA700_Phase4PFTFramework_about*" file outlines the relationship between NGEE-Arctic Phase 4, Tier 1 PFTs and the PFTs used within prominent arctic literature as well as publications by the NGEE-Arctic team during phases 1-3.This dataset consists of a table detailing a hierarchical PFT framework that spans 4 tiers with the most granular PFTs listed in tier 1 and the most general PFTs in tier 4. The PFTs within each tier has a single column in the dataset where the PFTs are named and a separate column where the characteristics used to define that PFT are listed. Grey fill of the cells is used to indicate where a given PFT starts to “lose” tier 1 details as you look from left to right. Note the excel file has merged cells to indicate grouping of PFTs across the Tiers- it will not translate into a delimited filetype (.csv, .txt, etc) without modification thus the hierarchical PFT framework table is available in three different file formats: 1) NGA700_Phase4PTS.xlsx – maintains the merged cells and grey fill; 2) NGA700_Phase4PTS.csv – merged cells are split, and grey fill is removed; 3) NGA700_Phase4PTS.pdf – image of the table with merged cells and grey fill. Metadata document included as a *.pdf and file-level metadata and data dictionary as *.csv files.

54 ENVIRONMENTAL SCIENCES↗
NASA NTRS2011

Java Image I/O for VICAR, PDS, and ISIS

This library, written in Java, supports input and output of images and metadata (labels) in the VICAR, PDS image, and ISIS-2 and ISIS-3 file formats. Three levels of access exist. The first level comprises the low-level, direct access to the file. This allows an application to read and write specific image tiles, lines, or pixels and to manipulate the label data directly. This layer is analogous to the C-language "VICAR Run-Time Library" (RTL), which is the image I/O library for the (C/C++/Fortran) VICAR image processing system from JPL MIPL (Multimission Image Processing Lab). This low-level library can also be used to read and write labeled, uncompressed images stored in formats similar to VICAR, such as ISIS-2 and -3, and a subset of PDS (image format). The second level of access involves two codecs based on Java Advanced Imaging (JAI) to provide access to VICAR and PDS images in a file-format-independent manner. JAI is supplied by Sun Microsystems as an extension to desktop Java, and has a number of codecs for formats such as GIF, TIFF, JPEG, etc. Although Sun has deprecated the codec mechanism (replaced by IIO), it is still used in many places. The VICAR and PDS codecs allow any program written using the JAI codec spec to use VICAR or PDS images automatically, with no specific knowledge of the VICAR or PDS formats. Support for metadata (labels) is included, but is format-dependent. The PDS codec, when processing PDS images with an embedded VIAR label ("dual-labeled images," such as used for MER), presents the VICAR label in a new way that is compatible with the VICAR codec. The third level of access involves VICAR, PDS, and ISIS Image I/O plugins. The Java core includes an "Image I/O" (IIO) package that is similar in concept to the JAI codec, but is newer and more capable. Applications written to the IIO specification can use any image format for which a plug-in exists, with no specific knowledge of the format itself.

Deen, Robert G.↗
NASA NTRS2012

Trick Simulation Environment 07

The Trick Simulation Environment is a generic simulation toolkit used for constructing and running simulations. This release includes a Monte Carlo analysis simulation framework and a data analysis package. It produces all auto documentation in XML. Also, the software is capable of inserting a malfunction at any point during the simulation. Trick 07 adds variable server output options and error messaging and is capable of using and manipulating wide characters for international support. Wide character strings are available as a fundamental type for variables processed by Trick. A Trick Monte Carlo simulation uses a statistically generated, or predetermined, set of inputs to iteratively drive the simulation. Also, there is a framework in place for optimization and solution finding where developers may iteratively modify the inputs per run based on some analysis of the outputs. The data analysis package is capable of reading data from external simulation packages such as MATLAB and Octave, as well as the common comma-separated values (CSV) format used by Excel, without the use of external converters. The file formats for MATLAB and Octave were obtained from their documentation sets, and Trick maintains generic file readers for each format. XML tags store the fields in the Trick header comments. For header files, XML tags for structures and enumerations, and the members within are stored in the auto documentation. For source code files, XML tags for each function and the calling arguments are stored in the auto documentation. When a simulation is built, a top level XML file, which includes all of the header and source code XML auto documentation files, is created in the simulation directory. Trick 07 provides an XML to TeX converter. The converter reads in header and source code XML documentation files and converts the data to TeX labels and tables suitable for inclusion in TeX documents. A malfunction insertion capability allows users to override the value of any simulation variable, or call a malfunction job, at any time during the simulation. Users may specify conditions, use the return value of a malfunction trigger job, or manually activate a malfunction. The malfunction action may consist of executing a block of input file statements in an action block, setting simulation variable values, call a malfunction job, or turn on/off simulation jobs.

Lin, Alexander S.↗
DOE OSTI2026

Stable Water Isotope Data for the East River Watershed, Colorado (2014-2025)

The stable water isotope data for the East River Watershed, Colorado, consists of delta2H (hydrogen) and delta18O (oxygen) values from samples collected at multiple, long-term monitoring sites including streams, groundwater wells, springs, and a precipitation collector used to establish a local meteoric water line (LMWL) for the watershed. These locations represent important and/or unique end-member locations for which stable isotope values can be diagnostic of the connection between precipitation inputs as snow and rain and riverine export. Such locations include drainages underline entirely or largely by shale bedrock, land covered dominated by conifers, aspens, or meadows, and drainages impacted by historic mining activity and the presence of naturally mineralized rock. Developing a long-term record of water isotope values from a diversity of environments is a critical component of quantifying the impacts of both climate change and discrete climate perturbations, such as drought, forest mortality, and wildfire, on water export. Such data may be combined with stream gaging stations co-located at each surface water monitoring site to relate seasonal variations in water export to their stable isotopic signature. Data for liquid water delta2H and delta18O values are reported in units of parts per thousand (per-mil; ‰). This data package contains (1) a zip file (isotope_data_2014-2025.zip) containing a total of 95 files: 96 data files of isotope data from across the Lawrence Berkeley National Laboratory (LBNL) Watershed Function Scientific Focus Area (SFA) which is reported in .csv files per location and a locations.csv (1 file) with latitude and longitude for each location; (2) a file-level metadata (v6_20260901_flmd.csv) file that lists each file contained in the dataset with associated metadata; and (3) a data dictionary (v6_20260901_dd.csv) file that contains terms/column_headers used throughout the files along with a definition, units, and data type. Missing values within the anion data files are noted as either "-9999" or "0.0" for not detectable (N.D.) data. There are a total of 43 locations containing isotope data. Update on 2022-06-10: versioned updates to this dataset was made along with these changes: (1) updated isotope data for all locations up to 2021-12-31 and (2) the addition of the file-level metadata (flmd.csv) and data dictionary (dd.csv) were added to comply with the File-Level Metadata Reporting Format. Update on 2022-09-09: Updates were made to reporting format specific files (file-level metadata and data dictionary) to correct swapped file names, add additional details on metadata descriptions on both files, add a header_row column to enable parsing, and add version number and date to file names (v2_20220909_flmd.csv and v2_20220909_dd.csv). Update on 2023-08-08: Updates were made to both the data files and reporting format specific files. New available anion data was added, up until 2023-03-13. The file level metadata and data dictionary files were updated to reflect the additional data added. Update on 2024-03-11: Updates were made to both the data files and reporting format specific files. New available anion data was added, up until 2024-02-19. Further, revisions to the data files were made to remove incorrect data points (from 1970 and 2001). The reporting format specific files were updated to reflect the additional data added. Update on 2025-05-15: Updates were made to both the data files and reporting format specific files. New available isotope data was added, up until the end of WY2024 (September 30, 2024). International Generic Sample Numbers (IGSNs), when registered, were added to the data files. The reporting format specific files were updated to reflect the additional data added. Update on 2026-09-01: Updates were made to both the data files and reporting format specific files. New available isotope data was added, up until the end of WY2025 (September 30, 2025).

54 ENVIRONMENTAL SCIENCES↗
DOE OSTI2026

Cation Data for the East River Watershed, Colorado (2014-2025)

This data package contains mean values for cation concentration for water samples taken from the East River Watershed in Colorado. Inductively coupled plasma mass spectrometry (ICP-MS) has been used to measure the concentrations of elements of interest simultaneously for the East River Watershed, Colorado groundwater and surface water samples to inform insights on the biogeochemistry processes within the watershed. The East River is part of the Watershed Function Scientific Focus Area (WFSFA) located in the Upper Colorado River Basin, United States. For samples collected prior to 06-16-2021, the instrumentation, Elan DRC II, PerkinElmer SCIEX, automatically switches among the three models necessary to analyze all 37 elements. These 37 elements include: (1) Lithium (Li), Beryllium (Be), Boron (B), Sodium (Na), Magnesium (Mg), Aluminium (Al), Silicon (Si), Phosphorus (P), Titanium (Ti), Cobalt (Co), Nickel (Ni), Copper (Cu), Zinc (Zn), Germanium (Ge), Arsenic (As), Rubidium (Rb), Strontium (Sr), Zirconium (Zr), Molybdenum (Mo), Silver (Ag), Cadmium (Cd), Tin (Sn), Antimony (Sb), Caesium (Cs), Barium (Ba), Europium (Eu), Lead (Pb), Thorium (Th), Uranium (U) using standard model, argon Ar as reaction gas, (2) Potassium (K), Calcium (Ca), Vanadium (V), Chromium (Cr), Manganese (Mn), Iron (Fe) using dynamic reaction cell (DRC) model, ammonia NH3 as reaction gas, and (3) Phosphorus (P) and Selenium (Se) using DRC model, oxygen O2 as reaction gas. Note for the samples with higher concentrations of chloride (Cl-), asenic (As) concentrations were analysed with DRC model (oxygen O2 as reaction gas) to avoid the interference of chloride. For samples collected on and after 06-16-2021, an advanced Agilent 8900 triple quadrupole inductively coupled plasma mass spectrometry system (Agilent 8900 QQQ ICP-MS, Agilent Technologies) has been used to measure the concentrations of interested 36 elements simultaneously for environmental samples, including (1) Lithium (Li), Beryllium (Be) and Boron (B) using standard no gas mode, (2) Sodium (Na), Magnesium (Mg), Aluminium (Al) Phosphorus (P), Potassium (K), Chromium (Cr), Manganese (Mn), Iron (Fe), Cobalt (Co), Nickel (Ni), Copper (Cu), Zinc (Zn), Germanium (Ge), Arsenic (As), Rubidium (Rb), Strontium (Sr), Zirconium (Zr), Molybdenum (Mo), Silver (Ag), Cadmium (Cd), Tin (Sn), Antimony (Sb), Cesium (Cs), Barium (Ba), Europium (Eu), Lead (Pb), Thorium (Th) and Uranium (U) using standard helium (He) collision mode, (3) Titanium (Ti) and Vanadium (V) using high Energy (HEHe) helium (He) collision mode, and (4) Silicon (Si), Calcium (Ca) and Selenium (Se) using standard H2 reaction mode. All samples were prepared/diluted with 2% (v/v) ultrapure nitric acid in Milli-Q water (18.2 mega ohm-cm), and analyzed under a rigorous quality assurance and quality control (QA/QC) process. This data package contains (1) a zip file (cation_data_2014_2025.zip) containing a total of 5,849 files: 5.848 data files of cation data from across the Lawrence Berkeley National Laboratory (LBNL) Watershed Function Scientific Focus Area (SFA) which is reported in .csv files per location and a locations.csv (1 file) with latitude and longitude for each location; (2) a file-level metadata (v6_20260901_flmd.csv) file that lists each file contained in the dataset with associated metadata; (3) a data dictionary (v6_20260901_dd.csv) file that contains terms/column_headers used throughout the files along with a definition, units, and data type; (4) PDF and docx files for the detemination of Method Detection Limits (MDLs) for ICP-MS PerkinElmer DRC II instrumentation (Detemination_of_Method_Detection_Limits__MDLs__for_ICP_MS__PerkinElmer_Elan_DRC_II__LBL_Bldg74_Lab214D) for samples before November 2021; (5) PDF and docx files for the determination of MDLs for ICP-MS Agilent 8900 QQQ instrumentation (ICP_MS_Analysis_detection_limits_and_QA_QC_WenmingDong_updated_2026-08-06) for samples November 2021 and onward. Missing values within the anion data files are noted as either "-9999" or "0.0" for not detectable (N.D.) data. There are a total of 113 locations containing cation data. Update on 2021-04-11: Added Detemination of Method Detection Limits (MDLs) for ICP-MS document, which can be accessed as a PDF or with Microsoft Word. Update on 2022-06-10: versioned updates to this dataset was made along with these changes: (1) updated cation data for all locations up to 2021-12-31, (2) removal of units from column headers in datafiles, (3) added row underneath headers to contain units of variables, (4) removed suffix and prefix on two variables (“aqberylliumion_asberyllium” and “aqlithiumion_aslithium”), (5) added -9999 for empty numerical cells, and (6) the addition of the file-level metadata (flmd.csv) and data dictionary (dd.csv) were added to comply with the File-Level Metadata Reporting Format. Update on 2022-09-09: Updates were made to reporting format specific files (file-level metadata and data dictionary) to correct swapped file names, add additional details on metadata descriptions on both files, add a header_row column to enable parsing, and add version number and date to file names (v2_20220909_flmd.csv and v2_20220909_dd.csv). Update on 2023-08-08: Updates were made to both the data files and reporting format specific files. New available anion data was added, up until 2023-01-05. The file level metadata and data dictionary files were updated to reflect the additional data added. Update on 2024-03-11: Updates were made to both the data files and reporting format specific files. New available anion data was added, up until 2023-10-16. Further, revisions to the data files were made to remove incorrect data points (from 1970 and 2001). The reporting format specific files were updated to reflect the additional data added. Updated versions of the PDF and docx files for determination of MDLs for ICP-MS data were added to this dataset for samples starting in November 2021. Update on 2025-05-15: Updates were made to both the data files and reporting format specific files. New available cation data was added, up until the end of WY2024 (September 30, 2024). International Generic Sample Numbers (IGSNs), when registered, were added to the data files. The reporting format specific files were updated to reflect the additional data added. Update on 2026-09-01: Updates were made to both the data files and reporting format specific files. New available cation data was added, up until the end of WY2025 (September 30, 2025). Updated versions, as of 2026-08-06, of the PDF and docx files for determination of MDLs for ICP-MS data were added to this dataset for samples starting in November 2021.

54 ENVIRONMENTAL SCIENCES↗