Search NASA⌕ Search

SEARCH · Search NASA

Results for “application programming interface”

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 307 records · Page 17

PROTEUS-SN User Manual

PROTEUS-SN is a three-dimensional, highly scalable, high-fidelity neutron transport code developed at Argonne National Laboratory. The code is applicable to all spectrum reactor transport calculations, particularly those in which a high degree of fidelity is needed either to represent spatial detail or to resolve solution gradients. PROTEUS-SN solves the second order formulation of the transport equation using the continuous Galerkin finite element method in space, the discrete ordinates approximation in angle, and the multigroup approximation in energy. PROTEUS-SN’s parallel methodology permits the efficient decomposition of the problem by both space and angle, permitting large problems to run efficiently on hundreds of thousands of cores. PROTEUS-SN can also be used in serial or on smaller compute clusters (10’s to 100’s of cores) for smaller homogenized problems, although it is generally more computationally expensive than traditional homogenized methodology codes. PROTEUS-SN has been used to model partially homogenized systems, where regions of interest are represented explicitly and other regions are homogenized to reduce the problem size and required computational resources. PROTEUS-SN solves forward and adjoint eigenvalue problems and permits both neutron upscattering and downscattering. An adiabatic kinetics option has recently been included for performing simple time-dependent calculations in addition to standard steady state calculations. PROTEUS-SN handles void and reflective boundary conditions. Multigroup cross sections can be generated externally using the MC2-3 fast reactor multigroup cross section generation code or internally using the cross section application programming interface (API) which can treat the subgroup or resonance table libraries. PROTEUS-SN is written in Fortran 90 and also includes C preprocessor definitions. The code links against the PETSc, METIS, HDF5, and MPICH libraries. It optionally links against the MOAB library and is a part of the SHARP multi-physics suite for coupled multi-physics analysis of nuclear reactors. This user manual describes how to set up a neutron transport simulation with the PROTEUS-SN code. A companion methodology manual describes the theory and algorithms within PROTEUS-SN.

97 MATHEMATICS AND COMPUTING↗

RAVEN User Manual

RAVEN is a generic software framework to perform parametric and probabilistic analysis based on the response of complex system codes. The initial development was aimed to provide dynamic risk analysis capabilities to the Thermo-Hydraulic code RELAP-7, currently under development at the Idaho National Laboratory (INL). Although the initial goal has been fully accomplished, RAVEN is now a multi-purpose probabilistic and uncertainty quantification platform, capable to agnostically communicate with any system code. This agnosticism includes providing Application Programming Interfaces (APIs). These APIs are used to allow RAVEN to interact with any code as long as all the parameters that need to be perturbed are accessible by input files or via python interfaces. RAVEN is capable of investigating the system response, and investigating the input space using Monte Carlo, Grid, or Latin Hyper Cube sampling schemes, but its strength is focused toward system feature discovery, such as limit surfaces, separating regions of the input space leading to system failure, using dynamic supervised learning techniques. The development of RAVEN started in 2012, when, within the Nuclear Energy Advanced Modeling and Simulation (NEAMS) program, the need to provide a modern risk evaluation framework became stronger. RAVEN principal assignment is to provide the necessary software and algorithms in order to employ the concept developed by the Risk Informed Safety Margin Characterization (RISMC) program. RISMC is one of the pathways defined within the Light Water Reactor Sustainability (LWRS) program. In the RISMC approach, the goal is not just the individuation of the frequency of an event potentially leading to a system failure, but the closeness (or not) to key safety-related events. Hence, the approach is interested in identifying and increasing the safety margins related to those events. A safety margin is a numerical value quantifying the probability that a safety metric (e.g. for an important process such as peak pressure in a pipe) is exceeded under certain conditions. The initial development of RAVEN has been focused on providing dynamic risk assessment capability to RELAP-7, currently under development at the INL and, likely, future replacement of the RELAP5-3D code. Most the capabilities that have been implemented having RELAP-7 as principal focus are easily deployable for other system codes. For this reason, several side activates are currently ongoing for coupling RAVEN with software such as RELAP5-3D, etc. The aim of this document is the explanation of the input requirements, focusing on the input structure.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

ExactPack Documentation

For code verification, one compares the code output against known exact solutions. There are many standard test problems used in this capacity, such as the Noh and Sedov problems. ExactPack is a utility that integrates many of these exact solution codes into a common API (application program interface), and can be used as a stand-alone code or as a python package. ExactPack consists of python driver scripts that access a library of exact solutions written in Fortran or Python. The spatial profiles of the relevant physical quantities, such as the density, fluid velocity, sound speed, or internal energy, are returned at a time specified by the user. The solution profiles can be viewed and examined by a command line interface or a graphical user interface, and a number of analysis tools and unit tests are also provided. We have documented the physics of each problem in the solution library, and provided complete documentation on how to extend the library to include additional exact solutions. ExactPack’s code architecture makes it easy to extend the solution-code library to include additional exact solutions in a robust, reliable, and maintainable manner.

97 MATHEMATICS AND COMPUTING↗

RAVEN User Manual

RAVEN is a generic software framework to perform parametric and probabilistic analy- sis based on the response of complex system codes. The initial development was aimed to provide dynamic risk analysis capabilities to the Thermo-Hydraulic code RELAP-7, currently under development at the Idaho National Laboratory (INL). Although the initial goal has been fully accomplished, RAVEN is now a multi-purpose probabilistic and uncer- tainty quantification platform, capable to agnostically communicate with any system code. This agnosticism includes providing Application Programming Interfaces (APIs). These APIs are used to allow RAVEN to interact with any code as long as all the parameters that need to be perturbed are accessible by inputs files or via python interfaces. RAVEN is capable of investigating the system response, and investigating the input space using Monte Carlo, Grid, or Latin Hyper Cube sampling schemes, but its strength is focused to- ward system feature discovery, such as limit surfaces, separating regions of the input space leading to system failure, using dynamic supervised learning techniques. The development of RAVEN has started in 2012, when, within the Nuclear Energy Advanced Modeling and Simulation (NEAMS) program, the need to provide a modern risk evaluation framework became stronger. RAVEN principal assignment is to provide the necessary software and algorithms in order to employ the concept developed by the Risk Informed Safety Margin Characterization (RISMC) program. RISMC is one of the pathways defined within the Light Water Reactor Sustainability (LWRS) program. In the RISMC approach, the goal is not just the individuation of the frequency of an event potentially leading to a system failure, but the closeness (or not) to key safety-related events. Hence, the approach is in- terested in identifying and increasing the safety margins related to those events. A safety margin is a numerical value quantifying the probability that a safety metric (e.g. for an important process such as peak pressure in a pipe) is exceeded under certain conditions. The initial development of RAVEN has been focused on providing dynamic risk assess- ment capability to RELAP-7, currently under develop-ment at the INL and, likely, future replacement of the RELAP5-3D code. Most the capabilities that have been implemented having RELAP-7 as principal focus are easily deployable for other system codes. For this reason, several side activates are currently ongoing for coupling RAVEN with soft- ware such as RELAP5-3D, etc. The aim of this document is the explaination of the input requirements, focalizing on the input structure.

97 MATHEMATICS AND COMPUTING↗

Warthog: Coupling Status Update

The Warthog code was developed to couple codes that are developed in both the Multi-Physics Object-Oriented Simulation Environment (MOOSE) from Idaho National Laboratory (INL) and SHARP from Argonne National Laboratory (ANL). The initial phase of this work, focused on coupling the neutronics code PROTEUS with the fuel performance code BISON. The main technical challenge involves mapping the power density solution determined by PROTEUS to the fuel in BISON. This presents a challenge since PROTEUS uses the MOAB mesh format, but BISON, like all other MOOSE codes, uses the libMesh format. When coupling the different codes, one must consider that Warthog is a light-weight MOOSE-based program that uses the Data Transfer Kit (DTK) to transfer data between the various mesh types. Users set up inputs for the codes they want to run, and then Warthog transfers the data between them. Currently Warthog supports XSProc from SCALE or the Sub-Group Application Programming Interface (SGAPI) in PROTEUS for generating cross sections. It supports arbitrary geometries using PROTEUS and BISON. DTK will transfer power densities and temperatures between the codes where the domains overlap. In the past fiscal year (FY), much work has gone into demonstrating two-way coupling for simple pin cells of various materials. XSProc was used to calculate the cross sections, which were then passed to PROTEUS in an external file. PROTEUS calculates the fission/power density, and Warthog uses DTK to pass this information to BISON, where it is used as the heat source. BISON then calculates the temperature profile of the pin cell and sends it back to XSProc to obtain the temperature corrected cross sections. This process is repeated until the convergence criteria (tolerance on BISON solve, or number of time steps) is reached. Models have been constructed and run for both uranium oxide and uranium silicide fuels. These models demonstrate a clear difference in power shape that is not accounted for in a stand-alone BISON run. Future work involves improving the user interface (UI), likely through integration with the Nuclear Energy Advanced Modeling and Simulation (NEAMS) Workbench. Furthermore, automating the input creation would ease the user experience. The next priority is to continue coupling the work with other codes in the SHARP package. Efforts on other projects include work to couple the Nek5000 thermo-hydraulics code to MOOSE, but this is in the preliminary stages.

71 CLASSICAL AND QUANTUM MECHANICS, GENERAL PHYSIC↗

Advanced Energy System Design (AESD): Technical Manual for the Records API

The Records API (application program interface) for Advanced Energy System Design (AESD) enables software that serves multidimensional record-oriented data to interoperate with software than uses such data. In the context of the Records API, multidimensional data records are simply tuples of real numbers, integers, and character strings, where each data value is tagged by a variable name, according to a pre-defined schema, and each record is assigned a unique integer identifier. Conceptually, these records are isomorphic to rows in a relational database, JSON objects, or key-value maps. Records servers might supply static datasets, sensor measurements that periodically update as new telemetry become available, or the results of simulations as the simulations generate new output. Records client software might display or analyze the data, but in the case of simulations the client request the creation of new ensembles for specified input parameters. It is also possible to chain records clients and servers together so that a client consuming data from a server might transform that data and serve it to further clients. This minimalist API avoids imposing burdensome metadata, structural, or implementation requirements on developers by relying on open-source technologies that is readily available for common programming languages. In particular, the API has been designed to place the smallest possible burden on services that provide data. This document defines the message format for the Records API, a transport mechanism for communicating the data, and semantics for interpreting it. The message format is specified as Google Protocol Buffers and the transport mechanism uses WebSockets. We discuss three major use cases for serving and consuming records data: (i) static data, (ii) dynamically augmented data, (iii) on-demand simulations, (iv) with filters, and (v) with bookmarks. Separate implementations of the API exist in C++, Haskell, JavaScript, Python, and R.

97 MATHEMATICS AND COMPUTING↗

RAVEN User Manual

RAVEN is a generic software framework to perform parametric and probabilistic analy- sis based on the response of complex system codes. The initial development was aimed to provide dynamic risk analysis capabilities to the Thermo-Hydraulic code RELAP-7, currently under development at the Idaho National Laboratory (INL). Although the initial goal has been fully accomplished, RAVEN is now a multi-purpose probabilistic and uncer- tainty quantification platform, capable to agnostically communicate with any system code. This agnosticism includes providing Application Programming Interfaces (APIs). These APIs are used to allow RAVEN to interact with any code as long as all the parameters that need to be perturbed are accessible by inputs files or via python interfaces. RAVEN is capable of investigating the system response, and investigating the input space using Monte Carlo, Grid, or Latin Hyper Cube sampling schemes, but its strength is focused to- ward system feature discovery, such as limit surfaces, separating regions of the input space leading to system failure, using dynamic supervised learning techniques. The development of RAVEN has started in 2012, when, within the Nuclear Energy Advanced Modeling and Simulation (NEAMS) program, the need to provide a modern risk evaluation framework became stronger. RAVEN principal assignment is to provide the necessary software and algorithms in order to employ the concept developed by the Risk Informed Safety Margin Characterization (RISMC) program. RISMC is one of the pathways defined within the Light Water Reactor Sustainability (LWRS) program. In the RISMC approach, the goal is not just the individuation of the frequency of an event potentially leading to a system failure, but the closeness (or not) to key safety-related events. Hence, the approach is in- terested in identifying and increasing the safety margins related to those events. A safety margin is a numerical value quantifying the probability that a safety metric (e.g. for an important process such as peak pressure in a pipe) is exceeded under certain conditions. The initial development of RAVEN has been focused on providing dynamic risk assess- ment capability to RELAP-7, currently under develop-ment at the INL and, likely, future replacement of the RELAP5-3D code. Most the capabilities that have been implemented having RELAP-7 as principal focus are easily deployable for other system codes. For this reason, several side activates are currently ongoing for coupling RAVEN with soft- ware such as RELAP5-3D, etc. The aim of this document is the explaination of the input requirements, focalizing on the input structure.

97 MATHEMATICS AND COMPUTING↗

Policy, Permit, Perform: Using City Benchmarking Data and Building Construction Permit History to Identify Energy Performance Improvements

The City of Portland (City) and Multnomah County 2015 Climate Action Plan targets a 40 percent reduction in carbon emissions below 1990 levels by 2030. To reach this goal, the plan includes a key objective to reduce the total energy use of existing buildings by 25 percent. Buildings are responsible for one-half of carbon emissions in Portland, Oregon, U.S., and improving their performance is critical to achieving the City’s climate goals. As part of its climate action planning, the City passed an ordinance on April 22, 2015, requiring commercial buildings 20,000 ft2 and larger to benchmark and disclose annual energy performance metrics through ENERGY STAR® Portfolio Manager® (ESPM), including greenhouse gas emissions, building energy use intensity (EUI) and ENERGY STAR scores. Twenty-five cities in the U.S. have adopted similar policies requiring energy benchmarking. These policies are generating a treasure trove of data about the drivers of building performance, but practitioners are only beginning to link benchmarking data to other datasets to produce actionable insight into improving building performance. In 2016, the City received a financial assistance award from the U.S. Department of Energy (DOE) through the Cities Leading through Energy Analysis and Planning project (Award Number DE-0007737). Portland’s project evaluated the application of the DOE Building Energy Asset Score Tool and rating system developed by Pacific Northwest National Laboratory (PNNL) to commercial buildings that report to the City. The City used building construction permit history to develop Asset Scores for a set of office buildings that reported energy performance for 2015 – the first year the City mandated energy benchmarking and reporting for commercial buildings 50,000 ft2 and larger. The primary project objective was to link energy benchmarking data and commercial building permit data to analyze commercial buildings systems that present the best, specific opportunities to improve energy performance. Integrating these datasets from two City departments, the Bureau of Development Services and the Bureau of Planning and Sustainability, could expand Portland’s use of analytics to inform climate policy decisions and strategic targeting of financial incentives for building owners and managers who are best positioned to improve the performance of their buildings. The project began with the commercial benchmarking data received for 340 commercial buildings that submitted calendar year 2015 energy reports. The City retained Research Into Action and Energy 350 (RIA team) to evaluate this self-reported benchmarking data. Based on a survey of 53 building managers, the RIA team found that most respondents used the City’s compliance tools, including a How-to Guide and Help Desk, and found access to utility data to be straightforward. However, almost one-third of the respondents encountered challenges when estimating the gross floor area (GFA), and some experienced confusion regarding the input of property use types and details into ESPM. Based on the RIA team’s recommendations, the City refined its How-to Guide, created online answers to frequently asked questions, and hosted office hour sessions to help building managers accurately characterize their building’s physical characteristics and operations in ESPM. Concurrently with the RIA team’s evaluation, the City worked with PNNL to estimate DOE Asset Score Preview (Preview) scores for 181 of the 340 commercial buildings that submitted ESPM reports to the City. Asset Score Tool is a web-based tool developed by PNNL for DOE to evaluate and rate the as-built energy efficiency of a building. Asset Score Tool’s full analysis capability runs a detailed energy model based on building geometry, age, envelope, lighting and mechanical systems using standard operating assumptions to give the building a score, similar to a miles per gallon rating for a car. Preview, a simplified deployment of the full Asset Score Tool, provides a preliminary score range using only seven data points, six of which are readily available in the ESPM benchmarking data. Analysis of the combined Preview scores and the operational ESPM scores identified buildings with a high potential for energy improvements through either retro-commissioning and retuning of existing operations or capital investments into building systems. The City contracted Whole Building Solutions (WBS) to mine building permit history and develop full Asset Scores for a subset of 26 office buildings that were eligible for both ENERGY STAR scores and Asset Scores. WBS researched permits and building plans to identify mechanical, lighting and envelope systems and other building characteristics necessary to complete Asset Scores. This historical data was recorded using the web-based Asset Score Tool, which evaluates the as designed energy efficiency of existing buildings. Much of this City information was available online after 2010; however, WBS had to search through microfiche files and the City’s database to obtain permit and plan history prior to 2010. Although building geometry, mechanical system type and basic envelope information was consistently identifiable, WBS found permit data gaps that prevented complete and accurate Asset Scores for most of the office buildings. If the City decides to develop Asset Scores based on building permit information in the future, WBS recommended requiring lighting plans, control diagrams and as-built drawings that reflect how the buildings are actually constructed. In addition, WBS recommended uploading plans and permits from microfiche storage into a more comprehensive, searchable database consistent with the City’s current online permit information. To identify the actual lighting types, WBS and City staff conducted site visits of all 26 office buildings. As part of managing the flow of ESPM and Asset Score data for the project, Earth Advantage, a sub-recipient of the Cities-LEAP award, created a DOE Standard Energy Efficiency Data (SEED) (USDOE 2018) instance for the City and used Asset Score’s Application Programming Interface (API) (Asset Score 2018) capabilities to develop two new features in the SEED Platform™: (1) automated Asset Score Preview ranges calculated based on benchmarking data and the City’s estimate of number of building floors; and (2) storage of full Asset Score information. Leveraging the construction permit history and site visit information for the 26 office buildings, The Cadmus Group (Cadmus) analyzed benchmarking data and Asset Score information to identify opportunities and drivers to improve performance. Correlation and regression analysis of the combined dataset was completed to determine whether building operations or specific systems – mechanical, lighting or envelope – present the best opportunities to improve energy performance. The central outcome of this project was Cadmus’ detailed analysis of the richer dataset that was created by combining the City of Portland’s commercial building permit activity and building-specific energy performance information based on metrics from ESPM and Asset Score Tool. Some of their findings collaborate with well-known facts, such as buildings with less efficient lighting systems are good targets for efficiency improvements through lighting upgrades. This analysis also helped identify that individual heating, ventilation, and air conditioning (HVAC) equipment efficiency does not necessarily correlate with building performance. However, overall HVAC system performance, as measured with the Total System Performance Ratio (TSPR) metric, is a better indicator of building performance (Goel et al. 2014). As a metric, TSPR considers whole system performance that includes equipment efficiency and system controls, such as resets for static pressure and chilled water setpoints, which can be more effective and financially feasible options for improving building performance. Given the high cost associated with envelope retrofits, opportunities to upgrade envelope insulation are likely to be limited. However, buildings with single-pane and non-thermal break windows are good candidates for window replacements, such as upgrading to double-pane windows with thermal breaks. This research project determined that developing Asset Scores based on site visits is preferable to mining City building permit data. In addition, the use of benchmarking data to develop Asset Score Preview Scores is recommended as a first step in engaging building managers to develop full Asset Scores. Asset Score Tool outputs can help building managers quickly identify opportunities for improvement and then work with the utility incentive administrator and energy service providers to develop their retrofit plan. Where full Asset Scores are available, analysis using a quadrant matrix with ENERGY STAR scores is recommended to identify buildings that present the best opportunities for operational-behavioral improvements versus ones with opportunities for upgrades to physical building systems. This workflow and the tools will help cities, utility incentive administrators, building portfolio managers and energy service providers develop energy programs and strategies for screening and analysis of buildings with the greatest energy savings potential. This report describes the project approach and research results to inform future coordination of ESPM and Asset Score data, including the use of benchmarking data to generate Preview scores. Given better awareness of energy performance, building managers can make more informed decisions to reduce energy consumption and carbon emissions. With cities, states and jurisdictions adopting benchmarking and auditing ordinances, there are substantial amounts of data submitted to cities that could be used to inform investments in energy efficiency.

29 ENERGY PLANNING, POLICY, AND ECONOMY↗

RAVEN User Manual, Revision 4

RAVEN is a generic software framework to perform parametric and probabilistic analysis based on the response of complex system codes. The initial development was aimed to provide dynamic risk analysis capabilities to the Thermo-Hydraulic code RELAP-7, currently under development at the Idaho National Laboratory (INL). Although the initial goal has been fully accomplished, RAVEN is now a multi-purpose probabilistic and uncertainty quantification platform, capable to agnostically communicate with any system code. This agnosticism includes providing Application Programming Interfaces (APIs). These APIs are used to allow RAVEN to interact with any code as long as all the parameters that need to be perturbed are accessible by inputs files or via python interfaces. RAVEN is capable of investigating the system response, and investigating the input space using Monte Carlo, Grid, or Latin Hyper Cube sampling schemes, but its strength is focused to- ward system feature discovery, such as limit surfaces, separating regions of the input space leading to system failure, using dynamic supervised learning techniques. The development of RAVEN has started in 2012, when, within the Nuclear Energy Advanced Modeling and Simulation (NEAMS) program, the need to provide a modern risk evaluation framework became stronger. RAVEN principal assignment is to provide the necessary software and algorithms in order to employ the concept developed by the Risk Informed Safety Margin Characterization (RISMC) program. RISMC is one of the pathways defined within the Light Water Reactor Sustainability (LWRS) program. In the RISMC approach, the goal is not just the individuation of the frequency of an event potentially leading to a system failure, but the closeness (or not) to key safety-related events. Hence, the approach is interested in identifying and increasing the safety margins related to those events. A safety margin is a numerical value quantifying the probability that a safety metric (e.g. for an important process such as peak pressure in a pipe) is exceeded under certain conditions. The initial development of RAVEN has been focused on providing dynamic risk assess- ment capability to RELAP-7, currently under development at the INL and, likely, future replacement of the RELAP5-3D code. Most the capabilities that have been implemented having RELAP-7 as principal focus are easily deployable for other system codes. For this reason, several side activates are currently ongoing for coupling RAVEN with soft- ware such as RELAP5-3D, etc. The aim of this document is the explanation of the input requirements, focalizing on the input structure.

97 MATHEMATICS AND COMPUTING↗

Sub-Libraries in ORIGEN

Libraries produced for the ORIGEN depletion code have the ability to label nuclides with a sublibrary integer tag. While this is useful for tracking different sources of the nuclides, it adds some complexity, increasing memory usage and computational effort. This report documents the effort of making the sublibraries optional in an ORIGEN calculation, with a focus on the creation of libraries using the LibraryBuilder application programming interface (API). ORIGEN will gain the ability to either use the normal sublibrary set, a reduced, unique, sublibrary set, or no sublibrary at all.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗

Multi–LDAP Dynamic User Management Tool Utilizing Oracle Application Express and PL/SQL

A Center for Infrastructure Security Analysis (CISA) client system required support of multiple Lightweight Directory Access Protocol (LDAP) directories for multiple, varied user communities. The LDAP directories were all based upon different technologies, i.e., Microsoft Active Directory (AD), Microsoft Active Directory Lightweight Directory Services (ADLDS), and Oracle Internet Directory (OID), depending on system setup, security requirements, and legacy software. Research revealed that PL/SQL provided the capability to execute dynamic PL/SQL and SQL blocks. The dynamic capabilities were utilized along with several configuration tables to provide an object-oriented, polymorphic-like behavior. This architecture was chosen so that a top-level application programming interface (API) could be defined for all calls, no matter what type of LDAP was being manipulated, as each LDAP type has slightly different attributes and requirements. The dynamic nature of the user management system allowed for easy setup and utilization of any new LDAP directories, minimizing the time and effort expended on system changes.

97 MATHEMATICS AND COMPUTING↗

Proactive Data Containers for Scientific Storage (Final Report)

Emerging HPC systems are expected to be deployed with an unprecedented level of complexity, due to a deep system memory/storage hierarchy and heterogeneity of the storage hardware. This hierarchy is expected to range from CPU cache through several levels of volatile memory to nonvolatile memory, traditional hard disks, and tape. Simple and efficient methods of data management and movement through this hierarchy is critical for scientific applications using exascale systems. Existing storage system and I/O (SSIO) technologies face severe challenges in dealing with these requirements. POSIX and MPI I/O standards that are the basis for existing I/O libraries and parallel file systems present fundamental challenges in the areas of scalable metadata operations, semantics-based data movement performance tuning, asynchronous operation, and support for scalable consistency of distributed operations. Moving toward new paradigms for SSIO in the extreme-scale era, we have proposed to investigate novel object-based data abstractions and storage mechanisms that take advantage of the deep storage hierarchy and enable proactive automated performance tuning. In order to achieve these overarching goals, we initiated an effort to develop a fundamental new data abstraction, called Proactive Data Containers (PDC). A PDC is a container within a locus of storage (memory, NVRAM, disk, etc.) that stores science data in an object-centric manner. Managing data as objects enables powerful optimization opportunities for data movement and transformations. The R&D focus of this project are: 1) formulation of object-oriented PDCs and their mapping in different levels of the exascale storage hierarchy; 2) efficient strategies for moving data in deep storage hierarchies using PDCs; 3) techniques for transforming and reorganizing data based on application requirements; and 4) novel analysis paradigms for enabling data transformations and user-defined analysis on data in PDCs. Toward achieving these overarching goals, we designed an object-centric application programing interface (API) for HPC, scalable metadata management for object-centric storage systems, and data movement optimizations such as Data Elevator for moving data between two levels of storage devices and TAPIOCA for efficient aggregation of data on compute nodes. We then implemented several components of the PDC system. They include metadata management, data placement services, remote procedure calls, data aggregation, etc. We have put them together into the overall PDC framework.

97 MATHEMATICS AND COMPUTING↗

Future SDN-HPON Control Plane Architecture and Protocol for On-Demand Terabit End-to-End Extreme-Scale Science Applications

The UC Davis team conducted architecture, algorithm and experimental studies for next generation ultra-high-bandwidth optical networks in support of extreme-scale science applications. In particular, over the course of this 3-year project, the UC Davis team achieved the following main accomplishments: Designed a network architecture for automated multi-domain service provisioning: Designed information exchange schemes between autonomous systems (domains) Designed application programming interfaces to orchestrate resource reservation in data centers, high performance computation facilities, and communication networks belonging to different autonomous systems Experimentally assessed the multi-domain network architecture in a distributed field trial set-up connecting premises in three continents Designed a broker-based orchestrated multi-domain optical networking framework supporting observe-analyze-act cycle based cognitive inter-domain service provisioning: Designed an inter-domain operation mechanism, e.g., topology abstraction, for the broker plane and domain managers to collaboratively accomplish inter-domain service provisioning while respecting the autonomy of each administrative domain Designed an alien wavelength monitoring scheme and an artificial neural network based optical signal-to-noise ratio estimator for quality-of-transmission aware inter-domain service provisioning Developed a deep neural network based multi-domain traffic predictor and a cognitive routing and spectrum assignment algorithm to realize knowledge-based autonomous traffic engineering in multi-domain networks Implemented an optical signal-to-noise ratio estimator and traffic predictor with Google’s Tensor flow and assessed their performance using experimental and synthetic data Demonstrated the benefits of the proposed cognitive schemes with experiments ona two-domain elastic optical network testbed and evaluations on a six-domain simulation framework Built a two-domain software-defined networking control plane testbed using the ONOS platform and demonstrated the workflow of broker and domain manager cooperation, including hierarchical performance monitoring, topology abstraction and cognitive resource allocation. Designed self-learning cognitive service provisioning schemes using advanced machine learning technologies: Designed a self-taught anomaly detection framework for optical networks, including an unsupervised data clustering module for pattern recognition, a supervised data regression and classification module for online anomaly detection, and the system operation principle Experimentally validated the effectiveness of the self-taught anomaly detection framework with various failure/anomaly scenarios. Designed a self-learning autonomic routing, modulation and spectrum assignment (RMSA) provisioning framework for elastic optical networks with deep reinforcement learning. Designed effective modeling and training mechanisms for the self-learning RMSA framework Conducted extensive numerical simulations with various traffic patterns and topologies to verify the advantage of the self-learning RMSA framework.

42 ENGINEERING↗

VERAView API and Programmer's Guide (Milestone L3:PHI.MQA-1.P19.03)

VERAView's component-based design facilitates extension and integration into other applications and systems. In addition to describing VERAView's architecture and components, this document provides details on the component application programming interfaces (API), illustrates how to use them independently of VERAView itself, and explains how to extend VERAView with custom visualizations.

97 MATHEMATICS AND COMPUTING↗

New Architecture to Support Integration and Processing of Seismic Data from Heterogeneous Sources

The Geophysical Monitoring Program (GMP) at Lawrence Livermore National Lab (LLNL) maintains a database and supporting infrastructure for geophysical data used in support of the Nuclear Detonation Detection mission. This database includes data from multiple sources, many of which do not distribute data to the public or for which there is no automated means of access. For example, Figure 1 shows (left) the distribution of waveform data in our database by source. The Incorporated Research Institutions for Seismology Data Management Center (IRISDMC) is our major source of waveform data and those data may be retrieved at will using the Federated Digital Seismograph Networks FDSN web Application Programming Interface (API). However, the next 6 most important sources of waveform data have no or only limited automated access to waveforms. As Figure 1 (right) shows, it is very common for waveform records associate with an event in our database to come from two or more sources, and in some cases data come from 10 sources. This diversity of data sources drives our need for efficient and correct integration of metadata, parametric data, and waveform data.

58 GEOSCIENCES↗

Water Network Tool for Resilience (WNTR). User Manual, Version 0.2.3

The Water Network Tool for Resilience (WNTR, pronounced winter) is a Python package designed to simulate and analyze resilience of water distribution networks. Here, a network refers to the collection of pipes, pumps, valves, junctions, tanks, and reservoirs that make up a water distribution system. WNTR has an application programming interface (API) that is flexible and allows for changes to the network structure and operations, along with simulation of disruptive incidents and recovery actions. WNTR is based upon EPANET, which is a tool to simulate the movement and fate of drinking water constituents within distribution systems. Users are encouraged to be familiar with the use of EPANET and/or should have background knowledge in hydraulics and pressurized pipe network modeling before using WNTR. EPANET has a graphical user interface that might be a useful tool to facilitate the visualization of the network and the associated analysis results. Information on EPANET can be found at https://www.epa.gov/water-research/epanet. WNTR is compatible with EPANET 2.00.12 [Ross00]. In addition, users should have experience using Python, including the installation of additional Python packages. General information on Python can be found at https://www.python.org/.

54 ENVIRONMENTAL SCIENCES↗

HFIRCON Version 1.0.5 User Guide

The High Flux Isotope Reactor (HFIR) Controller (HFIRCON) code is a collection of python routines and C plugins that automate the workflow for fuel and single- or multicycle target depletion analyses for HFIR at Oak Ridge National Laboratory (ORNL). This code calls the LAVAMINT (LAVA Model Interrogator) parallel (MCNP) Monte Carlo N-Particle model interrogator to stochastically calculate cell volumes and bounding boxes, the ADVANTG (Automatic Variance Reduction Generation) code package for all variance reduction and source biasing calculations, the ORNL-Transformative Neutronics/MCNP5 transport solver for all transport solutions, and the MSX_DEPLETE module to perform all depletion calculations via the ORIGEN (Oak Ridge Isotope Generation) application programming interface. It also performs a robust set of postprocessing functions to automatically provide summaries of several key metrics that are common to a wide variety of typical HFIR design and safety-basis analyses.

11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗

Retaining Systems Engineering Model Meaning Through Transformation: Demo 2

Digital engineering strategies typically assume that digital engineering models interoperate seamlessly across the multiple different engineering modeling software applications involved, such as model- based systems engineering (MBSE), mechanical computer-aided design (MCAD), electrical computer-aided design (ECAD), and other engineering modeling applications. The presumption is that the data schema in these modeling software applications are structured in the familiar flat- tabular schema like any other software application. Engineering domain-specific applications (e.g., systems, mechanical, electrical, simulation) are typically designed to solve domain-specific problems, necessarily excluding explicit representations of non-domain information to help the engineer focus on the domain problems (system definition, design, simulation). Such exclusions become problematic in inter-domain information exchange. The obvious assumptions of one domain might not be so obvious to experts in another domain. Ambiguity in domain-specific language can erode the ability to enable different domain modeling applications to interoperate, unless the underlying language is understood and used as the basis for translation from one application to another. The engineering modeling software application industry has struggled for decades to enable these applications to interoperate. Industry standards have been developed, but they have not unified the industry. Why is this? The authors assert that the industry has relied on traditional database integration methods. The basic issue prohibiting successful application integration then is that traditional database-driven integration does not consider the distinct languages of each domain. An engineering models meaning is expressed through the underlying language of that engineering domain. In essence, traditional integration methods do not retain the semantic context (meaning) of the model. The basis of this research stems from the widely held assumption that systems engineering models are (or can be) structured according to the underlying semantic ontology of the model. This assumption can be imagined from two thoughts. 1) Digital systems engineering models are often represented using graph theory (the graph of a complex systems model can contain millions of nodes and edges). When examining the nodes one at a time and following the outbound edges of each node one by one, one can end up with rudimentary statements about the model (i.e., node A relates to node B), as in a semantic graph. 2) Likewise, from the study of natural languages, a sentence can be structured into unambiguous triples of subject-predicate-object within formal and highly expressive semantic ontologies. The rudimentary statements about a systems model discerned with graph theory closely mimic the triples used in the ontologies that try to structure natural languages. In other words, a systems models semantic graph can be (or is) structured into an ontology. Additionally, it is well established in industry that through natural language processing (NLP), which provides the means to create language structures, that computers can interpret ontological graphs. Therefore, the authors hypothesized that if the integrity of the underlying semantic structure of a systems model is retained, the contextual meaning of the model is retained. By structuring system models into the triples of the underlying ontology during the transformation from one MBSE application to another, the authors have provided a proof of the concept that the meaning of a system model can be retained during transformation. The authors assert that this is the missing ingredient in effective systems model-to-model interoperability. ACKNOWLEDGEMENTS The authors would like to thank the FY19 Model Interoperability team members who provided a solid foundation for the FY20 team to leverage: John McCloud, for the work he did to guide us toward the right use of technology that will appropriately discover and manipulate ontologies. Carlos Tafoya, for the work he did to develop an application programming interface (API)/Adapter that would export ontology-based data from GENESYS. Peter Chandler, for the work he did to architect our overall integration solution, with an eye toward the future that would influence a large-scale federated production-level systems engineering digital model ecosystem.

42 ENGINEERING↗