Analyzing new and existing aerospace platforms is a time-consuming and labor-intensive process that often requires fusing multiple domains of physics and engineering, along with competing assumptions. Analyzing the vortex bursting behavior of the F/A-18 platform, for example, and its resulting impact on tail buffeting and structural fatigue1 is a multi-physics problem requiring aeroelasticity modeling, as well as fluid and structural meshes2. Capturing complicated physical events in a single model can be quite complex and require a lot of computing power.

To make this problem feasible or often, more importantly, to utilize existing work by other scientists and engineers, modelers typically break up the single physical phenomena into multiple simpler models. Each model represents different aspects of the problem. For instance, in a fluid-structure interaction (FSI) problem, there might be one model representing fluid flow and another representing a physical structure. Generally, modeling that refers to multiple interacting physics is called multi-physics modeling.

A key component in making a viable multi-physics model is the coupling process. Coupling refers to the way the two models, representing the different types of physics, interact. There are various types of coupling. For performance reasons, when two meshes at different refinement levels are coupled, the lower refinement model might sample the higher refinement model at a lower resolution than initially intended, introducing possible inaccuracies. Another type of coupling can include bi-directional information flow with different assumptions. If both models use a shared measurement, such as temperature along a boundary, then the models might need to run simultaneously with some information freely flowing between them.

Domain-specific tools are designed so that domain experts can write their problems in a syntax and style that is familiar to them and their applications are representative of the problems they are trying to solve.

Programming this type of coupling between models can be tricky. The user needs the flexibility to share information between models and make updates, but also be cautious of possible errors that can be introduced when coupling different models. Incompatibilities between individual models can damage the entire modeling system’s validity, such as when the coupled models make different assumptions about scale due to being developed by different teams.

Worse yet, errors can go undiscovered but cause inaccuracies in the final result. Across technical areas, models are used to represent various things but are made by people with inherent, and often differing, assumptions in place. Multi-physics is one of many areas where the assumptions embedded in models (created by different teams of people) could benefit from robust formal development.

In this article we describe the challenges in the tools available on today’s market and how it can impact applications at NASA. We also introduce cutting edge-research sponsored by DAPRA to address those challenges with techniques in programming languages.

State of the Market

While tools currently exist that allow users to create multi-physics models, the current state of the art has limitations. These tools tend to be proprietary, not portable, and designed for a particular sub-community of physics practitioners, or they are built for a limited set of solving techniques. These tools can side-step the issue of correctness by providing very specific built-in examples for the multi-physics problem. The problem with this approach, of course, is the lack of flexibility in creating new models or generalizing existing problems for new platforms. If you are hoping to create a model for something not previously implemented by the tool developers, you are often out of luck.

Multi-physics modeling of a spacecraft heat shield.

In practice, once reaching the limits of tools available, scientists end up writing their own software code. To reason about how to implement their code efficiently, correctly, or even at all, scientists need to act like software engineers. Creating custom code is a difficult task that requires the practitioner to balance the necessary customizations for their problem, leverage existing code and libraries, and implement custom tests to evaluate the model. In place of the rare superhero that is a physicist, high-performance computing expert, debugging savant, and software engineer, some things can fall through the cracks.

Due to these factors, the level of effort to encode, verify, execute, and maintain multi-physics problems is quite high. Encoding a model is typically a manual, ad-hoc, and difficult task to get right. One way to cut that down is to separate the tasks of physics modeling from software engineering. This would allow scientists to focus on science and the tools they are using to automatically generate high-performance, correct code. One popular method enabling this approach in the programming languages community has been in creating domain-specific languages.

Automated Tools and Domain-Specific Languages

DSL-Modeling Process

Domain-specific tools are designed so that domain experts can write their problems in a syntax and style that is familiar to them and so that their applications are representative of the problems they are trying to solve. In the scientific modeling space, this can include keywords to represent boundary conditions, governing equations, and solving techniques to represent a single model. The multi-physics domain can involve capturing both the individual models being created and the communication between them, making it explicit so that the model developer can deliberately choose how the information is passed between models. Some tools support the mathematics (involved in a physical phenomena) by providing a library of available scenarios or allowing them to define their own set of equations. By allowing the user to define their own equations, domain-specific tools can give scientists the flexibility needed to encode a wide range of problems.

Cutting edge R&D underway at places like DARPA is developing a tool for the multi-physics space focusing on robustness. These tools utilize domain-specific languages to allow users to define their problems and set various modeling parameters that define units, dimensions, and storage requirements, allowing the tool to synthesize a formal system automatically. The tool can ground modeling parameters in an intermediate representation to provide formal, comparable reasoning between models being coupled. The tool can then warn the user of incompatibility issues, report bugs earlier in the design process, reduce errors, and reduce development time. Once models pass the internal compatibility check without error, the code is translated into efficient executable code on one of a variety of platforms/framework combinations.


A primary use case of these tools involves helping NASA design next-generation aerospace platforms with increased payload capabilities suitable for launching advanced robotic and human missions to Mars. The payload requirements for such missions exceed current capabilities using traditional parachutes to decelerate. One potential solution to this problem is aerobraking with retro-propulsion to decelerate the vehicle for entry, descent, and landing. NASA hopes to utilize modeling of the thermal protection material and its impact from the retropropulsion system during descent stages. This NASA application can be represented as a multi-physics problem with multiple interacting components: fluid flow, thermodynamics, and solid mechanics.


These new technologies seek to advance the state of the art by addressing core challenges faced by aerospace engineers, physicists, and design teams in the industry. Often, scientists developing multi-physics models start by creating individual models coupled to make a multi-physics system. Besides representing different types of physics, the individual models can be created by entirely different teams relying on different solving techniques and be implemented in incompatible frameworks and languages, or target incompatible hardware platforms. These caveats can increase development time, create manual work (that should be automated), and make room for hard-to-detect errors.

The new techniques being developed will enable scientists to create new models to represent this NASA application and, more generally, the complicated world we live in. Domain-specific tools will enable the easy translation of scientific thinking to high-performance code. These work results are expected to dramatically lower the bar to build, maintain, and execute multi-physics models.

This article was written by Dr. Charisee Chiw and Dr. Eric Davis, Scientists, Galois, Inc. (Portland, OR). For more information, visit here .


  1. Meyn, Larry A., and Kevin D. James. “Integrated tail buffet loads on the F/A-18.” RECON 20010062152 (1994).
  2. Michopoulos, John G., Charbel Farhat, and Jacob Fish. “Modeling and simulation of multiphysics systems.” (2005): 198- 213

Aerospace & Defense Technology Magazine

This article first appeared in the October, 2021 issue of Aerospace & Defense Technology Magazine.

Read more articles from this issue here.

Read more articles from the archives here.