Search NASA⌕ Search

SEARCH · Search NASA

Results for “File System”

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 631 records · Page 35
All sourcesNASA NTRSDOE OSTI
DOE OSTI2016

An asynchronous traversal engine for graph-based rich metadata management

Rich metadata in high-performance computing (HPC) systems contains extended information about users, jobs, data files, and their relationships. Property graphs are a promising data model to represent heterogeneous rich metadata flexibly. Specifically, a property graph can use vertices to represent different entities and edges to record the relationships between vertices with unique annotations. The high-volume HPC use case, with millions of entities and relationships, naturally requires an out-of-core distributed property graph database, which must support live updates (to ingest production information in real time), low-latency point queries (for frequent metadata operations such as permission checking), and large-scale traversals (for provenance data mining). Among these needs, large-scale property graph traversals are particularly challenging for distributed graph storage systems. Most existing graph systems implement a "level synchronous" breadth-first search algorithm that relies on global synchronization in each traversal step. This performs well in many problem domains; but a rich metadata management system is characterized by imbalanced graphs, long traversal lengths, and concurrent workloads, each of which has the potential to introduce or exacerbate stragglers (i.e., abnormally slow steps or servers in a graph traversal) that lead to low overall throughput for synchronous traversal algorithms. Previous research indicated that the straggler problem can be mitigated by using asynchronous traversal algorithms, and many graph-processing frameworks have successfully demonstrated this approach. Such systems require the graph to be loaded into a separate batch-processing framework instead of being iteratively accessed, however. In this work, we investigate a general asynchronous graph traversal engine that can operate atop a rich metadata graph in its native format. We outline a traversal-aware query language and key optimizations (traversal-affiliate caching and execution merging) necessary for efficient performance. We further explore the effect of different graph partitioning strategies on the traversal performance for both synchronous and asynchronous traversal engines. Our experiments show that the asynchronous graph traversal engine is more efficient than its synchronous counterpart in the case of HPC rich metadata processing, where more servers are involved and larger traversals are needed. Furthermore, the asynchronous traversal engine is more adaptive to different graph partitioning strategies.

96 KNOWLEDGE MANAGEMENT AND PRESERVATION↗
DOE OSTI2019

Open Data, Models, and Codes for Vanadium Redox Batch Cell Systems: A Systems Approach Using Zero-Dimensional Models

Abstract In this paper, we study, analyze, and validate some important zero-dimensional physics-based models for vanadium redox batch cell (VRBC) systems and formulate an adequate physics-based model that can predict the battery performance accurately. In the model formulation process, a systems approach to multiple parameters estimation has been conducted using VRBC systems at low C-rates (~C/30). In this batch cell system, the effect of ions' crossover through the membrane is dominant, and therefore, the capacity loss phenomena can be explicitly observed. Paradoxically, this means that using the batch system might be a better approach for identifying a more suitable model describing the effect of ions transport. Next, we propose an efficient systems approach, which enables to help understand the battery performance quickly by estimating all parameters of the battery system. Finally, open source codes, executable files, and experimental data are provided to enable people's access to robust and accurate models and optimizers. In battery simulations, different models and optimizers describing the same systems produce different values of the estimated parameters. Providing an open access platform can accelerate the process to arrive at robust models and optimizers by continuous modification from the users' side.

25 ENERGY STORAGE↗
DOE OSTI2023

Recent streamflow trends across permafrost basins of North America: Datasets

Climate change impacts, including changing temperatures, precipitation, and vegetation, are widely anticipated to cause major shifts to the permafrost with resulting impacts to hydro-ecosystems across the high latitudes of the globe. However, it is challenging to examine streamflow shifts in these regions owing to a paucity of data, discontinuity of records, and other issues related to data consistency and accuracy. We looked at recent changes in streamflow over 1976-2021 in watersheds affected by varying degrees of permafrost coverage to characterize trends and drivers for a range of watersheds across North America. Data sets are described in detail in the paper associated with this data set, Bennett et al. 2023, Front. Water - Water and Critical Zone, DOI: 10.3389/frwa.2023.1099660.These data contain CSV files of the streamflow, climate, and land surface characteristics for several sites located across the high latitude regions of North America. Both observed and reanalysis data products are provided. These files can be opened using Excel or a text editor, or they can be read, and analyzed in software tools such as Python or R. A brief description of the files is below, and more details can be found in the Methods section.rabpro_stats_north_select_74_55m.csv - This file describes the observed gages used in the analysis.GF31_23_metadat.csv - This file describes the 23 permafrost systems. Columns are as described in rabpro_stats_north_select_74_55m.csv above, with rabpro_id, the id used for the timeseries file mapping in GF31_23_time_series.csv.GF31_23_time_series.csv - This file contains the time series data for the stations described in GF31_23_metadat.csv.GF31_random_reaches_1583.csv - This file describes the 1583 randomly selected permafrost-dominant sites for machine learning analysis.era5_GF31_monthly_vars_random_reaches_1583.csv - This file contains the monthly ERA5 land data for the 1583 randomly selected permafrost-dominant sites.observed.zip: USGS and Hydat station data for the 74 gages analyzed in this study. Monthly, seasonal, and annual streamflow observations for minimum streamflow, mean streamflow, and maximum streamflow. Units are m3/sec. 1975-2022.streamflow_daily_GF31_infilled_1979_2022.csv - infilled daily streamflow data (infilled using GloFAS v 3.1) for 55 gages. Units are m3/sec. 1979-2022.glofas_23.zip - Glofas v3.1 file for the 23 permafrost-dominant gages in the study. Monthly, seasonal, and annual streamflow observations for minimum streamflow, mean streamflow, and maximum streamflow. Units are m3/sec. 1979-2021.glofas_1583.zip - Glofas v3.1 file for the 1583 randomly selected permafrost-dominant gages in the study. Monthly, seasonal, and annual streamflow observations for minimum streamflow, mean streamflow, and maximum streamflow. Units are m3/sec. 1979-2021.

54 ENVIRONMENTAL SCIENCES↗
NASA NTRS2011

ISS Operations Cost Reductions Through Automation of Real-Time Planning Tasks

In 2008 the Johnson Space Center s Mission Operations Directorate (MOD) management team challenged their organization to find ways to reduce the costs of International Space station (ISS) console operations in the Mission Control Center (MCC). Each MOD organization was asked to identify projects that would help them attain a goal of a 30% reduction in operating costs by 2012. The MOD Operations and Planning organization responded to this challenge by launching several software automation projects that would allow them to greatly improve ISS console operations and reduce staffing and operating costs. These projects to date have allowed the MOD Operations organization to remove one full time (7 x 24 x 365) ISS console position in 2010; with the plan of eliminating two full time ISS console support positions by 2012. This will account for an overall 10 EP reduction in staffing for the Operations and Planning organization. These automation projects focused on utilizing software to automate many administrative and often repetitive tasks involved with processing ISS planning and daily operations information. This information was exchanged between the ground flight control teams in Houston and around the globe, as well as with the ISS astronaut crew. These tasks ranged from managing mission plan changes from around the globe, to uploading and downloading information to and from the ISS crew, to even more complex tasks that required multiple decision points to process the data, track approvals and deliver it to the correct recipient across network and security boundaries. The software solutions leveraged several different technologies including customized web applications and implementation of industry standard web services architecture between several planning tools; as well as a engaging a previously research level technology (TRL 2-3) developed by Ames Research Center (ARC) that utilized an intelligent agent based system to manage and automate file traffic flow, archiving f data, and generating console logs. This technology called OCAMS (OCA (Orbital Communication System) Management System), is now considered TRL level 9 and is in daily use in the Mission Control Center in support of ISS operations. These solutions have not only allowed for improved efficiency on console; but since many of the previously manual data transfers are now automated, many of the human error prone steps have been removed, and the quality of the planning products has improved tremendously. This has also allowed our Planning Flight Controllers more time to focus on the abstract areas of the job, (like the complexities of planning a mission for 6 international crew members with a global planning team), instead of being burdened with the administrative tasks that took significant time each console shift to process. The resulting automation solutions have allowed the Operations and Planning organization to realize significant cost savings for the ISS program through 2020 and many of these solutions could be a viable

Hall, Timothy A.↗
DOE OSTI2024

Grid Resilience Plans: State Requirements, Utility Practices, and Utility Plan Template

As of June 2024, 14 states and one city require jurisdictional electric utilities to file resilience plans. Drawing on these requirements and filed plans, this report offers a standard template that states and utilities can consider to improve utility filings for grid resilience plans, either as part of a distribution system plan or as a separate filing. Key elements include a vulnerability assessment, description of proposed resilience programs, and projected costs and rate impacts. While many of these requirements and plans focus on extreme weather hazards, the template also can be used to address additional threats, including cyber and physical attacks and seismic events.

24 POWER TRANSMISSION AND DISTRIBUTION↗
NASA NTRS1980

Interactive display of molecular models using a microcomputer system

A simple, microcomputer-based, interactive graphics display system has been developed for the presentation of perspective views of wire frame molecular models. The display system is based on a TERAK 8510a graphics computer system with a display unit consisting of microprocessor, television display and keyboard subsystems. The operating system includes a screen editor, file manager, PASCAL and BASIC compilers and command options for linking and executing programs. The graphics program, written in USCD PASCAL, involves the centering of the coordinate system, the transformation of centered model coordinates into homogeneous coordinates, the construction of a viewing transformation matrix to operate on the coordinates, clipping invisible points, perspective transformation and scaling to screen coordinates; commands available include ZOOM, ROTATE, RESET, and CHANGEVIEW. Data file structure was chosen to minimize the amount of disk storage space. Despite the inherent slowness of the system, its low cost and flexibility suggests general applicability.

Egan, J. T.↗
DOE OSTI2016

PcapDB: Search Optimized Packet Capture, Version 0.1.0.0

PcapDB is a packet capture system designed to optimize the captured data for fast search in the typical (network incident response) use case. The technology involved in this software has been submitted via the IDEAS system and has been filed as a provisional patent. It includes the following primary components: capture: The capture component utilizes existing capture libraries to retrieve packets from network interfaces. Once retrieved the packets are passed to additional threads for sorting into flows and indexing. The sorted flows and indexes are passed to other threads so that they can be written to disk. These components are written in the C programming language. search: The search components provide a means to find relevant flows and the associated packets. A search query is parsed and represented as a search tree. Various search commands, written in C, are then used resolve this tree into a set of search results. The tree generation and search execution management components are written in python. interface: The PcapDB web interface is written in Python on the Django framework. It provides a series of pages, API's, and asynchronous tasks that allow the user to manage the capture system, perform searches, and retrieve results. Web page components are written in HTML,CSS and Javascript.

Ferrell, Paul↗
DOE OSTI2016

PcapDB: Search Optimized Packet Capture, Version 0.1.0.0

PcapDB is a packet capture system designed to optimize the captured data for fast search in the typical (network incident response) use case. The technology involved in this software has been submitted via the IDEAS system and has been filed as a provisional patent. It includes the following primary components: capture: The capture component utilizes existing capture libraries to retrieve packets from network interfaces. Once retrieved the packets are passed to additional threads for sorting into flows and indexing. The sorted flows and indexes are passed to other threads so that they can be written to disk. These components are written in the C programming language. search: The search components provide a means to find relevant flows and the associated packets. A search query is parsed and represented as a search tree. Various search commands, written in C, are then used resolve this tree into a set of search results. The tree generation and search execution management components are written in python. interface: The PcapDB web interface is written in Python on the Django framework. It provides a series of pages, API's, and asynchronous tasks that allow the user to manage the capture system, perform searches, and retrieve results. Web page components are written in HTML,CSS and Javascript.

Ferrell, Paul↗
NASA NTRS2006

Non Radiation Hardened Microprocessors in Spaced Based Remote Sensing Systems

The CALIPSO (Cloud-Aerosol Lidar and Infrared Pathfinder Satellite Observations) mission is a comprehensive suite of active and passive sensors including a 20Hz 230mj Nd:YAG lidar, a visible wavelength Earth-looking camera and an imaging infrared radiometer. CALIPSO flies in formation with the Earth Observing System Post-Meridian (EOS PM) train, provides continuous, near-simultaneous measurements and is a planned 3 year mission. CALIPSO was launched into a 98 degree sun synchronous Earth orbit in April of 2006 to study clouds and aerosols and acquires over 5 gigabytes of data every 24 hours. The ground track of one CALIPSO orbit as well as high and low intensity South Atlantic Anomaly outlines is shown. CALIPSO passes through the SAA several times each day. Spaced based remote sensing systems that include multiple instruments and/or instruments such as lidar generate large volumes of data and require robust real-time hardware and software mechanisms and high throughput processors. Due to onboard storage restrictions and telemetry downlink limitations these systems must pre-process and reduce the data before sending it to the ground. This onboard processing and realtime requirement load may mean that newer more powerful processors are needed even though acceptable radiation-hardened versions have not yet been released. CALIPSO's single board computer payload controller processor is actually a set of four (4) voting non-radiation hardened COTS Power PC 603r's built on a single width VME card by General Dynamics Advanced Information Systems (GDAIS). Significant radiation concerns for CALIPSO and other Low Earth Orbit (LEO) satellites include the South Atlantic Anomaly (SAA), the north and south poles and strong solar events. Over much of South America and extending into the South Atlantic Ocean the Van Allen radiation belts dip to just 200-800km and spacecraft entering this area are subjected to high energy protons and experience higher than normal Single Event Upset (SEU) and Single Event Latch-up (SEL) rates. Although less significant, spacecraft flying in the area around the poles experience similar upsets. Finally, powerful solar proton events in the range of 10MeV/10pfu to 100MeV/1pfu as are forecasted and tracked by NOAA's Space Environment Center in Colorado can result in Single Event Upset (SEU), Single Event Latch-up (SEL) and permanent failures such as Single Event Gate Rupture (SEGR) in some technologies. (Galactic Cosmic Rays (GCRs) are another source, especially for gate rupture) CALIPSO mitigates common radiation concerns in its data handling through the use of redundant processors, radiation-hardened Application Specific Integrated Circuits (ASIC), hardware-based Error Detection and Correction (EDAC), processor and memory scrubbing, redundant boot code and mirrored files. After presenting a system overview this paper will expand on each of these strategies. Where applicable, related on-orbit data collected since the CALIPSO initial boot on May 4, 2006 will be noted.

Decoursey, Robert J.↗
DOE OSTI2017

Web Proxy Auto Discovery for the WLCG

All four of the LHC experiments depend on web proxies (that is, squids) at each grid site to support software distribution by the CernVM FileSystem (CVMFS). CMS and ATLAS also use web proxies for conditions data distributed through the Frontier Distributed Database caching system. ATLAS & CMS each have their own methods for their grid jobs to find out which web proxies to use for Frontier at each site, and CVMFS has a third method. Those diverse methods limit usability and flexibility, particularly for opportunistic use cases, where an experiment’s jobs are run at sites that do not primarily support that experiment. This paper describes a new Worldwide LHC Computing Grid (WLCG) system for discovering the addresses of web proxies. The system is based on an internet standard called Web Proxy Auto Discovery (WPAD). WPAD is in turn based on another standard called Proxy Auto Configuration (PAC). Both the Frontier and CVMFS clients support this standard. The input into the WLCG system comes from squids registered in the ATLAS Grid Information System (AGIS) and CMS SITECONF files, cross-checked with squids registered by sites in the Grid Configuration Database (GOCDB) and the OSG Information Management (OIM) system, and combined with some exceptions manually configured by people from ATLAS and CMS who operate WLCG Squid monitoring. WPAD servers at CERN respond to http requests from grid nodes all over the world with a PAC file that lists available web proxies, based on IP addresses matched from a database that contains the IP address ranges registered to organizations. Large grid sites are encouraged to supply their own WPAD web servers for more flexibility, to avoid being affected by short term long distance network outages, and to offload the WLCG WPAD servers at CERN. The CERN WPAD servers additionally support requests from jobs running at non-grid sites (particularly for LHC@Home) which it directs to the nearest publicly accessible web proxy servers. Furthermore, the responses to those requests are geographically ordered based on a separate database that maps IP addresses to longitude and latitude.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS1983

DOCU-TEXT: A tool before the data dictionary

DOCU-TEXT, a proprietary software package that aids in the production of documentation for a data processing organization and can be installed and operated only on IBM computers is discussed. In organizing information that ultimately will reside in a data dictionary, DOCU-TEXT proved to be a useful documentation tool in extracting information from existing production jobs, procedure libraries, system catalogs, control data sets and related files. DOCU-TEXT reads these files to derive data that is useful at the system level. The output of DOCU-TEXT is a series of user selectable reports. These reports can reflect the interactions within a single job stream, a complete system, or all the systems in an installation. Any single report, or group of reports, can be generated in an independent documentation pass.

Carter, B.↗
NASA NTRS1987

The 28-entity IGES test file results using ComputerVision CADDS 4X

The investigation was based on the following steps: (1) Read the 28 Entity IGES (Initial Graphics Exchange Specification) Test File into the CAD data base with the IGES post-processor; (2) Make the modifications to the displayed geometries, which should produce the normalized front view and the drawing entity defined display; (3) Produce the drawing entity defined display of the file as it appears in the CAD system after modification to the geometry; (4) Translate the file back to IGES format using IGES pre-processor; (5) Read the IGES file produced by the pre-processor back into the CAD data base; (6) Produce another drawing entity defined display of the CAD display; and (7) Compare the plots resulting from steps 3 and 6 - they should be identical to each other.

Kuan, Anchyi↗
NASA NTRS1994

A report of work activities on the NASA Spacelink public electronic library

NASA Spacelink is a comprehensive electronic data base of NASA and other source educational and informational materials. This service originates at Marshall Space Flight Center (MSFC) in Huntsville, Alabama. This is an education service of NASA Headquarters, through the MSFC Education Office, that first began in February of 1988. The new NASA Spacelink Public Electronic Library was the result of a study conducted to investigate an upgrade or redesign of the original NASA Spacelink. The UNIX Operating System was chosen to be the host operating system for the new NASA Spacelink Public Electronic Library. The UNIX system was selected for this project because of the strengths built into the embedded communication system and for its simple and direct file handling capabilities. The host hardware of the new system is a Sun Microsystems SPARCserver 1000 computer system. The configuration has four 50-MHz SuperSPARC processors with 128 megabytes of shared memory; three SB800 serial ports allowing 24 cable links for phone communications; 4.1 gigabytes of on-line disk storage; and ten (10) CD-ROM drives. Communications devices on the system are sufficient to support the expected number of users through the Internet, the local dial services, long distance dial services; the MSFC PABX, and the NPSS (NASA Packet Switching System) and 1-800 access service for the registered teachers.

Smith, Willard A.↗
NASA NTRS2000

Modeling Tools for Propulsion Analysis and Computational Fluid Dynamics on the Internet

The existing RocketWeb(TradeMark) Internet Analysis System (httr)://www.iohnsonrockets.com/rocketweb) provides an integrated set of advanced analysis tools that can be securely accessed over the Internet. Since these tools consist of both batch and interactive analysis codes, the system includes convenient methods for creating input files and evaluating the resulting data. The RocketWeb(TradeMark) system also contains many features that permit data sharing which, when further developed, will facilitate real-time, geographically diverse, collaborative engineering within a designated work group. Adding work group management functionality while simultaneously extending and integrating the system's set of design and analysis tools will create a system providing rigorous, controlled design development, reducing design cycle time and cost.

Muss, J. A.↗
NASA NTRS2003

HEASARC Software Archive

(1) Chandra Archive: SAO has maintained the interfaces through which HEASARC gains access to the Chandra Data Archive. At HEASARC's request, we have implemented an anonymous ftp copy of a major part of the public archive and we keep that archive up-to- date. SAO has participated in the ADEC interoperability working group, establishing guidelines or interoperability standards and prototyping such interfaces. We have provided an NVO-based prototype interface, intending to serve the HEASARC-led NVO demo project. HEASARC's Astrobrowse interface was maintained and updated. In addition, we have participated in design discussions surrounding HEASARC's Caldb project. We have attended the HEASARC Users Group meeting and presented CDA status and developments. (2) Chandra CALDB: SA0 has maintained and expanded the Chandra CALDB by including four new data file types, defining the corresponding CALDB keyword/identification structures. We have provided CALDB upgrades for the public (CIAO) and for Standard Data Processing. Approximately 40 new files have been added to the CALDB in these version releases. There have been in the past year ten of these CALDB upgrades, each with unique index configurations. In addition, with the inputs from software, archive, and calibration scientists, as well as CIAO/SDP software developers, we have defined a generalized expansion of the existing CALDB interface and indexing structure. The purpose of this is to make the CALDB more generally applicable and useful in new and future missions that will be supported archivally by HEASARC. The generalized interface will identify additional configurational keywords and permit more extensive calibration parameter and boundary condition specifications for unique file selection. HEASARC scientists and developers from SAO and GSFC have become involved in this work, which is expected to produce a new interface for general use within the current year. (3) DS9: One of the decisions that came from last year's HEADCC meeting was to make the ds9 image display program the primary vehicle for displaying line graphics (as well as images). The first step required to make this possible was to enhance the line graphics capabilities of ds9. SAO therefore spent considerable effort upgrading ds9 to use Tcl 8.4 so that the BLT line graphics package could be built and imported into ds9 from source code, rather than from a pre-built (and generally outdated) shared library. This task, which is nearly complete, allows us to extend BLT as needed for the HEAD community. Following HEADCC discussion concerning archiving and the display of archived data, we extended ds9 to support full access to many astronomical Web-based archives sites, including HEASARC, MAST, CHANDRA, SKYVIEW, ADS, NED, SIMBAD, IRAS, NVRO, SAO TDC, and FIRST. Using ds9's new internal Web access capabilities, these archives can be accessed via their Web page. FITS images, plots, spectra, and journal abstracts can be referenced, down-loaded, and displayed directly and easily in ds9. For more information, see: http://hea-www.harvard.edu/saord/ds9. Also after the HEADCC discussion concerning region filtering, we extended the Funtools sample implementation of region filtering as described in: http://hea-www.harvard.edu/saord/funtools/regions.html. In particular, we added several new composite regions for event and image filtering, including elliptical and box annuli. We also extended the panda (Pie AND Annulus) region support to include box pandas and elliptical pandas. These new composite regions are especially useful in programs that need to count photons in each separate region using only a single pass through the data. Support for these new regions was added to ds9. In the same vein, we developed new region support for filtering images using simple FITS image masks, i.e. 8-bit or 16-bit FITS images where the value of a pixel is the region id number for that pixel. Other important enhancements to DS9 this year, include supporor multiple world coordinate systems, three dimensional event file binning, image smoothing, region groups and tags, the ability to save images in a number of image formats (such as JPEG, TIFF, PNG, FITS), improvements in support for integrating external analysis tools, and support for the virtual observatory. In particular, a full-featured web browser has been implemented within D S 9 . This provides support for full access to HEASARC archive sites such as SKYVIEW and W3BROWSE, in addition to other astronomical archives sites such as MAST, CHANDRA, ADS, NED, SIMBAD, IRAS, NVRO, SA0 TDC, and FIRST. From within DS9, the archives can be searched, and FITS images, plots, spectra, and journal abstracts can be referenced, downloaded and displayed The web browser provides the basis for the built-in help facility. All DS9 documentation, including the reference manual, FAQ, Know Features, and contact information is now available to the user without the need for external display applications. New versions of DS9 maybe downloaded and installed using this facility. Two important features used in the analysis of high energy astronomical data have been implemented in the past year. The first is support for binning photon event data in three dimensions. By binning the third dimension in time or energy, users are easily able to detect variable x-ray sources and identify other physical properties of their data. Second, a number of fast smoothing algorithms have been implemented in DS9, which allow users to smooth their data in real time. Algorithms for boxcar, tophat, and gaussian smoothing are supported.

White, Nicholas↗
NASA NTRS1978

Associative programming language and virtual associative access manager

APL provides convenient associative data manipulation functions in a high level language. Six statements were added to PL/1 via a preprocessor: CREATE, INSERT, FIND, FOR EACH, REMOVE, and DELETE. They allow complete control of all data base operations. During execution, data base management programs perform the functions required to support the APL language. VAAM is the data base management system designed to support the APL language. APL/VAAM is used by CADANCE, an interactive graphic computer system. VAAM is designed to support heavily referenced files. Virtual memory files, which utilize the paging mechanism of the operating system, are used. VAAM supports a full network data structure. The two basic blocks in a VAAM file are entities and sets. Entities are the basic information element and correspond to PL/1 based structures defined by the user. Sets contain the relationship information and are implemented as arrays.

Carol Price↗
DOE OSTI2019

FGR 13 Dose Conversion Factor Files

The purpose of this document is to discuss the construction of two MELCOR Accident Consequence Code System (MACCS) dose conversion factor (DCF) files in some detail, an older file created in 2007 named FGR13DCF.inp and a newer file created in 2018 called FGR13GyEquiv_RevAinp. Very briefly, the difference between the two files is that the older file follows the standard conventions of assigning a radiation weighting factor of 20 for alpha radiation for all tissues and organs; whereas, the newer file complies with the Federal Guidance Report (FGR) 13 health effects modeling and uses modified radiation weighting factors (referred to as relative biological effectiveness (RBE) factors) for alpha radiation of 10 for breast and of 1 for red bone marrow. During an intermediate period, a file called FGR13GyEquiv.inp was created and used for the State-of-the-Art Reactor Consequence Analysis (SOARCA) calculations. This file was not released to the MACCS user community, but it is also discussed briefly in this document.

63 RADIATION, THERMAL, AND OTHER ENVIRON. POLLUTAN↗