Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “compiler verification”

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 37 records · Page 2

Sierra/SolidMechanics 5.10 Verification Tests Manual

Presented in this document is a small portion of the tests that exist in the Sierra/SolidMechanics (Sierra/SM) verification test suite. Most of these tests are run nightly with the Sierra/SM code suite, and the results of the test are checked versus the correct analytical result. For each of the tests presented in this document, the test setup, a description of the analytic solution, and comparison of the Sierra/SM code results to the analytic solution is provided. Mesh convergence is also checked on a nightly basis for several of these tests. This document can be used to confirm that a given code capability is verified or referenced as a compilation of example problems. Additional example problems are provided in the Sierra/SM Example Problems Manual. Note, many other verification tests exist in the Sierra/SM test suite, but have not yet been included in this manual.

42 ENGINEERING↗

Sierra/SolidMechanics 5.20 Verification Tests Manual

Presented in this document is a small portion of the tests that exist in the Sierra/SolidMechanics (Sierra/SM) verification test suite. Most of these tests are run nightly with the Sierra/SM code suite, and the results of the test are checked versus the correct analytical result. For each of the tests presented in this document, the test setup, a description of the analytic solution, and comparison of the Sierra/SM code results to the analytic solution is provided. Mesh convergence is also checked on a nightly basis for several of these tests. This document can be used to confirm that a given code capability is verified or referenced as a compilation of example problems. Additional example problems are provided in the Sierra/SM Example Problems Manual. Note, many other verification tests exist in the Sierra/SM test suite, but have not yet been included in this manual.

97 MATHEMATICS AND COMPUTING↗

Sierra/SolidMechanics 5.18 Verification Tests Manual

Presented in this document is a small portion of the tests that exist in the Sierra/SolidMechanics (Sierra/SM) verification test suite. Most of these tests are run nightly with the Sierra/SM code suite, and the results of the test are checked versus the correct analytical result. For each of the tests presented in this document, the test setup, a description of the analytic solution, and comparison of the Sierra/SM code results to the analytic solution is provided. Mesh convergence is also checked on a nightly basis for several of these tests. This document can be used to confirm that a given code capability is verified or referenced as a compilation of example problems. Additional example problems are provided in the Sierra/SM Example Problems Manual. Note, many other verification tests exist in the Sierra/SM test suite, but have not yet been included in this manual.

97 MATHEMATICS AND COMPUTING↗

Sierra/SolidMechanics 5.16 Verification Tests Manual

Presented in this document is a small portion of the tests that exist in the Sierra/SolidMechanics (Sierra/SM) verification test suite. Most of these tests are run nightly with the Sierra/SM code suite, and the results of the test are checked versus the correct analytical result. For each of the tests presented in this document, the test setup, a description of the analytic solution, and comparison of the Sierra/SM code results to the analytic solution is provided. Mesh convergence is also checked on a nightly basis for several of these tests. This document can be used to confirm that a given code capability is verified or referenced as a compilation of example problems. Additional example problems are provided in the Sierra/SM Example Problems Manual. Note, many other verification tests exist in the Sierra/SM test suite, but have not yet been included in this manual.

97 MATHEMATICS AND COMPUTING↗

Sierra/SolidMechanics 5.22 Verification Tests Manual

Presented in this document is a small portion of the tests that exist in the Sierra/SolidMechanics (Sierra/SM) verification test suite. Most of these tests are run nightly with the Sierra/SM code suite, and the results of the test are checked versus the correct analytical result. For each of the tests presented in this document, the test setup, a description of the analytic solution, and comparison of the Sierra/SM code results to the analytic solution is provided. Mesh convergence is also checked on a nightly basis for several of these tests. This document can be used to confirm that a given code capability is verified or referenced as a compilation of example problems. Additional example problems are provided in the Sierra/SM Example Problems Manual. Note, many other verification tests exist in the Sierra/SM test suite, but have not yet been included in this manual.

97 MATHEMATICS AND COMPUTING↗

Sierra/SolidMechanics 5.28 Verification Tests Manual

Presented in this document is a small portion of the tests that exist in the Sierra/SolidMechanics (Sierra/SM) verification test suite. Most of these tests are run nightly with the Sierra/SM code suite, and the results of the test are checked versus the correct analytical result. For each of the tests presented in this document, the test setup, a description of the analytic solution, and comparison of the Sierra/SM code results to the analytic solution is provided. Mesh convergence is also checked on a nightly basis for several of these tests. This document can be used to confirm that a given code capability is verified or referenced as a compilation of example problems. Additional example problems are provided in the Sierra/SM Example Problems Manual. Note, many other verification tests exist in the Sierra/SM test suite, but have not yet been included in this manual.

96 KNOWLEDGE MANAGEMENT AND PRESERVATION↗

Sierra/SolidMechanics 5.0 Verification Tests Manual

Presented in this document is a small portion of the tests that exist in the Sierra/SolidMechanics (Sierra/SM) verification test suite. Most of these tests are run nightly with the Sierra / SM code suite, and the results of the test are checked versus the correct analytical result. For each of the tests presented in this document, the test setup, a description of the analytic solution, and comparison of the Sierra / SM code results to the analytic solution is provided. Mesh convergence is also checked on a nightly basis for several of these tests. This document can be used to confirm that a given code capability is verified or referenced as a compilation of example problems. Additional example problems are provided in the Sierra/SM Example Problems Manual. Note, many other verification tests exist in the Sierra/SM test suite, but have not yet been included in this manual.

97 MATHEMATICS AND COMPUTING↗

Invited: Bambu: an Open-Source Research Framework for the High-Level Synthesis of Complex Applications

This paper presents the open-source High-Level Synthesis research framework Bambu. The framework provides an open-source starting point to experiment with new ideas across High-Level Synthesis, high-level verification and debugging, FPGA/ASIC design, design flow space exploration, and parallel hardware accelerator design. The tool accepts as input standard C/C++ specifications and compiler intermediate representations (IRs) coming from the well-known Clang/LLVM and GCC com- pilers. The broad spectrum and flexibility of input formats allow the electronic design automation (EDA) research community to explore and integrate new transformations and optimizations. The easily extendable modular framework already includes many op- timizations and HLS benchmarks. The integration with synthesis and verification backends (commercial and open-source) allows researchers to quickly test any new finding and easily obtain performance and resource usage metrics for a given application. Different FPGA devices are supported from several different vendors: AMD/XILINX, Intel/Altera, Lattice Semiconductor, and NanoXplore. Finally, integration with the OpenRoad open-source end-to-end silicon compiler perfectly fits with the recent push towards open-source EDA.

Ferrandi, Fabrizio↗

Special Observing Period (SOP) data for the Year of Polar Prediction site Model Intercomparison Project (YOPPsiteMIP)

The rapid changes occurring in the polar regions require an improved understanding of the processes that are driving these changes. At the same time, increased human activities such as marine navigation, resource exploitation, aviation, commercial fishing, and tourism require reliable and relevant weather information. One of the primary goals of the World Meteorological Organization's Year of Polar Prediction (YOPP) project is to improve the accuracy of numerical weather prediction (NWP) at high latitudes. During YOPP, two Canadian “supersites” were commissioned and equipped with new ground-based instruments for enhanced meteorological and system process observations. Additional pre-existing supersites in Canada, the United States, Norway, Finland, and Russia also provided data from ongoing long-term observing programs. These supersites collected a wealth of observations that are well suited to address YOPP objectives. In order to increase data useability and station interoperability, novel Merged Observatory Data Files (MODFs) were created for the seven supersites over two Special Observing Periods (February to March 2018 and July to September 2018). All observations collected at the supersites were compiled into this standardized NetCDF MODF format, simplifying the process of conducting pan-Arctic NWP verification and process evaluation studies. This paper describes the seven Arctic YOPP supersites, their instrumentation, data collection and processing methods, the novel MODF format, and examples of the observations contained therein. MODFs comprise the observational contribution to the model intercomparison effort, termed YOPP site Model Intercomparison Project (YOPPsiteMIP). All YOPPsiteMIP MODFs are publicly accessible via the YOPP Data Portal (Whitehorse: https://doi.org/10.21343/a33e-j150, Huang et al., 2023a; Iqaluit: https://doi.org/10.21343/yrnf-ck57, Huang et al., 2023b; Sodankylä: https://doi.org/10.21343/m16p-pq17, O'Connor, 2023; Utqiagvik: https://doi.org/10.21343/a2dx-nq55, Akish and Morris, 2023c; Tiksi: https://doi.org/10.21343/5bwn-w881, Akish and Morris, 2023b; Ny-Ålesund: https://doi.org/10.21343/y89m-6393, Holt, 2023; and Eureka: https://doi.org/10.21343/r85j-tc61, Akish and Morris, 2023a), which is hosted by MET Norway, with corresponding output from NWP models.

54 ENVIRONMENTAL SCIENCES↗

Code Coverage Status of the ARC Code PERSENT

The Argonne Reactor Code (ARC) software system supports users in their fast reactor design goals by providing neutronic, thermal-hydraulic, and structural analysis capabilities. PERSENT fulfills the role of generating reactivity coefficients for a given time point of a REBUS calculation usable in a point kinetics based safety analysis capability. PERSENT also provides a sensitivity coefficient capability on eigenvalue, reactivity worth, and several other key coefficients that are used in the follow-on safety analysis. Given a co-variance matrix, PERSENT can carry out the uncertainty quantification to indicate the amount of error in the reactivity coefficients derived from the errors in the cross section measurements. With continued improvement of computational resources, many of the geometry modeling capabilities in DIF3D that were primarily used in low order schemes are not really needed anymore. Today, the diffusion and transport capabilities of DIF3D-VARIANT are primarily used in the reactor design process with some scattered usage of DIF3D-FD and DIF3D-Nodal. PERSENT is part of the ARC code system and is built around DIF3D-VARIANT and the flux solution it provides. The purpose of the present work is to identify a set of test problems for PERSENT and assess the code coverage of PERSENT for those test problems. PERSENT treats the DIF3D executable as an external executable and thus the code coverage considerations only need to focus on the PERSENT source code and only a fraction of the connected modules in the existing ARC software library. The goal is to document what parts of the existing PERSENT code are touched by the set of test problems and which are not. Because the verification work done on PERSENT was focused on the most common uses of PERSENT for fast reactor analysis, the code coverage assessment of those capabilities is the highest priority. This will ensure that nothing is being missed by the existing verification test problems that users of PERSENT rely upon. The code coverage analysis of PERSENT was performed with the Code Coverage Tool of the Intel Fortran compiler which requires modifications to the compilation of PERSENT. The detailed coverage tables are given for each submodule of PERSENT. Most of the uncovered parts/files could be easily ignored because they are either for error message and debugging output or not needed by PERSENT today. Only a few uncovered parts of PERSENT deserve extending the verification test suite.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

A Formalization of Core Why3 in Coq

Intermediate verification languages like Why3 and Boogie have made it much easier to build program verifiers, transforming the process into a logic compilation problem rather than a proof automation one. Why3 in particular implements a rich logic for program specification with polymorphism, algebraic data types, recursive functions and predicates, and inductive predicates; it translates this logic to over a dozen solvers and proof assistants. Accordingly, it serves as a backend for many tools, including Frama-C, EasyCrypt, and GNATProve for Ada SPARK. But how can we be sure that these tools are correct? The alternate foundational approach, taken by tools like VST and CakeML, provides strong guarantees by implementing the entire toolchain in a proof assistant, but these tools are harder to build and cannot directly take advantage of SMT solver automation. As a first step toward enabling automated tools with similar foundational guarantees, we give a formal semantics in Coq for the logic fragment of Why3. We show that our semantics are useful by giving a correct-by-construction natural deduction proof system for this logic, using this proof system to verify parts of Why3's standard library, and proving sound two of Why3's transformations used to convert terms and formulas into the simpler logics supported by the backend solvers.

97 MATHEMATICS AND COMPUTING↗

SPEL: Software tool for Porting E3SM Land Model with OpenACC in a Function Unit Test Framework

Most high-end computers adopt hybrid architecture, porting a large-scale scientific code onto accelerators is necessary. The paper presents a generic method for porting large-scale scientific code onto accelerators using compiler directives within a modularized function unit test platform. We have implemented the method and designed a software tool (SPEL) to port the E3SM Land Model (ELM) onto the GPUs in the Summit computer. SPEL automatically generates GPU-ready test modules for all ELM functions, such as CanopyFlux, SoilTemperature, and EcosystemDynamics. SPEL breaks the ELM into a collection of standalone unit test programs for easy code verification and further performance improvement. We further optimize several ELM test modules with advanced techniques, including memory reduction, reconstructed parallel loops, and asynchronous GPU kernel launch. We hope our study will inspire new toolkit developments that expedite large-scale scientific code porting with compiler directives.

Schwartz, Peter↗

Water at the Research and Education Complex [Poster]

Purpose: To identify the management methods for stormwater, sanitary sewer, and potable water throughout the facilities at the Research and Education Complex (REC) using drawings and written documents. To confirm the locations and status of wells located throughout the REC. To compile appropriate documentation that relates to water for each facility at the REC, verify that documentation is accurate, and create any new documentation that is necessary through field verification.

54 ENVIRONMENTAL SCIENCES↗

Code Coverage Status of the ARC Code DASSH-F

The Argonne Reactor Code (ARC) software system supports users in their fast reactor design goals by providing neutronic, thermal-hydraulic, and structural analysis capabilities. DASSH-F serves as a steady state thermal hydraulic capability within the ARC system and replaces the SE2-ANL software that preceded it. This document identifies the set of test problems used to assess the code coverage for DASSH-F. The goal is to document what parts of the existing DASSH-F code are touched by the set of test problems and which are not. Because the verification work remains to be done on DASSH-F, one can assume that most of these issues will be resolved as part of that work. The code coverage analysis of DASSH-F was performed with the Code Coverage Tool of the Intel Fortran compiler which requires modifications to the compilation of DASSH-F. The code coverage tables are given for each submodule of DASSH-F. Because DASSH-F links to modules in DIF3D, some details on coverage changes to the DIF3D linked files is provided. As will be seen, most of the uncovered parts/files can be ignored because they are either for error message and debugging output or obviously not needed by DASSH-F today. Seven features of the DASSH-F code were identified to not be covered by the existing testing suite and thus additional verification test problems are suggested to fully cover these sections.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

Code Coverage Status of the ARC Code RCT

The Argonne Reactor Code (ARC) software system supports users in their fast reactor design goals by providing neutronic, thermal-hydraulic, and structural analysis capabilities. REBUS plays a pivotal role in the ARC system as the primary fuel cycle analysis capability for fast reactor problems. Over its 60 year history, ARC software usage with REBUS has been applied to numerous fast and thermal spectrum reactor analysis projects with good to excellent comparison against experiments. The RCT code is a later addition and uses the REBUS restart files to define its input. The RCT code was built to provide pin depletion details on EBR-II models and thus many features of RCT were specifically tailored to the needs of EBR-II models. Additional approximations were invoked which are likely only valid for the EBR-II reactor and the particular fuel management that was done for it. The purpose of the present work is to identify a set of test problems for RCT and assess the code coverage for those test problems. The goal is to document what parts of the existing RCT code are touched by the set of test problems and which are not. Because no detailed verification work has been done on RCT, the existing regression testing suite was chosen for the code coverage assessment. The code coverage analysis of RCT was performed with the Code Coverage Tool of the Intel Fortran compiler which requires modifications to the compilation of RCT. The detailed coverage tables are given for each part of RCT. As will be discussed and shown, some parts of the RCT capability that are known to be used by the EBR-II analysis work are not tested by the regression testing suite. These aspects should be resolved before major source code changes are taken for the RCT software. Because REBUS and DIF3D are not subroutines of RCT, the coverage changes in both of those codes is not altered by RCT. The same is true for all of the modules of DIF3D that are used by RCT such as SYSLIB and SEGLIB.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

Fiscal Year 2025 Software Quality Assurance Activities for the ARC Software

The continued goal of the ARC SQA project in the Advanced Reactor Technologies program of DOE is to resolve the QA gaps for the ARC software that limit, or prevent, commercialization of the software for industry users. This project started in earnest in fiscal year 2023 which saw the entire code system moved from a SVN repository to a GitLab repository and an associated software quality assurance plan (SQAP) developed and ratified. Most of the QA gaps in the ARC software were identified in collaboration with industry partners and work begin in fiscal year 2023 and continued through 2024 and 2025. The continuous integration testing was extended to RCT, DASSH, and SE2ANL. Minor changes were required to the original continuous integration methodology to make this happen. When full confidence in the methodology is complete, a report will be created to detail the automated regression testing methodology and minor reports will be created to detail the tolerance settings that have been applied to the output for each ARC code. The primary documentation that is missing includes user manuals, user guides, software verification reports, and code coverage assessments. The DASSH, SE2ANL, and SE2RCT manuals were completed this fiscal year. A review of the SE2ANL software identified that it is unrealistic to include updated correlations or different geometry models and it was scheduled for deprecation in favor of DASSH. The SE2ANL manual is essential for SE2RCT as they are similar but quite different in purpose. The only piece of software missing a manual consistent with the source code is NUBOW-3D which is a focus of the coming year. The code coverage report for DIF3D was updated and code coverage reports were created for REBUS, RCT, PERSENT, GAMSRC, and DASSH. Minor coverage issues were identified for all of these pieces of software which did not prevent the work done to transition them to the OneAPI compiler. Because SE2ANL was scheduled for deprecation, it was not transitioned, but it was successfully tested with the OneAPI compiler. This leaves SE2RCT and NUBOW-3D as the only pieces of software not transitioned to OneAPI and further work is required to get SE2RCT to work properly. The SE2RCT software transition will begin early next year while the NUBOW-3D software requires a manual before it can begin. Software verification work has been completed for DIF3D, REBUS, GAMSOR, GAMSRC, VARPOW, EvaluateFlux, and SUMMAR. The PERSENT software verification work was completed this year which was somewhat delayed because of unexpected bugs in the software. The PERSENT manual was updated to detail some of the issues and discuss the bowing reactivity worth feature added in the previous fiscal year. The RCT, DASSH, SE2RCT, and NUBOW-3D software are the only maintained pieces of software without verification reports. The software verification work for DASSH will be a focus in the upcoming fiscal year and it is hoped that some of the test cases created can serve as verification tests for SE2RCT. The NUBOW-3D work will begin when the manual and requirements report are completed. Only minor industry partner software development funds were provided this year. The DASSH software was updated to handle general axial geometry for each assembly and the NUBOW-3D software was updated to incorporate a new input format and better output. Overall progress on resolving the QA gaps has been good this year.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

Fiscal Year 2025 Software Quality Assurance Activities for the ARC Software

The continued goal of the ARC SQA project in the Advanced Reactor Technologies program of DOE is to resolve the QA gaps for the ARC software that limit, or prevent, commercialization of the software for industry users. This project started in earnest in fiscal year 2023 which saw the entire code system moved from a SVN repository to a GitLab repository and an associated software quality assurance plan (SQAP) developed and ratified. Most of the QA gaps in the ARC software were identified in collaboration with industry partners and work begin in fiscal year 2023 and continued through 2024 and 2025. The continuous integration testing was extended to RCT, DASSH, and SE2ANL. Minor changes were required to the original continuous integration methodology to make this happen. When full confidence in the methodology is complete, a report will be created to detail the automated regression testing methodology and minor reports will be created to detail the tolerance settings that have been applied to the output for each ARC code. The primary documentation that is missing includes user manuals, user guides, software verification reports, and code coverage assessments. The DASSH, SE2ANL, and SE2RCT manuals were completed this fiscal year. A review of the SE2ANL software identified that it is unrealistic to include updated correlations or different geometry models and it was scheduled for deprecation in favor of DASSH. The SE2ANL manual is essential for SE2RCT as they are similar but quite different in purpose. The only piece of software missing a manual consistent with the source code is NUBOW-3D which is a focus of the coming year. The code coverage report for DIF3D was updated and code coverage reports were created for REBUS, RCT, PERSENT, GAMSRC, and DASSH. Minor coverage issues were identified for all of these pieces of software which did not prevent the work done to transition them to the OneAPI compiler. Because SE2ANL was scheduled for deprecation, it was not transitioned, but it was successfully tested with the OneAPI compiler. This leaves SE2RCT and NUBOW-3D as the only pieces of software not transitioned to OneAPI and further work is required to get SE2RCT to work properly. The SE2RCT software transition will begin early next year while the NUBOW-3D software requires a manual before it can begin. Software verification work has been completed for DIF3D, REBUS, GAMSOR, GAMSRC, VARPOW, EvaluateFlux, and SUMMAR. The PERSENT software verification work was completed this year which was somewhat delayed because of unexpected bugs in the software. The PERSENT manual was updated to detail some of the issues and discuss the bowing reactivity worth feature added in the previous fiscal year. The RCT, DASSH, SE2RCT, and NUBOW-3D software are the only maintained pieces of software without verification reports. The software verification work for DASSH will be a focus in the upcoming fiscal year and it is hoped that some of the test cases created can serve as verification tests for SE2RCT. The NUBOW-3D work will begin when the manual and requirements report are completed. Only minor industry partner software development funds were provided this year. The DASSH software was updated to handle general axial geometry for each assembly and the NUBOW-3D software was updated to incorporate a new input format and better output. Overall progress on resolving the QA gaps has been good this year.

97 MATHEMATICS AND COMPUTING↗

Reported Energy and Cost Savings from the DOE ESPC IDIQ Program: FY 2024

Energy Savings Performance Contracts (ESPCs)are a contractual mechanism that allow a federal agency to procure energy savings and facility improvements without upfront capital costs to reduce costs and resiliency. ESPCs are covered under FAR Part 23.2, and 42 USC § 8287. Section 8287(a)(2)(A) of Title 42 of the U.S. Code requires that each energy savings performance contract (ESPC) undergo an annual energy audit, resulting in a separate audit report for every project. The objective of the present report is to compile and analyze all annual ESPC audit reports issued between October 1, 2023, and September 30, 2024, for projects awarded under Generations 1, 2, and 3 of DOE’s ESPC IDIQ contracts. During this period, 205 measurement and verification (M&V) reports were produced for 200 projects; the total number of reports exceeds the number of projects because some projects generated more than one report(for example, a few projects measure savings twice per year and produce two audit reports annually, each covering a different six-month period). By aggregating the results from these individual audits, the report determines the portfolio-wide realization rate of energy and cost savings for all active ESPC projects awarded under DOE’s IDIQ program. For all 205audit reports, sufficient information was available to compare project-level estimated, reported, and guaranteed cost savings. Reported cost savings accounted for ESCO verified savings per each project’s M&V plan. The total reported cost savings for the period addressed were $\$$647.8million,compared with the total guaranteed cost savings of $\$$601.6million. On average across the reported projects: •ESPC contractors guaranteed 92.8% of the estimated cost savings• projects reported achieving 100.0% of the estimated cost savings• projects reported achieving 107.7% of the guaranteed cost savings. The M&V performed for the period indicated adjustments for government operations and maintenance impacts to savings amount to$\$$43.9millionandcould be restored with the original operational parameters for impacted projects. Accounting for this potential cost savings impact, these projects still realized 100.4% of the guaranteed cost savings. The information on estimated and reported energy savings was collected and compared for all 205of the reports examined. Based on site energy, estimated savings totaled 14.88million MMBtu, and reported savings were 15.33million MMBtu; 3.1% greater than the estimated energy savings. All of the reports examined contained sufficient information to calculate source energy savings. Based on site-adjusted source energy, total estimated energy savings were 20.90 million MMBtu, and reported savings were 21.22million MMBtu, 101.5% of the estimated energy savings. For water savings, the estimated savings were 11,539,055 kGal and the reported savings were 13,315,930 kGal. This means 1,776,875 kGal more water was saved than estimated, which is about 15% higher than the estimate. These results indicate that, overall, the reported energy savings slightly exceeded the estimated values, while estimated water savings significantly exceeded estimated values, suggesting that the projects achieved greater cost savings than originally projected. The total annual expense for the ESCOs to perform annual M&V audits and reporting was $\$$10.02million. Through this effort, $\$$647.8 million in annual cost savings was verified. The M&V results indicated that $\$$43.9 million of these verified savings reflected adjustments due to government operations A-6and maintenance impacts, which could be restored under the original operational parameters for the affected projects. These findings show the value of M&V that only costs 1.7%of the guaranteed cost savings to ensure guarantees are met.

29 ENERGY PLANNING, POLICY, AND ECONOMY↗