Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “database for model validation”

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.

295 records · Page 17

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↗

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↗

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 collection of objects stored within an RDate file, stateWaterRightsHarmonized.RData. Each object either describes how one should interact with the other objects, or contains the harmonized water rights data. Here is each object described in detail: 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. The column headers for each data frame are: waterRightID - The unique identifying ID of the water right, the same identifier as its state uses. basinNum - The alpha-numeric identifier of the WMA the record belongs to. priorityDate - The priority date associated with the right. allocatedFlow - The maximum flow of the allocation in cubic feet per second (ft3s-1). source - Whether the right is for surface water or groundwater. origWaterUse - The original stated water use from the state. waterUse - The water use category under the unified use categories established here. rightsByState_surface: A list of the cleaned surface water rights collected from each state. See rightsByState_ground for more details on how the data is formatted. fullRightsRecs: A list of the combined groundwater and surface water records for each state. Essentially, these lists are the merging of rightsByState_ground and rightsByState_surface by state. See rightsByState_ground for more details on how the data is formatted. 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.

Economics↗

IM3 Open Source Data Center Atlas

IM3 Open Source Data Center Atlas Description This dataset contains locations of existing data center facilities in the United States. Data center locations were derived from OpenStreetMap (OSM), a crowd-sourced database. Data points from OSM are processed in various ways to determine additional variables provided in the data including: facility area (square feet), associated US county, and US state. This dataset can be used to identify areas of concentrated data center development and inform government and private sector planning strategies for future buildout of data centers and the infrastructure necessary to support it. Usage Notes Validation of OSM-derived data center locations is an ongoing development under the IM3 project, and the database will be updated as new information becomes available. In some instances, both the data center area (e.g., campus) and individual data center buildings are included as overlapping areas in the database. Both values are retained. Data center points, buildings, and campus areas are provided as separate layers in the downloadable data package. Note that data items are not necessarily complete across layers. That is, a specific data center may only be present as a single point geometry in the "point" layer while other data centers are represented in both the campus and building layers. In some cases, data center campuses and/or buildings straddle a county boundary line. Mappings to both counties are retained in the database as separate rows. These data rows will have the same data center id information, but each will have different county information. Crowd-sourced data, by nature, relies on individuals and communities to provide information. As a result, some data may be missing where it has not yet been reported. As we collect information on additional data center locations and as OSM receives additional contributions, the database will be updated to capture additional data points not yet shown. Technical Information Data is available for download under the following formats: GeoPackage (GPKG) CSV Geospatial data is provided in the WGS84 (EPSG:4326) coordinate reference system. The GeoPackage download contains the following layers. See usage notes for more information. "point" "building" "campus" The "point" layer includes all data from OSM that had POINT geometry type (i.e., individual coordinates). The "building" layer includes all OSM data that did not have POINT geometry and where the building tag in the OSM export was neither equal to "no" or null. Data that did not meet the "point" or "building" qualification was assumed to be a facility campus and included in the "campus" layer. The dataset contains the following parameters. Variables provided by OSM are labeled with (OSM-provided). id - unique identification number (OSM-provided with prefix of "node/", "relation/" and similar attributes removed) state - name of US state state_abb - two letter US state abbreviation state_id - state ID number county - name of US county county_id - county ID number ref - reference numbers or codes (OSM-provided) operator - the name of the company, corporation, or person in charge facility (OSM-provided) name - name of facility (OSM-provided) sqft - surface area of facility polygon, measured in square feet. Only available for "building" and "campus" layers lat - latitude of data centroid point lon - longitude of data centroid point type – represented spatial information. One of "point", "building", or "campus". geometry – POLYGON geometry of area footprint (in "campus" and "building" layers) or POINT geometry of locations (in "point" layer). This parameter is not included in the csv download. Attribution Data center locations were derived from OpenStreetMap, which is made available at openstreetmap.org under the Open Database License (ODbL). US state and county boundary information was collected from the US Census Bureau for the year 2024, which is made publicly available at https://www.census.gov/geographies/mapping-files.html 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. License The IM3 Open Source Data Center Atlas is made available under the Open Database License: http://opendatacommons.org/licenses/odbl/1.0/. Disclaimer This material was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the United States Department of Energy, nor the Contractor, nor any or their employees, nor any jurisdiction or organization that has cooperated in the development of these materials, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness or any information, apparatus, product, software, 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 any agency thereof, or Battelle Memorial Institute. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or any agency thereof. PACIFIC NORTHWEST NATIONAL LABORATORYoperated byBATTELLEfor theUNITED STATES DEPARTMENT OF ENERGYunder Contract DE-AC05-76RL01830

Mongird, Kendall [Pacific Northwest National Labor↗

IM3 Open Source Data Center Atlas

IM3 Open Source Data Center Atlas Description This dataset contains locations of existing data center facilities in the United States. Data center locations were derived from OpenStreetMap (OSM), a crowd-sourced database. Data points from OSM are processed in various ways to determine additional variables provided in the data including: facility area (square feet), associated US county, and US state. This dataset can be used to identify areas of concentrated data center development and inform government and private sector planning strategies for future buildout of data centers and the infrastructure necessary to support it. Usage Notes Validation of OSM-derived data center locations is an ongoing development under the IM3 project, and the database will be updated as new information becomes available. In some instances, both the data center area (e.g., campus) and individual data center buildings are included as overlapping areas in the database. Both values are retained. Data center points, buildings, and campus areas are provided as separate layers in the downloadable data package. Note that data items are not necessarily complete across layers. That is, a specific data center may only be present as a single point geometry in the "point" layer while other data centers are represented in both the campus and building layers. In some cases, data center campuses and/or buildings straddle a county boundary line. Mappings to both counties are retained in the database as separate rows. These data rows will have the same data center id information, but each will have different county information. Crowd-sourced data, by nature, relies on individuals and communities to provide information. As a result, some data may be missing where it has not yet been reported. As we collect information on additional data center locations and as OSM receives additional contributions, the database will be updated to capture additional data points not yet shown. Data items will occasionally be removed from OSM if they are misidentified, if they no longer exist, if they are duplicates of another item, or similar. For that reason, updated versions of this database may not contain all data center locations included in previous versions. Technical Information Data is available for download under the following formats: GeoPackage (GPKG) CSV Geospatial data is provided in the WGS84 (EPSG:4326) coordinate reference system. The GeoPackage download contains the following layers. See usage notes for more information. "point" "building" "campus" The "point" layer includes all data from OSM that had POINT geometry type (i.e., individual coordinates). The "building" layer includes all OSM data that did not have POINT geometry and where the building tag in the OSM export was neither equal to "no" or null. Data that did not meet the "point" or "building" qualification was assumed to be a facility campus and included in the "campus" layer. The dataset contains the following parameters. Variables provided by OSM are labeled with (OSM-provided). id - unique identification number (OSM-provided with prefix of "node/", "relation/" and similar attributes removed) state - name of US state state_abb - two letter US state abbreviation state_id - state ID number county - name of US county county_id - county ID number ref - reference numbers or codes (OSM-provided) operator - the name of the company, corporation, or person in charge facility (OSM-provided) name - name of facility (OSM-provided) sqft - surface area of facility polygon, measured in square feet. Only available for "building" and "campus" layers lat - latitude of data centroid point lon - longitude of data centroid point type – represented spatial information. One of "point", "building", or "campus". geometry – POLYGON geometry of area footprint (in "campus" and "building" layers) or POINT geometry of locations (in "point" layer). This parameter is not included in the csv download. Attribution Data center locations were derived from OpenStreetMap, which is made available at openstreetmap.org under the Open Database License (ODbL). US state and county boundary information was collected from the US Census Bureau for the year 2024, which is made publicly available at https://www.census.gov/geographies/mapping-files.html 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. License The IM3 Open Source Data Center Atlas is made available under the Open Database License: http://opendatacommons.org/licenses/odbl/1.0/. Disclaimer This material was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the United States Department of Energy, nor the Contractor, nor any or their employees, nor any jurisdiction or organization that has cooperated in the development of these materials, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness or any information, apparatus, product, software, 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 any agency thereof, or Battelle Memorial Institute. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or any agency thereof. PACIFIC NORTHWEST NATIONAL LABORATORYoperated byBATTELLEfor theUNITED STATES DEPARTMENT OF ENERGYunder Contract DE-AC05-76RL01830

Mongird, Kendall [Pacific Northwest National Labor↗

Residential Building Energy Efficiency Field Studies: Low-Rise Multifamily

In recent years, the U.S. Department of Energy (DOE) has conducted a series of research studies to validate energy efficient building technologies in the field. Much of the work has focused on single-family construction, and some has also addressed commercial energy codes. The work detailed in this DOE-funded study (EE0007616) focuses on low-rise multifamily buildings (three stories or fewer above grade) in various regions of the United States, and reports on how state-level building codes are being implemented, both in terms of observed characteristics and also in terms of estimated energy impacts. Nearly 100 buildings across four states—Illinois, Minnesota, Oregon, and Washington—were sampled, which represent a range of climate types from mild temperature to very cold continental. Both common entry and outdoor entry buildings were included, and a parallel research project evaluated envelope air tightness and current still-evolving air tightness testing methods. Finally, a set of structured interviews of building designers and other relevant professionals was carried to out to gain more insight into this market. To the greatest extent possible, the methodology developed under the project for low-rise multifamily buildings mirrored the approach established by Pacific Northwest National Laboratory (PNNL) for single-family residential buildings (https://www.energy.gov/eere/buildings/downloads/residential-building-energy-code-field-study). This included the general approach to sampling, recruitment, and data collection, as well as data analysis and presentation. The range of permitting dates for the sites encompassed two energy code cycles in most regions. All states in the study had adopted a variation of the International Energy Conservation Code (IECC) for the structure of their state code. The low-rise multifamily occupancy presents a hybrid building type: most of the building’s conditioned floor area was covered by the residential chapter of the code while portions of the building (such as corridors and common spaces) fell under the commercial code chapter. The key items assessed in this work were: Building Shell—exterior wall insulation, ceiling insulation, foundation insulation, windows. Common Areas—HVAC and lighting. Living Units—lighting, ventilation. A few items were not assessed in detail, given their relative paucity in this occupancy type; these included duct leakage, pipe insulation, and hot water circulation controls. Building characteristics were collected via a combination of architectural, mechanical, electrical, and plumbing plan reviews and field inspections, and entered into a spreadsheet-based tool that was later queried to build a database. Data went through quality control both upon arrival and via a later semi-automated review and assurance process. Most of the data are presented graphically so that the reader can quickly assess compliance with the applicable energy codes (both by state and by code year). As a final step, EnergyPlus™ simulations were created for all buildings in the study to estimate both the as-found energy use intensity (EUI) and the energy and CO 2 that could be saved if features that were found to not meet code minimums were brought up to code. The savings estimates were tabulated for each of the four states in the study. The research team found that the single-family approach was largely applicable to low-rise multifamily buildings. This applies to both the data collection and the prototype EUI analysis. Most of the occupied space is living units and falls under residential energy codes, and many characteristics use similar envelope construction and relatively straightforward mechanical systems and lighting. One of the most challenging aspects of this work was to build an effective spreadsheet-based data collection instrument that could allow efficient collection of both building plan and field data. The research team is of the view that other methods could be equally effective if the work is done carefully with diligent quality control. The primary findings for the work center around the thermal envelope and mechanical systems and lighting at the sites: For thermal envelope components, the majority of buildings met or were better than the prescriptive code.This suggests that building designers and builders are aware of code requirements. In some cases, surveyed buildings were designed to qualify for energy efficiency certification programs. These buildings made up at least 20% of sampled buildings in each state. Almost all buildings met mechanical system efficiency requirements (for both living units and common areas). In some cases, sites employed systems that were considerably more efficient than required by the applicable energy code. Dwelling units had a majority of high-efficacy lighting, often in excess of the state’s residential code requirements. While high-efficacy fixtures were also typical in common areas (corridors and stairwells), lighting power densities (LPDs) in these areas were sometimes higher than levels dictated by the applicable part of the state commercial energy code. The simulation models run on a series of low-rise multifamily prototypes, informed by a composite of the field data collected, calculated annual EUIs of between 20 and 50 kBtu/ft2-yr, with the range representing the effects of both building characteristics and building location (climate zone). A detailed process (based on simulations of prototype buildings) was used to estimate the amount of avoided energy use that would occur if 100% adherence to energy codes were attained. The results indicated modest savings are attainable for items such as window thermal performance and common area lighting. The result is overall only a modest potential for additional energy savings, averaging about 10% of EUI.

29 ENERGY PLANNING, POLICY, AND ECONOMY↗

ORNL_AISD-Ex: Quantum chemical prediction of UV/Vis absorption spectra for over 10 million organic molecules

We performed calculations of electronic excitation energies and associated oscillator strengths based on the time-dependent density-functional tight-binding (TD-DFTB) method [1]. The SMILES (Simplified molecular-input line-entry system) strings of the molecules from the AISD HOMO-LUMO database [2] were converted to a 3D atomistic structure and stored in a PDB file after preliminary geometry optimization using the Merck Molecular Force Field (MMFF94) in RDKit [3,4]. The primary information stored in the PDB file archive consists of Cartesian coordinates for each atom of the molecule in their 3D location in space, along with summary information about the structure, sequence, and experiment. We then performed molecular geometry optimization using the density-functional tight-binding (DFTB) method [5] in the electronic ground state, followed by single-point excited states calculations, as described below. We note that, since RDKit employs a random choice for the generation of molecular conformers, the molecular geometries obtained in this dataset could be different from the ones that were generated when the AISD HOMO-LUMO dataset was generated. The computed excitation energies and associated oscillator strengths can be converted to predict UV/Vis absorption spectra, where excitation energies correspond to absorption peak positions, and oscillator strengths are a good measure of the probability of absorption of visible or UV light in transitions between electronic ground and excited states. The conversion of SMILES strings to 3D Cartesian coordinates of fully DFTB-optimized molecules was successful for 10,502,904 out of 10,502,917 molecules. For these molecules, both geometry optimizations and excited states calculations were successful. The DFTB calculations did not complete for 13 molecules of the original AISD HOMO-LUMO dataset. We still provide information about the geometry of these molecules. The molecules are diverse for chemical compositions (which span 5 non-hydrogen elements: oxygen, carbon, nitrogen, fluorine, sulfur) and molecular size (the smallest molecule contains 5 non-hydrogen atoms, and the largest molecule contains 71 non-hydrogen atoms). The DFTB method [5] is an approximation to density functional theory (DFT), utilizing a minimal basis set in conjunction with a two-center approximation to the electronic Hamiltonian and overlap matrix elements. The DFTB total energy is the sum of an electronic and a repulsive energy contribution, and their calculation requires optimized electronic parameters and diatomic repulsive potential energy functions. All DFTB calculations were performed using the DFTB+ code [6] (version 21.2) and the wrapper for DFTB+ in the Atomic Simulation Environment (ASE) (version 3.22.1) [7], which performed an internal conversion of Cartesian coordinates from PDB to the .gen file format. For the geometry optimizations on the electronic ground state potential energy surface of the molecules, we have chosen the third-order DFTB (DFTB3) method [5c] and employed the matching 3ob set of electronic parameters and repulsive potentials [8]. The empirical γ-damping for hydrogen bond correction, and Grimme's D3 empirical dispersion correction with Becke-Johnson damping (D3(BJ)) [9] dispersion correction was included to improve the description of non-covalent interactions. For excited states single-point energy calculations, we employed the TD-DFTB method in conjunction with the DFTB2 method [5b] and the matching mio [5b,10] and halorg [11] parameter sets. We opted to request the simultaneous calculation of 50 excited states for singlet transition to investigate sufficient number of excited states, based on linear response theory using the Casida equation [Ref: T. A. Niehaus, S. Suhai, F. Della Sala, P Lugli, M. Elstner, G. Seifert, and Th. Frauenheim. Tight-binding approach to time-dependent density-functional response theory. Phys. Rev. B, 63:085108, 2001] and the ARPACK diagonalizer [R. B. Lehoucq, D. C. Sorensen, and C. Yang. Arpack users guide: Solution of large-scale eigenvalue problems by implicitly restarted arnoldi methods, 1997. 46, 51]. The dataset contains 1001 tar.gz files. Tar files are named as “ornl_aisd_ex_1.tar.gz†through “ornl_aisd_ex_1000.tar.gzâ€. Additionally, the 13 failed molecules are in “ornl_aisd_ex_unprocessed.tar.gzâ€. Except for the tar files listed below, each tar file contains 10,500 molecules. Tar files numbered 34, 121, 128, 352, 360, 429, 495, 509, 518, 627, 676, 668, and 862 contain 10,499 molecules each. The last tar file numbered 1000 contains 13,417 molecules. The total size of the uncompressed dataset is over 283 Gigabytes. The code for calculating the electronic excitation energies and statistical analysis of the dataset is provided at the following GitLab repository: https://github.com/ORNL/Analysis-of-Large-Scale-Molecular-Datasets-with-Python Calculating the UV spectrum of a molecule requires performing 3 main operations: 1. Converting the smiles string representation of a molecule into a geometric structure where each atom is assigned XYZ coordinates. The geometric structure is written to the file smiles.pdb. 2. Using smiles.pdb to compute the relaxed geometry of the molecule, which corresponds with the position of the atoms at the position of equilibrium at the ground state. This generates the files band.out, detailed.out, and geo_end.gen. 3. Using geo_end.gen to calculate the UV spectrum of the molecule which is written into the file EXC.DAT. Every molecule in the dataset has its own directory. The files contained in each molecule directory are as follows: 1. geo_end.gen 2. detailed.out 3. band.out 4. EXC.DAT 5. smiles.pdb REFERENCES [1] Niehaus, T. A.; Suhai, S.; Della Salla, F.; Lugli, P.; Elstner, M.; Seifert, G.; Frauenheim, Th. Tight-binding approach to time-dependent density-functional response theory. Phys. Rev. B, 2001, 63, 085108/1-9. [2] Blanchard, A.; Gounley, J.; Metha, K.; Yoo, P.; Irle, S. AISD HOMO-LUMO. DOI: 10.13139/ORNLNCCS/1869409 [3] RDKit: Cheminformatics and Machine Learning Software. 2013, [http://www.rdkit.org] [4] Tosco, P.; Stiefl, N. and Landrum, G. Bringing the MMFF force field to the RDKit: implementation and validation. J Cheminform. 2014, 6, 1–4. [5] a) Porezag, D.; Frauenheim, T.; Kohler, T.; Seifert, G.; Kaschner, Construction of tight-binding-like potentials on the basis of density-functional theory: Application to carbon, R. Phys. Rev. B 1995, 51, 12947-12957; b) Elstner, M.; Porezag, D.; Jungnickel, G.; Elsner, J.; Haugk, M.; Frauenheim, Th.; Suhai, S.; Seifert, G.; Phys. Rev. B 1998, 58, 7260-7268; c) Gaus, M.; Cui, Q.; Elstner, M. DFTB3: Extension of the Self-Consistent-Charge Density-Functional Tight-Binding Method (SCC-DFTB), J. Chem. Theory Comput. 2011, 7, 931-948; d) Cui, Q.; Elstner, M. Density functional tight binding: values of semi-empirical methods in an ab initio era, Phys. Chem. Chem. Phys. 2014, 16, 14368-14377. [6] Hourahine, B. et al. DFTB+, a software package for efficient approximate density functional theory based atomistic simulations, J. Chem. Phys. 2020, 152, 124101/1-19. [7] Larsen, A. H. et al. The atomic simulation environment—a Python library for working with atoms. J. Phys.: Cond. Matter 2017, 29, 273002. [8] Kubillus, M.; Kubar, T.; Gaus, M.; Rezac, J.; Elstner, M. Parameterization of the DFTB3 Method for Br, Ca, Cl, F, I, K, and Na in Organic and Biological Systems, J. Chem. Theory Comput. 2015, 11, 332-342. [9] Brandenburg, J. G.; Grimme, S. Accurate Modeling of Organic Molecular Crystals by Dispersion-Corrected Density Functional Tight Binding (DFTB), J. Phys. Chem. Lett. 2014, 5, 1785−1789. [10] a) Niehaus, T. A.; Elstner, M.; Frauenheim, Th.; Suhai, S. Application of an approximate density-functional method to sulfur containing compounds. J. Mol. Struct.: THEOCHEM 2001, 541, 185-94; b) Elstner, M.; Hobza, P.; Frauenheim, Th.; Suhai, S.; Kaxiras, E. Hydrogen bonding and stacking interactions of nucleic acid base pairs: A density-functional-theory based treatment. J. Chem. Phys. 2001, 114, 5149-55. [11] Kubar, T.; Bodrog, Z.; Gaus, M.; Köhler, C.; Aradi, B.; Frauenheim, Th.; Elstner, M. Parametrization of the SCC-DFTB Method for Halogens. J. Chem. Theory Comput. 2013, 9, 2939-49.

36 MATERIALS SCIENCE↗