The aerospace industry has been using Computational Fluid Dynamics (CFD) for decades to create and optimize designs digitally, from the largest passenger planes and fighter jets to gliders and drones. CFD allows them to get to market faster and at a lower development cost, reducing, for instance, expensive wind tunnel testing.
But performance and cost-effectiveness need to get even tighter. By 2050, commercial aircraft will face even more stringent environmental legislation, which necessitates continuously improving aircraft performance. As such, engineers are increasingly using more complex and higher fidelity CFD simulations as well as digital twinning to reduce design times.
Running these simulations requires a large computing power and as the simulation complexity increases so does the demand of High-Performance Computing (HPC) systems. This trend is set to continue, and aerospace companies are exploring the next generation of CFD tools and the HPC systems to run them.
In the last few years, the advances in cloud computing infrastructure has meant that more and more workloads that previously required on-premises HPC can now run on the cloud. However, there is still the perception that large scale workloads require an on-premises HPC resource. In this article we explore this and test various AWS HPC performance options for a large scale industrial CFD test case.
This article is a summary of the study based on the tests carried out as part of the Aerospace Cloud Services project, funded by Innovate UK and the Aerospace Technology Institute.
Authors of the original white paper: Mike Turner, CTO at Zenotech, Neil Ashton, Principal Solution Architect CFD and AWS, and Gilles Tourpe, Senior Go-to-Market Specialist at AWS.
The CFD challenge
To test the AWS infrastructure, we used the zCFD solver from Zenotech. Zenotech is a computational engineering company based in Bristol, UK, that has extensive experience working in the aerospace industry and offers on-demand cloud HPC via their EPIC product.
XRF1 Simulation Challenge supplied by Airbus was used as a test case. XRF1 is a generic non-production aircraft design but represents the kind of simulations that Airbus performs to produce a real aircraft. Airbus has extensive wind tunnel result data for XRF1 and has released the model to partners to support the verification and validation of CFD codes.
The combination of zCFD and XRF1 allowed us to run the benchmarks in a way that replicates runs that are typically used in an aerospace production design cycle.
To quantify the performance of AWS infrastructure we compared it with an on-premises Cray CS400 cluster, configured specifically for HPC tasks. It is one of several types of HPC clusters that large organizations have on-premise.
AWS HPC Configuration
To create an HPC cluster in AWS the following services were used:
- Amazon Elastic Compute Cloud (EC2): The initial scaling tests used the compute optimized Amazon EC2 C5 instances. For the GPU runs, Amazon EC2 P3 and Amazon EC2 G4 instance types were used. Finally, Amazon EC2 C6g Graviton2 arm64-based instance types were used.
- Elastic Fabric Adapter (EFA)
- Elastic Network Adapter (ENA)
- Amazon FSx for Lustre (FSx for Lustre)
The AWS infrastructure was set up by Zenotech and managed via Zenotec’s EPIC platform, which provides access to a variety of HPC systems, both cloud-based and a range of specialist supercomputing providers.
We ran the benchmarks on 3,600 CPU cores using a 149 million cell aircraft mesh and test results demonstrated that the AWS based infrastructure is capable of running a large aircraft CFD simulation at scale delivering performance that exceeds an on-premises HPC cluster.
The results below show how the runtime of the CFD solver scales with the number of CPU cores used. The “ideal” metric is where the performance scales linearly to the number of CPUs used, while at higher core counts this “ideal” scenario becomes more difficult as the communication between partitions starts to dominate the calculation time. The speed and bandwidth of the network interconnect also have a considerable impact on strong scaling.
The tests run with zCFD in three modes:
- MPI: The code was run in pure MPI mode, one MPI process per CPU core and one thread per MPI process. This mode is the most network intensive as all processes can potentially communicate.
- Hybrid: The code was run in hybrid MPI/OpenMP mode. In this case one MPI process is run per CPU socket and then one OpenMP thread per CPU core on that socket. So, for example a compute node with two 12 core CPUs would run two MPI processes each with 12 OpenMP threads. This mode is more efficient on the network as it reduces the number of components communicating.
- GPU: Zenotech’s zCFD is capable of offloading the solve to GPUs via CUDA . To do this one MPI process is run per GPU on the system and the code detects the available GPUs and binds one MPI process to each GPU.
The solver was also compiled for arm64 to benchmark the Graviton2 arm64-based CPUs.
How did the AWS cluster do?
The chart below illustrates the strong scaling results for the Amazon EC2 c5n.18xlarge instance type. It shows a comparison of the scaling with and without the use of EFA for communications, running zCFD in Hybrid mode with two MPI processes on each node and 18 OpenMP threads per MPI process.
As shown above, the scaling without ETA is still very strong, with around 75% efficiency at 100 nodes/3600 cores. This is over the standard ENA based ethernet interfaces on those nodes using the libfabric TCP provider. Introduction of EFA improves metrics even further, with near linear scaling up to around 75 nodes and an efficiency of 87% at 100 nodes/3600 cores.
Some applications, legacy CFD codes in particular, are not capable of running in a hybrid mode and so we also ran our tests in full MPI mode; with 36 MPI processes per node and no OpenMP threads. As demonstrated in the chart below, the scaling for the MPI run drops off faster than the Hybrid run. This was expected due to the increased number of communication processes in the MPI run putting more load on the network. These results mirror those seen on the on-premises cluster.
How does it compare to the On-Premises Cluster?
The results from the AWS cluster look very promising. The chart below shows a comparison of a zCFD hybrid running on c5n.18xlarge with EFA enabled and the Infiniband connected on-premises cluster.
As demonstrated in the above chart, scaling on the AWS cluster is closer to “ideal” than the on-premises cluster. Even at 100 nodes we see 78% parallel efficiency, when compared to a single node, for the on-premises cluster versus 87% on the AWS cluster.
It is also useful to make a direct performance comparison. If we look at cycle time per compute node/instance, the AWS cluster is around 1.5x faster than the on-premises cluster. If we run the job until the solver converges (in this case around 15,000 cycles) we can calculate a time to solution. The graph below shows this time to solution at different node counts, where a lower time to solution is better.
The above chart demonstrates that AWS instances are giving a quicker time to solution for the same node counts as the on-premises cluster. This is to be expected as the AWS compute nodes have 36 Skylake cores versus the 24 Broadwell cores on the on-premises cluster compute nodes. However, the scaling performance demonstrates that this advantage is still present at the higher node counts although one might expect that the impact of the interconnect network would give the on-premises cluster an advantage.
What was the impact of FSx for Lustre?
To assess the impact of Amazon FSx for Lustre we also ran the tests using an NVMe exported via NFS based solution and compared the overall elapsed time for the run (to 20 cycles). The chart below shows the comparison between the on-premises cluster with IBM Spectrum Scale storage, Amazon FSx for Lustre and the NFS solution.
The above chart shows that Amazon FSx for Lustre scales well with the increased node count and at the higher node counts actually outperforms the Spectrum Scale solution.
Our additional tests demonstrated:
- Use of GPU instances like Amazon EC2 P3 Instances and Amazon EC2 instances can significantly accelerate your workloads
- Use of Graviton2 instances (performance tests were repeated on the c6g.16xlarge instance type) demonstrated better performance
The number of CFD runs that need to be performed as part of the design cycle is enormous and so price/performance for CFD on HPC becomes critical. AWS offers several pricing models. For the purposes of this study, we considered standard On-demand pricing, Reserved Instances (RI) and Spot instances. For on-premises cluster, we used a price of £0.05 per core/hour, which from our experience is a fair representation of the cost of using an on-demand specialist HPC system.
The relative price performance shown on the chart below is the cycle time of the run divided by the resource cost, normalized relative to the on-premises system. The value above 1 represents better price/performance than the on-premises cluster.
On-demand pricing places the AWS solution at a lower price/performance than the on-premises cluster. However, when we apply Reserved Instances or Spot, the AWS solution is more cost effective than the on-premises cluster. Overall, mixing On-demand, Reserved Instances and Spot pricing models will often provide an organization with the best mix of flexibility and cost savings.
Below is the same price/performance metric for the GPU and Graviton2 instances demonstrating that increased performance of the GPU options balances out the higher instances prices and brings the price performance in line with on-premises cluster even at on-demand pricing, in fact the G4 instances are providing significantly better price performance.
Graviton2 price performance makes it an interesting option for those codes that cannot easily take advantage of GPUs but may be able to target the arm64 architecture.
One of the biggest changes that comes with using cloud HPC is the ability to be flexible with the size of the infrastructure. Cloud allows you to do things that are not easy with an in-house cluster such as ‘Design of experiments’ and increase model accuracy or fidelity.
If turnaround time is a priority, you can scale your HPC cluster size to meet your demand, meaning users no longer have to queue. HPC clusters can be spun up in a matter of minutes and then used for a single job, a specific project or even dedicated to a single user. For example, Zenotech was able to spin up all the infrastructure required to run the 100 node benchmarks in less than 10 minutes, and then when the runs completed they post-processed the data, stored the results on S3, and terminated all of the infrastructure – with no on-going costs associated with the HPC cluster.
The study conducted by Zenotech and AWS demonstrated that the AWS based infrastructure is capable of running a large aircraft CFD simulation at scale at a level of performance that exceeds an on-premises HPC cluster. This coupled with the on-demand Lustre file system offered by FSx for Lustre gives organizations that require HPC a flexible cloud-based option to complement, or replace on-premises HPC.
We also demonstrated that running CFD on GPUs gives the industry the ability to vastly speed up CFD simulations, a trend that will continue as next generation of GPUs gets deployed. The advent of arm64 processors is a very interesting development and we have demonstrated that they can be used for an HPC workload and offer a price/performance advantage over the x86 equivalent. Cloud HPC offers the flexibility to use this heterogeneous mix of hardware without expensive reconfiguration or capital purchases.
Learn more about CFD simulations on AWS here.
Customers are responsible for making their own independent assessment of the information in this article. This document: (a) is for informational purposes only, (b) represents current AWS product offerings and practices, which are subject to change without notice, and (c) does not create any commitments or assurances from AWS and its affiliates, suppliers or licensors. AWS products or services are provided “as is” without warranties, representations, or conditions of any kind, whether express or implied. The responsibilities and liabilities of AWS to its customers are controlled by AWS agreements, and this document is not part of, nor does it modify, any agreement between AWS and its customers.