Combustion simulation might seem like the ultimate in esoteric technologies, but auto companies, aircraft firms and fuel designers need increasingly sophisticated software to serve the needs of 21st century engine designs. And as government and industry demand better fuel efficiency and cleaner emissions, combustion software has become a hot topic.

HPCwire recently got the opportunity to take a look at Reaction Design, one of the premier makers of combustion simulation software, and talk with its CEO, Bernie Rosenthal.

A privately-funded company based in San Diego, Reaction Design has been around since 1995 and today employs about 30 people. Its claim to fame is providing state-of-the-art combustion simulation by bringing high-fidelity computational chemistry into the realm of computational fluid dynamics (CFD).

As with many types of computer aided engineering, the idea behind combustion simulation is to allow companies to replace millions of dollars in physical mockups and experiments with software models. According to Rosenthal, that requires sophisticated algorithms plus an intimate understanding of the different types of engines and fuels used by industry. The goal is to predict the thermodynamic behavior of combustion as well as the undesirable byproducts — carbon soot, nitrous oxide compounds (NOx), unburnt hydrocarbons, and carbon monoxide.

As far as the chemistry goes, Reaction Design developed its core competency early on. A couple of years after it was founded, the company acquired exclusive rights to a chemistry kinetics solver from Sandia National Laboratories, which the lab had developed to simulate rocket plumes and missile reactor designs. In conjunction with the software, Reaction Design picked up some of the key Sandia developers and brought them on-board. The solver was subsequently productized into CHEMKIN, the package that forms the basis of most of Reaction Design’s software offerings.

What sets Reaction Design apart is their ability to combine their computational chemistry codes with third-party CFD packages for combustion simulation. According to Rosenthal, they are the only vendor that combines the two components with a level of detail that he refers to as “real fuel modeling.”

Engine fuels are not simple formulations. Even refined gasoline is made up of thousands of different molecules that interact with each other during the combustion process. “Over the last 15 years that CFD has been available, most simulations have been approximating that fuel as one molecule,” notes Rosenthal. In general, he says, those simple simulations have worked. At least they did a good enough job to provide a 90 percent reduction in undesirable byproducts.

But emission standards now mandate combustion byproducts in the parts-per-million or even parts-per-billion range, which can be an expensive proposition for the end user. For example, a $65 thousand diesel engine could require a $15,000 after-treatment system just to deal with undesirable tailpipe emissions. In addition, the need for better fuel efficiency as well as the changing nature of the fuel itself — which can be anything from standard gasoline, to diesel, ethanol, liquified natural gas, biodiesel, propane, rapeseed oil, or some combination thereof — necessitates a more complex engine design.

To model all this in software requires a lot of number crunching. That’s especially true in the realm of turbine engines, which have very large geometries. Even with the benefit of parallelization on a medium-sized cluster with a dozen or two CPUs, a CFD simulation using a multi-million cell computational mesh requires multiple days of run-time execution — and that’s without any complex chemistry involved. “These guys were taking around a week to get an answer for a single cycle of the combustor,” says Rosenthal.

Reaction Design’s initial approach for the turbine engine community was to hook their existing chemistry solver onto CFD codes like FLUENT, STAR-CD and CFX, which are the ones most commonly used by manufacturers. Essentially they mapped the chemistry kinetics onto the CFD by splitting the combustion into a number of distinct regions, applying the chemistry to the CFD output, and then aggregating the results. The ensuing product, ENERGICO, is now used by a number of turbine firms, including the world’s largest gas turbine manufacturer for aircraft and power generation.

The problem was that this approach didn’t really offer true CFD-chemistry integration, and that is what automobile companies and other internal combustion engine manufacturers were demanding. This sector has traditionally looked to HPC to reduce compute times and increase capability by running their simulations on ever-larger and more powerful clusters. In general, simulation times for a combustion cycle were in the 8 to 12 hour range, meaning designers could initiate on an overnight run and analyze the results in the morning.

But newer engine designs, more complex injection and pressure schemes, and stricter emission requirements meant the simulations would have to do a lot more computation. Not only did the manufacturers want real fuel chemistry to be a part of this, they also wanted to keep their half-day simulation times.

Unfortunately, such chemistry is quite compute-intensive. According to Rosenthal, 80 to 90 percent of the run-time was going to be spent in the chemistry computation if they used their existing algorithms. So the Reaction Design developers took a second look at their software and were able to squeeze a 10-fold improvement in the algorithmic performance.

But even that wasn’t enough to keep the simulation run-times in the overnight realm. To accomplish that, they needed to parallelize their algorithms, which they did in typical MPI fashion. By doing so, users could scale the chemistry computation linearly just by adding more compute nodes, at least for moderate-sized clusters.

The second part to the solution was to merge the chemistry and CFD codes. There was just one problem: Reaction Design had no in-house CFD code, so they had to develop their own. The company now offers this as a standalone product called CHEMKIN CFD.

But the chemistry-integrated version, called FORTE, was the real breakthrough. It’s a complete HPC solution that supports advanced, 3D internal combustion engine design with real fuel chemistry hooked into a CFD solver. FORTE was officially announced in April, and a number of large auto firms in the US, Europe and Japan have already signed on, says Rosenthal.

FORTE may well scale up into hundreds of nodes, which would put simulation run-times into the 60-minute realm. But most manufacturers would probably use such large clusters to run multiple simulations using different parameters, rather than opt for shorter turnarounds on a single design run. The company’s next step is to see if they can scale their integrated CFD-chemistry approach to the larger geometries of the turbine engine, and offer a FORTE-like product for that industry.

Beyond that, Rosenthal is looking at GPU computing to further accelerate their codes. At this point, he’s wondering if he should invest development cycles in CUDA or OpenCL technology or wait for higher-level development tools to offer a more transparent way to tap into GPUs. Like most developers, he would rather the compiler and runtime do the heavy lifting in order to simplify any GPU-specific source code changes on his part. “But the real question to me is: what do my customers have?” says Rosenthal. “And they don’t have these… yet.”