Closing the Loop on RCS-Aware Design

Jeffrey Hernandez on Closing the Loop on RCS-Aware Design, nTop Intern 2026

Connecting implicit geometry, automated validation, and progressive physical-optics analysis

By Jeffrey Hernandez, Aircraft Design Intern at nTop

Radar cross section (RCS) can influence aircraft geometry from the earliest stages of design. During my internship at nTop, I explored how to make that relationship more computational and iterative: rather than analyzing one finished concept at a time, could geometry generation, feasibility checks, and RCS analysis operate together as a single design loop?

What began as an effort to calculate and visualize the RCS of one tube-and-wing aircraft developed into two automated, constraint-aware design studies. The first used nTop Automate, Python, and an implicit-native physical-optics capability called ImplicitRCS to evaluate a population of tube-and-wing configurations. That study established the workflow architecture for the project: parameterize the aircraft, generate a design population, check feasibility, screen valid designs efficiently, refine the strongest candidates, and preserve reproducible results.

I then used that study as the foundation for a larger exploration based on our existing ducted flying-wing aircraft notebook. I adapted the notebook for automation by adding similar feasibility checks, then extended the workflow with an independent signed-distance-field check for internal duct connectivity. This made it possible to evaluate a much larger population while preventing invalid geometry from reaching the RCS analysis.

The project taught me that automating an analysis is only part of the challenge. A useful computational design workflow must also recognize invalid geometry, preserve functional requirements, apply the appropriate simulation fidelity at each stage, and return results in a form that a designer can interpret and reproduce.

Bringing Radar Returns into nTop

My initial goal was to bring electromagnetic analysis closer to the aircraft-design process. I built a custom workflow connecting implicit aircraft geometry created in nTop with physical-optics RCS analysis in MATLAB Antenna Toolbox.

*Workflow diagram of original MATLAB connector.*

The workflow converted the implicit body into a controllable surface mesh and exposed inputs such as frequency, polarization, angular sweep, mesh settings, and viewing direction. After MATLAB completed the analysis, the workflow returned angular RCS data to nTop, where I reconstructed the results as polar curves and three-dimensional visualizations around the aircraft.

*The original nTop-MATLAB connector transferring a meshed tube-and-wing aircraft to a physical-optics analysis and reconstructing its angular RCS response in nTop.*

Building the connector required more than passing geometry between two programs. I had to diagnose non-watertight meshes and invalid results, balance mesh resolution against computational cost, correct file-handling issues, and work through timeouts and output-caching behavior. I also verified the polar-plot construction using a simple reference geometry before applying it to a complete aircraft.

Once the connector was reliable, I used it for preliminary comparisons among conventional-tail, T-tail, and V-tail configurations. Benchmark geometries also helped evaluate the mesh-based approach and informed the transition toward calculations performed directly on implicit geometry.

That transition was a direct result of the connector work. ImplicitRCS was developed in response to the initial mesh-to-MATLAB workflow and the need to evaluate physical-optics backscatter directly from an nTop implicit field, without first creating an intermediate surface mesh. By eliminating the mesh conversion and external MATLAB handoff, it also ran significantly faster than the MATLAB-based workflow, making automated population studies much more practical.

*A tube-and-wing aircraft with its predicted angular RCS reconstructed as a polar curve inside nTop along with its maximum equivalent RCS area represented as a circle.*

The connector demonstrated that I could obtain and visualize a useful RCS result for a chosen geometry. The next step was more ambitious: instead of manually deciding which aircraft to analyze next, could I automate the generation, validation, analysis, and ranking of an entire design population?

From Analysis Tool to Design Study

I began with a parameterized tube-and-wing aircraft notebook. This was the first complete automated design-space study in the project, connecting the nTop model, nTop Automate, Python orchestration, and ImplicitRCS.

The study explored 20 aircraft configurations generated through Latin-hypercube sampling. Rather than changing only the tail or one wing planform property at a time, it varied features across the wing and fuselage, including planform, placement, sweep, dihedral, overall fuselage proportions, and profile shape. The V-tail remained fixed so that the effects of the other geometry changes could be compared more consistently.

Every generated aircraft also had to meet the underlying design requirements. The workflow checked its span, preserved the required payload envelope, maintained the fixed tail definition, and confirmed that the implicit body could be constructed successfully. Candidates that failed those checks were rejected before analysis.

Most of the generated concepts passed the feasibility checks and completed the initial RCS screen. From there, the best candidates were reevaluated with denser angular sampling and both co-polarized responses. The winning tube-and-wing design then received a global validation sweep followed by localized refinement around its strongest glint regions.

This staged approach made it possible to explore broadly without using the highest analysis fidelity everywhere. It also revealed an important lesson: a coarse mean value can rank a population efficiently, but it cannot fully characterize narrow signature peaks. The final validation therefore mattered just as much as the initial screening.

The pipeline retained the geometry inputs, implicit bodies, analysis configurations, numerical results, plots, timing, and status information for each candidate. It also generated a technical report that documented the feasibility checks, rankings, refinement, and final validation. The study was therefore reproducible rather than simply a collection of final images.

*The foundational tube-and-wing workflow, from Latin-hypercube generation and feasibility checks through coarse RCS screening, finalist refinement, and validation of the winning design.*

This study established the pattern that shaped the rest of my RCS work: generate broadly, reject invalid configurations before expensive analysis, screen the valid population efficiently, and reserve greater fidelity for the best candidates. I then carried that architecture forward into a more complex aircraft model.

*The winning design for the tube and wing nTop automate study.*

Scaling the Method to a Flying Wing

For the next phase, I took our existing ducted flying-wing aircraft notebook and modified it to support a 100-design study. The aircraft itself was not created from scratch for this RCS project. My contribution was adapting the existing parametric model for automated exploration by adding notebook checks based on the tube-and-wing workflow and connecting it to a larger nTop Automate study.

The existing model exposed variables controlling the planform, center body, duct position, and inlet geometry. nTop Automate generated the candidate population, and each parameter set was evaluated against the notebook’s primary conditions before it could proceed to additional validation or RCS analysis.

The flying wing introduced more demanding functional requirements than the tube-and-wing aircraft. In addition to span and payload constraints, each design needed sufficient inlet area and a properly enclosed internal duct between the intended inlet and outlet. The first requirements could be evaluated directly from the generated geometry. Duct integrity was more difficult: a small unintended opening could be hard to see, yet still invalidate the aircraft and any downstream analysis.

Teaching the Workflow to Catch Implicit Surprises

While adapting the model, I found a small sliver (or as some at nTop like to call them: Implicit Surprises) created by a Boolean blend in the duct geometry. Adjusting the blend removed the false opening without changing the intended outer mold line. Fixing that individual model was necessary, but I also wanted a general method for detecting similar problems anywhere in the generated population.

I developed an independent signed-distance-field connectivity checker using nTop Core. For each candidate that passed the notebook conditions, the workflow exported the aircraft outer mold line, required duct volume, and temporary caps over the intended inlet and outlet. It then sampled the implicit fields on a regular grid.

The aircraft and virtual caps were treated as solid obstacles while the checker flood-filled exterior air. If exterior-connected air could reach the protected core of the required duct, the candidate contained an unintended opening and was rejected. Temporarily sealing the intended inlet and outlet allowed the method to distinguish them from leaks elsewhere in the duct wall.

Of the 100 attempted flying-wing candidates, just over half passed both the primary notebook checks and the independent duct-connectivity check. Only those validated designs advanced to RCS analysis. Because every candidate’s artifacts were stored independently, the study also remained traceable and could resume without repeating completed work.

*Flying-wing candidates generated from the existing aircraft notebook after it was adapted with automated feasibility checks and an independent duct-connectivity check.*

The rejected candidates were not failed runs; they showed that the pipeline was doing its job. Without automated checks, invalid geometry could have consumed analysis time or, worse, appeared in the final ranking.

Screen Broadly, Refine Selectively

Running the highest-fidelity analysis on every concept would have been inefficient. Instead, I reused the staged method established in the tube-and-wing study.

The validated flying-wing candidates first completed a coarse RCS screen. The strongest designs were then reevaluated with denser angular sampling and both co-polarized responses. Importantly, the coarse leader did not remain the winner after refinement. A different candidate rose to the top once the finalists were sampled more thoroughly.

The winning flying-wing design then received a detailed global sweep and localized analysis around its strongest glint regions. This confirmed the broader lesson from the first study: mean RCS is useful for screening many concepts, but it does not tell the complete story. A geometry with a low average signature may still produce a narrow but significant peak, and a design that looks strongest on a sparse angular grid may not remain strongest at higher resolution.

The results should be understood as comparative physical-optics predictions under a defined analysis condition, not as a claim of broadband, all-aspect, or operational stealth performance. The connectivity method also verifies topology only at its chosen sampling resolution. A complete aircraft decision would require additional electromagnetic modeling along with aerodynamic, propulsion, stability, structural, manufacturing, and flight-test considerations.

*The winning flying-wing design, selected after geometric screening, duct-connectivity validation, coarse ranking, finalist refinement, and targeted glint analysis.*

The Workflow was the Real Result

The most valuable result of the project was not one aircraft geometry or one RCS value. It was learning how to connect geometry, verification, simulation, and decision-making in reusable computational workflows.

nTop allowed me to keep each aircraft definition parameterized while integrating nTop Automate, Python, the original MATLAB workflow, nTop Core, and ImplicitRCS around it. When a geometry issue emerged, I could convert that failure mode into a check that applied to future designs. More importantly, the geometry itself would not break when exploring the design space even though it may have had errors or unexpected shapes. When full-resolution analysis became too expensive for an entire population, I could build a progression from broad screening to targeted refinement. Instead of manually rebuilding and transferring each concept among disconnected tools, I could focus on defining the engineering logic of the study and interpreting its results.

Over the course of the internship, I really got to see the power of nTop first hand. Even when manually exploring designs and evaluating their RCS values, nTop allowed me to explore different designs faster than I ever thought possible. It also allowed me to rethink computational design and simulation as I learned that simulation is significantly more powerful when it is included from the start of the design process. Overall this project was one of the most interesting and challenging projects I have ever taken on and I am very happy with the results.

Main menu