Results for “application program interface” — Page 4

NASA NTRS2004

Activity-Centric Approach to Distributed Programming

The first phase of an effort to develop a NASA version of the Cybele software system has been completed. To give meaning to even a highly abbreviated summary of the modifications to be embodied in the NASA version, it is necessary to present the following background information on Cybele: Cybele is a proprietary software infrastructure for use by programmers in developing agent-based application programs [complex application programs that contain autonomous, interacting components (agents)]. Cybele provides support for event handling from multiple sources, multithreading, concurrency control, migration, and load balancing. A Cybele agent follows a programming paradigm, called activity-centric programming, that enables an abstraction over system-level thread mechanisms. Activity centric programming relieves application programmers of the complex tasks of thread management, concurrency control, and event management. In order to provide such functionality, activity-centric programming demands support of other layers of software. This concludes the background information. In the first phase of the present development, a new architecture for Cybele was defined. In this architecture, Cybele follows a modular service-based approach to coupling of the programming and service layers of software architecture. In a service-based approach, the functionalities supported by activity-centric programming are apportioned, according to their characteristics, among several groups called services. A well-defined interface among all such services serves as a path that facilitates the maintenance and enhancement of such services without adverse effect on the whole software framework. The activity-centric application-program interface (API) is part of a kernel. The kernel API calls the services by use of their published interface. This approach makes it possible for any application code written exclusively under the API to be portable for any configuration of Cybele.

Levy, Renato↗

DOE OSTI2023

EDX Spatial: Leveraging cloud and hybrid data management resources for spatial data

In the last few years, the National Energy Technology Laboratory has started leveraging cloud-hosted services for hosting spatial data collections published on the Energy Data eXchange (EDX). Using cloud-hosted storage and compute options offers multiple benefits for visualization and tool development through utilization of spatial data resources. The transition from on-premises services to cloud-hosted services has enabled a few key features: increased accessibility of large derivative datasets, dynamic integration of external authoritative data resources directly from outside entities through representational state transfer application programming interfaces (REST API), and the ability to produce complex mapping applications, dashboards, and online maps. As a result of the shift, NETL has launched EDX Spatial, a platform that leverages on-premises resources combined with cloud compute capabilities to enable enhanced online mapping interfaces and optimize data access. In addition, a unified workflow for handling the public release of spatial data products through EDX has been developed, including standardization of data hosting practices, metadata, symbology, and application elements. This poster reviews the opportunity of leveraging cloud-hosted and hybrid data management solutions for spatial data, and discusses the benefits and lessons learned while leveraging these services through the data repository EDX.

Morkner, Paige↗

NASA NTRS2016

Experimenting Galileo on Board the International Space Station

The SCaN Testbed is an advanced integrated communications system and laboratory facility installed on the International Space Station (ISS) in 2012. The testbed incorporates a set of new generation of Software Defined Radio (SDR) technologies intended to allow researchers to develop, test, and demonstrate new communications, networking, and navigation capabilities in the actual environment of space. Qascom, in cooperation with ESA and NASA, is designing a Software Defined Radio GalileoGPS Receiver capable to provide accurate positioning and timing to be installed on the ISS SCaN Testbed. The GalileoGPS waveform will be operated in the JPL SDR that is constituted by several hardware components that can be used for experimentations in L-Band and S-Band. The JPL SDR includes an L-Band Dorne Margolin antenna mounted onto a choke ring. The antenna is connected to a radio front end capable to provide one bit samples for the three GNSS frequencies (L1, L2 and L5) at 38 MHz, exploiting the subharmonic sampling. The baseband processing is then performed by an ATMEL AT697 processor (100 MIPS) and two Virtex 2 FPGAs. The JPL SDR supports the STRS (Space Telecommunications Radio System) that provides common waveform software interfaces, methods of instantiation, operation, and testing among different compliant hardware and software products. The standard foresees the development of applications that are modular, portable, reconfigurable, and reusable. The developed waveform uses the STRS infrastructure-provided application program interfaces (APIs) and services to load, verify, execute, change parameters, terminate, or unload an application. The project is divided in three main phases. 1)Design and Development of the GalileoGPS waveform for the SCaN Testbed starting from Qascom existing GNSS SDR receiver. The baseline design is limited to the implementation of the single frequency Galileo and GPS L1E1 receiver even if as part of the activity it will be to assess the feasibility of a dual frequency implementation (L1E1+L5E5a) in the same SDR platform.2)Qualification and test the GalileoGPS waveform using ground systems available at the NASA Glenn Research Center. Experimenters can have access to two SCaN Testbed ground based systems for development and verification: the Experimenter Development System (EDS) that is intended to provide initial opportunity for software testing and basic functional validation and the Ground Integration Unit (GIU) that is a high fidelity version of the SCaN Testbed flight system and is therefore used for more controlled final development testing and verification testing.3)Perform in-orbit validation and experimentation: The experimentation phase will consists on the collection of raw measurements (pseudorange, Carrier phase, CN0) in space, assessment on the quality of the measurements and the receiver performances in terms of signal acquisition, tracking, etc. Finally computation of positioning in space (Position, Velocity and time) and assessment of its performance.(Complete abstract in attached document).

GPS↗

NASA NTRS2016

Experimenting Galileo on Board the International Space Station

The SCaN Testbed is an advanced integrated communications system and laboratory facility installed on the International Space Station (ISS) in 2012. The testbed incorporates a set of new generation of Software Defined Radio (SDR) technologies intended to allow researchers to develop, test, and demonstrate new communications, networking, and navigation capabilities in the actual environment of space. Qascom, in cooperation with ESA and NASA, is designing a Software Defined Radio GalileoGPS Receiver capable to provide accurate positioning and timing to be installed on the ISS SCaN Testbed. The GalileoGPS waveform will be operated in the JPL SDR that is constituted by several hardware components that can be used for experimentations in L-Band and S-Band. The JPL SDR includes an L-Band Dorne Margolin antenna mounted onto a choke ring. The antenna is connected to a radio front end capable to provide one bit samples for the three GNSS frequencies (L1, L2 and L5) at 38 MHz, exploiting the subharmonic sampling. The baseband processing is then performed by an ATMEL AT697 processor (100 MIPS) and two Virtex 2 FPGAs. The JPL SDR supports the STRS (Space Telecommunications Radio System) that provides common waveform software interfaces, methods of instantiation, operation, and testing among different compliant hardware and software products. The standard foresees the development of applications that are modular, portable, reconfigurable, and reusable. The developed waveform uses the STRS infrastructure-provided application program interfaces (APIs) and services to load, verify, execute, change parameters, terminate, or unload an application. The project is divided in three main phases. 1)Design and Development of the GalileoGPS waveform for the SCaN Testbed starting from Qascom existing GNSS SDR receiver. The baseline design is limited to the implementation of the single frequency Galileo and GPS L1E1 receiver even if as part of the activity it will be to assess the feasibility of a dual frequency implementation (L1E1+L5E5a) in the same SDR platform.2)Qualification and test the GalileoGPS waveform using ground systems available at the NASA Glenn Research Center. Experimenters can have access to two SCaN Testbed ground based systems for development and verification: the Experimenter Development System (EDS) that is intended to provide initial opportunity for software testing and basic functional validation and the Ground Integration Unit (GIU) that is a high fidelity version of the SCaN Testbed flight system and is therefore used for more controlled final development testing and verification testing.3)Perform in-orbit validation and experimentation: The experimentation phase will consists on the collection of raw measurements (pseudorange, Carrier phase, CN0) in space, assessment on the quality of the measurements and the receiver performances in terms of signal acquisition, tracking, etc. Finally computation of positioning in space (Position, Velocity and time) and assessment of its performance.(Complete abstract in attached document).

Galileo↗

NASA NTRS2012

Flexible Architecture for FPGAs in Embedded Systems

Commonly, field-programmable gate arrays (FPGAs) being developed in cPCI embedded systems include the bus interface in the FPGA. This complicates the development because the interface is complicated and requires a lot of development time and FPGA resources. In addition, flight qualification requires a substantial amount of time be devoted to just this interface. Another complication of putting the cPCI interface into the FPGA being developed is that configuration information loaded into the device by the cPCI microprocessor is lost when a new bit file is loaded, requiring cumbersome operations to return the system to an operational state. Finally, SRAM-based FPGAs are typically programmed via specialized cables and software, with programming files being loaded either directly into the FPGA, or into PROM devices. This can be cumbersome when doing FPGA development in an embedded environment, and does not have an easy path to flight. Currently, FPGAs used in space applications are usually programmed via multiple space-qualified PROM devices that are physically large and require extra circuitry (typically including a separate one-time programmable FPGA) to enable them to be used for this application. This technology adds a cPCI interface device with a simple, flexible, high-performance backend interface supporting multiple backend FPGAs. It includes a mechanism for programming the FPGAs directly via the microprocessor in the embedded system, eliminating specialized hardware, software, and PROM devices and their associated circuitry. It has a direct path to flight, and no extra hardware and minimal software are required to support reprogramming in flight. The device added is currently a small FPGA, but an advantage of this technology is that the design of the device does not change, regardless of the application in which it is being used. This means that it needs to be qualified for flight only once, and is suitable for one-time programmable devices or an application specific integrated circuit (ASIC). An application programming interface (API) further reduces the development time needed to use the interface device in a system.

Clark, Duane I.↗

DOE OSTI2023

Working with Multiple MPIs: Overcoming ABI Incompatibility

Scientific applications rely on third-party libraries, which may have multiple implementations. While sharing an application programming interface (API), many of these implementations do not have a shared application binary interface (ABI) and require recompiling. Recompiling can be a long and complex process and sometimes not even an option when the application is shipped binary only. ABI incompatibility strikes at the heart of portability, productivity, and performance by (1) impeding application execution across different HPC and Cloud systems; (2) adding developer hours rebuilding an application; and (3) not taking advantage of host-optimized libraries. This tutorial teaches attendees a portable way to address ABI incompatibility in MPI using the Wi4MPI library. Wi4MPI translates the ABI dynamically from the MPI library used to build the application to a different MPI library available at run time. With Wi4MPI, HPC practitioners can break the portability barrier imposed by ABI incompatibility, potentially increase performance, and increase user productivity. The tutorial is broken down in three components: (1) Understanding ABI compatibility in MPI; (2) Translating MPI libraries dynamically; and (3) Applying dynamic translation to key use cases in HPC, including Containers. If you use more than one MPI library or supercomputer, this tutorial is for you.

97 MATHEMATICS AND COMPUTING↗

NASA NTRS1994

Coordinating complex decision support activities across distributed applications

Knowledge-based technologies have been applied successfully to automate planning and scheduling in many problem domains. Automation of decision support can be increased further by integrating task-specific applications with supporting database systems, and by coordinating interactions between such tools to facilitate collaborative activities. Unfortunately, the technical obstacles that must be overcome to achieve this vision of transparent, cooperative problem-solving are daunting. Intelligent decision support tools are typically developed for standalone use, rely on incompatible, task-specific representational models and application programming interfaces (API's), and run on heterogeneous computing platforms. Getting such applications to interact freely calls for platform independent capabilities for distributed communication, as well as tools for mapping information across disparate representations. Symbiotics is developing a layered set of software tools (called NetWorks! for integrating and coordinating heterogeneous distributed applications. he top layer of tools consists of an extensible set of generic, programmable coordination services. Developers access these services via high-level API's to implement the desired interactions between distributed applications.

Adler, Richard M.↗

NASA NTRS2003

Development of a Dynamically Configurable, Object-Oriented Framework for Distributed, Multi-modal Computational Aerospace Systems Simulation: Second Year Progress Report

Mesh generation has long been recognized as a bottleneck in the CFD process. While much research on automating the volume mesh generation process have been relatively successful,these methods rely on appropriate initial surface triangulation to work properly. Surface discretization has been one of the least automated steps in computational simulation due to its dependence on implicitly defined CAD surfaces and curves. Differences in CAD peometry engines manifest themselves in discrepancies in their interpretation of the same entities. This lack of "good" geometry causes significant problems for mesh generators, requiring users to "repair" the CAD geometry before mesh generation. The problem is exacerbated when CAD geometry is translated to other forms (e.g., IGES )which do not include important topological and construction information in addition to entity geometry. One technique to avoid these problems is to access the CAD geometry directly from the mesh generating software, rather than through files. By accessing the geometry model (not a discretized version) in its native environment, t h s a proach avoids translation to a format which can deplete the model of topological information. Our approach to enable models developed in the Denali software environment to directly access CAD geometry and functions is through an Application Programming Interface (API) known as CAPRI. CAPRI provides a layer of indirection through which CAD-specific data may be accessed by an application program using CAD-system neutral C and FORTRAN language function calls. CAPRI supports a general set of CAD operations such as truth testing, geometry construction and entity queries.

Afjeh, Abdollah A.↗

NASA NTRS2013

NASA Tech Briefs, June 2013

Topics include: Cloud Absorption Radiometer Autonomous Navigation System - CANS, Software Method for Computed Tomography Cylinder Data Unwrapping, Re-slicing, and Analysis, Discrete Data Qualification System and Method Comprising Noise Series Fault Detection, Simple Laser Communications Terminal for Downlink from Earth Orbit at Rates Exceeding 10 Gb/s, Application Program Interface for the Orion Aerodynamics Database, Hyperspectral Imager-Tracker, Web Application Software for Ground Operations Planning Database (GOPDb) Management, Software Defined Radio with Parallelized Software Architecture, Compact Radar Transceiver with Included Calibration, Software Defined Radio with Parallelized Software Architecture, Phase Change Material Thermal Power Generator, The Thermal Hogan - A Means of Surviving the Lunar Night, Micromachined Active Magnetic Regenerator for Low-Temperature Magnetic Coolers, Nano-Ceramic Coated Plastics, Preparation of a Bimetal Using Mechanical Alloying for Environmental or Industrial Use, Phase Change Material for Temperature Control of Imager or Sounder on GOES Type Satellites in GEO, Dual-Compartment Inflatable Suitlock, Modular Connector Keying Concept, Genesis Ultrapure Water Megasonic Wafer Spin Cleaner, Piezoelectrically Initiated Pyrotechnic Igniter, Folding Elastic Thermal Surface - FETS, Multi-Pass Quadrupole Mass Analyzer, Lunar Sulfur Capture System, Environmental Qualification of a Single-Crystal Silicon Mirror for Spaceflight Use, Planar Superconducting Millimeter-Wave/Terahertz Channelizing Filter, Qualification of UHF Antenna for Extreme Martian Thermal Environments, Ensemble Eclipse: A Process for Prefab Development Environment for the Ensemble Project, ISS Live!, Space Operations Learning Center (SOLC) iPhone/iPad Application, Software to Compare NPP HDF5 Data Files, Planetary Data Systems (PDS) Imaging Node Atlas II, Automatic Calibration of an Airborne Imaging System to an Inertial Navigation Unit, Translating MAPGEN to ASPEN for MER, Support Routines for In Situ Image Processing, and Semi-Supervised Eigenbasis Novelty Detection.

Source record↗

DOE OSTI2021

Accessing Microsoft Access Databases Using ODBC and RODBC

ODBC (Open Database Connectivity) is an industry-standard API (Application Program Interface) that provides a standard interface, based on SQL (Structured Query Language) between applications and databases. This insulates applications from specific details of different database management systems (DBMS). Microsoft Windows TM provides an implementation of ODBC, which, along with drivers for various databases, supports the API. Windows also provides a driver for Access databases.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2021

Building Performance Database API (BPD API) v2.1

The Building Performance Database (BPD) is the largest publicly-available source of measured energy performance data for buildings in the United States. It contains information about the building's energy use, location, and physical and operational characteristics. The BPD can be used by building owners, operators, architects and engineers to compare a building's energy efficiency against customized peer groups, identify energy efficiency opportunities, and set energy efficiency targets. It can also be used by energy efficiency program implementers and policymakers to analyze energy efficiency features and trends in the building stock. The BPD compiles data from various data sources, converts it into a standard format, cleanses and quality checks the data, and provides users with access to the data in a way that maintains anonymity for data providers. This software is the database and the Application Programming Interface (API). Users can utilize the BPD's data to develop their own applications using the API. Version 2.1 included a major update for multiple years of data and refactoring of code for faster queries.

Mathew, Paul↗

NASA NTRS2017

The HITRAN2016 Molecular Spectroscopic Database

This paper describes the contents of the 2016 edition of the HITRAN molecular spectroscopic compilation. The new edition replaces the previous HITRAN edition of 2012 and its updates during the intervening years. The HITRAN molecular absorption compilation is composed of five major components: the traditional line-by-line spectroscopic parameters required for high-resolution radiative-transfer codes, infrared absorption cross-sections for molecules not yet amenable to representation in a line-by-line form, collision-induced absorption data, aerosol indices of refraction, and general tables such as partition sums that apply globally to the data. The new HITRAN is greatly extended in terms of accuracy, spectral coverage, additional absorption phenomena, added line-shape formalisms, and validity. Moreover, molecules, isotopologues, and perturbing gases have been added that address the issues of atmospheres beyond the Earth. Of considerable note, experimental IR cross-sections for almost 300 additional molecules important in different areas of atmospheric science have been added to the database. The compilation can be accessed through www.hitran.org. Most of the HITRAN data have now been cast into an underlying relational database structure that offers many advantages over the long-standing sequential text-based structure. The new structure empowers the user in many ways. It enables the incorporation of an extended set of fundamental parameters per transition, sophisticated line-shape formalisms, easy user-defined output formats, and very convenient searching, filtering, and plotting of data. A powerful application programming interface making use of structured query language (SQL) features for higher-level applications of HITRAN is also provided.

HITRAN↗

NASA NTRSDate not supplied

RadLab: A Comprehensive Database and Graphical and Programming Interfaces for Biologically Relevant Space Radiation Data

RadLab, a new component of the NASA Open Science Data Repository (OSDR), is a platform built upon a database of radiation data relevant to space biology. RadLab provides visual and programmatic interfaces for interrogation of its database, as well as a submission process for inclusion of data from investigators. The RadLab application programming interface (API) implements a request syntax enabling users to retrieve data filtered by various combinations of parameters (detector type, location, direction, timespan, etc), which are delivered in machine-readable text formats, ready to be ingested by downstream analysis pipelines; while the graphical user interface (GUI) provides easy means to iteratively modify query parameters and incorporates a number of standard analyses and visualizations (time series plots, geospatial visualizations, detector comparison). Investigators from many countries, including US, Russia, Japan, Canada, the Czech Republic, Germany, Hungary, and Italy, have committed to provide data from their instruments located on the ISS; RadLab will also include data from other spacecraft in LEO (e.g., the Space Shuttle, the Mir space station), BLEO (e. g. BioSentinel, Mars Orbiter, among others), and on other celestial bodies (e. g. Chang’e 4, Curiosity). The first release of RadLab has been made available to the public. Once fully operational, RadLab will provide a comprehensive and ever-growing compendium of space radiation data, facilitating straightforward access to multiple types of readings and enabling space biology researchers to perform intercomparisons of detectors and to determine the radiation environment of research missions, both via programmatic retrieval of these data and via the graphical analysis toolkit; as well as a user-friendly submission portal for ingesting data from space agencies and research institutions. Radiation scientists will be able to use RadLab to gain a deeper understanding of the space radiation environment for future human space exploration. The RadLab Working Group has been formed to foster close collaborations among data contributors and users, to identify data sources, to put in place standards for data normalization, to guide the development of features of the analysis toolkit, to establish the use of RadLab in space radiation biology research, and eventually to provide a forum for discussing relevant research issues that can take advantage of RadLab's capabilities.

radiation↗

NASA NTRS1998

A Geometry Based Infra-Structure for Computational Analysis and Design

The computational steps traditionally taken for most engineering analysis suites (computational fluid dynamics (CFD), structural analysis, heat transfer and etc.) are: (1) Surface Generation -- usually by employing a Computer Assisted Design (CAD) system; (2) Grid Generation -- preparing the volume for the simulation; (3) Flow Solver -- producing the results at the specified operational point; (4) Post-processing Visualization -- interactively attempting to understand the results. For structural analysis, integrated systems can be obtained from a number of commercial vendors. These vendors couple directly to a number of CAD systems and are executed from within the CAD Graphical User Interface (GUI). It should be noted that the structural analysis problem is more tractable than CFD; there are fewer mesh topologies used and the grids are not as fine (this problem space does not have the length scaling issues of fluids). For CFD, these steps have worked well in the past for simple steady-state simulations at the expense of much user interaction. The data was transmitted between phases via files. In most cases, the output from a CAD system could go to Initial Graphics Exchange Specification (IGES) or Standard Exchange Program (STEP) files. The output from Grid Generators and Solvers do not really have standards though there are a couple of file formats that can be used for a subset of the gridding (i.e. PLOT3D data formats). The user would have to patch up the data or translate from one format to another to move to the next step. Sometimes this could take days. Specifically the problems with this procedure are:(1) File based -- Information flows from one step to the next via data files with formats specified for that procedure. File standards, when they exist, are wholly inadequate. For example, geometry from CAD systems (transmitted via IGES files) is defined as disjoint surfaces and curves (as well as masses of other information of no interest for the Grid Generator). This is particularly onerous for modern CAD systems based on solid modeling. The part was a proper solid and in the translation to IGES has lost this important characteristic. STEP is another standard for CAD data that exists and supports the concept of a solid. The problem with STEP is that a solid modeling geometry kernel is required to query and manipulate the data within this type of file. (2) 'Good' Geometry. A bottleneck in getting results from a solver is the construction of proper geometry to be fed to the grid generator. With 'good' geometry a grid can be constructed in tens of minutes (even with a complex configuration) using unstructured techniques. Adroit multi-block methods are not far behind. This means that a million node steady-state solution can be computed on the order of hours (using current high performance computers) starting from this 'good' geometry. Unfortunately, the geometry usually transmitted from the CAD system is not 'good' in the grid generator sense. The grid generator needs smooth closed solid geometry. It can take a week (or more) of interaction with the CAD output (sometimes by hand) before the process can begin. One way Communication. (3) One-way Communication -- All information travels on from one phase to the next. This makes procedures like node adaptation difficult when attempting to add or move nodes that sit on bounding surfaces (when the actual surface data has been lost after the grid generation phase). Until this process can be automated, more complex problems such as multi-disciplinary analysis or using the above procedure for design becomes prohibitive. There is also no way to easily deal with this system in a modular manner. One can only replace the grid generator, for example, if the software reads and writes the same files. Instead of the serial approach to analysis as described above, CAPRI takes a geometry centric approach. This makes the actual geometry (not a discretized version) accessible to all phases of the analysis. The connection to the geometry is made through an Application Programming Interface (API) and NOT a file system. This API isolates the top-level applications (grid generators, solvers and visualization components) from the geometry engine. Also this allows the replacement of one geometry kernel with another, without effecting these top-level applications. For example, if UniGraphics is used as the CAD package then Parasolid (UG's own geometry engine) can be used for all geometric queries so that no solid geometry information is lost in a translation. This is much better than STEP because when the data is queried, the same software is executed as used in the CAD system. Therefore, one analyzes the exact part that is in the CAD system. CAPRI uses the same idea as the commercial structural analysis codes but does not specify control. Software components of the CAD system are used, but the analysis suite, not the CAD operator, specifies the control of the software session. This also means that the license issues (may be) minimized and individuals need not have to know how to operate a CAD system in order to run the suite.

Haimes, Robert↗

DOE OSTI2020

STEPS: A Portable Numerical Simulation Toolkit for Electrical Power System Dynamic Studies

Numerical simulation is the key technique for large scale power system analysis. Redistribution of global renewable power via international interconnections requires new simulation tools to study the interconnected systems with different nominal frequencies as a whole. In this paper we introduce an open source simulation toolkit for electrical power systems (STEPS) which is hosted at Github. Its kernel is coded in C++ with major functions of power flow and electro-mechanical dynamic simulation. Flexible options are provided and configurable to improve power flow solution and dynamic simulation. Common devices and models are supported in STEPS for AC/DC hybrid system studies. Studies of interconnected systems with different nominal frequencies is supported in STEPS for research of international interconnection. Application program interfaces are provided and wrapped with Python to enable high-level interfaces for general applications. STEPS is thread safe and parallel computation is supported in both kernel and script levels to accelerate simulation. It is portable and works on Windows and GNU/Linux platforms. Cases from small to large scale systems are thoroughly tested to validate the toolkit with commercial packages as benchmarks.

42 ENGINEERING↗

NASA NTRSDate not supplied

POST Explorer: A Design Space Exploration Tool for POST2

Recent improvements for the Program to Optimize Simulated Trajectories II (POST2) have included the development of an application programming interface (API). This API allows POST2 simulation inputs to be directly manipulated from other applications (such as MATLAB or Python), and the outputs from POST2 are streamed directly to the external application that enables visualization, data manipulation, etc. Through this framework, a new tool called POST Explorer is being developed that provides a user the capability to modify the simulation inputs and interrogate the outputs within the same application, with raw data inspection and visualization embedded. This tool can be leveraged for multiple types of analyses, such as parametric sweeps and sensitivity studies, and will be available with a future release of the POST2 software.

Robert Anthony Williams↗

NASA NTRSDate not supplied

POST Explorer: A Design Space Exploration Tool for POST2

Recent improvements for the Program to Optimize Simulated Trajectories II (POST2) have included the development of an application programming interface (API). This API allows POST2 simulation inputs to be directly manipulated from other applications (such as MATLAB or Python), and the outputs from POST2 are streamed directly to the external application that enables visualization, data manipulation, etc. Through this framework, a new tool called POST Explorer is being developed that provides a user the capability to modify the simulation inputs and interrogate the outputs within the same application, with raw data inspection and visualization embedded. This tool can be leveraged for multiple types of analyses, such as parametric sweeps and sensitivity studies, and will be available with a future release of the POST2 software.

Anthony Williams↗

DOE OSTI2020

Refreshing Waste Tracking Software for the 2020's - 20059

The Waste Compliance and Tracking System (WCATS) is a software application designed to manage waste operations from cradle to grave. The system provides the support needed for characterization, generation, processing, and shipment of all waste generated or stored at Los Alamos National Laboratory (LANL). Waste is tracked with task records for containers in real-time via both desktop and mobile device applications. The software allows application administrators to configure sites with appropriate limits for Pu-239 equivalent Curies (PE-Ci), fissile gram equivalents (FGEs), volume limits, as well as custom limits for site-specific technical safety requirements (TSRs). WCATS was developed based on a need at Los Alamos National Laboratory for a modern, customizable waste tracking system that could support many different waste types. The application is built using Oracle{sup R} database and Oracle{sup R} ADF Swing application framework. The technologies and software frameworks selected for the system were finalized in 2006. Although Oracle{sup R} Database has proven to be robust, the user interface and application framework interface with the database have been deprecated and need to be replaced. The technologies selected for modernization follow the open-source model, which allows the WCATS team to more easily recruit developers, improve the speed of development, and ease the deployment and adoption of the system. The tools that support the re-engineering effort are Vue.js{sup R}, a JavaScript{sup R} framework, and Spring Boot{sup R}, an API (application programming interface) development tool written in Java{sup R}. An API allows for simplified communication from the database to the user interface of the application. In addition, legacy Crystal Reports{sup R} will be replaced with reports developed with the open source Pentaho{sup TM}f Report Designer community edition. Because the application uses HTML and JavaScript{sup R}, it builds upon tools that have been used for many years in web development. These tools have large community support and their proven track record will ensure that enhancements to WCATS can continue for years to come. (authors)

12 MANAGEMENT OF RADIOACTIVE AND NON-RADIOACTIVE W↗