Search NASA⌕ Search

SEARCH · Search NASA

Results for “DIRECTORIES”

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

Soil Water Retention and Hydraulic Conductivity Data and Model at Snodgrass Mountain in East River Watershed, Colorado 2020-2025

This data package includes soil water retention and hydraulic conductivity data and model fitting results from measurements of ex-situ soil samples and in-situ soil sensors at Snodgrass Mountain. Soil water retention curves (SWRC) characterize soil water content as a function of soil water potential. SWRC depends on soil texture and pore structure and can be used to describe the constraints on biogeochemical processes in terms of soil water availability. In this data package, the sample identification follows the format SG-X-Y, where SG refers to Snodgrass Mountain, X is the location identifier, and Y is the depth identifier at the same X (shallow Y=1). Specifically, SG-EHS is associated with ecohydrology sites under the East-Taylor Watershed Community Observatory Sites directory, and SG-ERTn (upslope n=1) are points along the Snodgrass electrical resistivity tomography transect not associated with the existing site names in the directory. The sample and location information can be found in metadata.csv. Sampling and Measurements Each sample falls into one of the three sampling methods – (1) intact cores, (2) repacked samples, or (3) soil sensors – and one of the two measurement methods – (a) laboratory or (b) in-situ. Both intact cores and repacked samples were measured using the laboratory methods, which include measurements of soil water potential (HYPROP & WP4C, METER), saturated (KSAT, METER) and unsaturated hydraulic conductivity (HYPROP). The in-situ method uses a pair of co-located soil sensors to measure volumetric water content (TEROS12, METER) and soil water potential (TEROS21, METER), and the hydraulic conductivity was not measured. In comparison, the laboratory methods progress from full saturation to dry conditions, and the in-situ method includes both dry-to-wet and wet-to-dry cycles. The sampling and measurement methods for each sample can be found in metadata.csv, and more information about the measurements is detailed in the Methods section below. Models Retention and hydraulic conductivity data were fitted with four van-Genuchten-type models (specified by “model_name” column in the files): (1) traditional constrained van Genuchten model (“vG_constrained”), (2) traditional unconstrained van Genuchten model (“vG_unconstrained”), (3) PDI-variant of the constrained van Genuchten model (“vG_constrained_PDI”), and (4) PDI-variant of the unconstrained van Genuchten model (“vG_unconstrained_PDI”). The difference between the constrained (1: n) and the unconstrained (2: n, m) van Genuchten models is the number of pore-size distribution parameters in the model equations, giving the unconstrained model more degrees of freedom when fitting the data. Between the traditional and the PDI-variant models, model fitting differs the most at the dry end of the measurements. The traditional models allow infinite suction at the residual water content (water content does not drop below residual water content), and the PDI-variant models enforce a soil water potential value of pF=6.8 (~ -630 MPa) at oven-dryness (water content reaches 0). The inclusion of the van-Genuchten-type models is due to their common application. If other retention models are required, users can access the data in data.csv for further data fitting. More information about the models can be found in the Methods section below. Fitting Tasks The model fitting can be categorized into three levels of tasks (specified by “fitting_task” column in the files). Level 1 (“fit_retention”) only includes retention data fitting (the only level available for the in-situ method). Level 2 (“fit_retention_conductivity”) includes both retention and hydraulic conductivity data fitting, and the saturated hydraulic conductivity (Ks, a parameter of the hydraulic conductivity functions) is fixed by the measurements from KSAT. Level 3 (“fit_retention_conductivity_Ks”) also includes both retention and hydraulic conductivity data fitting, but Ks is a fitted parameter without the constraints from KSAT measurements. Among the same retention models (e.g. vG_constrained models of the same sample), level 1 should produce the best retention data fitting. Level 2 should have the highest misfit of the retention and hydraulic conductivity data, because the retention and hydraulic conductivity functions share common model parameters, and the unsaturated hydraulic conductivity (HYPROP) data fitting is subject to Ks measured independently by KSAT. Level 3 should have mid-level misfits of the retention and hydraulic conductivity data. While level 3 fits the hydraulic conductivity data better than level 2, the fitted Ks value might be unreasonable due to the lack of constraints at the wet end of the measurements. General recommendation when using this data package: (1) Choice of sampling methods: Intact cores and in-situ soil sensors could be prioritized because these sampling methods are less destructive. While the repacked samples were packed to the target bulk density (estimated post-sampling, when sample volume was known), these samples had altered pore structures. Nevertheless, intact cores might suffer from sample gaps that would lead to overestimation of Ks (sample gaps can be inferred from the “soil_sample_volume” column in metadata.csv when the value is < 249). In-situ method also has higher uncertainty in characterizing the wet end of the SWRC because of sensor limitations and the difficulty in reaching full saturation under natural conditions. (2) Choice of fitting tasks: When only retention data is needed, level 1 (“fit_retention”) should be prioritized. When both retention and hydraulic conductivity data are needed, level 2 (“fit_retention_conductivity”) could be prioritized. (3) Choice of models: This could depend on what the downstream models call for. If no specific model is required, model misfit could be used as a ranking criterion. Model misfit values in terms of RMSE can be found in model_parameters.csv. The following files are included in this data package: (1) metadata.csv – This file includes the general information of each sample, including location (description, geocoordinates, elevation), sampling and measurements details (method, depth, time or period, volume, instruments), and soil physical properties (bulk density, saturated hydraulic conductivity, only applicable to physical soil samples). (2) data.csv – This file includes soil water potential, volumetric water content, and unsaturated hydraulic conductivity data of each sample. Column “instrument” specifies the instrument (HYPROP, WP4C, or TEROS) used to perform the measurements. (3) model_fit.csv – This file includes soil water potential, volumetric water content, and unsaturated hydraulic conductivity fitted from the four models and three fitting tasks. Column “model_name” specifies the retention model used, and “fitting_task” specifies the level of data fitting. Missing values indicate that the variable does not apply to that fitting task. (4) model_parameters.csv – This file includes the fitted model parameters, model misfits, and conventional water content thresholds (field capacity and wilting point) from the four models and three fitting tasks. Column “model_name” specifies the retention model used, and “fitting_task” specifies the level of data fitting. Missing values indicate that the parameter does not apply to that model and/or that fitting task. (5) data_Ks.csv – This file includes the saturated hydraulic conductivity measurements from KSAT. (6) /figure/*.png – This folder includes three quick visualizations of the data, retention model fitting results and misfits, and hydraulic conductivity model fitting results, misfits, and parameters. The model fitting results are separated by samples and fitting tasks and colored by models. Zoom-in required. (7) /hyprop/*.bdhx – This folder includes proprietary hyprop files that require the free Labros SoilView-Analysis (METER) to open. Users can explore data fitting using other retention models (i.e. Brooks-Corey, Fredlund-Xing, Kosugi, bimodal models). Be aware that Ks value is pre-entered under “Fitting tab, Conductivity functions parameters” for level 2 fitting. If the value is lost, please refer to metadata.csv under “Ks” column. (8) Six file-level metadata that summarize file, header, column, and variable information of all files. This work was supported by the Watershed Function Science Focus Area at Lawrence Berkeley National Laboratory funded by the US Department of Energy, Office of Science, Biological and Environmental Research under Contract No. DE-AC02-05CH11231.

EARTH SCIENCE > LAND SURFACE > SOILS↗
DOE OSTI2026

Data and Scripts Associated with "Modeling Ecohydrological Responses of Vegetation to Urban Microclimates Using the E3SM Land Model"

This dataset supports the study of vegetation ecohydrological responses to urban microclimates using the land component of the Energy Exascale Earth System Model (ELM) at four urban sites in Knoxville, Tennessee, USA. It includes the model inputs, simulation outputs, and associated scripts for running ELM simulations and analyzing the resulting data. The Model_Inputs folder includes static surface data, satellite-derived phenology (i.e., leaf area index), and atmospheric forcing data used to drive ELM simulations. Detailed descriptions of these datasets are provided in Section 2.3.2 of the associated manuscript. The Model_Outputs folder contains simulation results for the baseline, treatment, and ensemble experiments. Outputs from the baseline and treatment simulations are provided as raw ELM NetCDF files. Because the raw outputs from the 4,000-member ensemble are prohibitively large, the ensemble results are provided as summarized CSV files, which also serve as the source data for Figure 5 of the associated manuscript. The Scripts folder contains three components: E3SM, the core codebase of the Energy Exascale Earth System Model (E3SM); elm-olmt, the Offline Land Model Testbed (OLMT) used to perform the simulations; and knoxville_elm, which contains the analysis scripts used to process model outputs and generate the figures and results presented in the associated manuscript. Additional information is provided in Scripts_readme.txt within the Scripts directory.

Lu, Xiaoman [ORNL] (ORCID:0000000306698780)↗
DOE OSTI2020

LLNL Kimberlina 1.2 NUFT Simulations June 2018 (v2)

This dataset contains the output 6,000, 3-dimensional reactive multi-phase flow and transport aquifer simulations of brine and CO2 leakage into a protective aquiver in California’s San Joaquin Valley and input data files detailing the geologic mesh, aquifer physical properties and CO2 and brine injection rates. This data set was generated as an ongoing effort with the US DOE National Risk Assessment Partnership (NRAP) to evaluate the effectiveness of monitoring techniques to detect brine and CO2 leakage from legacy wells into underground sources of drinking water overlaying a CO2 storage reservoir. Each simulation contains a unique set of input parameters, generated stochastically. The outputs consist of these upper three geologic layers (from top): the Etchegoin, Macoma-Chanac, Santa Margarita-McLure formations. These simulations span the several distances (1, 3 and 6 km or wells W31-0.2, W31-0.5 and W31-1.0, respectively) from the CO2 injector, initiated from bottom hole pressure and saturation to calculate wellbore leakage from the storage reservoir, with low and high regional groundwater gradients and wellbore leakage into 5 leaky nodes. The dataset includes 1,000 unique simulations for each distance, which each contain a unique aquifer heterogeneity, aquifer and caprock permeability, and two model generations are included with a high permeability (prod07) and hybrid permeability (prod09). The range of permeability distributions is listed in Table 1. Each model generation consists of 3,000 simulations. Included in the dataset are the leakage rates determined from 2D wellbore models which utilize the pressure and CO2 saturation from LBL's reservoir simulations, NUFT mesh files with distributed lithology, NUFT rocktab files which describe the material properties for the geologic layers and the NUFT input files and post-processed output 'ntab' files. Each ntab file contains spatial (rows) and temporal (columns) model output tables for each model cell, the locations (x,y,z) and dimensions for each cells (dx, dy, dz). Table 1. Permeability distribution ranges for prod07 and prod09 model generations Geologic Layer: Permeability Range (log10 m^2) prod07 prod09 Etchegoin -12.92 to -10.92 -13.70 to -11.44 Macoma-Chanac -12.72 to -10.72 -13.50 to -11.24 Santa Margarita-McLure -12.70 to -10.70 -13.48 to -11.22 The input files used to generate the model include which are included in the dataset are: Time series of CO2 leakage input into the model (ex: Q_brn.W31-0.2.sim1000.layers123.tab) Time series of CO2 leakage input into the model (ex: Q_CO2.W31-0.2.sim1000.layers123.tab) Physical properties of the aquifer materials detailing the aquifer porosity, solid density, partitioning coefficients, permeabilities and van-Genuchten parameters detailed in a NUFT rocktab file: (ex: sim1000.usnt.rocktab) Numerical mesh and geologic data assigned to each model cell detailed in a NUFT genmsh format (ex: sim1000.mesh_k16.prod07.trans.genmsh) The primary output parameters are: pH (use absolute value) Change in TDS (mg/kg) Change in Pressure (Pa) Change CO2 gas saturation (fraction range 0.0-1.0) for example, the directory /p/lscratchh/mansoor1/nrap/kimberlina/prod09/mainfiles/sim1000/W31- 0.2 contains: sim1000.W31-0.2.trans.pH.red.ntab sim1000.W31-0.2.no_bg.trans.TDS.red.ntab sim1000.W31-0.2.usnt.P.deltabg.red.ntab sim1000.W31-0.2.usnt.CO2_sat.deltabg.red.ntab Each row in the NTAB files consist of model output per numerical grid cell. Each output file contains 33 columns (variables), including the information of numerical records, geologic location and sizes and the simulated parameter values over time. The first 13 variables are about numerical records and relative geologic information for a simulation grid: 1. index: simulation index 2. i: the ith grid of x-axis 3. j: the ith grid of y-axis 4. k: the ith grid of z-axis 5. element_ref: element reference 6. nuft_ind: nuft index 7. x: grid location in the x axis direction 8. y: grid location in the y axis direction 9. z: grid location in the z axis direction 10. dx: grid length in the x axis direction 11. dy: grid length in the y axis direction 12. dz: grid length in the z axis direction 13. volume: volume of the simulation grid The remainder (14, 15, 16...) variables are the simulated parameter values over time, take Pressure as an example, are: 14. 0.0y: initial pressure per cell. 15. 10.0y: simulated pressure at the end of the 10th year. 16. 20.0y: simulated pressure at the end of the 20th year. ... (repeated for every 10 years until 200 years)... The model extends 10,000 m, 5,000 m and 1,411 m in the x,y and z dimensions, respectively. The mesh consists of 164,832 cells with mesh dimensions of 101 x 51 x 32 (nx, ny, nz), with cell dimensions ranging from 100 m laterally (along x and y-axis) and model layers are as designated in the z-axis: Layer 1: atmosphere (1e-30 m thick) Layer 2: upper caprock (10 m thick) Layers 3-13: Etchegoin (536.23 m thck) Layers 14-27: Macoma-Chanac (679.04 m thick) Layers 28-32: Santa Margarita-McLure (185.94 m thick) The wellbore is placed along node i=51, j=26, and extends vertically along 5 nodes from the top to the bottom of the model. Special instructions when extracting files: Each Gzip archive (ex: prod07.sim1000-sim00099.tar.gz) contains 100 simulations. Gzip archives should be transferred into base directories (ie. In Linux: mkdir prod07; mv prod07.*.tar.gz prod07/.) before extracting, or files will be overwritten. Each sub-simulation tree should have the following file structure pattern (using the linux 'tree' command): |-- prod07 | |-- sim0001 | |-- W31-0.2 | | |-- Q_brn.W31-0.2.sim0001.layers123.tab | | |-- Q_co2.W31-0.2.sim0001.layers123.tab | | |-- sim0001.W31-0.2.no_bg.trans.TDS.red.ntab | | |-- sim0001.W31-0.2.trans.pH.red.ntab | | |-- sim0001.W31-0.2.usnt.CO2_sat.deltabg.red.ntab | | |-- sim0001.W31-0.2.usnt.P.deltabg.red.ntab | |-- W31-0.5 | | |-- Q_brn.W31-0.5.sim0001.layers123.tab | | |-- Q_co2.W31-0.5.sim0001.layers123.tab | | |-- sim0001.W31-0.5.no_bg.trans.TDS.red.ntab | | |-- sim0001.W31-0.5.trans.pH.red.ntab | | |-- sim0001.W31-0.5.usnt.CO2_sat.deltabg.red.ntab | | |-- sim0001.W31-0.5.usnt.P.deltabg.red.ntab | |-- W31-1.0 | | |-- Q_brn.W31-1.0.sim0001.layers123.tab | | |-- Q_co2.W31-1.0.sim0001.layers123.tab | | |-- sim0001.W31-1.0.no_bg.trans.TDS.red.ntab | | |-- sim0001.W31-1.0.trans.pH.red.ntab | | |-- sim0001.W31-1.0.usnt.CO2_sat.deltabg.red.ntab | | |-- sim0001.W31-1.0.usnt.P.deltabg.red.ntab | |-- sim0001.mesh_k16.prod07.trans.genmsh Disclaimer This document was prepared as an account of work sponsored by an agency of the United States government. Neither the United States government nor Lawrence Livermore National Security, LLC, nor any of their employees makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States government or Lawrence Livermore National Security, LLC. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States government or Lawrence Livermore National Security, LLC, and shall not be used for advertising or product endorsement purposes. Lawrence Livermore National Laboratory is operated by Lawrence Livermore National Security, LLC, for the U.S. Department of Energy, National Nuclear Security Administration under Contract DE-AC52-07NA27344. This report was reviewed and released as LLNL-MI-753464.

aquifer↗
DOE OSTI2016

Lustre Distributed Name Space (DNE) Evaluation at the Oak Ridge Leadership Computing Facility (OLCF)

This document describes the Lustre Distributed Name Space (DNE) evaluation carried at the Oak Ridge Leadership Computing Facility (OLCF) between 2014 and 2015. DNE is a development project funded by the OpenSFS, to improve Lustre metadata performance and scalability. The development effort has been split into two parts, the first part (DNE P1) providing support for remote directories over remote Lustre Metadata Server (MDS) nodes and Metadata Target (MDT) devices, while the second phase (DNE P2) addressed split directories over multiple remote MDS nodes and MDT devices. The OLCF have been actively evaluating the performance, reliability, and the functionality of both DNE phases. For these tests, internal OLCF testbed were used. Results are promising and OLCF is planning on a full DNE deployment by mid-2016 timeframe on production systems.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2021

VERA Installation Guide

This guide describes the structure and setup of the standard VERA development environment (VERA Dev Env) and standard VERA Third Party Libraries (TPLs) that need to be in place before installing many of the VERA simulation components. It describes everything from the initial setup on a new machine to the final build, testing, and installation of VERA components. The goal of this document is to describe how to create the directories and contents outlined in 'Standard VERA Dev Env Directory Structure' and then obtain the remaining VERA source and build, test, and install any of the necessary VERA components on a given system. This document describes the process both for a development version of VERA and for a released tarball of the VERA sources.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2023

Updated Baseline Cost Model for Hydropower (2023)

The "Updated Baseline Cost Model (BCM) for Hydropower" is an empirical model for estimating the costs of US hydropower projects in six categories (Non-Powered Dam (NPD), New Stream Development (NSD), Canal/Conduit, Pumped Storage Hydro (PSH), Capacity Expansion, Generator Rewind). The model equations have been estimated with data on existing or planned projects obtained from various sources. NOTE: This is a macro-enabled workbook, so Excel may block it on the first opening. In that case: 1. Save the workbook to a local directory 2. Right-click on the workbook in the local directory and select “Properties” 3. Then check “Unblock” at the bottom of the “General” tab.

13 HYDRO ENERGY↗
DOE OSTI2017

Facilitating the Use of Epidemiological Models for Infectious Disease Surveillance

1. To develop a comprehensive model characterization framework to describe epidemiological models in an operational context. 2. To apply the framework to characterize “operational” models for specific infectious diseases and provide a web-based directory, the biosurveillance analytics resource directory (BARD) to the global infectious disease surveillance community. Epidemiological modeling for infectious disease is useful for disease management and routine implementation needs to be facilitated through better description of models in an operational context. A standardized model characterization process that allows selection or making manual comparisons of available models and their results is currently lacking. Los Alamos National Laboratory(LANL) has developed a comprehensive framework that can be used to characterize an infectious disease model in an operational context. We offer this framework and an associated database to stakeholders of the infectious disease modeling field as a tool for standardizing model description and facilitating the use of epidemiological models. Such a framework could help the understanding of diverse models by various stakeholders with different preconceptions, backgrounds, expertise ,and needs, and can foster greater use of epidemiological models as tools in infectious disease surveillance. We define, “operational” as the application of an epidemiological model to a real-world event for decision support and can be used by experts and non-experts alike. The term “model” covers three major types, risk mapping, disease dynamics and anomaly detection. To develop a framework for characterizing epidemiological models we collected information via a three-step process: a literature search of model characteristics, a review of current operational infectious disease epidemiological models, and subject matter expert (SME)panel consultation. We limited selection of operational models to five infectious diseases: influenza, malaria, dengue, cholera and foot-and-mouth disease (FMD). These diseases capture a variety of transmission modes, represent high or potentially high epidemic or endemic burden, and are well represented in the literature. We also developed working criteria for what attributes can be used to comprehensively describe an operational model including a model’s documentation, accessibility, and sustainability. To apply the model characterization framework, we built the BARD, which is publicly available (http://brd.bsvgateway.org).A document was also developed to describe the usability requirements for the BARD; potential users (and non-users) and use cases are formally described to explain the scope of use. 1. Framework for model characterization. The framework is divided into six major components (Figure 1):Model Purpose, Model Objective, Model Scope, Biosurveillance(BSV) goals, Conceptual Model and Model Utility; each of which has several sub-categories for characterizing each aspect of a model.2. Application to model characterization Models for five infectious diseases—cholera, malaria, influenza, FMD and dengue were characterized using the framework and are included in the BARD database. Our framework characterized disparate models in a streamlined fashion. Model information could be binned into the same categories, allowing easy manual comparison and understanding of the models.3. Development of the BARD. Our model characterization framework was implemented into an actionable tool which provides specific information about a model that has been systematically categorized. It allows manual category-to-category comparison of multiple models for a single disease and while the tool does not rank models it provides model information in a format that allows a user to make a ranking or an assessment of the utility of the model. With the model characterization framework we hope to encourage model developers to start describing the many features of their models using a common format. We illustrate the application of the framework through the development of the BARD which is a scientific and non-biased tool for selecting an appropriate epidemiological model for infectious disease surveillance. Epidemiological models are not necessarily being developed with decision makers in mind. This gap between model developers and decision makers needs to be narrowed before modeling becomes routinely implemented in decision making. The characterization framework and the tool developed (BARD) area first step towards addressing this gap.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2022

IM3/HyperFACETS Thermodynamic Global Warming (TGW) Simulation Datasets

Publication For a thorough description of the methods, see the peer-reviewed paper: Jones, A.D., Rastogi, D., Vahmani, P. et al. Continental United States climate projections based on thermodynamic modification of historical weather. Sci Data 10, 664 (2023). https://doi.org/10.1038/s41597-023-02485-5 Overview The IM3 / HyperFACETS climate simulations provide 40-year historical (1980-2019) as well as four 80-year future simulations (2020-2099) over the U.S. The future simulations are split into near (2020-2059) and far future (2060-2099) segments. The future scenarios span a range of plausible changes in future climate (both Global Circulation Model (GCM) and Representative Concentration Pathways/Shared Socioeconomic Pathway (RCP/SSP) dimensions). The simulations provide climate variables with high spatiotemporal resolution (25 hourly variables and 207 3-hourly variables at 12 km2). The datasets are generated using dynamical downscaling with the WRF (Weather Research and Forecasting) model (version 4.2.1) and therefore preserve physical consistency across variables. WRF is a state-of-the-art, fully compressible, non-hydrostatic, mesoscale numerical weather prediction model. WRF is coupled with an urban canopy model (UCM), which resolves urban surfaces. The future scenarios were developed using a thermodynamic global warming approach where past events are replayed under a range of future warming conditions. These scenarios therefore provide a perspective on potential increases in extreme event intensity, geographic scope, and duration, with previously non-extreme conditions potentially crossing new thresholds to be considered extreme by today's standards. This approach is not intended to estimate future changes in extreme event frequency that might result from changes in large-scale atmospheric dynamics. This dataset has NOT been bias corrected. A bias corrected version of selected variables is under development and will be released here when available. Scenarios Files Data for each scenario is provided in weekly NetCDF files. 25 variables are available at hourly resolution, and 207 variables are available at three-hourly resolution. Spatial resolution is 12km and spans the conterminous United States (CONUS), including some areas of Canada and Mexico, resulting in a grid of 424 by 299 cells. The spatial projection is a Lambert Conformal Conic with the following proj-string: "+proj=lcc +lat_0=40.0000076293945 +lon_0=-97 +lat_1=30 +lat_2=45 +x_0=0 +y_0=0 +R=6370000 +units=m +no_defs". The available scenarios and simulation periods are listed below: historical | 1980 - 2019 rcp45cooler | 2020 - 2059 rcp45cooler | 2060 - 2099 rcp45hotter | 2020 - 2059 rcp45hotter | 2060 - 2099 rcp85cooler | 2020 - 2059 rcp85cooler | 2060 - 2099 rcp85hotter | 2020 - 2059 rcp85hotter | 2060 - 2099 * The first year (1979, 2019, and 2059) of data within each scenario represents a model warmup period and should not be used. These are located in the `spinup_files` directory. Historical year 2020 is considered an extra year of data beyond the simulation period and can be found in the `additional_files` directory. For information on specific variables and a more in-depth discussion of methodology, please refer to the data landing page at https://tgw-data.msdlive.org. Delta Warming Files The global and CONUS warming deltas for each scenario are provided in degrees Celsius annually and monthly. Restart Files Yearly restart files are provided for each scenario which can be used to restart the WRF model at a particular point in time. Spinup Files The first year of data within each simulation period represents a model warmup period and should not be used. The files are provided here for the sake of reproducibility. Additional Files Additional years of data are provided as an extension of the historic simulation.

Jones, Andrew D.↗
DOE OSTI2024

Data for Grogan et al. "Bringing Hydrologic Realism to Water Markets"

This data set provides model output and post-processing files required to reproduce the results, tables, and figures in the paper "Bringing Hydrologic Realism to Water Markets" by Grogan et al. (in review). Other input data used in this study includes: Lisk, M., Grogan, D., Zuidema, S., Caccese, R., Peklak, D., Zheng, J., Fisher-Vanden, K., Lammers, R., Olmstead, S., & Fowler, L. (2023). Harmonized Database of Western U.S. Water Rights (HarDWR) (Version v1) [Data set]. MSD-LIVE Data Repository. https://doi.org/10.57931/2205619 Two models were used in this study: (1) The University of New Hampshire Water Balance Model WBM, and (2) a Water Market Model. Market model code and model output post-processing code that make use of these data can be found here Model output files are: 1. WBM output files: scenario[x]_wbm_output.zip Where [x] is one of 1, 2, 2a, 3, and 3a Each zipped directory contains 7 gridded NetCDF files, each reporting the 10-year annual average value of a given variable, in units of average mm/day: File Name: wbm_indUseGross_yc.nc; Description: Water withdrawals by industry (part of the urban sector) File Name: wbm_domUseGross_yc.nc; Description: Water withdrawals by the domestic sector (part of the urban sector) File Name: wbm_irrigationGross_yc.nc; Description: Water withdrawals for agriculture File Name: wbm_irrigationExtra_yc.nc; Description: Water withdrawals from unsustainable groundwater for agriculture File Name: wbm_indUseEvap_yc.nc; Description: Consumptive water use by industry File Name: wbm_domUseEvap_yc.nc; Description: Consumptive water use by the domestic sector File Name: wbm_irrigationNet_yc.nc; Description: Consumptive water use by agriculture The file full_cell_area.nc gives the area of each grid cell in km2, which is used for converting water depth to water volume. 2. Water market model output & post processing output Folder: marketTrdSummaries/ Description: Files in this folder are used as input to code 1_WelfareCalculation_actual_trades.R. They summarize historical water right trade transactions in each state. File Name: welfare_gain_by_state_sector.csv; Description: Welfare gains by state and sector, as shown in Figure 3F. Used in code Figure3.R and produced (as a .xlsx file) by code 2_DemandCurves_simulated_trades.R File Name: welfare_data_actual.rdata; Description: welfare gains by WMA from actual historical trades, as shown in Figure 3A. This data is the output of code 1_WelfareCalculation_actual_trades.R File Name: welfare_summary_simulated.xlsx; Description: Welfare gains by state as simulated by the market model in Scenario 1. Produced by code 2_DemandCurves_simulated_trades.R, and used in code 4_WelfareCalculation.R. File Name: welfare_summary_cutoffs.xlsx; Description: Welfare gains by state as simulated by the market model in Scenario 2. Produced by code 3_DemandCurves_simulated_trades_cutoffs.R, and used in code 4_WelfareCalculation.R. File Name: welfare_summary_cutoffs_SGMS.xlsx; Description: Welfare gains by state as simulated by the market model in Scenario 2a. Produced by code 3_DemandCurves_simulated_trades_cutoffs.R, and used in code 4_WelfareCalculation.R. File Name: welfare_data_actual.rdata; Description: Spatial data, actual historical welfare gains by WMA as shown in Figure 3A. Produced by code 4_WelfareCalculation.R and used by code Figure3.R. File Name: welfare_data_simulated.rdata; Description: Spatial data, simulated Scenario 1 welfare gains by WMA as shown in Figure 3B. Produced by code 4_WelfareCalculation.R and used by code Figure3.R. File Name: welfare_data_simulated_cutoffs.rdata; Description: Spatial data, simulated Scenario 2 welfare gains by WMA. Produced by code 4_WelfareCalculation.R and used by code Figure3.R. File Name: welfare_data_simulated_cutoffs_SGMA.rdata; Description: Spatial data, simulated Scenario 2a welfare gains by WMA. Produced by code 4_WelfareCalculation.R and used by code Figure3.R. Additional files are provided for efficient reproduction of tables and figures. These include: File Name: wma_thresold_dates_Scenario2(a).csv; Description: Wet vs. paper right threshold dates for each WMA. Shown in Figure 2A,B. Produced and used by code calculate_thresolds_Figure2.R File Name: WWRTradeBounds (directory); Description: Trade boundary shapefile required to reproduce Figure 3A-D. Used in code Figure3.R File Name: welfare_region_totals.csv; Description: Welfare gains for the entire study region, as shown in Figure 3E. Used in code Figure3.R File Name: Welfare_gain_by_state_sector.csv; Description: Welfare gains by state and sector, as shown in Figure 3F. Used in code Figure3.R and produced (as a .xlsx file) by code 2_DemandCurves_simulated_trades.R File Name: WECC_MERIT_5min_v3b_mask.nc; Description: Gridded file that identified which land grid cells are in the WBM model domain, used for processing in code Figure4.py File Name: Table_1.csv; Description: All data in Table 1, reproducible from WBM output files using code table_1.R

Economics↗
DOE OSTI2024

HarDWR - Harmonized Water Rights Records

For a detailed description of the database of which this record is only one part, please see the HarDWR meta-record. Here we present a new dataset of western U.S. water rights records. This dataset provides consistent unique identifiers for each spatial unit of water management across the domain, unique identifiers for each water right record, and a consistent categorization scheme that puts each water right record into one of 7 broad use categories. These data were instrumental in conducting a study of the multi-sector dynamics of intersectoral water allocation changes through water markets (Grogan et al., in review). Specifically, the data were formatted for use as input to a process-based hydrologic model, WBM, with a water rights module (Grogan et al., in review). While this specific study motivated the development of the database presented here, U.S. west water management is a rich area of study (e.g., Anderson and Woosly, 2005; Tidwell, 2014; Null and Prudencio, 2016; Carney et al, 2021) so releasing this database publicly with documentation and usage notes will enable other researchers to do further work on water management in the U.S. west. The raw downloaded data for each state is described in Lisk et al. (in review), as well as here. The dataset is a series of various files organized by state sub-directories. The first two characters of each file name is the abbreviation for the state the in which the file contains data for. After the abbreviation is the text which describes the contents of the file. Here is each file type described in detail: XXFullHarmonizedRights.csv: A file of the combined groundwater and surface water records for each state. Essentially, this file is the merging of XXGroundwaterHarmonizedRights.csv and XXSurfaceWaterHarmonizedRights.csv by state. The column headers for each of this type of file are: state - The name of the state the data comes from. FIPS - The two digit numeric state ID code. waterRightID - The unique identifying ID of the water right, the same identifier as its state uses. priorityDate - The priority date associated with the right. origWaterUse - The original stated water use from the state. waterUse - The water use category under the unified use categories established here. source - Whether the right is for surface water or groundwater. basinNum - The alpha-numeric identifier of the WMA the record belongs to. CFS - The maximum flow of the allocation in cubic feet per second (ft3s-1). Arizona is unique among the states, as its surface and groundwater resources are managed with two different sets of boundaries. So, for Arizona, the basinNum column is missing and instead there are two columns: surBasinNum - The alpha-numeric identifier of the surface water WMA the record belongs to. grdBasinNum - The alpha-numeric identifier of the groundwater WMA the record belongs to. XXStatePOD.shp: A shapefile which identifies the location of the Points of Diversion for the state's water rights. It should be noted that not all water right records in XXFullHarmonizedRights.csv have coordinates, and therefore may be missing from this file. XXStatePOU.shp: A shapefile which contains the area(s) in which each water right is claimed to be used. Currently, only Idaho and Washington provided valid data to included within this file. XXGroundwaterHarmonizedRights.csv: A file which contains only harmonized groundwater rights collected from each state. See XXFullHarmonizedRights.csv for more details on how the data is formatted. XXSurfaceWaterHarmonizedRights.csv: A file which contains only harmonized surface water rights collected from each state. See XXFullHarmonizedRights.csv for more details on how the data is formatted. Additionally, one file, stateWMALabels.csv, is not stored within a sub-directory. While we have referred to the spatial boundaries that each state uses to manage its water resources as WMAs, this term is not shared across all states. This file lists the proper name for each boundary set, by state.

Economics↗
DOE OSTI2024

HarDWR - Harmonized Water Rights Records

For a detailed description of the database of which this record is only one part, please see the HarDWR meta-record. Here we present a new dataset of western U.S. water rights records. This dataset provides consistent unique identifiers for each spatial unit of water management across the domain, unique identifiers for each water right record, and a consistent categorization scheme that puts each water right record into one of 7 broad use categories. These data were instrumental in conducting a study of the multi-sector dynamics of intersectoral water allocation changes through water markets (Grogan et al., in review). Specifically, the data were formatted for use as input to a process-based hydrologic model, WBM, with a water rights module (Grogan et al., in review). While this specific study motivated the development of the database presented here, U.S. west water management is a rich area of study (e.g., Anderson and Woosly, 2005; Tidwell, 2014; Null and Prudencio, 2016; Carney et al, 2021) so releasing this database publicly with documentation and usage notes will enable other researchers to do further work on water management in the U.S. west. The raw downloaded data for each state is described in Lisk et al. (in review), as well as here. The dataset is a series of various files organized by state sub-directories. The first two characters of each file name is the abbreviation for the state the in which the file contains data for. After the abbreviation is the text which describes the contents of the file. Here is each file type described in detail: XXFullHarmonizedRights.csv: A file of the combined groundwater and surface water records for each state. Essentially, this file is the merging of XXGroundwaterHarmonizedRights.csv and XXSurfaceWaterHarmonizedRights.csv by state. The column headers for each of this type of file are: state - The name of the state the data comes from. FIPS - The two-digit numeric state ID code. waterRightID - The unique identifying ID of the water right, the same identifier as its state uses. priorityDate - The priority date associated with the right. origWaterUse - The original stated water use(s) from the state. waterUse - The water use category under the unified use categories established here. source - Whether the right is for surface water or groundwater. basinNum - The alpha-numeric identifier of the WMA the record belongs to. CFS - The maximum flow of the allocation in cubic feet per second (ft3s-1). Arizona is unique among the states, as its surface and groundwater resources are managed with two different sets of boundaries. So, for Arizona, the basinNum column is missing and instead there are two columns: surBasinNum - The alpha-numeric identifier of the surface water WMA the record belongs to. grdBasinNum - The alpha-numeric identifier of the groundwater WMA the record belongs to. XXStatePOD.shp: A shapefile which identifies the location of the Points of Diversion for the state's water rights. It should be noted that not all water right records in XXFullHarmonizedRights.csv have coordinates, and therefore may be missing from this file. XXStatePOU.shp: A shapefile which contains the area(s) in which each water right is claimed to be used. Currently, only Idaho and Washington provided valid data to include within this file. XXGroundwaterHarmonizedRights.csv: A file which contains only harmonized groundwater rights collected from each state. See XXFullHarmonizedRights.csv for more details on how the data is formatted. XXSurfaceWaterHarmonizedRights.csv: A file which contains only harmonized surface water rights collected from each state. See XXFullHarmonizedRights.csv for more details on how the data is formatted. Additionally, one file, stateWMALabels.csv, is not stored within a sub-directory. While we have referred to the spatial boundaries that each state uses to manage its water resources as WMAs, this term is not shared across all states. This file lists the proper name for each boundary set, by state. For those whom may be interested in exploring our code more in depth, we are also making available an internal data file for convenience. The file is in .RData format and contains everything described above as well as some minor additional objects used within the code calculating the cumulative curves. For completeness, here is a detailed description of the various objects which can be found within the .RData file: states: A character vector containing the state names for those states in which data was collected for. More importantly, the index of the state name is also the index in which that state's data can be found in the various following list objects. For example, if California is the third index in this object, the data for California will also be in the third index for each accompanying list. rightsByState_ground: A list of data frames with the cleaned ground water rights collected from each state. This object holds the the data that is exported to created the xxGroundwaterHarmonizedRights.csv files. rightsByState_surface: A list of data frames with the cleaned surface water rights collected from each state. This object holds the the data that is exported to created the xxSurfaceWaterHarmonizedRights.csv files. fullRightsRecs: A list of the combined groundwater and surface water records for each state. This object holds the the data that is exported to created the xxFullHarmonizedRights.csv files. projProj: The spatial projection used for map creation in the beginning of the project. Specifically, the World Geodetic System (WGS84) as a coordinate reference system (CRS) string in PROJ.4 format. wmaStateLabel: The name and/or abbreviation for what each state legally calls their WMAs. h2oUseByState: A list of spatial polygon data frames which contain the area(s) in which each water right is claimed to be used. It should be noted that not all water right records have a listed area(s) of use in this object. Currently, only Idaho and Washington provided valid data to be included in this object. h2oDivByState: A list of spatial points data frames which identifies the location of the Point of Diversion for the state's water rights. It should be noted that not all water right records have a listed Point of Diversion in this object. spatialWMAByState: A list of spatial polygon data frames which contain the spatial WMA boundaries for each state. The only data contained within the table are identifiers for each polygon. It is worth reiterating that Arizona is the only state in which the surface and groundwater WMA boundaries are not the same. wmaIDByState: A list which contains the unique ID values of the WMAs for each state. plottingDim: A character vector used to inform mapping functions for internal map making. Each state is classified as either "tall" or "wide", to maximize space on a typical 8x11 page. The code related to the creation of this dataset can be viewed within HarDWR GitHub Repository/dataHarmonization.

Economics↗
DOE OSTI2024

BSEC VPRM 10m Hourly Biogenic Fluxes in Baltimore (2021)

Model outputs from the Vegetation Photosynthesis and Respiration Model (VPRM: version from Horne et al. in prep). Model remote sensing inputs come from Sential 2-derived EVI and LSWI. Model meteorological inputs for two-meter air temperature and shortwave incoming come from the BSEC WRF 2021 Control Run (Foust, W. 2023). Plant functional Types (PFTs) are spatially classified using the Chesapeake Bay Program 2018 land use land cover product. The final biogenic flux (µmol CO2 m^-2 s^-1) outputs of NEE, RESP, and GEE are a weighted average based on the portion of PFTs within the cell. Individual PFT outputs are saved inside PFT directories (e.g., Crops, Grass, etc.) inside the specific month directory. Model outputs are denoted as a negative flux into the land system (i.e., photosynthesis) and a positive flux as a net release into the overlying atmosphere. Respiration (RESP) fluxes are positive and combine heterotrophic (only soil) and autotrophic sources. Gross ecosystem exchange (GEE) is a negative flux driven by only photosynthetic activity from vegetation, and the Net ecosystem exchange (NEE) is the sum of the two (i.e., NEE=RESP+GEE). Data Characteristics Spatial Resolution: 10m Temporal Resolution: Hourly File Format: VPRM_ _BSEC. .tif (Hour is in UTC) For more information on the model results, please email Jason Horne (jph6488@psu.edu). References: Foust, W. (2023). BSEC WRF 2021 Control Run Output (v0.1.0) [Data set]. MSD-LIVE Data Repository. https://data.msdlive.org/records/m0e6m-vvq17

Baltimore↗
DOE OSTI2024

HarDWR - Harmonized Water Rights Records

A dataset within the Harmonized Database of Western U.S. Water Rights (HarDWR). For a detailed description of the database, please see the meta-record v2.0. Changelog v2.0 - Recalculated based on data sourced from WestDAAT - Changed using a Site ID column to identify unique records to using aa combination of Site ID and Allocation ID - Removed the Water Management Area (WMA) column from the harmonized records. The replacement is a separate file which stores the relationship between allocations and WMAs. This allows for allocations to contribute to water right amounts to multiple WMAs during the subsequent cumulative process. - Added a column describing a water rights legal status - Added "Unspecified" was a water source category - Added an acre-foot (AF) column - Added a column for the classification of the right's owner v1.02 - Added a .RData file to the dataset as a convenience for anyone exploring our code. This is an internal file, and the one referenced in analysis scripts as the data objects are already in R data objects. v1.01 - Updated the names of each file with an ID number less than 3 digits to include leading 0s v1.0 - Initial public release Description Here we present an updated database of Western U.S. water right records. This database provides consistent unique identifiers for each water right record, and a consistent categorization scheme that puts each water right record into one of seven broad use categories. These data were instrumental in conducting a study of the multi-sector dynamics of inter-sectoral water allocation changes though water markets (Grogan et al., *in review*). Specifically, the data were formatted for use as input to a process-based hydrologic model, Water Balance Model (WBM), with a water rights module (Grogan et al., *in review*). While this specific study motivated the development of the database presented here, water management in the U.S. West is a rich area of study (e.g., Anderson and Woosly, 2005; Tidwell, 2014; Null and Prudencio, 2016; Carney et al., 2021) so releasing this database publicly with documentation and usage notes will enable other researchers to do further work on water management in the U.S. West. We produced the water rights database presented here in four main steps: (1) data collection, (2) data quality control, (3) data harmonization, and (4) generation of cumulative water rights curves. Each of steps (1)-(3) had to be completed in order to produce (4), the final product that was used in the modeling exercise in Grogan et al. (*in review*). All data in each step is associated with a spatial unit called a Water Management Area (WMA), which is the unit of water right administration utilized by the state in which the right came from. Steps (2) and (3) required use to make assumptions and interpretation, and to remove records from the raw data collection. We describe each of these assumptions and interpretations below so that other researchers can choose to implement alternative assumptions an interpretation as fits their research aims. Motivation for Changing Data Sources The most significant change has been a switch from collecting the raw water rights directly from each state to using the water rights records presented in WestDAAT, a product of the Water Data Exchange (WaDE) Program under the Western States Water Council (WSWC). One of the main reasons for this is that each state of interest is a member of the WSWC, meaning that WaDE is partially funded by these states, as well as many universities. As WestDAAT is also a database with consistent categorization, it has allowed us to spend less time on data collection and quality control and more time on answering research questions. This has included records from water right sources we had previously not known about when creating v1.0 of this database. The only major downside to utilizing the WestDAAT records as our raw data is that further updates are tied to when WestDAAT is updated, as some states update their public water right records daily. However, as our focus is on cumulative water amounts at the regional scale, it is unlikely most records updates would have a significant effect on our results. The structure of WestDAAT led to several important changes to how HarWR is formatted. The most significant change is that WaDE has calculated a field known as `SiteUUID`, which is a unique identifier for the Point of Diversion (POD), or where the water is drawn from. This separate from `AllocationNativeID`, which is the identifier for the allocation of water, or the amount of water associated with the water right. It should be noted that it is possible for a single site to have multiple allocations associated with it and for an allocation to be able to be extracted from multiple sites. The site-allocation structure has allowed us to adapt a more consistent, and hopefully more realistic, approach in organizing the water right records than we had with HarDWR v1.0. This was incredibly helpful as the raw data from many states had multiple water uses within a single field within a single row of their raw data, and it was not always clear if the first water use was the most important, or simply first alphabetically. WestDAAT has already addressed this data quality issue. Furthermore, with v1.0, when there were multiple records with the same water right ID, we selected the largest volume or flow amount and disregarded the rest. As WestDAAT was already a common structure for disparate data formats, we were better able to identify sites with multiple allocations and, perhaps more importantly, allocations with multiple sites. This is particularly helpful when an allocation has sites which cross WMA boundaries, instead of just assigning the full water amount to a single WMA we are now able to divide the amount of water between the number of relevant WMAs. As it is now possible to identify allocations with water used in multiple WMAs, it is no longer practical to store this information within a single column. Instead the stAllocationToWMATab.csv file was created, which is an allocation by WMA matrix containing the percent Place of Use area overlap with each WMA. We then use this percentage to divide the allocation's flow amount between the given WMAs during the cumulation process to hopefully provide more realistic totals of water use in each area. However, not every state provides areas of water use, so like HarDWR v1.0, a hierarchical decision tree was used to assign each allocation to a WMA. First, if a WMA could be identified based on the allocation ID, then that WMA was used; typically, when available, this applied to the entire state and no further steps were needed. Second was the spatial analysis of Place of Use to WMAs. Third was a spatial analysis of the POD locations to WMAs, with the assumption that allocation's POD is within the WMA it should belong to; if an allocation still had multiple WMAs based on its POD locations, then the allocation's flow amount would be divided equally between all WMAs. The fourth, and final, process was to include water allocations which spatially fell outside of the state WMA boundaries. This could be due to several reasons, such as coordinate errors / imprecision in the POD location, imprecision in the WMA boundaries, or rights attached with features, such as a reservoir, which crosses state boundaries. To include these records, we decided for any POD which was within one kilometer of the state's edge would be assigned to the nearest WMA. Other Changes WestDAAT has Allowed In addition to a more nuanced and consistent method of assigning water right's data to WMAs, there are other benefits gained from using the WestDAAT dataset. Among those is a consistent categorization of a water right's legal status. In HarDWR v1.0, legal status was effectively ignored, which led to many valid concerns about the quality of the database related to the amounts of water the rights allowed to be claimed. The main issue was that rights with legal status' such as "application withdrawn", "non-active", or "cancelled" were included within HarDWR v1.0. These, and other water rights status' which were deemed to not be in use have been removed from this version of the database. Another major change has been the addition of the "unspecified water source category. This is water that can come from either surface water or groundwater, or the source of which is unknown. The addition of this source category brings the total number of categories to three. Due to reviewer feedback, we decided to add the acre-foot (AF) column so that the data may be more applicable to a wider audience. We added the ownerClassification column so that the data may be more applicable to a wider audience. File Descriptions The dataset is a series of various files organized by state sub-directories. In addition, each file begins with the state's name, in case the file is separate from its sub-directory for some reason. After the state name is the text which describes the contents of the file. Here is each file described in detail. Note that st is a placeholder for the state's name. stFullRecords_HarmonizedRights.csv: A file of the complete water records for each state. The column headers for each of this type of file are: state - The name of the state to which the allocations belong to. FIPS - The two digit numeric state ID code. siteID - The site location ID for POD locations. A site may have multiple allocations, which are the actual amount of water which can be drawn. In a simplified hypothetical, a farm stead may have an allocation for "irrigation" and an allocation for "domestic" water use, but the water is drawn from the same pumping equipment. It should be noted that many of the site ID appear to have been added by WaDE, and therefore may not be recognized by a given state's water rights database. allocationID - The allocation ID for the water right. For most states this is the water right ID, and what is recommended to use should a right be looked up on a given state's water rights database. The water amounts associated with these IDs tend to be finer scaled than those associated with siteID. It should be noted that some allocations may be extracted from multiple sites, particularly for larger Places of Use. ownerClassification - A classification of the types of owners for water rights. The most common is `Private` which incorporates a wide range of entities. Several classifications would be grouped into a government category, most of which are for the U.S. Federal Government. These allocations could be listed as "Federal", "United States of America", or as the names of any number of federal agencies. The last major grouping of entities is for "Native American"s. priorityDate - The date we use as the water right priority date for our modeling analysis. This is the legal priority date when it is available. However, for some rights, specifically from California and New Mexico, we used a pseudo priority date (e.g. well completion date or start of well drilling date) when a legal priority date was not available. The most questionable dates come from New Mexico, where the only date associated with certain water right records was the date the allocation was recorded in the database. As the allocation record creation tended to be within a few months of the filing of the application of the water right, from manually double checking the water rights, and our analysis focuses on aggregating water rights on the timescale of years, we determined it was acceptable to use such dates to include as many records as possible. primaryBeneficialUse - From the numerous state water use categories, WaDE categorized them into 21 categories WestDAAT. This column is the original WaDE category for the primary water use at the PoD site. allocationBeneficialUse - From the numerous state water use categories, WaDE categorized them into 21 categories for WestDAAT. This column is the original WaDE category

Economics↗
DOE OSTI2025

CERF: IM3 Projected Western US Power Plant Locations

Overview The Capacity Expansion Regional Feasibility (CERF) model is an open-source geospatial python package that provides new power plant locations at a 1km resolution. The model ingests U.S. state or regional-scale electricity system capacity expansion plans, such as those produced by the Global Change Analysis Model (GCAM-USA), and identifies feasible, site-specific locations for individual new power plants (renewable and non-renewable). CERF combines high-resolution geospatial suitability analyses with an economic algorithm that selects individual plant siting locations based on grid interconnection costs and the locational marginal value of new generation. The model incorporates a wide range of dynamic constraints and opportunities, such as protected lands, population density, existing infrastructure, and water availability. This dataset provides CERF power plant siting results for IM3 Phase 2 simulations across eight different scenarios for the Western US through 2055. The scenarios include combinations of two Shared Socioeconomic Pathways (SSP3 and SSP5) with four high-resolution climate projections specific to the United States (see, https://tgw-data.msdlive.org/). These climate projections include "hotter" and "cooler" variants for two Representative Concentration Pathways (RCP4.5 and RCP8.5). The resulting eight simulations are: rcp45cooler_ssp3 rcp45cooler_ssp5 rcp45hotter_ssp3 rcp45hotter_ssp5 rcp85cooler_ssp3 rcp85cooler_ssp5 rcp85hotter_ssp3 rcp85hotter_ssp5 CERF siting results in this dataset correspond to capacity expansion plans in the GCAM-USA IM3 Phase 2 simulation data and are available for each of the above scenarios. Data Details Temporal Range: 2015-2055 in 5-year timesteps. Note that 2015 is the experiment base year and 2020 and beyond represent model simulation years. Spatial Range: Plant locations are provided for the eleven states in the Western US including Arizona, California, Colorado, Idaho, Montana, New Mexico, Nevada, Oregon, Utah, Washington, and Wyoming. Spatial Resolution: 1 km-squared, provided in x and y coordinates Geospatial Projection: Albers Equal Area Conic (ESRI:102003) File Type: csv The dataset contains subdirectories for each of the eight scenarios described in the overview. Each scenario folder contains two subfolders with the following information: 1. Power Plant Data This directory contains a single .csv file of power plant locations for both pre-existing (non-CERF sited plants in operation in 2015) and new (CERF-sited) power plants across the temporal range along with additional CERF model output parameters for CERF-sited plants. Plant with a siting year earlier than 2020 correspond to facilities that are operational leading into the first timestep CERF simulation. For a more detailed description of CERF model output parameters, see the CERF model documentation. Note that the cerf_plant_id parameter is unique within each scenario file but not across scenario files. Parameter Descriptions scenario - Name of scenario cerf_plant_id - Unique siting identifier cerf_sited - If True, indicates that plant was sited by CERF model. If False, indicates pre-existing facility region_name - Name of region (state) tech_id - Technology ID tech_name - Full generation technology name inclusive of cooling type (if applicable) and additional characteristics tech_simple - Simplified generation technology type unit_size_mw - Power plant unit size (MW) xcoord - X coordinate in the default CRS (meters) ycoord - Y coordinate in the default CRS (meters) index - Index position in the flattend 2D array buffer_in_km - Exclusion buffer around site (km) sited_year - Year of siting retirement_year - Year of retirement lmp_zone - Locational marginal price (LMP) zone ID locational_marginal_price_usd_per_mwh - Locational marginal price ($/MWh) generation_mwh_per_year - Generation output (MWh/yr) operating_cost_usd_per_year - Cost of plant operations ($/yr) net_operational_value - Net operational value based on LMP and and operating costs ($/yr) interconnection_cost - Cost of interconnection for transmission & gas pipeline (if applicable) net_locational_cost -- Difference of interconnection cost and operating value ($/yr) capacity_factor_fraction - Capacity factor (fraction) carbon_capture_rate_fraction - Carbon capture rate (fraction) fuel_co2_content_tons_per_btu - Fuel CO2 content (tons/Btu) fuel_price_usd_per_mmbtu - Fuel price ($/MMBtu) fuel_price_esc_rate_fraction - Fuel price escalation rate (fraction) heat_rate_btu_per_kWh - Heat rate (Btu/kWh) lifetime_yrs - Technology lifetime for annuity (years) operational_life_yrs - Operational lifetime for retirement (years) variable_om_usd_per_mwh - Variable operation and maintenance costs of yearly capacity use ($/MWh) variable_om_esc_rate_fraction - Variable operation and maintenance costs escalation rate (fraction) carbon_tax_usd_per_ton - Carbon tax ($/ton) carbon_tax_esc_rate_fraction - Carbon tax escalation rate (fraction) 2. Storage Data This directory contains information on new and pre-existing energy storage facilities operational in each timestep along with various storage operational parameters. The 2015 timestep provides pre-existing energy storage data and corresponds with facilities that are operational leading into the first model simulation timestep. Note that coordinates in the storage files correspond to the interconnection point on the grid (substation location), not individual energy storage locations. Energy storage is added in a cumulative process at each given interconnection point. That is, each individual file provides the total operational storage capacity interconnected to the specified substation for the given timestep, inclusive of previously installed storage at that location and new storage installed in that timestep at that location. Parameters scenario - Name of scenario timestep - Simulation timestep name - Unique storage identifier s_typ - Type of energy storage technology (battery or pumped storage hydro) s_node - Node ID of interconnecting substation xcoord - X coordinate in the default CRS (meters) ycoord - Y coordinate in the default CRS (meters) charge_rate - Maximum charge rate (power capacity) of storage system (MW) discharge_rate - Maximum discharge rate (power capacity) of storage system (MW) duration - Duration of storage system (hours) max_SoC - Allowed maximum state of charge (energy capacity) of storage system (MWh) min_SoC -Allowed minimum state of charge (energy capacity) of storage system (MWh) charge_eff - Efficiency of charge (fraction between 0 and 1) discharge_eff - Efficiency of discharge (fraction between 0 and 1) Acknowledgment IM3 is a multi-institutional effort led by Pacific Northwest National Laboratory and supported by the U.S. Department of Energy's Office of Science as part of research in MultiSector Dynamics, Earth and Environmental Systems Modeling Program.

CERF↗
DOE OSTI2026

NATURF: Urban Building Parameters for Chicago, Illinois, USA at a 100m resolution

132 Urban parameters based on building physical dimensions and location were generated for the city of Chicago at 100m resolution using the NATURF model. To use the binary file with WRF, the binary file and the index file must be placed in their own directory in WRF_GEOG and accessed in the same way NUDAPT44 would be accessed.

Vernon, Chris R [Pacific Northwest National Labora↗
DOE OSTI2026

Urban Parameters Arizona Urban Corridor 100m

132 Urban parameters based on building physical dimensions and location were generated for the cities in six Arizona Counties at 100m resolution using the NATURF model. To use the binary file with WRF, the binary file and the index file must be placed in their own directory in WRF_GEOG and accessed in the same way NUDAPT44 would be accessed.

Dumas, Melissa [ORNL] (ORCID:0000000233190846)↗
DOE OSTI2026

Urban Parameters Washington, DC 100m

132 Urban parameters based on building physical dimensions and location were generated for Washington, District of Columbia at 100m resolution using the NATURF model. To use the binary file with WRF, the binary file and the index file must be placed in their own directory in WRF_GEOG and accessed in the same way NUDAPT44 would be accessed.

Dumas, Melissa [ORNL] (ORCID:0000000233190846)↗