SEARCH · Engineering Papers
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.
This presentation serves as the peer review requirement for FCIC Task X. It covers structure, approach, impact, and accomplishments. The project will be scored by a peer review panel based on the presentation.
The Department of Homeland Security (DHS) Science and Technology Directorate (S&T) is partnering with Pacific Northwest National Laboratory (PNNL) to execute the Emergency Management (EM) of Tomorrow Research (EMOTR) program to identify current EM research, elicit capability needs from EM practitioners, and identify where technology, such as artificial intelligence (AI), may benefit the future of EM and emergency operations centers. This report details the methodology, analysis, and insights of interviews and focus groups conducted as part of the task to elicit stakeholder input.
Enchant Energy, L.L.C. (Enchant) was selected to conduct a Front-End Engineering Design study (FEED) for the addition of a full-scale carbon capture system to remove carbon dioxide from the flue gas emissions of the two coal-fired generating units (total of 847 MW net) at San Juan Generating Station (SJGS), using Mitsubishi Heavy Industries Americas (MHIA) KM CDR Process™. Sargent & Lundy LLC (S&L) was selected as the primary technical lead, and along with various other organizations, were able to support Enchant’s completion of the following FEED tasks: Task 1 – Project Management & Planning; Task 2 – FEED Study; Task 3 - Final FEED Study Package. The FEED study period was between October 15, 2019 to September 30, 2022.
Weightless containerless processing for space, electromagnetic position control, force measurements and techniques, and hydrodynamics
Melting and handling of molten material in weightless space environment
Missions to be performed, station operations and functions to be carried out, and technologies anticipated during the time frame of the space station were examined in order to determine the scope of the overall information management system for the space station. This system comprises: (1) the data management system which includes onboard computer related hardware and software required to assume and exercise control of all activities performed on the station; (2) the communication system for both internal and external communications; and (3) the ground segment. Techniques used to examine the information system from a functional and performance point of view are described as well as the analyses performed to derive the architecture of both the onboard data management system and the system for internal and external communications. These architectures are then used to generate a conceptual design of the onboard elements in order to determine the physical parameters (size/weight/power) of the hardware and software. The ground segment elements are summarized.
Abstract: The worth of completing parallel tasks is modeled using utility functions, which monotonically-decrease with time and represent the importance and urgency of a task. These functions define the utility earned by a task at the time of its completion. The performance of such a system is measured as the total utility earned by all completed tasks over some interval of time (e.g., 24 hours). To maximize system performance when scheduling dynamically arriving parallel tasks onto a high performance computing (HPC) system that is oversubscribed and energy-constrained, we have designed, analyzed, and compared different heuristic techniques. Four utility-aware heuristics (i.e., Max Utility, Max Utility-per-Time, Max Utility-per-Resource, and Max Utility-per-Energy), three FCFS-based heuristics (Conservative Backfilling, EASY Backfilling, and FCFS with Multiple Queues), and a Random heuristic were examined in this study. A technique that is often used with the FCFS-based heuristics is the concept of a permanent reservation. We compare the performance of permanent reservations with temporary place-holders to demonstrate the advantages that place-holders can provide. We also present a novel energy filtering technique that constrains the maximum energy-per-resource used by each task. We conducted a simulation study to evaluate the performance of these heuristics and techniques in an energy-constrained oversubscribed HPC environment. With place-holders, energy filtering, and dropping tasks with low potential utility, our utility-aware heuristics are able to significantly outperform the existing FCFS-based techniques.
Abstract not provided.
The International Space Station (ISS) Management and Cost Evaluation Task Force (IMCE) was chartered to conduct an independent external review and assessment of the ISS cost, budget, and management. In addition, the Task Force was asked to provide recommendations that could provide maximum benefit to the U.S. taxpayers and the International Partners within the President's budget request. The Task Force has made the following principal findings: (1) The ISS Program's technical achievements to date, as represented by on-orbit capability, are extraordinary; (2) The Existing ISS Program Plan for executing the FY 02-06 budget is not credible; (3) The existing deficiencies in management structure, institutional culture, cost estimating, and program control must be acknowledged and corrected for the Program to move forward in a credible fashion; (4) Additional budget flexibility, from within the Office of Space Flight (OSF) must be provided for a credible core complete program; (5) The research support program is proceeding assuming the budget that was in place before the FY02 budget runout reduction of $1B; (6) There are opportunities to maximize research on the core station program with modest cost impact; (7) The U.S. Core Complete configuration (three person crew) as an end-state will not achieve the unique research potential of the ISS; (8) The cost estimates for the U.S.-funded enhancement options (e.g., permanent seven person crew) are not sufficiently developed to assess credibility. After these findings, the Task Force has formulated several primary recommendations which are published here and include: (1) Major changes must be made in how the ISS program is managed; (2) Additional cost reductions are required within the baseline program; (3) Additional funds must be identified and applied from the Human Space Flight budget; (4) A clearly defined program with a credible end-state, agreed to by all stakeholders, must be developed and implemented.
IPG Execution Service is a framework that reliably executes complex jobs on a computational grid, and is part of the IPG service architecture designed to support location-independent computing. The new grid service enables users to describe the platform on which they need a job to run, which allows the service to locate the desired platform, configure it for the required application, and execute the job. After a job is submitted, users can monitor it through periodic notifications, or through queries. Each job consists of a set of tasks that performs actions such as executing applications and managing data. Each task is executed based on a starting condition that is an expression of the states of other tasks. This formulation allows tasks to be executed in parallel, and also allows a user to specify tasks to execute when other tasks succeed, fail, or are canceled. The two core components of the Execution Service are the Task Database, which stores tasks that have been submitted for execution, and the Task Manager, which executes tasks in the proper order, based on the user-specified starting conditions, and avoids overloading local and remote resources while executing tasks.
The XPRESS project is the research and development of a complete software architecture for Exascale computing. The four major R&D thrusts include: 1) an Exascale lightweight kernel operating system (LXK), based on the Kitten operating system (OS), to manage billion way hardware parallelism, management of faults and power, management of global virtual name space, and other features of future system architectures; 2) a runtime system (HPX-5), co-designed with LXK, based on the ParalleX execution model that supports dynamic resource management and task scheduling; 3) system interfaces for interoperability between the runtime system and both the OS and the runtime system (RIOS); 4) compilation strategies and systems to translate MPI and OpenMP legacy codes to a form that can be run with performance at least as good as a native code implementation. The software architecture development has been driven by performance evaluation of mini-applications developed at Department of Energy Co-Design Centers as well as ancillary in-house developed applications and benchmarks. Research on the ParalleX execution model has been driven by the development of formal semantics and model checkers for the execution model. The major components of the software architecture are: ParalleX execution model – guiding principles for co-design of components of the system stack with advances in locality management and task prioritization through introspection; HPX runtime system – support of application dynamic adaptive resource management, task scheduling, and introspective control policies; LXK operating system – lightweight kernel operating system for order-constant scalability and low/no noise to manage resources; RIOS – a realm of Exascale system operation unique in the XPRESS project that includes the relationship between the new generation of lightweight kernel operating systems and runtime system software; XPI advanced programming model – intermediate form and low-level (readable) programming interface reflecting the ParalleX model, providing a target for source-to- source high level parallel language translation, and supporting early direct programming experimentation and measurement; Performance models & metrics – providing parameters and their mutual sensitivities to guide co-design and quantify operational behavior; Legacy migration – ensuring seamless transition of legacy codes and programming methods to the future generation of ParalleX-based Exascale systems; . Experiments and evaluation – critical to determining degree of effectiveness and likelihood of ultimate success as well as guiding corrective design changes to achieve DOE objectives; and Applications – collaborations with Co-Design Centers and other mission critical codes. The exemplar implementation of the ParalleX execution model, HPX-5, has been released along with five fully ported applications (LULESH, HPCG, SSSP, WAMR, and DASHMM) and multiple microbenchmarks. Using these applications, the system architecture demonstrated dynamic load balancing through active migration, legacy code migration, and data-driven approaches to for graph-like applications. Crucially for Exascale and billion way parallelism, the needs and patterns of irregular applications in HPX-5 were addressed using local flow control rather than relying on globally synchronized data structures.
This technical report is provided to US Department of Energy for progress made on the AGGERGATE project led by the Washington State University. This report is specifically related to the deliverable: ’D6: Technical report discussing the viability of the developed data-driven models and co-simulation architecture for models for operation in a real-world operational setting and the results of Tasks 1 to 8, summarizing the project findings and accomplishments to date’.
The HPC software ecosystem is growing larger and more complex, but software distribution mechanisms have not kept up with this trend. Tools, Libraries, and applications need to run on multiple platforms and build with multiple compliers. Increasingly, packages leverage common software components, and building any one component requires building all of its dependencies. In HPC environments, ABI-incompatible interfaces (likeMPI), binary-incompatible compilers, and cross-compiled environments converge to make the build process a combinatoric nightmare. This obstacle deters many users from adopting useful tools, and others waste countless hours building and rebuilding tools. Many package managers exist to solve these problems for typical desktop environments, but none suits the unique needs of supercomputing facilities or users. To address these problems, we have Spack, a package manager that eases the task of managing software for end-users, across multiple platforms, package versions, compilers, and ABI incompatibilities.
This briefing was presented during the Test Site Kick Off Meeting to discuss the contract awards for Task 1 and Task 2. This briefing covered a high level overview for contract deliverables, Task 1 - UAS Traffic Management and Task 2, Live Virtual Constructive Distributed Environment.
This report provides progress update for the development of a outage management, feeder restoration, and restoration action feasibility check modules as part of the AGGREGATE project. Details for integration with controllability module, data driven situational awareness of network and distributed energy resources as well cyber security plan for these modules integrated with GE ADMS are also presented in the report. These three modules for outage management, feeder restoration, and restoration action feasibility check modules are developed in MATLAB and validated with a modified IEEE 123-node feeder. Results demonstrate ability of these new modules to improve the restoration process post-disaster to enhance the system resilience.
The project currently is composed of six specific tasks – three research tasks, two outreach and training tasks, and one project management and communications task. Task 1 addresses project management and communication. Research activities focused on Task 2 (Describe and Quantify the Economic Impacts and Implications of the Development and Deployment of Coal-to-Liquid Facilities in China), Task 3 (Development of Alternative Coal Gasification Database), and Task 4 (Geologic Carbon Management Options). There also were significant activities related to Task 5 (US-China Communication, Collaboration, and Training on Clean Coal Technologies) as well as planning activity performed in support of Task 6 (Training Programs).
Systems, apparatuses, and methods for performing temperature-aware task scheduling and proactive power management. A SoC includes a plurality of processing units and a task queue storing pending tasks. The SoC calculates a thermal metric for each pending task to predict an amount of heat the pending task will generate. The SoC also determines a thermal gradient for each processing unit to predict a rate at which the processing unit's temperature will change when executing a task. The SoC also monitors a thermal margin of how far each processing unit is from reaching its thermal limit. The SoC minimizes non-uniform heat generation on the SoC by scheduling pending tasks from the task queue to the processing units based on the thermal metrics for the pending tasks, the thermal gradients of each processing unit, and the thermal margin available on each processing unit.
Operators can be poor monitors of automation if they are engaged concurrently in other tasks. However, in previous studies of this phenomenon the automated task was always presented in the periphery, away from the primary manual tasks that were centrally displayed. In this study we examined whether centrally locating an automated task would boost monitoring performance during a flight-simulation task consisting of system monitoring, tracking and fuel resource management sub-tasks. Twelve nonpilot subjects were required to perform the tracking and fuel management tasks manually while watching the automated system monitoring task for occasional failures. The automation reliability was constant at 87.5% for six subjects and variable (alternating between 87.5% and 56.25%) for the other six subjects. Each subject completed four 30 min sessions over a period of 2 days. In each automation reliability condition the automation routine was disabled for the last 20 min of the fourth session in order to simulate catastrophic automation failure (0 % reliability). Monitoring for automation failure was inefficient when automation reliability was constant but not when it varied over time, replicating previous results. Furthermore, there was no evidence of resource or speed accuracy trade-off between tasks. Thus, automation-induced failures of monitoring cannot be prevented by centrally locating the automated task.