Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “big format module”

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.

Leveling-Up for Big-Format Modules

Like Mario grabbing a super mushroom, PV modules just keep getting bigger! As they grow, so do the challenges of handling, installing, and testing them in the field. At NREL, we've embarked on our own New Hope - adapting to this size revolution across our tools, transportation, ergonomics, and field compatibility. Join us as we navigate this galactic expansion and keep PV testing at the cutting edge.

14 SOLAR ENERGY↗

Database Management Module Framework for Dynamic Contingency Analysis and Visualization

The Dynamic Contingency Analysis Tool (DCAT) is being developed to mimic the response of generation dynamics, protection, and load components to extreme contingencies in power systems. Currently, DCAT generates a huge data set, with the analysis results stored in multiple subfolders using a great many files in different formats (power flow cases, time series, figures, spreadsheets). To help power system engineers thoroughly understand and analyze system behavior under many scenarios and contingencies, we developed a database management module (DBM) that enables future integration of DCAT with industry-grade Big Data analytical and interactive visualization platforms. In this paper, we demonstrate the DBM framework with interactive analytics and visualization for DCAT on the synthetic South Carolina 500-bus power system model using hurricane contingencies that capture possibilities for an extreme contingency. DCAT’s advanced data management and interactive visualization can help planning engineers to visually explore and analyze system behavior, all in one view.

Cascading, dynamic simulations, database managemen↗

Aerojet - Attitude Control Engines

All the engines were both qualification and acceptance tested at Marquardt s facilities. After we won the Apollo Program contract, we went off and built two vacuum test facilities, which simulated altitude continuous firing for as long as we wanted to run an engine. They would run days and days with the same capability we had on steam ejection. We did all of the testing in both for the qualification and the acceptance test. One of them was a large ball, which was an eighteen-foot diameter sphere, evacuated again with a big steam ejector system that could be used for system testing; that s where we did the Lunar Excursion Module testing. We put the whole cluster in there and tested the entire cluster at the simulated altitude conditions. The lowest altitude we tested at - typically an acceptance test - was 105,000 feet simulated altitude. The big ball - because people were interested in what they called goop formation, which is an unburned hydrazine product migrating to cold surfaces on different parts of spacecraft - was built to address those kinds of issues. We ran long-life tests in a simulated space environment with the entire inside of the test cell around the test article, liquid nitrogen cooled, so it could act as getter for any of the exhaust products. That particular facility could pull down to about 350,000 feet (atmosphere) equivalent altitude, which was pushing pretty close to the thermodynamic triple point of the MMH. It was a good test facility. Those facilities are no longer there. When the guys at Marquardt sold the company to what eventually became part of Aerojet, all those test facilities were cut off at the roots. I think they have a movie studio there at this point. That part of it is truly not recoverable, but it did some excellent high-altitude, space-equivalent testing at the time. Surprisingly, we had very few problems while testing in the San Fernando Valley. In the early 1960s, nobody had ever seen dinitrogen tetroxide (N2O4), so that wasn't too big a deal. We really did only make small, red clouds. In all the hundreds of thousands of tests and probably well over one million firings that I was around that place for, in all that thirty-something years, we had a total of one serious injury associated with rocket engine testing and propellants. Because we were trying to figure out what propellants would really be good, we tried all of the fun stuff like the carbon tetrafluoride, chlorine pentafluoride, and pure fluorine. The materials knowledge wasn't all that great at the time. On one test, the fluorine we had didn't react well with the copper they were using for tubing, and it managed to cause another unscheduled disassembly of the facility. It was very serious. It's like one of those Korean War stories. The technician happened to be walking past the test facility when it decided to blow itself up. A piece of copper tubing pierced one cheek and came out the other. That was the only serious accident in all of the engines handled in all those years. Now, we did have a problem with the EPA later because they figured out what the brown clouds were about. We built a whole bunch of exhaust mitigation scrubbers to take care of engine testing in the daytime. In general, we operated the big shuttle (RCS) engine, the 870- pounder at nominal conditions; they scrubbed the effluents pretty well. If you operated that same 870-pound force engine at a level where you get a lot of excess oxidizer, yeah, there s a brown cloud. But, you know, it doesn't show up well in the dark. They did do some of that. But, that s gone; it was addressed one way or another. RELEASED -

Pfeifer, Gerald R.↗

Big Data Framework with Machine Learning for D and D Applications - 19108

The nuclear industry is experiencing a steady increase in maintenance costs even though plants are maintained under high levels of safety, capability and reliability. Nuclear power plants are expected to run every unit at maximum capacity at all times, efficiently utilizing assets with minimal downtime. Surveillance and maintenance of nuclear decommissioning infrastructure provides lot challenges with respect to maintenance or decommissioning of the buildings. There is a need for a framework to analyze the huge amount of data generated by the sensors on the nuclear reactor components as well as structures, to monitor the conditions of these building over a period of time. Emerging technologies such as big data analytics have become a requirement in the nuclear industry to improve structural health monitoring and diagnostics. FIU will make use of existing mature technologies in the areas of imaging, robotics, big data, and machine learning/deep learning to assess the structural integrity of aging facilities at DOE sites. As these facilities await decommissioning, there is a need to understand the structural health of these structures. Many of these facilities were built over 50 years ago and in some cases these facilities have gone beyond the operational life expectancy. In other cases, the facilities have been placed in a state of 'cold and dark' and they are sitting unused, awaiting decommissioning. Finally, some older facilities are one-of-a-kind operational/production facilities supporting critical DOE missions and cannot be shut down. In any of these scenarios, the structural integrity of these facilities may be compromised, so it is imperative that adequate inspections and data collection/analysis be performed on a continuous and ongoing basis. The primary goals of the research include collecting various formats of data such as structured, unstructured and streaming data from the various sensors deployed in buildings, collect videos/pictures from various imaging sources, ingest them using a Hadoop distributed file system and process the data using Spark to perform batch processing and real time analytics. Research and development on various machine learning/deep learning algorithms will also be performed to analyze the heterogeneous data collected from nuclear decommission infrastructure. FIU will design the big data framework to ingest, store and process huge amounts of heterogeneous data collected from many sources and optimize the algorithms to provide insights into the data and predict anomalies observed when compared against baseline conditions. Various modules of this framework will include heterogeneous data sources, message broker, Hadoop distributed file system, Spark for stream and batch processing, machine learning/ deep learning, Cassandra - persistent data store and visualization. (authors)

12 MANAGEMENT OF RADIOACTIVE AND NON-RADIOACTIVE W↗

A network of soil moisture, soil temperature, air temperature, net radiation, ground heat flux and ground water for Chicago, Illinois

This dataset contains environmental monitoring data collected using solar-powered Multi-Function Research (MFR) Long Range Wide Area (LoRaWAN)-enabled nodes at 11 sites in Chicago, Illinois, as part of the DOE Urban Integrated Field Lab CROCUS project. The MFR node system consists of an Input/Output Digital Input Module (IB8) interface box (ICT International) providing wired connections for environmental sensors and an MFR-Node-L data logger that manages power, data processing, and LoRaWAN communication. The wireless data are ingested via Sage network (https://sagecontinuum.org/) nodes that contain LoRaWAN antennae. Measurements were collected from 11 MFR nodes deployed across Chicago State University (CSU), Northeastern Illinois University (NEIU), Northwestern University (NU), University of Illinois Chicago (UIC), West Woodlawn "Blacks in Green" (BIG), and Indian Boundary Prairies (IBP). Each MFR node supports a consistent suite of sensors measuring atmospheric, soil, and hydrological variables. Atmospheric measurements include 2m air temperature (°C), 2m vapor pressure deficit (kPa), and 2m shortwave/longwave radiation (incoming and outgoing, W/m²) measured using ATH-VPD and Apogee SN500 sensors. Soil measurements include volumetric water content (VWC, %) and temperature (°C) at four depths (15, 30, 45, and 60 cm below surface) using Meter Teros54 sensors, and heat flux (W/m²) at 10 cm depth using Huske HFP01-05 sensors. At selected locations, Meter Hydros21 sensors measure groundwater depth (mm), specific conductivity (dS/m), and temperature (°C). The dataset includes timestamps, site identifiers with location names, device IDs, Global Positioning System (GPS) coordinates, variable names with units, measurement depths, values, sensor names, and Sage node identifiers. All timestamps are in local Chicago time (CDT/CST). Quality control flags are provided using a 6-bit binary system indicating physical range violations, step spikes, 24-hour flat-line conditions, 6-hour jitter, 7-day ultra-low variance, and persistent high offset. Data is provided in CSV and CF-compliant NetCDF formats. This dataset is part of a larger collection of CROCUS environmental monitoring data, including linked datasets from Air Quality Transmitter (AQT) sensors, Weather Transmitter (WXT) sensors, and Sap Flow Meter (SFM1x) sensors.

Chicago↗