Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “FILES”

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 181 records · Page 10

Data-model files associated with the manuscript titled "The Importance of Explicitly Representing the Streambed in Watershed Models" (Shuai et al., 2023 HP)

This data package contains the model inputs and outputs used in the manuscript titled "The Importance of Explicitly Representing the Streambed in Watershed Models" (Shuai et al., 2023 HP). The data.zip file contains the data used to drive the Advanced Terrestrial Simulator (ATS) model simulations. The model.zip file contains the XML input file for ATS. The notebook.zip file contains the Jupyter notebooks for pre- and post- processing model results. The figures.zip file contains the raw figures associated with the manuscript. We generated this data package in support of the manuscript and research reproducibility. The background of this study is that the streambed itself has not been explicitly represented in watershed models, although the streambed characteristics are significantly different from those of its surrounding soil. We aim to answer the following questions: 1) How do streambed properties including hydraulic conductivity, thickness and resolution impact the groundwater-surface water exchange fluxes across the streambed? 2) Is an explicit representation of streambed important in watershed modeling?; 3) Is a high-resolution streambed needed for watershed simulations?

54 ENVIRONMENTAL SCIENCES↗

Electricity Baseline 2022 Background Data and Log File

The ElectricityLCI v2 Python package (https://github.com/USEPA/ElectricityLCI/tree/v2.0) was used to generate the 2022 electricity baseline: a regionalized life cycle inventory model of U.S. electricity generation, consumption, and distribution using standardized facility and generation data. ElectricityLCI implements a local data store for downloading and accessing public data on an individual's computer. The data store follows the folder definition provided by USEPA's esupy Python package (https://github.com/USEPA/esupy), which utilized the appdirs Python dependency (https://pypi.org/project/appdirs/). This submission includes the background data used to generate the 2022 electricity baseline inventory. Each zip archive stores the source files as found in their data stores. Sub-folders in each of the data stores are archived separately. For example, stewi.zip contains the JSON files, while stewi.facility.zip is the 'facility' sub-folder of stewi data store that stores the parquet files. To reproduce the data store, extract each zip file and drag-and-drop sub-folders in to their appropriate root folders to recreate the data stores, then copy the root folders to your data store folder (as returned by running the following on the command line: `python -c "import appdirs; print(appdirs.user_data_dir())"`). The main five data stores include: 'electricitylci', 'facilitymatcher', 'fedelemflowlist', 'stewi', and 'stewicombo'. The log file generated by the 2022 model run is also included, which contains the statements at the DEBUG level and above.

Electricity; LCA; data inventory↗

Electricity Baseline 2021 Background Data and Log File

The ElectricityLCI v2 Python package (https://github.com/USEPA/ElectricityLCI/tree/v2.0) was used to generate the 2021 electricity baseline: a regionalized life cycle inventory model of U.S. electricity generation, consumption, and distribution using standardized facility and generation data. ElectricityLCI implements a local data store for downloading and accessing public data on an individual's computer. The data store follows the folder definition provided by USEPA's esupy Python package (https://github.com/USEPA/esupy), which utilizes the appdirs Python dependency (https://pypi.org/project/appdirs/). An overview of the ElectricityLCI data stores may be found on the README (https://github.com/USEPA/ElectricityLCI/blob/v2.0/README.md#data-store). This submission includes the background data used to generate the 2021 electricity baseline inventory. Each zip archive stores the source files as found in their data stores. Sub-folders in each of the data stores are archived separately. For example, stewi.zip contains the JSON files, while stewi.facility.zip is the 'facility' sub-folder of stewi data store that stores the parquet files. To reproduce the data store, extract each zip file and drag-and-drop sub-folders in to their appropriate root folders to recreate the data stores, then copy the root folders to your data store folder (as returned by running the following on the command line: python -c "import appdirs; print(appdirs.user_data_dir())"). The main five data stores include: 'electricitylci', 'facilitymatcher', 'fedelemflowlist', 'stewi', and 'stewicombo'. The log file generated by the 2021 model run is also included, which contains the statements at the DEBUG level and above.

Electricity; LCA; LCI; Life Cycle; data inventory↗

Electricity Baseline 2020 Background Data and Log File

The ElectricityLCI v2 Python package (https://github.com/USEPA/ElectricityLCI/tree/v2.0) was used to generate the 2020 electricity baseline: a regionalized life cycle inventory model of U.S. electricity generation, consumption, and distribution using standardized facility and generation data. ElectricityLCI implements a local data store for downloading and accessing public data on an individual's computer. The data store follows the folder definition provided by USEPA's esupy Python package (https://github.com/USEPA/esupy), which utilizes the appdirs Python dependency (https://pypi.org/project/appdirs/). An overview of the ElectricityLCI data stores may be found on the README (https://github.com/USEPA/ElectricityLCI/blob/v2.0/README.md#data-store). This submission includes the background data used to generate the 2020 electricity baseline inventory. Each zip archive stores the source files as found in their data stores. Sub-folders in each of the data stores are archived separately. For example, stewi.zip contains the JSON files, while stewi.facility.zip is the 'facility' sub-folder of stewi data store that stores the parquet files. To reproduce the data store, extract each zip file and drag-and-drop sub-folders in to their appropriate root folders to recreate the data stores, then copy the root folders to your data store folder (as returned by running the following on the command line: python -c "import appdirs; print(appdirs.user_data_dir())"). The main five data stores include: 'electricitylci', 'facilitymatcher', 'fedelemflowlist', 'stewi', and 'stewicombo'. The log file generated by the 2020 model run is also included, which contains the statements at the DEBUG level and above.

Electricity; LCA; LCI; Life Cycle; data inventory↗

Revision of the APGEMS Dose Conversion Factor File Using Revised Factors from Federal Guidance Report 12 and 13

The Air Pollutant Graphical Environmental Monitoring System (APGEMS) is used by the Hanford Emergency Operation Center (EOC) to provide refined plume modeling of releases involving radionuclides. The dose conversion factors (DCFs) used by APGEMS to convert air concentration to dose are stored in a file called HUDUFACT.dat; the DCFs are based primarily on ICRP 30 compiled in the late 1980’s. This report updates the DCFs using more recent values reported in the Environmental Protection Agencies (EPAs) Federal Guidance Report (FGR) 12 and 13. FGR 12 provides external exposure (air submersion) DCFs for radionuclides in air; FGR 13 provides DCFs for radionuclides from inhalation. DCFs were updated for only those radionuclides listed in the original HUDUFACT.dat file. Since FGR 13 provides inhalation dose conversion factors as a function of age, revised DCF files were created for APGEMS for each age group. The “adult” DCF file is the most relevant to compare to the original DCF file being used in APGEMS; these DCF values are compared in this report.

APGEMS↗

Information Files of 238 U(n,f)/ 235 U(n,f) NIFFTE fissionTPC Cross-sections for the Neutron Data Standards Project

This report documents input files, output files and underlying assumptions for an uncertainty estimate for nuclear data evaluations purposes of the normalized 238 U/ 235 U neutron-induced fission cross-section ratios, 238 U(n,f)/ 235 U(n,f), measured by the NIFFTE fission Time Projection Chamber (fissionTPC). This uncertainty estimate and the resulting files were based on information provided by fissionTPC experimentalists, R.J.Casperson, N.S. Bowden, L. Snyder and K.T. Schmitt, and an EXFOR file compiled by N. Otuka. These files were generated for the Neutron Data Standards project coordinated by the IAEA in order to simplify the incorporation of 238 U(n,f)/ 235 U(n,f) fissionTPC data into the standards database.

238 U(n,f)/ 235 U(n,f)↗

Telestream CML File

This is a chronicle file from the Telestream video digitization software that the NSRC Digital Collections Group has installed on the Red. We have not gotten this software to totally function and want to be able to do a workalong with a Telestream representative. One of their technician’s said this file might be helpful to replicate the problem we see in our digitization lab. (The main pointer to the red network that is in this file are file paths. They have been scrubbed so that “valid path to mxf” replaces the real file path.) (CML stands for controlled markup language.)

97 MATHEMATICS AND COMPUTING↗

Telestream Chronicle File

This is a chronicle file from the Telestream video digitization software that the NSRC Digital Collections Group has installed on the Red. We have not gotten this software to totally function and want to be able to do a workalong with a Telestream representative. One of their technician’s said this file might be helpful to replicate the problem we see in our digitization lab. (The main pointer to the red network that is in this file are file paths. They have been scrubbed so that “valid path to mxf” replaces the real file path.)

97 MATHEMATICS AND COMPUTING↗

A Python Script to Read MCNP6.3 Surface-Source Files

This report provides a Python script to read an MCNP ® surface source file created with the SSW card with SYM = 0 (i.e., the default symmetry treatment). For background: the general format of an MCNP surface-source file is described in; however, that document did not provide coding and/or a tool to interrogate such files. The current format will not be given in this document other than through the record-read statements necessary for the script to function. The reader capability in this report is augmented with the ability to directly write a couple demonstrative outputs: 1. A comma-separated value (CSV) file containing particle phase-space state information and 2. A Matplotlib histogram of the energy distribution of the particles. This report also describes accompanying verification work that shows the script performing as required with MCNP6.2, MCNP6.3, and (expected) MCNP6.4 surface-source files. However, users of the enclosed script must still verify that the script is behaving correctly for their own work.

97 MATHEMATICS AND COMPUTING↗

Restart File Improvements for MPACT

This report documents the work performed to address several defects and features request related to the restart capability in MPACT. The following defects were fixed as a part of this milestone: • #3616 (Defect) Error in MPACT Restart Files with BPRs, • #3637 (Defect) Restart with Semi-PC Yields Inconsistent Results, • #3652 (Defect) Fix Incorrect Exposure Value on HDF File After Restart, • #3777 (Defect) Fix State Point Number when Using Restart File, • #3986 (Defect) Pin Exposures are Incorrect, • #4106 (Defect) Pin Exposures Equal to Zero After Restart, and • #4288 (Defect) Core Average Exposure Wrong when Reading Restart Files. The new features that were added are: • Axial Re-meshing capability, • Incorporation of MAMBA-1D data necessary to restart coupled MPACT/CTF/MAMBA calculations, and • Addition of state variables to the restart file. Numerous tests were also implemented to verify and protect these features and this report was prepared to document the work performed.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

Performance analysis of an optimal file transfer protocol for integrated mobile satellite services

A file-transfer protocol based on the selective-repeat automatic-retransmission-request (ARQ) scheme has been developed for the Mobile Satellite Experiment (MSAT-X). In this protocol, each file is divided into packets, which are error-detected and acknowledge individually. A file can be transferred in either the open- or closed-end connection. In the open-end connection, the file is transmitted continuously according to the selective-repeat scheme until all packets are positively acknowledged; in the closed-end connection, each retransmission will initiate its own connection request. The relationship between the packet size and the average end-to-end delay in the mobile fading environment is investigated. The communications channel uses trellis-coded modulation with symbol interleaving, packet replication, and error detection. The packet error performance in such a channel is evaluated by simulation, and the optimal packet size for various operating conditions is derived, using the simulated results. It is shown that for a symbol-energy-to-noise ratio of 12 dB, each file should be divided into packets of length between 256 bits and 512 bits (excluding the overhead) to minimize the average end-to-end delay.

Wang, Charles C.↗

File concepts for parallel I/O

The subject of input/output (I/O) was often neglected in the design of parallel computer systems, although for many problems I/O rates will limit the speedup attainable. The I/O problem is addressed by considering the role of files in parallel systems. The notion of parallel files is introduced. Parallel files provide for concurrent access by multiple processes, and utilize parallelism in the I/O system to improve performance. Parallel files can also be used conventionally by sequential programs. A set of standard parallel file organizations is proposed, organizations are suggested, using multiple storage devices. Problem areas are also identified and discussed.

Crockett, Thomas W.↗

File concepts for parallel I/O

The subject of input/output (I/O) was often been neglected in the design of parallel computer systems, although for many problems I/O rates will limit the speedup attainable. The I/O problem is addressed by considering the role of files in parallel systems. The notion of parallel files is introduced. Parallel files provide for concurrent access by multiple processes, and utilize parallelism in the I/O system to improve performance. Parallel files can also be used conventionally by sequential programs. A set of standard parallel file organizations is proposed, based on common data partitioning techniques. Implementation strategies for the proposed organizations are suggested, using multiple storage devices. Problem areas are also identified and discussed.

Crockett, Thomas W.↗

Characterizing parallel file-access patterns on a large-scale multiprocessor

High-performance parallel file systems are needed to satisfy tremendous I/O requirements of parallel scientific applications. The design of such high-performance parallel file systems depends on a comprehensive understanding of the expected workload, but so far there have been very few usage studies of multiprocessor file systems. This paper is part of the CHARISMA project, which intends to fill this void by measuring real file-system workloads on various production parallel machines. In particular, we present results from the CM-5 at the National Center for Supercomputing Applications. Our results are unique because we collect information about nearly every individual I/O request from the mix of jobs running on the machine. Analysis of the traces leads to various recommendations for parallel file-system design.

Purakayastha, A.↗

Performance of the Galley Parallel File System

As the input/output (I/O) needs of parallel scientific applications increase, file systems for multiprocessors are being designed to provide applications with parallel access to multiple disks. Many parallel file systems present applications with a conventional Unix-like interface that allows the application to access multiple disks transparently. This interface conceals the parallism within the file system, which increases the ease of programmability, but makes it difficult or impossible for sophisticated programmers and libraries to use knowledge about their I/O needs to exploit that parallelism. Furthermore, most current parallel file systems are optimized for a different workload than they are being asked to support. We introduce Galley, a new parallel file system that is intended to efficiently support realistic parallel workloads. Initial experiments, reported in this paper, indicate that Galley is capable of providing high-performance 1/O to applications the applications that rely on them. In Section 3 we describe that access data in patterns that have been observed to be common.

Nieuwejaar, Nils↗

Publication Bias ( The "File-Drawer Problem") in Scientific Inference

Publication bias arises whenever the probability that a study is published depends on the statistical significance of its results. This bias, often called the file-drawer effect since the unpublished results are imagined to be tucked away in researchers' file cabinets, is potentially a severe impediment to combining the statistical results of studies collected from the literature. With almost any reasonable quantitative model for publication bias, only a small number of studies lost in the file-drawer will produce a significant bias. This result contradicts the well known Fail Safe File Drawer (FSFD) method for setting limits on the potential harm of publication bias, widely used in social, medical and psychic research. This method incorrectly treats the file drawer as unbiased, and almost always miss-estimates the seriousness of publication bias. A large body of not only psychic research, but medical and social science studies, has mistakenly relied on this method to validate claimed discoveries. Statistical combination can be trusted only if it is known with certainty that all studies that have been carried out are included. Such certainty is virtually impossible to achieve in literature surveys.

Scargle, Jeffrey D.↗

Configuration Management File Manager Developed for Numerical Propulsion System Simulation

One of the objectives of the High Performance Computing and Communication Project's (HPCCP) Numerical Propulsion System Simulation (NPSS) is to provide a common and consistent way to manage applications, data, and engine simulations. The NPSS Configuration Management (CM) File Manager integrated with the Common Desktop Environment (CDE) window management system provides a common look and feel for the configuration management of data, applications, and engine simulations for U.S. engine companies. In addition, CM File Manager provides tools to manage a simulation. Features include managing input files, output files, textual notes, and any other material normally associated with simulation. The CM File Manager includes a generic configuration management Application Program Interface (API) that can be adapted for the configuration management repositories of any U.S. engine company.

Follen, Gregory J.↗

Documenting AUTOGEN and APGEN Model Files

A computer program called "autogen hypertext map generator" satisfies a need for documenting and assisting in visualization of, and navigation through, model files used in the AUTOGEN and APGEN software mentioned in the two immediately preceding articles. This program parses autogen script files, autogen model files, PERL scripts, and apgen activity-definition files and produces a hypertext map of the files to aid in the navigation of the model. This program also provides a facility for adding notes and descriptions, beyond what is in the source model represented by the hypertext map. Further, this program provides access to a summary of the model through variable, function, sub routine, activity and resource declarations as well as providing full access to the source model and source code. The use of the tool enables easy access to the declarations and the ability to traverse routines and calls while analyzing the model.

Gladden, Roy E.↗