Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Postgres”

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.

Fascinating Reporting with Postgres psql and sendmail

Among many things, psql, the Postgres command line tool, can create decent output to share with coworkers and customers, and that is where many Postgres users stop. The extreme limits of psql's formatting will be explored, delving into Unicode and HTML reports and the backslash/meta commands. Pretty reports are useless unless good data can be reported. The past and current developers of Postgres have packed a wonderful set functionality into the query language such as array aggregation and un-nesting. The staggering usefulness of "DISTINCT ON ()" will also be shown (without stepping into the quagmire of window functions). Environmentally conscious developers don't want to dump endless reports onto paper, so the power of psql is paired with the power of the UNIX/Linux sendmail command to generate electronic reports to send to coworkers and customers. The icing on the cake will be an example set of simple database tables to manage recipients of an automated reporting system.

97 MATHEMATICS AND COMPUTING↗

The implementation of POSTGRES

The design and implementation decisions made for the three-dimensional data manager POSTGRES are discussed. Attention is restricted to the DBMS backend functions. The POSTGRES data model and query language, the rules system, the storage system, the POSTGRES implementation, and the current status and performance are discussed.

Stonebraker, Michael↗

ARM Data Integrator

The Atmospheric Radiation Measurement (ARM) Data Integrator (ADI) streamlines the development of scientific algorithms and analysis of time-series NetCDF data, and improves the content and consistency of the output data products produced by these algorithms. The framework automates the process of retrieving and preparing data for analysis, and allows users to design output data products through a graphical interface. It also provides a modular, flexible software development architecture that scientists can use to generate C, Python, and IDL source code templates that embed the pre and post processing logic allowing the scientist to focus on only their science. The input data, preprocessing, and output data specifications of algorithms are defined through a graphical interface and stored in a database. ADI implements workflow for data integration and supports user access to data through a library of software modules. Data preprocess capabilities supported include automated retrieval of data from input files, merging the retrieved data into appropriately sized chunks, and transformation of the data onto a common coordinate system grid. Through the graphical interface, users can view the details of both their data products and those in the ARM catalog and allows developers to use existing data product to build new data products. Views of the output data products include an overlay of how the design meets ARM archive's data standards providing the user with a visual cue indicating where their output violates an archive standard. The ADI libraries access the information provided through the GUI via a Postgres database. The ADI framework and its supporting components can significantly decrease the time and cost of implementing scientific algorithms while improving the ability of scientists to disseminate their results.

Source record↗

dbprocessing

dbprocessing is a python framework for automating data processing pipelines. The dbprocessing package uses a configuration file to define the input, intermediate, and output data products for a particular data type as well as the processes that connect those data products. In addition, dbprocessing uses python scripts called inspectors to determine if a particular file matches a configured data product. If a particular data product is found, it is ingested into the dbprocessing database (sqlite3 or postgres) which then triggers all of the chained processes to the final data product. While the framework is written in python, it can run software in any language but may require a “wrapper” to translate the dbprocessing command line arguments to the form expected by the software.

Walker, Andrew↗

Soda Pop: A Time-Series Clustering, Alarming and Disease Forecasting Application

To introduce Soda Pop, an R/Shiny application designed to be a disease agnostic time-series clustering, alarming, and forecasting tool to assist in disease surveillance “triage, analysis and reporting” workflows within the Biosurveillance Ecosystem (BSVE). In this poster, we highlight the new capabilities that are brought to the BSVE by Soda Pop with an emphasis on the impact of methodological decisions. The Biosurveillance Ecosystem (BSVE) is a biological and chemical threat surveillance system sponsored by the Defense Threat Reduction Agency (DTRA). BSVE is intended to be user-friendly, multi-agency, cooperative, modular and threat agnostic platform for biosurveillance. In BSVE, a web-based workbench presents the analyst with applications (apps) developed by various DTRA funded researchers, which are deployed on-demand in the cloud(e.g., Amazon Web Services). These apps aim to address emerging needs and refine capabilities to enable early warning of chemical and biological threats for multiple users across local, state, and federal agencies. Soda Pop is an app developed by Pacific Northwest National Laboratory (PNNL) to meet the current needs of the BSVE for early warning and detection of disease outbreaks. Aimed for use bya diverse set of analysts, the application is agnostic to data source and spatial scale enabling it to be generalizable across many diseases and locations. To achieve this, we placed a particular emphasis on clustering and alerting of disease signals within Soda Pop without strong prior assumptions on the nature of observed diseased counts. Although designed to be agnostic to the data source, Soda Pop was initially developed and tested on data summarizing Influenza-Like Illness in military hospitals from collaboration with the Armed Forces Health Surveillance Branch. Currently, the data incorporated also includes the CDC’s National Notifiable Diseases Surveillance System(NNDSS) tables and the WHO’s Influenza A/B Influenza Data(Flunet). These data sources are now present in BSVE’s Postgres data storage for direct access. Soda Pop is designed to automate time-series tasks of data summarization, exploration, clustering, alarming and forecasting. Built as an R/Shiny application, Soda Pop is founded on the powerful statistical tool R.. Where applicable, Soda Pop facilitates nonparametric seasonal decomposition of time-series; hierarchical agglomerative clustering across reporting areas and between diseases within reporting areas; and a variety of alarming techniques including Exponential Weighted Moving Average alarms and Early Aberration Detection. Soda Pop embeds these techniques within a user-interface designed to enhance an analyst’s understanding of emerging trends in their data and enables the inclusion of its graphical elements into their dossier for further tracking and reporting. The ultimate goal of this software is to facilitate the discovery of unknown disease signals along with increasing the speed of detection of unusual patterns within these signals. Soda Pop organizes common statistical disease surveillance tasks in a manner integrated with BSVE data source inputs and outputs. The app analyzes time-series disease data and supports a robust set of clustering and alarming routines that avoid strong assumptions on the nature of observed disease counts. This attribute allows for flexibility in the data source, spatial scale, and disease types making it useful to a wide range of analysts.

97 MATHEMATICS AND COMPUTING↗

XBoard: A Framework for Integrating and Enhancing Collaborative Work Practices

Teams typically collaborate in different modes including face-to-face meetings, meetings that are synchronous (i. e. require parties to participate at the same time) but distributed geographically, and meetings involving asynchronously working on common tasks at different times. The XBoard platform was designed to create an integrated environment for creating applications that enhance collaborative work practices. Specifically, it takes large, touch-screen enabled displays as the starting point for enhancing face-to-face meetings by providing common facilities such as whiteboarding/electronic flipcharts, laptop projection, web access, screen capture and content distribution. These capabilities are built upon by making these functions inherently distributed by allowing these sessions to be easily connected between two or more systems at different locations. Finally, an information repository is integrated into the functionality to provide facilities for work practices that involve work being done at different times, such as reports that span different shifts. The Board is designed to be extendible allowing customization of both the general functionality and by adding new functionality to the core facilities by means of a plugin architecture. This, in essence, makes it a collaborative framework for extending or integrating work practices for different mission scenarios. XBoard relies heavily on standards such as Web Services and SVG, and is built using predominately Java and well-known open-source products such as Apache and Postgres. Increasingly, organizations are geographically dispersed, and rely on "virtual teams" that are assembled from a pool of various partner organizations. These organizations often have different infrastructures of applications and workflows. The XBoard has been designed to be a good partner in these situations, providing the flexibility to integrate with typical legacy applications while providing a standards-based infrastructure that is readily accepted by most organizations. The XBoard has been used on the Mars Exploration Rovers mission at JPL, and is currently being used or considered for use in pilot projects at Johnson Space Center (JSC) Mission Control, the University of Arizona Lunar and Planetav Laboratory (Phoenix Mars Lander), and MBART (Monterey Bay Aquarium Research Institute).

Shab, Ted↗

ARM Data Integrator

The Atmospheric Radiation Measurement (ARM) Data Integrator (ADI) streamlines the development of scientific algorithms and analysis of time-series NetCDF data, and improves the content and consistency of the output data products produced by these algorithms. The framework automates the process of retrieving and preparing data for analysis, and allows users to design output data products through a graphical interface. It also provides a modular, flexible software development architecture that scientists can use to generate C, Python, and IDL source code templates that embed the pre and post processing logic allowing the scientist to focus on only their science. The input data, preprocessing, and output data specifications of algorithms are defined through a graphical interface and stored in a database. ADI implements workflow for data integration and supports user access to data through a library of software modules. Data preprocess capabilities supported include automated retrieval of data from input files, merging the retrieved data into appropriately sized chunks, and transformation of the data onto a common coordinate system grid. Through the graphical interface, users can view the details of both their data products and those in the ARM catalog and allows developers to use existing data product to build new data products. Views of the output data products include an overlay of how the design meets ARM archive's data standards providing the user with a visual cue indicating where their output violates an archive standard. The ADI libraries access the information provided through the GUI via a Postgres database. The ADI framework and its supporting components can significantly decrease the time and cost of implementing scientific algorithms while improving the ability of scientists to disseminate their results.

Source record↗

Conquering Data Chaos: Research Data Management with Kubernetes

Managing massive volumes of data and effectively making it accessible to researchers poses significant challenges and is a barrier to scientific discovery. In many cases, critical data is locked up in unwieldy file formats or one-off databases and is too large to effectively process on a single machine. This talk explores the role of Kubernetes, an open-source container orchestration platform, in addressing research data management challenges. I will discuss how we are using a set of publicly available open-source and home-grown tools in the National Renewable Energy Lab (NREL) Data, Analysis, and Visualization (DAV) group to help researchers overcome data-related bottlenecks. The talk will begin by providing an overview of the data challenges faced in research data management, including data storage, processing, and analysis. I will highlight Kubernetes' ability to handle large-scale data by leveraging containerization and distributed computing, including distributed storage. Kubernetes allows researchers to encapsulate data processing infrastructure and workflows into portable containers, enabling reproducibility and ease of deployment. Kubernetes can then schedule and manage the resource allocation of these containers to enable efficient utilization of limited computing resources, leading to more efficient data processing and analysis. I will discuss some limitations of traditional, siloed approaches to dealing with data and emphasize the need for solutions which foster collaboration. I will highlight how we are using Kubernetes at NREL to facilitate data sharing and cooperation among research teams. Kubernetes' flexible architecture enables the deployment of shared computing environments, such as Apache Superset, where researchers can seamlessly access and analyze shared datasets. Providing the ability to have one research team easily consume data generated by another, utilizing Kubernetes' as a central data platform, is one of the major wins we've encountered by adopting the platform. Finally, I will showcase real-world use cases from NREL where we have used Kubernetes to solve some persistent data challenges involving large volumes of sensor and monitoring data. I will discuss the challenges we encountered when creating our cluster and making it available as a production-ready resource. I will also discuss the specific suite of tools, including Postgres and Apache Druid for columnar and timeseries data, and Redpanda Kafka for streaming data we have deployed in our infrastructure, and the process that went into the selection of these tools.

collaborative environment↗

Fuser and Fuser in the Cloud

The ˜Fuser' is the name of the SWIM data integration service that has been built, utilized and evolved on ATD-2 to synchronize trajectory predictions from multiple decision support tools. NASA is researching ways to make this data stream available for broader consumption as an example implementation that would help reduce the burden for consumers while enabling access to data that would help industry prepare and innovate for TFDM (e.g. integrates TTP feed).

Fuser↗