Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “example”

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 973 records · Page 54

Modeling Electric Vehicle Charging Station Siting Suitability with a Focus on Equity

As adoption of electric vehicles increases, the infrastructure to charge them must keep pace. Determining where to add new charging infrastructure is a complex process subject to many factors, including electrical service availability, vehicle dwell time, the type(s) of drivers and vehicles the stations will serve, traffic levels and timing, and land ownership. In addition, advancing social equity is a current priority of federal efforts to invest in electric vehicle charging infrastructure. Conducting Multi-criteria Decision Analysis (MCDA) within Argonne’s Energy Zones Mapping Tool (EZMT) is a useful method for analyzing many of the factors that influence how suitable a location is for potentially adding new charging infrastructure, and we show how equity metrics can be included in the analysis. However, data limitations impose challenges to using MCDA to evaluate and prioritize locations. We use three examples to demonstrate how to use publicly available data and MDCA to analyze different siting objectives. Each example starts with defining a specific objective and ends with how to use the results to identify specific potential locations that could be investigated further. This analysis demonstrates how interested stakeholders can use the EZMT to run the example MCDA models defined in this study, modify them to suit their needs, or create new MCDA models.

29 ENERGY PLANNING, POLICY, AND ECONOMY↗

Implementation of an Orificing Optimization Algorithm in the DASSH Subchannel Analysis Code

The Ducted Assembly Steady-State Heat transfer code (DASSH) performs full-core subchannel thermal hydraulics calculations in liquid metal fast reactors. One of the applications of subchannel codes is to optimize coolant flow orificing. As a design activity, the primary task is to determine the best way to divide assemblies into groups and distribute coolant flow rates among them. This report documents an algorithm implemented in DASSH to automatically optimize coolant orificing. Over the course of multiple iterations, DASSH determines the orifice grouping and flow distribution that minimizes peak coolant, clad, or fuel temperatures across all timesteps for a user-specified number of assembly groups. The total coolant flow rate in the reactor is constrained to achieve the specified core-average outlet temperature. The flow rate to each orifice group may also be constrained by the allowable pressure drop. The distribution of coolant flow among groups is accelerated using a predictor-corrector algorithm based on interpolated results from single-assembly parametric calculations. The assembly orificing grouping is initially predicted based on assembly power but can be refined if results demonstrate that an assembly would fit better in another group. The algorithm is demonstrated with two case studies. The first is a simple model for a reactor core consisting of just fuel assemblies; the pin power distributions are specified to create a situation where the initial assembly grouping prediction is suboptimal. This example is used to describe the initial grouping, demonstrate convergence over multiple iterations, and highlight the impact of regrouping. Then, the algorithm is applied to minimize peak clad and fuel temperatures in an example sodium-cooled fast reactor, the Versatile Test Reactor. The multicycle optimization confirms prior calculations for the reference core design. The example highlights how optimizing for different peak temperatures affects the results and demonstrates the use of the pressure drop constraint to limit the maximum flow rate.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

Engineering Computational Practices (Rev. 1)

This manual will attempt to motivate the use of an automated build system for the purposes of computational science and engineering. As part of this motivation, the surrounding computational practices of version control, documen tation, compute environment management, and regression testing will also be addressed as applied to the practice of computational engineering. Specifically, this manual intends to motivate the adoption of these traditional software engineering practices for use in research and production engineering simulation projects. This manual is not the first such effort in the greater scientific computing community. In fact, the authors relied heavily on the lesson plans of the Software Carpentry, established to teach computing skills to researchers in 1998. As the intention for this manual is to lay out fundamental practices of engineering computing, it will not attempt to fully teach the underlying concepts and will instead reference the well designed lesson plans of the Software Carpentry. Where possible, this manual will explain to general computing practices and concepts and limit discussion of specific software implementations to examples or vehicles for practice in concrete application. The specific software taught by the Software Carpentry curriculum is an excellent starting point to learn the core concepts of computational engi neering. However, the authors have found that applications to engineering simulation and analysis require translation of these software development concepts into the language and workflows of computational engineers. Adopting these computational tools may require engineers to re-imagine their workflows in some combination of traditional engineer ing and software concepts. It has also been necessary to extend existing software build systems for engineering practices beyond the simple wrap ping of engineering software execution. Where necessary, examples of specific software and their method of extension to engineering simulations will be given, with reference to the User Manual for recommended practical use. Where this manual relies on specific implementation examples, it should be understood that the practicing engineer may find that different software is more amenable to their specific work. It is always the overall collection of computational practices is more important than any specific software implementation. The ability to recognize which concepts are implemented by a software package will make a practicing engineer agile to changing project needs, computing resources, numeric solvers, programming languages, and even available funding.

42 ENGINEERING↗

Earth Sciences Applications for Energy and Global Security: A Few Vignettes [Slides]

Understanding the physics of flow and transport in the subsurface environment is crucial to several National Security applications. In the Energy Security realm, some examples include characterizing radioactive waste disposal, exploring natural gas extraction and sequestering CO2. An example in the Global Security arena is to be able to distinguish between anthropogenic and naturally occurring seismic disturbances, the former being of particular concern as underground nuclear testing activity has seen an increase in recent years. A common theme across these applications is the ability to accurately model fluid flow in porous and/or fractured subsurface media. For decades, researchers have grappled with how to include the effects of uncertainties in these models, including but not limited to heterogeneity, unknown initial and boundary conditions and issues with scalability. More recently advances in computing and machine learning methodologies have allowed a broader exploration of the uncertainty space as we strive for real time decision making. I will present an overview of the field and discuss a few examples of how my own research in these topics has evolved over nearly two decades.

58 GEOSCIENCES↗

Universal Utility Data Exchange (UUDEX) – Security and Administration: Cybersecurity of Energy Delivery Systems (CEDS) Research and Development

A critical component of the Universal Utility Data Exchange (UUDEX) approach is the integrated security contained within its processing. This document describes how that security is designed and expected to be implemented by UUDEX Implementations (U-Implementations), including the UUDEX Server (U-Server) and UUDEX Clients (U-Clients). The UUDEX security hierarchy consists of three levels: 1. The UUDEX Instance (U-Instance) itself, which sits at the top of the hierarchy and contains the U-Server, the UUDEX Identity Authority (U-Identity Authority), and the UUDEX Administrator (U-Administrator) functions; 2. A group of one or more UUDEX Participants (U-Participants) that present “organizations” that participate in the U-Instance and contains the UUDEX Administrator Participant (U-U-Administrator Participant) function; 3. A group of one or more UUDEX Endpoints (U-Endpoints) that represent the individual UUDEX Publish Clients (U-Publish Client) responsible for supplying data to the U-Instance that is consumed by UUDEX Subscriber Clients (U-Subscriber Clients). U-Endpoints can be either autonomous devices that publish and subscribe data such as data exchange servers found in supervisory control and data acquisition and energy management systems, or they can be tied to users of applications that, for example, submit DOE OE-417 disturbance reports. U-Participants and U-Endpoints can be organized into UUDEX Groups (U-Groups). Any number of U-Participants or U-Endpoints can be members of a U-Group. A given U-Participant or U-Endpoint can be a member of multiple U-Groups, but a U-Group cannot contain other U-Groups. For example, a U-Group could be created to contain all U-Participant Transmission Operators within the purview of a Reliability Coordinator, and another U-Group could be created to contain all U-Participant Generator Operators within the purview of a Reliability Coordinator. U-Participants that are both Transmission Operators and Generator Operators would be members of both U-Groups. U-Participants, U-Endpoints, and U-Groups are used in the access control structures to provide access to individual UUDEX Subjects (U-Subjects). U-Groups are created by the U-Administrator and are managed by the U-Administrator or the designated U-Group Managers. U-Endpoints can be assigned UUDEX Roles (U-Roles) that can be used to further restrict access. U-Roles are assigned to individual U-Endpoints. For example, a U-Role of “Security Analyst” could be used to restrict which U-Endpoints can publish or subscribe security incident reports and vulnerability notifications, while a U-Role of “Transmission Planner” can be used to restrict which U-Endpoints can publish power system model updates. U-Role definitions are created by the U-Administrator, but the U-Roles are assigned to U-Endpoints by their respective UUDEX Participant Administrators (U-Participant Administrator). Because all information required to make security decisions is either included within the U-Endpoint’s X.509 digital certificate or stored in a datastore on the U-Server, all security decisions are performed and enforced within the U-Server. This reduces the complexity of the U-Client code and minimizes the chance for compromise of the integrity of the UUDEX security features.

97 MATHEMATICS AND COMPUTING↗

FY23 Status Report on MOOSE-Based Approaches to Modeling Core Bowing in Fast Reactors

Under the U.S. Department of Energy Office of Nuclear Energy’s Advanced Modeling and Simulation (NEAMS) Program, an integrated multiphysics approach is being developed to model the core bowing phenomena important to liquid metal-cooled fast reactors. Core bowing is an important passive safety mechanism whereby increased power (which leads to temperature and flux gradients) influences the core to bow into less reactive configurations when the restraint system is properly designed. The phenomenon includes a complex interplay of radiation transport, duct temperature calculations involving fluid flow and heat transfer, and thermo-mechanical responses to the induced temperature and flux gradients. Structural material properties are also important to determining inelastic response to longer term flux gradients which cause irradiation creep and swelling. While core bowing provides a strong negative reactivity feedback when the restraint system is designed properly, it also results in additional forces between assemblies which increase the loads required to extricate them during refueling or control rod movement. Therefore, the restraint system must be designed with these tradeoffs in mind. The first stage of the work, which commenced in FY21 and continues through FY23, assesses thermo-mechanical modeling tools for producing core bowing predictions consistent with conventional tools. The Multiphysics Object Oriented Simulation Environment (MOOSE) Tensor Mechanics and Contact Modules are employed. This status report describes work on additional thermo-mechanical benchmark verification problems with increased complexity from the examples demonstrated in FY21 and FY22. Several benchmark verification examples were selected from the IAEA verification and validation report with increased number of ducts and more complex contact interaction behavior. These examples involve a full symmetric sector with restraint rings at multiple load pad locations to simulate a limited free-bow restraint system concept, as well as irradiation induced swelling and creep effects in a sector. In addition, improvements to the contact module sideset assignment were assessed and compared with previous MOOSE results to verify the contact behavior. The MOOSE-based results were compared to IAEA benchmark participants’ results. In every case, the MOOSE results agreed with other simulations results for estimating bowing behavior, providing additional verification basis of the tools for this particular physics application. Estimation of contact forces were mostly in agreement, with a few outlier results. A plan was suggested for dealing with the discrepancies with estimating contact force values. In addition, a 1-way coupling demonstration was performed using subchannel analysis code Pronghorn-SC and MOOSE on an ABR-1000-design sodium-cooled fast reactor assembly to evaluate coolant and duct wall temperatures.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

Energy Services Interface: Requirements Document

This energy services interface (ESI) requirements document represents a process step in the path for creating an ESI specification, which will describe the technical characteristics of an ESI. This document outlines the concepts that need to be covered in the ESI specification, such as principal functions of the ESI, grid services communicated through the ESI, and the ESI lifecycle. It provides context for the Department of Energy’s (DOE’s) Grid Modernization Laboratory Consortium (GMLC) to engage industry participants in the development of the ESI specification. To do this, it describes the desired contents of the ESI specification and provides examples of the type of material that needs to be included in it. The purpose of the ESI specification is to define the requirements that are to be addressed in information and communications technology (ICT) interface standards for enabling the integration of a facility containing responsive distributed energy resources (DER facility) to an electric system consistent with the fundamental ESI principles. In this context, a DER facility may consist of a single DER with a communicating controller or may be as complex as a microgrid campus with several buildings and many DERs. The ESI specification is not a technical interface standard, but the requirements in the specification can be used to check that existing, augmented, or new interface standards meet the interoperability requirements of the ESI concept, which is explained further in this document. In this way, the ESI specification can be used to guide standards advancement work in multiple standards development organizations. To explain the scope of the ESI specification, this ESI requirements document provides examples of situations (or illustrative applications) for using an ESI to coordinate DER flexibility for grid operations. These examples originate from foundational work for describing common grid-DER service agreements that are anticipated to be supported using this interface.

24 POWER TRANSMISSION AND DISTRIBUTION↗

State Energy Offices’ Engagement in Electric Distribution Planning to Meet State Policy Goals

NASEO and Berkeley Lab released a new publication on State Energy Offices’ Engagement in Electric Distribution Planning to Meet State Policy Goals. State and Territory Energy Offices develop plans, programs, policies, and projects that have a substantial impact on electric distribution systems. They also can participate in distribution system planning (DSP) processes to help ensure that utilities – consumer- and investor-owned – meet the state’s future energy needs. This paper recognizes the wide spectrum of roles that State Energy Offices can play in DSP processes, including planning for distributed energy resources and grid modernization. It highlights various examples of non-regulatory activities by State Energy Offices including planning, conducting studies, convening stakeholder processes, and implementing programs that inform and contribute to distribution system planning. It also provides examples of State Energy Offices’ engagement in proceedings before their respective public utility commissions. As State Energy Offices face myriad challenges associated with meeting state policy goals, preparing for anticipated rates of distributed energy resource deployment, addressing concerns regarding grid reliability and resilience, and recommending and making long-term investment decisions, the examples provided through this guide can serve as a resource in navigating those challenges.

24 POWER TRANSMISSION AND DISTRIBUTION↗

Molecular Hypernetworks for Exploration of Multi-Dimensional Metabolomics Data (Chyper)

Orthogonal separations of data from high-resolution mass spectrometry can provide insight into sample composition and help address the challenge of complete annotation of molecules in untargeted metabolomics. “Molecular networks” (MNs), as used, for example, in the Global Natural Products Social Molecular Networking platform, are an increasingly popular computational strategy for exploring and visualizing molecular relationships and improving annotation. MNs use graph representations to show the relationships between measured multidimensional data features. MNs also show promise for using network science algorithms to automatically identify targets for annotation candidates and to dereplicate features associated to a single molecular identity. However, more advanced methods may better represent the complexity present in samples. Our work aims to increase confidence in annotation propagation by extending molecular network methods to include “molecular hypernetworks” (MHNs), able to natively represent multiway relationships among observations supporting both human and analytical processing. In this paper we first introduce MHNs illustrated with simple examples, and demonstrate how to build them from liquid chromatography- and ion mobility spectrometry- separated MS data. We then describe a method to construct MHNs directly from existing MNs as their “clique reconstructions”, demonstrating their utility by comparing examples of previously published graph-based MNs to their respective MHNs.

59 BASIC BIOLOGICAL SCIENCES↗

Diagnosing and overcoming recombination and resistive losses in non-silicon solar cells using a silicon-inspired characterization platform

This project aimed to generate the characterization tools needed for accurate and systematic loss analysis in non-silicon photovoltaic solar cell technologies and, through the use of these tools and analysis techniques, contribute to the development of a novel class of hetero-contacts to II-VI absorbers, with the final goal of demonstrating record-breaking CdSeTe devices. CdSeTe solar cells provide a prime example of the potential impact of the techniques we proposed to develop and implement: record poly-CdSeTe cells have bandgap-voltage deficits (W oc ) of approximately 550 mV, as compared with below 400 mV for all other mature PV technologies. Similarly, these record CdSeTe devices have FFs below 80%, when other mature cells are near or above 85%. Frustratingly, a systematic identification of the origin of these sub-par performances—for example recombination or resistive losses—has been lacking, thus slowing down the development of these technologies. Similarly, it is often asserted that CdSeTe cells need a better back (hole) contact. Although most believe this is true, no one knew—at the start of this project—how high the V oc and FF could be for a given cell if it had a perfect back contact. Such characterization techniques and loss analysis methods exist and are routinely performed on c-Si solar cells (e.g. injection-dependent lifetime, Suns-V oc , transfer length method, etc). Over the years, they have been instrumental in the development of silicon devices that operate at 91% of their theoretical (Auger) limit. Lifetime testing, and the associated reconstruction of the implied-J-V curve, can moreover be performed at every cell-processing step, thus allowing a direct peek into the impact of that step on cell performance. Therefore, adapting these techniques and tools to non-Si devices would greatly improve their learning rate. In this project, we developed a Suns-ERE technique—the equipment, methodology, and know-how—to measure the implied-J-V curve, the pseudo-J-V curve, and the actual J-V curve of a thin-film solar cell, allowing an accurate assessment of the quality of the bulk material and its surface passivation, the selectivity of the contact, and its resistivity. We used this technique to show that the absorber of present CdSeTe solar cells is capable of achieving 1 V Voc,, that passivation layers exist (e.g., Al2O3) that can support such high voltages, and that the barrier is identifying contact layers that are both passivating and carrier-selective. The characterization platform created in this project and the understanding generated using it will accelerate the progress of non-silicon PV technologies. In particular, the project will contribute to CdSeTe solar cells with Voc > 1 V and cell efficiency > 24%. Such cells provide a pathway to module-level efficiencies >23%. As CdSeTe presently competes with silicon on module cost (in $\$ $/W) and yet has significantly more room for efficiency gains, the potential for LCOE reduction is particularly large. For example, CdTe modules with an efficiency of 21% would allow an LCOE below $\$ $0.04kWh -1 in average US climates.

14 SOLAR ENERGY↗

DRiFT Current Mode, Trigger Settings and Flexible Detector Specifications Applied to Scintillator Arrays

MCNP radiation transport output is post-processed by DRiFT, a Detector Response Function Toolkit to simulate detailed nuclear instrumentation response. DRiFT can be used to assess the performance and potential limitations of scintillator, gas, and semiconductor detectors under a variety of simulated conditions not easily achievable in a laboratory setting. This work describes new updates in DRiFT for scintillator simulations which focus on the capability to simulate scintillators in current mode, an expansion of trigger options, and the ability to customize individual detector properties in a simulation. These improvements are designed to facilitate the ability to model large arrays of scintillator detectors with higher fidelity than was previously possible and are demonstrated in three examples. The first shows the difference between operating DRiFT in current and pulse mode. In the second example, which is intended to demonstrate deviations in individual detector performance, each detector has properties (PMT gain, optical transport, scintillation yield, etc.) that vary between detectors and are specified in DRiFT. A final example examines how DRiFT could be used to optimize digitizer settings in high rate measurements with split signals using the new common trigger option.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗

AIACHNE's contribution for Nuclear Energy Agency Working Party on International Nuclear Data Evaluation Co-operation Subgroup 50

The AIACHNE (AI/ML Informed cAlifornium CHi Nuclear data Experiment) project aims at designing an experiment for the 252 Cf Prompt Fission Neutron Spectrum (PFNS) that explores systematic biases in an experimental database retrieved from the EXFOR databases. To that end, machine learning (ML) methods were applied to pint-point measurement features likely related to bia. From that information, we selected a feature that should be explored by the AIACHNE experiment. Measurement features are metadata encapsulating all pertinent information about the physical measurement and analysis techniques. Examples are, for instance, what neutron and fission detectors were used for the physical metadata, and what background reduction techniques were employed for analysis techniques. Such metadata were retrieved both from EXFOR entries as well as the literature of data sets described in detail in Ref. [2]. The prerequisite for applying machine learning techniques is casting the metadata into a format that can be parsed by the algorithm. This step might seem trivial but requires to find a unique language where metadata that carry the same physics meaning across several experiments must have the same identifier. One example is, for instance, the neutron detector. As seen in Figure 1, the machine learning code identified the use of 6 Li detectors as being related to bias in some datasets of the AIACHNE 252 Cf PFNS experimental database. In fact, here are several experiments that used neutron detectors containing 6Li in the database, for instance for the example below. EXFOR format has a unique keywords describing detectors such as “SCIN” or “GLASD”. One may think that these keywords are already sufficient descriptors for ML to uniquely find an issue. However, “SCIN” (used for [3, 4]) and “GLASD” (used for [5]) fail to inform the algorithm what is the active material in the detector. And, the key common issue leading to bias in 252 Cf related to neutron detectors is not whether it is a glass detector or a scintillator. No, the issue is that 6 Li was within both detector types and that even small mistakes in the detector response functions around approximately 200 keV are amplified by the 6 Li(n,α) resonance there leading to bias in data as highlighted in Fig. 1 and Ref. [1]. Hence, the features describing the neutron detector must call out the active material in the detector, rather than the existing EXFOR detector keyword, that the ML algorithm can find physically meaningful features related to bias. The AIACHNE team used a precursor of the WPEC (Working Party on International Nuclear Data Evaluation Co-operation) SG(Subgroup)-50 format to store the metadata for the ML analysis.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗

Sandia Toolkit Manual (V.5.21.1)

This report provides documentation for the Sandia Toolkit (STK) modules. STK modules are intended to provide infrastructure that assists the development of computational engineering software such as finite-element analysis applications. STK includes modules for unstructured-mesh data structures, reading/writing mesh files, geometric proximity search, transfers, MPMD coupling support, and various other utilities. This document contains a chapter for each module, and each chapter contains overview descriptions and usage examples. Usage examples are primarily code listings which are generated from working test programs that are included in the STK code-base. A goal of this approach is to ensure that the usage examples will not fall out of date.

97 MATHEMATICS AND COMPUTING↗

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↗

Sandia Toolkit Manual Version 5.15.6

This report provides documentation for the Sandia Toolkit (STK) modules. STK modules are intended to provide infrastructure that assists the development of computational engineering software such as finite-element analysis applications. STK includes modules for unstructured-mesh data structures, reading/writing mesh files, geometric proximity search, and various utilities. This document contains a chapter for each module, and each chapter contains overview descriptions and usage examples. Usage examples are primarily code listings which are generated from working test programs that are included in the STK code-base. A goal of this approach is to ensure that the usage examples will not fall out of date.

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↗