CONVERGE CFD Software

Blog

Published March 20, 2018

CONVERGE: 10 Years of Perseverance and Success… and Autonomous Meshing!

Author:
Kelly Senecal

Owner and Vice President of Convergent Science

A lot of things happened in 2008. There was a financial crisis. China hosted the Olympics. Barack Obama won the US presidency. Sarah Palin could even see Russia from her house! But something else was brewing in the Midwestern college town of Madison, Wisconsin. In 2008, Keith Richards, Eric Pomraning, and I realized that we had written a CFD code that could change the simulation world. Not only that, but it was finally ready to be shared with the public. We had spent the last seven years developing this software and now had to figure out how to market it, sell it, support it, and document it, all while running a business. A business that had focused on consulting services since its inception in 1997. How were we going to pull this off? Especially at a time when our biggest client base, the US automotive industry, was facing its own crisis, including bankruptcies and government bailouts. I’ll come back to that in a minute, but first, a bit more history on the CFD code that turns ten this year.

Kelly, Eric, and Keith at a 2003 Badgers football game

Many of you know that CONVERGE started out as MOSES (named by David Schmidt, one of the original founders of our company). But did you know that this stood for Modular Open Source Engine Simulation? That’s right, open source. CONVERGE was originally written with the intent of replacing KIVA, the software that we (and many others) had used in our graduate studies. We accomplished a lot with KIVA, and it taught us a lot about reacting flow CFD. However, there was one big problem with it and, frankly, all CFD codes at the time: the mesh. The mesh quality was often low and the resolution coarse, both of which significantly degraded the accuracy of CFD simulations. Moreover, for anything but a simple, stationary geometry, mesh creation was incredibly painful. In fact, much of the consulting we did in the early years was based around KIVA mesh generation. Keith had written a tool called G-Smooth, which allowed us to make full, complicated engine meshes for KIVA faster than anyone else—in one week. Are you kidding? An entire week of engineering time to make a mesh was considered fast? We knew something needed to change.

In 2001 we sent the US government a proposal called The MOSES Project: A Modular, Open Source Engine Simulation Code for Parallel Computation of Complex Geometries. Their response was something along the lines of “this sounds like a great idea; please come back when industry is interested.” In their defense, this was unsolicited, they weren’t asking for MOSES, and “never make a mesh again” probably sounded pretty far-fetched to the reviewers. This was the first of many times when it would have been easy to throw in the towel.

An early version of the user manual

Instead, we went to industry, specifically to a large engine manufacturer (Engine Maker X). It wasn’t easy to convince them, but they too were frustrated with the time required for making meshes as well as the accuracy implications of using a poor quality mesh. A few key people at Engine Maker X believed in us enough to secure funding to help with early development. So in late 2001 we went to work—Keith and Eric developed the core solver while I kept up the consulting side of things to keep the lights on. A couple of years later, I joined them full-time on code development and started implementing the spray and combustion models. I’ll never forget the month of April 2004. The first version of MOSES was due on May 1, and like any good researchers, we pulled an all-nighter—that lasted the whole month! This month-long all-nighter was required because we’d scrapped our original approach when we realized that an immersed boundary method wasn’t going to work for our purposes. Yet another time when throwing in the towel would have been easy, but I’m so glad we didn’t.

Fast forward to 2008 and a lot of changes were about to drop. Our company, Convergent Thinking, LLC changed its name to Convergent Science, Inc. We also changed the name of our software from MOSES to CONVERGE (fun fact: believe it or not, we discovered there was another CFD code called MOSES!). We were entering the automotive CFD market at one of the worst times in history for that industry. But we quickly learned that the financial crisis was motivating companies to make changes. Companies needed to tighten their belts and find the most efficient and accurate simulation tools possible—enter CONVERGE.

Sales of CONVERGE unofficially started where else but at the SAE World Congress in 2008. Daniel Lee, who was one of the original founders of our company, had left to pursue a career at Fluent (and later ANSYS) after graduating from UW-Madison in 1998. Ten years later, he had honed his CFD sales chops and was ready to come back to Convergent Science. Good timing, as Eric, Keith, and I had no experience selling software. So the four of us met at SAE, ready to take on the big players in the engine industry. No booth, no brochures, just Dan’s little sales notebook and phrases like “imagine a car without gas” (trying to make an analogy with “imagine a CFD code where the user doesn’t have to make a mesh”). These days gasless cars are a little easier to imagine, but our analogy sounded good at the time!

Our website circa 2009

Selling any software is difficult, but selling CFD software can be next to impossible when you’re dealing with companies that have an established workflow and years of experience with a legacy code. We heard a lot of “no” before hearing “yes.” We were told many times early on that we were, hands down, the best CFD code, but there was concern that our company was too small. Eventually, though, we convinced automotive engineers, and later engineers from a host of other industries, that we were (and still are!) a company dedicated to continued innovation and superlative customer service.

We’re also experts in our application fields. There really is something to all of the firsts that we’ve introduced to the community (autonomous meshing, direct detailed chemistry for combustion, grid-convergent Lagrangian spray modeling, cyclic variability with URANS, etc.), many of which were originally quite controversial. I like to tell students that if they’re not working on something at least somewhat disruptive in their research, it’s probably not that novel. Boy were we controversial with CONVERGE—many of the entrenched CFD best practices were based on software and hardware limitations rather than fundamental scientific concepts, and we challenged these practices with new ideas based on first principles. These innovations have no doubt succeeded in helping move the needle from postdiction to prediction over the last ten years, and these innovations have helped propel CONVERGE’s continued growth.

In 2018, ten years after we started selling CONVERGE, we have around 100 team members in our offices across the globe. Approximately 95% of engine makers in the US use CONVERGE, and around 85% of engine makers worldwide use CONVERGE. We’re taking our predictive CFD approach to new markets, and we’re once again changing the game with CONVERGE 3.0, which will be released later this year. CONVERGE has taken on a life of its own, with a large user community that includes engineers in industry, national labs, and universities. We have annual user conferences in both the US and in Europe (don’t miss our US event in Madison in September, celebrating CONVERGE’s ten-year anniversary!). Indeed, the quotation from Robert Fritz that I added to CONVERGE’s main.c subroutine many years ago has, in fact, come true: “At first, I am giving energy to the creation, but later the creation seems to be giving energy to me.” Happy tenth birthday, CONVERGE, may you continue to empower CFD users to never make a mesh again for years to come.