Search NASA⌕ Search

SEARCH · Search NASA

Results for “embedded model error”

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.

75 records · Page 5
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

Demand Capacity Balancing at Vertiports for Initial Strategic Conflict Management of Urban Air Mobility Operations

Urban Air Mobility (UAM) is a new transportation concept that enables highly automated, cooperative, passenger or cargo-carrying air transportation services in and around urban areas. To achieve the high level of operational density and complexity desired by the UAM community, an airspace system that allows UAM operators to readily access and operate safely and efficiently in the airspace is needed. This airspace system will require air traffic management designed to reduce the risk of conflicts and loss of separation between UAM flights. In general, strategic conflict management is considered as the first layer of conflict management for safe flight operations to condition the traffic to reduce the need for airborne separation provision, the second layer of conflict management. Demand Capacity Balancing (DCB) is one of the concept components to achieve strategic conflict management. DCB strategically evaluates traffic demand and resource capacities to allow UAM operators to determine when, where and how they operate, while mitigating conflicting needs for airspace and vertiport capacity. DCB can be applied whenever UAM demand exceeds the capacity in airspace or at vertiports. As the UAM ecosystem evolves with advanced technologies and matured operational procedures, more complicated conflict management will likely be needed. In the current UAM ‘Concept of Operation (ConOps) 1.0’ operational stage defined by FAA, however, it will be meaningful to explore the demand capacity balancing at vertiports only, as an initial strategic conflict management approach for UAM operations because vertiport capacity seems to be a bottleneck of UAM traffic. For this research, we developed a demand-capacity imbalance detection and resolution service for UAM. This DCB service identifies the demand from operators and compares the demand to a given capacity at the shared resources (i.e., vertiports) over the upcoming time horizon which is divided into time bins having a constant interval. When a new flight plan is submitted, the algorithm embedded in the DCB service checks the available time bins based on the desired departure time and estimated arrival time at origin and destination vertiports, respectively. If the time bins for the originally desired times are already occupied by other flights (i.e., demand is at or above capacity), the algorithm finds the next available time bins for takeoff and landing and shifts the conflicting departure time to the earliest time that satisfies the capacity constraints at both origin and destination vertiports. The details of the algorithm will be described in the final manuscript. Figure 1 shows that the proposed DCB algorithm works well for a sample traffic scenario. In this example, a total of 144 flights, split between two operators, are planned over 2 hours, traveling 10 routes between five vertiports. In the heatmaps, the horizontal axis shows 12 time bins where each bin represents a 12-minute interval, and the vertical axis shows five vertiports. The number in each cell shows the number of operations, counting both departures and arrivals, at a specific vertiport in each time bin. For the given capacity of 2 operations/vertiport/bin, Figure 1 shows that the original demand sometimes exceeds the capacity, but the modified demand is reduced to the given capacity after resolving demand-capacity imbalances. When UAM flights are operated, it is expected that many practical issues would arise in the federated system architecture with multiple operators. UAM operators may experience a time synchronization issue due to communication delay between operator and vehicle. UAM vehicles would fly at different flight speeds, depending on vehicle models. Actual departure and arrival times can have large variations, compared to the schedule. The lead time from flight plan submission to desired departure time can vary by service type (e.g., regular shuttle service vs. on-demand service). Using the proposed DCB algorithm, we also investigated how the actual flight schedule and DCB performance are affected by these uncertainties such as unsynchronized times between operators, flight speed differences, lead time differences, and departure time errors. The final manuscript will include the background of this research work, the description of the DCB algorithm and its use cases with traffic scenarios. It will also provide the analytical results about the impact of various uncertainties that can occur in actual UAM operations on the DCB at vertiports, in terms of demand distribution changes, number of simultaneous operations, and delay propagation.

Urban Air Mobility↗
NASA NTRS2011

Should Pruning be a Pre-Processor of any Linear System?

There are many real-world problems whose mathematical models turn out to be linear systems Ax = b , where A is an m by x n matrix. Each equation of the linear system is an information. An information, in a physical problem, such as 4 mangoes, 6 bananas, and 5 oranges cost $10, is mathematically modeled as 4x(sub 1) + 6x(sub 2) + 5x (sub 3) = 10, where x(sub 1), x(sub 2), x(sub 3) are each cost of one mango, that of one banana, and that of one orange, respectively. All the information put together in a specified context, constitutes the physical problem and need not be all distinct. Some of these could be redundant, which cannot be readily identified by inspection. The resulting mathematical model will thus have equations corresponding to this redundant information and hence are linearly dependent and thus superfluous. Consequently, these equations once identified should be better pruned in the process of solving the system. The benefits are (i) less computation and hence less error and consequently a better quality of solution and (ii) reduced storage requirements. In literature, the pruning concept is not in vogue so far although it is most desirable. In a numerical linear system, the system could be slightly inconsistent or inconsistent of varying degree. If the system is too inconsistent, then we should fall back on to the physical problem (PP), check the correctness of the PP derived from the material universe, modify it, if necessary, and then check the corresponding mathematical model (MM) and correct it. In nature/material universe, inconsistency is completely nonexistent. If the MM becomes inconsistent, it could be due to error introduced by the concerned measuring device and/or due to assumptions made on the PP to obtain an MM which is relatively easily solvable or simply due to human error. No measuring device can usually measure a quantity with an accuracy greater that 0.005% or, equivalently with a relative error less than 0.005%. Hence measurement error is unavoidable in a numerical linear system when the quantities are continuous (or even discrete with extremely large number). Assumptions, though not desirable, are usually made when we find the problem sufficiently difficult to be solved within the available means/tools/resources and hence distort the PP and the corresponding MM. The error thus introduced in the system could (not always necessarily though) make the system somewhat inconsistent. If the inconsistency (contradiction) is too much then one should definitely not proceed to solve the system in terms of getting a least-squares solution or a minimum norm solution or the minimum-norm least-squares solution. All these solutions will be invariably of no real-world use. If, on the other hand, inconsistency is reasonably low, i.e. the system is near-consistent or, equivalently, has near-linearly-dependent rows, then the foregoing solutions are useful. Pruning in such a near-consistent system should be performed based on the desired accuracy and on the definition of near-linear dependence. In this article, we discuss pruning over various kinds of linear systems and strongly suggest its use as a pre-processor or as a part of an algorithm. Ideally pruning should (i) be a part of the solution process (algorithm) of the system, (ii) reduce both computational error and complexity of the process, and (iii) take into account the numerical zero defined in the context. These are precisely what we achieve through our proposed O(mn2) algorithm presented in Matlab, that uses a subprogram of solving a single linear equation and that has embedded in it the pruning.

Sen, Syamal K.↗
NASA NTRSDate not supplied

CFD 2030 Grand Challenge: CFD-in-the-Loop Monte Carlo Flight Simulation for Space Vehicle Design

Flight qualification of space vehicles is markedly different from those typically employed for aircraft. The concept of an extensive flight test campaign for a space vehicle does not exist, and vehicle designers must look to alternative techniques for demonstrating robust and reliable performance of their vehicles prior to operational flight. A space vehicle may undergo only a handful of flight tests in its development cycle, with each flight representing a drastically different flight phase or flight configuration. For instance, NASA’s Space Launch System (SLS) launch vehicle and Orion spacecraft will only see a total of four flight demonstrations before flying a crew on its first operational mission, and each flight demonstrates a unique vehicle configuration and/or set of flight conditions. The SLS will be flown only one time before it becomes operational (Artemis 1). The Orion spacecraft Crew Module (CM) will have been tested twice, once on a Delta IV launch vehicle (Exploration Flight Test 1) and once as a fully integrated system with the SLS launch vehicle (Artemis 1). The Orion Launch abort system will have been tested twice, once in a pad abort scenario (Pad Abort 1) and once in an inflight abort scenario (Ascent Abort 2) on a modified Peacekeeper booster. Both of these latter tests involve only a boiler plate CM, not a functional Orion spacecraft. Thus, unlike aircraft, there is very little opportunity for engineers to assess and evaluate their preflight predictions. Instead, space vehicle designers rely on Monte Carlo flight simulations with detailed dispersions of predicted nominal flight behavior to determine how robust their design is to errors and uncertainties in the flight conditions their vehicle may encounter. These Monte Carlo analyses entail thousands of trajectory simulations to demonstrate that the vehicle can meet design requirements at a specified level of reliability. From an aerodynamics and aerothermodynamics perspective, these trajectory simulations are fueled by an extensive aerodynamic database that covers the complete range of expected flight conditions, vehicle configurations, and flight attitudes expected in a given mission. Today, these databases amount to a table of engineering parameters that can be quickly interrogated by the trajectory simulator. The aerodynamic and aerothermodynamic databases are assembled via a series of ground tests, empirical and analytical analysis, physics-based computational analysis, applicable past flight performance data, and in some cases, engineering judgment. These databases generally take years to assemble for a new space vehicle system and in the case of SLS/Orion, over a decade of test and analysis have been expended to develop the extensive databases required to cover the myriad of configurations and potential flight conditions required for the system. Recently, it has been proposed that Computational Fluid Dynamic (CFD) and computing capability may be reaching a point where it is foreseeable that CFD could be integrated directly into the production trajectory simulation tools used to design NASA’s space vehicles. To demonstrate this, NASA has embarked on two demonstrations of this type of capability, one where six degree of freedom flight trajectory simulation equations are embedded in an existing CFD solver and another where a production CFD solver is loosely coupled with a production trajectory simulation tool. These efforts represent an initial demonstration of a future approach to flight trajectory simulation, but they are a far cry from the capability required to perform a full-up CFD-in-the-loop Monte Carlo trajectory simulation. Therefore, this represents a viable grand challenge for computational methods addressing space vehicle design and development. The final paper/presentation will discuss the many hurdles, beyond simply raw computational power, to realizing this grand challenge and how they map directly to the CFD Vision 2030 ojectives. Among these are the wide range of flight conditions, including accelerating/decelerating flight, encountered by a space vehicle during launch and/or entry. The vehicle can also encounter numerous configuration changes, some of which can be quite drastic, during the course of its flight, so robust, automated geometry modeling, grid generation, and adaptation will play a huge role in reaching this goal. Multiply this by 1000’s of trajectory simulations occurring simultaneously in a given Monte Carlo analysis, and the problem readily scales to absorb virtually any size of supercomputer envisioned today. The concept of CFD-in-the-loop Monte Carlo trajectory simulation poses a formidable challenge for emerging and future computing systems, and it has the potential to shave years off the development cycle for aerodynamic and aerothermodynamic performance predictions as compared to today’s space vehicle design approach.

CFD 2030↗