THE IMPACT OF PATH OPTIMIZATION ON PRINT TIME IN ADDITIVE MANUFACTURING
Explore the source record for details and available documents.
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.
Explore the source record for details and available documents.
Document provides an overview of an alternate, containment-based licensing framework with the potential to reduce nuclear power costs.
The achievement of fusion ignition at Lawrence Livermore National Laboratory's (LLNL) National Ignition Facility (NIF) in December 2022 was the culmination of more than 60 years of research and development in laser-driven inertial confinement fusion at LLNL. That historic scientific, engineering, and technological accomplishment, a prime example of the value of ingenuity and commitment in the face of a grand scientific challenge, marked a significant advance in LLNL's support of the National Nuclear Security Administration's science-based Stockpile Stewardship Program to maintain the reliability and security of the nation's nuclear deterrent without underground testing. It also furthered Livermore's research in high energy density science and established the fundamental scientific basis for inertial fusion energy (IFE), emboldening further public and private research into the development of IFE as a potential source of abundance clean, safe, and reliable energy. Finally, the U.S. government has funded a multi-disciplinary, multi-institutional program that LLNL is now leading to make inertial fusion energy a reality.
Explore the source record for details and available documents.
Explore the source record for details and available documents.
Explore the source record for details and available documents.
Explore the source record for details and available documents.
Fact sheet and flyer provide an overview of the Re-tuning Challenge, including case study highlights, resources, benefits, and outcomes.
Explore the source record for details and available documents.
This is a presentation, where the team updates industry and DOE on progress made in the Storage Innovations 2030 initiative. The team also presents updates to the methodology, plans for the future, and revised results.
Explore the source record for details and available documents.
Explore the source record for details and available documents.
Explore the source record for details and available documents.
The national airspace has evolved over many years to accommodate increased traffic demand [1] while simultaneously maintaining one of the safest forms of transportation [2], [3]. One of the reasons for this success is the ability of the system and the operators to adapt and accommodate to situations that routinely disrupt optimal operations. These situations may include: adverse weather, delays, early arrivals, equipment outages, and other factors that are outside the operators ability to control. These factors can lead to states where automation is unable to properly handle these issues and therefore air traffic controllers and pilots have to intervene, ultimately increasing communication between operators resulting in higher workload. As controller workload increases to handle sub-optimal operating conditions this can be viewed as an increase in complexity. The reasoning for this is because humans are now required to make tactical decisions in response to external factors, resulting in a departure from the strategic plan where operations would be more efficiently managed. Human operators control airspace complexity under rigid regulations that are constantly changing. The airspace is divided into sectors and the number of aircraft assigned to each controller is limited for safe handling. There has been past work that devised airspace complexity metrics in commercial aviation and related these metrics to controller workload (e.g., [4],[5]). The upper bounds on the system load are pre-determined. Such bounds on complexity make for a safe system, but the system cannot scale and adapt to autonomous, dense, and heterogeneous traffic, including the many types of Unmanned Aerial Vehicles (UAVs) envisioned to be added to the operations. We hypothesize that, as traffic density and heterogeneity grow, and other key metrics change, there will be phase transitions at which the way traffic should be managed changes significantly [6]. We offer a method for in-time detection of contributing factors that lead to phase transitions, characterized by increased complexity. To the best of our knowledge, there is no tool similar to our proposed effort that identifies such contributing factors or precursor patterns. To define the scope we are proposing to measure complexity from the viewpoint of the Terminal Radar Approach Control Facilities (TRACON) controller’s perspective. In particular we are analyzing arrivals into KSFO. With safety as the top concern for airspace operators, it is important to recognize that as density and heterogeneity grow, the focus of the system will change. Times of the day when the airspace has low density and heterogeneity, the flights will follow more efficient paths where the aircraft move on established routes that are more or less directly to the destination. However, when density and heterogeneity increases, the system will begin changing focus to avoiding conflicts and collisions and route the flights in a more flexible way. Higher flexibility requires more communication and coordination between controllers and pilots which the current automation is unable to handle. This paper proposes a novel approach that monitors airspace complexity at multiple scales, uses a Machine Learning-based tool that predicts when operations will transition to a regime of greater complexity, and identifies actions that can reduce the complexity while still maintaining efficient and safe operations. We demonstrate our proposed approach using data from multiple complementary sources. This includes, but is not limited to: historical aircraft surveillance data from NASA’s Sherlock Data Warehouse [7], METAR weather data, and airport configuration data from Aviation System Performance Metrics (ASPM). The surveillance data flight paths are sampled at a variable sample rate — increasing as the aircraft approaches the airport. This is due to how Sherlock manages flight track stitching between different radar facilities which have different sampling rates. The weather and performance data are logged at defined intervals throughout the day at a courser refresh rate. In addition to the logged data and metrics, we leverage pre-defined Standard Terminal Arrival Routes (STARs) procedures to characterize the path of each flight. Each flight files for one of these routes in the flight plan well before entering the terminal airspace, and approximately follows the route until it leaves the STAR, typically on the final fix of a runway transition. However, most flights do not always fly the full STAR procedure to completion [8], but the majority do adhere to the fixes within the common route of the procedure. Our approach leverages fixes in the common route of each of the STARs to build a reference path to the airport. This allows us to characterize the flight paths in what we are defining as the “maneuvering area” (the airspace between the STAR and before the flight is lined up on the runway’s final approach) to determine how off nominal the flights are to calculate its complexity score. Determining airspace complexity is a concept that does not have a concrete answer. In designing this metric, we consider what increases the workload for the air traffic controllers. Consequently more specialized vectoring maneuvers results in higher workload. Accordingly, we start with a theory: each flight has a direct path it takes from the STAR’s common route to the final approach’s outer marker fix for the flight’s landing runway. It is important to note that the direct path is only used as a reference. If the majority of the flights have a large consistent offset as compared to other routes it does not necessarily mean that those flights have higher complexity. We are merely building a distribution based on this direct path for that particular STAR and runway pair to determine the normal mode of operations for that route. Flights that are in the upper tail of these distributions will result in higher complexity scores and flights that fly in the median will represent the normal mode of operations and therefore will have lower complexity scores. Since flights following each STAR route take different paths to the airport, we have a different distribution for each STAR route and therefore can model these distributions to compute a complexity score from their respective normalized distributions. To evaluate the effectiveness of our proposed airspace complexity metric we will compare against an established approach based on trajectory clustering [9]. This unsupervised learning technique consists of the following steps: (1) identify the general maneuvering areas (waypoints) by performing $\kappa$-means or DBSCAN clustering on locations where aircraft frequently turn based on the surveillance radar track data, (2) map flight trajectories onto sequences of waypoints, and (3) cluster the sequences based on their common subsequences. From a high-level perspective, this baseline model learns nominal operations in the airspace through the sequence of waypoints that are representative of where aircraft change direction and defines deviations from the nominal operations as “complex.” Therefore, more deviations from the nominal operations correspond to higher complexity values. For our validation, we re-implemented this technique and tune model hyper-parameters to correctly detect waypoints for the arrival traffic into the San Francisco bay area. We will compute the complexity measure over a one-year period using our proposed technique as well as the baseline. Our validation will be based on each technique’s ability to detect a set of undesirable outcomes (e.g., go-arounds, holding patterns, average time in the airspace, etc.). Since our current complexity metric is derived from the offset from the direct reference path, it’s important to understand what causes these offsets. In many of the flights with high offset distance, flights performing holding patterns and S turns can be observed. These maneuvering tactics are utilized to add distance between the aircraft and the destination runway to prevent multiple flights from having conflicting arrival times. In order to predict a rise in complexity (or the precursor to complexity), it’s necessary to be able to identify these potential conflicts (which in turn, result in higher offsets). To do this, we define a “representative flight” for each STAR route and runway pair. This flight is approximately the path the flight would take if there was a clear path with no other flights in the airspace — including the time remaining to the airport. We first identify the flights for a given STAR runway pair using the offset to the reference path distributions that fall between the 44-55 percentiles. This yields the flights that conform to the most normal mode of operation. Each of these flights is partitioned based on the percent complete from the entry point into the maneuvering areas from 0\% – 100\% complete. Then for each percent “bin”, we take the median value of the flight’s latitude/longitude coordinates, airspeed, and (non causal) time remaining to the airport to construct a lookup table for each percent complete bin on a given route. As a flight enters the maneuvering area, we can find the estimated arrival time of a flight to the airport by finding the closest point to the representative path’s percent complete bin (relative to the flight’s current position at any snapshot in the airspace) and therefore retrieve the corresponding remaining time left on the “representative path”. We assume that the flight will follow the representative path to completion when deriving these estimates. We can then compare these estimated arrival times against other flights for the same snapshot in time to identify potential conflicts. If more flights are estimated to arrive within a tolerance window than there are runways available, then we have a potential conflict. We can use this derived measure along with other factors expected to add disruption to the operation such as weather and runway configuration changes as an input to machine learning tools to detect precursors that increases in our complexity measure. This novel method will assist in uncovering insights into the contributing factors that lead to increased complexity that may allow for in-time responses to avoid reaching a high complexity state in the airspace.
Here a mechanistic study was conducted on the catalytic conversion of ethanol over La 0.7 Sr 0.3 MnO 3–x perovskite catalysts in the presence and absence of water. The study sought insights into the path of C–C coupling toward acetone and crotonaldehyde and also into clarifying whether the lack of previous reports of C–C coupling over La 0.7 Sr 0.3 MnO 3–x (100) could be due to a “pressure gap”. Several types of experiments were performed at 400–800 K: flow experiments with a torr range reactant gas flown over La 0.7 Sr 0.3 MnO 3–x powders; ultra-high vacuum experiments with continuous gas exposures to a La 0.7 Sr 0.3 MnO 3–x (100) single-crystal sample; and torr range continuous gas exposures to a La 0.7 Sr 0.3 MnO 3–x (100) single-crystal sample. When ethanol and water were flown over La 0.7 Sr 0.3 MnO 3–x powders at 400–800 K, the products detected were ethene, acetaldehyde, acetone, crotonaldehyde, CO, CO 2 , and H 2 . Acetone was catalytically produced over both the La 0.7 Sr 0.3 MnO 3–x powder and the La 0.7 Sr 0.3 MnO 3–x (100) single-crystal sample at temperatures of 700–800 K when reaction conditions were on the order of 1 Torr of reactant gas and with an excess of water relative to ethanol (1 ethanol/9 water). Isotopic labeling with deuterium was used to gain insights into the C–C coupling reaction mechanism and paths in species with three and four carbons (C 3 and C 4 species). Additionally, steady-state isotopic transient kinetic analysis (SSITKA) experiments + simulations using carbon labeling of the ethanol feed were performed. Three mechanistic paths were considered for the C–C coupling step: the first two paths, A and B, involve coupling between two intermediates which are both in oxygen vacancies; and the third path, C, involves coupling between one intermediate in an oxygen vacancy and one intermediate outside of an oxygen vacancy. The results suggest that the dominant path to the C 3 product, acetone, depends on the conditions. The less active path (attributed to path A or B) occurs at 600–700 K and involves coupling between two irreversibly bound species. The more active path (attributed to path C) requires an excess of water, becomes dominant at 600–800 K, and involves coupling between one irreversibly bound species and one reversibly bound species. Based on these various observations from experiments and simulations, an elementary step is proposed for acetone formation involving a previously unreported C 4 transition state that is formed after aldol addition. Density functional theory calculations were performed based on this hypothesis, and it confirmed that this specific and previously unreported aldol addition path to acetone does exist and that this path consistent with the experimental data. In this path, C–C formation occurs to create a C 4 intermediate that is bound to an oxygen vacancy, then a hydrogen transfer with C–C bond breaking occurs that results in the production of the acetone molecule. The proposed mechanism is also consistent with the experimental observation that acetone formation has a greater than first-order dependence on the water vapor pressure.
A two-wavelength, single-camera imaging thermography system for in-situ temperature measurement of a target, comprising: a target light path inlet conduit for receiving a target light beam reflected from the target; a beam splitter installed in a splitter housing at a distal end of the target light path conduit, wherein the beam splitter divides the target light beam into a first light beam and a second light beam; a first light path conduit emanating from the splitter housing comprising a first aperture iris installed within the first light path conduit for aligning the first light beam; a first band pass filter installed within the first light path conduit for regulating the first light beam to a first wavelength λ1 and an optional half waveplate installed within the first light path conduit to modulate a polarization ratio of the first light beam of λ1 wavelength; a second light path conduit emanating from the splitter housing comprising a second aperture iris installed within the second light path conduit for aligning the second light beam; a second band pass filter installed within the second light path conduit for regulating the second light beam to a second wavelength λ2; a junction housing, wherein distal ends of each of the first and second light path conduits are connected to the junction housing; a polarizing beam splitter installed in the junction housing, wherein the polarizing beam splitter reflects the first light beam of λ1 wavelength along the same path or a parallel path of the second light beam of λ2 wavelength that passes directly through the polarizing beam splitter unreflected to create a merged light beam comprising light of λ1 and λ2 wavelengths; and a light path outlet conduit connected to the junction for directing the merged beam to a high-speed camera for imaging.
In this report there are many scenarios in which a mobile agent may not want its path to be predictable. Examples include preserving privacy or confusing an adversary. However, this desire for deception can conflict with the need for a low path cost. Optimal plans such as those produced by RRT* may have low path cost, but their optimality makes them predictable. Similarly, a deceptive path that features numerous zig-zags may take too long to reach the goal. We address this trade-off by drawing inspiration from adversarial machine learning. We propose a new planning algorithm, which we title Adversarial RRT*. Adversarial RRT* attempts to deceive machine learning classifiers by incorporating a predicted measure of deception into the planner cost function. Adversarial RRT* considers both path cost and a measure of predicted deceptiveness in order to produce a trajectory with low path cost that still has deceptive properties. We demonstrate the performance of Adversarial RRT*, with two measures of deception, using a simulated Dubins vehicle. We show how Adversarial RRT* can decrease cumulative RNN accuracy across paths to 10%, compared to 46% cumulative accuracy on near-optimal RRT* paths, while keeping path length within 16% of optimal. We also present an example demonstration where the Adversarial RRT* planner attempts to safely deliver a high value package while an adversary observes the path and tries to intercept the package.
1. This software utilizes python pandas to pull data from P6 databases or XER files. The software transforms the datasets into multiple main tables by joining, filtering, iteratively flattening hierarchical structured data, and pivoting datasets to give simple flat output tables. The activity table includes all of the information related to an activity including activity codes, global, EPS, and project codes, UDFs, and WBS information as separate columns. This includes the code id, code value and sequence number for all levels in hierarchical codes. The resource table is similar to the activity table and includes all of the information related to resources on activities including UPFs and resource codes. The resource time phased table takes the resource information and time phases it for the budget, forecast, late, and actual dates/units/costs that closely matches P6's user interface's values as it implements the resource curve and calendars. The wbs table contains the WBS structure broken out by levels and includes UDFs, codes, and notebook topics. The final P6 data table is the relationships table which simply contains the relationships. 2. When a user updates the tool with data (via giving it P6 project names with database username/password information or XER files) the system creates the data in #1, then creates a networkx graph with the activity data imbedded in the node data and the relationships added as edges. Each edge also has it's float calculated (working time distance between the predecessor and successor) and attached to the edge. Activities are also tagged as a potential start of a path based on their constraints, constraint dates, remaining start date, and activity status. When a user enters an activity ID into the UI, it runs a shortest path calculation on the network graph between each node tagged as potential start to the entered activity id based on the float tagged on the edge. Each path returned by the algorithm contains all of the nodes on the path in order, as well as the total float of the edges that make the path. This data is then collected and returned to the user in the form of a gantt chart with groupings for each path that includes the total float for each group. 3. Similar to 2, if the user passes through a reference dataset each activity set in the path is checked to see if it had a path in the reference dataset, if that path was the primary path between the start and end activities, and what has changed regarding logic and durations. These changes are color coded and summarized before sent to the user to be displayed by the UI for simple discovery. 4. Utilizing the data from #1, the user can submit desired grouping code(s) and filters to the system. The system will then pull the activities, resources, and relationships and create a gantt chart based on the groupings sent and filtered based on the filters sent. 5. The system will produce a gantt chart in a similar method to #4, but allows interactivity with the data. As the user interacts with the gantt chart, the software captures the changes and stores it with the user making the change so that project controls and implement those changes in P6.