Cloud-Based Generative AI for Preliminary Engineering Design

rolls-royce · Automotive · year n/a · source Agentic: no · promotional bias: low · source-backed · extracted with prompt 0.5.5 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Preliminary aerospace engineering design with generative models

Rolls-Royce, Databricks, and the University of Southampton explored how to accelerate preliminary engineering design by generating viable design concepts from requirements and simulation-derived training data while preserving physics validation and sensitive-data controls.

Constraints:

• Preliminary aerospace design must explore many concepts before full 3D detail exists.
• Physics simulations such as CFD and finite element analysis are expensive and slow.
• Rolls-Royce data classification limits what can be pushed to cloud infrastructure.
• Generative outputs must be decoded back to engineering parameters and validated by actual simulations.

Architecture

The team trains conditional GANs from simulation-derived images whose embedded bars/glyphs encode geometry, performance, and environmental parameters. Generated images are decoded back into parametric design values, validated with physics simulations, and tracked in a Databricks cloud environment using GPU clusters, Ray/Spark hyperparameter tooling, Unity Catalog, Jobs API, and MLflow for model management/tracking.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  simulation-database["simulation database"] --> image-parameter-encoder["image-parameter encoder"]
  image-parameter-encoder --> curated-training-dataset["curated training dataset"]
  curated-training-dataset --> cgan-training-job["cGAN training job"]
  databricks-cloud-workspace["Databricks cloud workspace"] --> cgan-training-job
  databricks-cloud-workspace --> gpu-cluster["GPU cluster"]
  gpu-cluster --> cgan-training-job
  databricks-cloud-workspace --> mlflow-tracking["MLflow tracking"]
  databricks-cloud-workspace --> unity-catalog-governance["Unity Catalog governance"]
  cgan-training-job --> generated-design-image["generated design image"]
  generated-design-image --> decoder["decoder"]
  decoder --> physics-simulation-validator["physics simulation validator"]
  physics-simulation-validator --> designer-review["designer review"]

Components

Data flow

Simulation databases provide design images and parameters; parameters are normalized and embedded into images; the cGAN trains on curated categories; inference generates synthetic design images for a requested performance category; parameters are decoded from the image; real CFD/FEA or other mechanical simulations validate prediction error; cloud training metadata, governance, and model versions are tracked in Databricks/MLflow.

Why this architecture

The architecture uses cGANs as a semi-instant design-space explorer while preserving the engineering requirement that generated designs be decoded into parameters and validated through physics simulations; Databricks provides the cloud GPU, governance, tracking, and hyperparameter tooling to make training practical.

Models used: conditional generative adversarial network · cGAN · physics simulation models · CFD · finite element analysis

Scale

• Training iteration time dropped from about seven days to four to six hours.
  “we were able to speed up the iteration from 7 days to actually down to about four or 6 hours for a training run”transcript, stated
• One training dataset initially used about 98,000 images or 98/88,000 design points before curation.
  “initially we had a training data set of 98,000 images or 98 88,000 design points”transcript, stated
• After curation, the dataset reduced to 63,000 images.
  “now the data set kind of reduced to 63,000 images”transcript, stated
• The scaling heuristic recommends single GPU below about 0.5 million images, then single-node multi-GPU, then multinode clusters for hyperparameter search.
  “anything less than a milli .5 million image set you could just run it off a single GPU”transcript, stated

  “only if you wanted to do a hyperparameter search space analysis do you go for a multinode cluster”transcript, stated

Alternatives considered (roads not taken)

Run traditional simulations for every preliminary design concept

Rejected because: The goal is faster design-space exploration with a semi-instant generative alternative, while retaining simulation for validation.

Push sensitive engineering data directly to the cloud

Rejected because: Rolls-Royce only pushes lower-sensitivity classified data to cloud training and keeps sensitive transfer-learning work local.

Assume GPU will always outperform CPU

Rejected because: The team found cases where GPU produced a flat-line result while CPU retained expected variance, so GPU architecture needed more investigation.

Patterns

synthetic-data-generation (generative-design)

The cGAN generates synthetic design images/concepts conditioned on design requirements and performance categories.

eval-driven-development (validation)

Generated designs are decoded and compared with actual physics simulations to quantify prediction error.

observability-tracing (mlops)

Databricks, Unity Catalog, Jobs API, and MLflow provide traceability, access control, preprocessing, model management, and tracking.

cost-aware-routing (training-infrastructure)

The team uses heuristics to choose single GPU, multi-GPU, or multinode clusters based on dataset size and hyperparameter-search needs.

privacy-preserving-processing (data-governance)

Sensitive engineering data stays local for transfer learning, while lower-sensitivity classified data is used in cloud training.

Tradeoffs

Use cGAN suggestions for preliminary design, then validate with physics.

Chose Fast generative exploration plus simulation validation over Simulation-only exploration for every concept.

Rationale: The cGAN accelerates search, but engineering trust still comes from decoding and running real simulations.

Separate cloud and local phases for data sensitivity.

Chose Cloud training on permitted data plus local transfer learning for sensitive data over Pushing all engineering data to cloud.

Rationale: The approach captures cloud training benefits without violating data-classification constraints.

Choose cluster size by workload rather than always scaling out.

Chose Single GPU, single-node multi-GPU, or multinode cluster based on dataset and search space over Always using large clusters.

Rationale: Different dataset sizes and hyperparameter tasks have different cost/performance needs.

Gotchas (what bit them)

Data curation can dominate model quality.

Root cause: Dense and sparse regions in the design space collapsed into weak pixel differences after normalization.

Resolution: Curate and normalize the design space more carefully, reducing the dataset to ranges that preserve meaningful variation.

GPU acceleration did not automatically improve this engineering model.

Root cause: The model's quantitative simulation-validation objective behaved differently from common qualitative image-generation benchmarks.

Resolution: Investigate GPU-specific architecture/tuning rather than assuming generic GPU literature transfers.

Cloud use is constrained by export classification and sensitive engineering data.

Root cause: Rolls-Royce cannot push all proprietary or sensitive product data to cloud services.

Resolution: Train on allowed PL 909c-style data in cloud and transfer learned capabilities locally for sensitive products.

Evaluation

The team evaluates generated designs by decoding parameters, running actual simulations, comparing predicted versus actual values, analyzing correlation plots, and tracking experiments in Databricks/MLflow.

Metrics: training runtime · predicted versus actual design values · correlation with diagonal target line · dataset size after curation · prediction error · CPU versus GPU result quality · experiment/model traceability

Outcomes

• Training iteration time improved from roughly seven days to four to six hours.
• Data curation improved prediction correlation after reducing the dataset to 63,000 images.
• The work exposed unresolved CPU/GPU behavior and future needs around 3D, multi-objective optimization, and hyperparameter automation.

The case reports a seven-day to four-to-six-hour training speedup, a dataset reduction from roughly 98k/88k design points to 63k images, and cluster guidance from single GPU to multinode clusters for hyperparameter search.