I was born in Montreal, Quebec, Canada to an Irish mother and a French-Canadian father. We moved to Northern Michigan just before first grade, and it was there that I attended school through the twelfth grade. I was always interested in math and science as a kid, but I also liked the arts (especially music). I pursued a physics major at Lawrence University (a small, liberal arts school in Wisconsin), because I liked applying mathematics to describe the physical world.

My junior year, a few of my classmates and I convinced the department to let us do an independent study in Fluid Dynamics. I quickly realized that I liked this even more than the quantum mechanics and solid-state physics we had been learning throughout my degree. Everything came together during the summer between my junior and senior year. I stayed at the university to conduct theoretical research on the instability at the interface between two immiscible fluids. Some of the calculations I could do by hand, but my advisor, Professor Cook, introduced me to a code called FIDAP, a finite element CFD code, for doing more complicated problems. I was hooked.

John Chawner (JC): Coincidentally, my career direction was also strongly influenced by the summer between my junior and senior years when I worked at NASA Lewis (now Glenn) using a rudimentary CFD code.

I knew I wanted to do CFD in graduate school, but I honestly didn’t care what the application was. I decided to attend the University of Wisconsin-Madison and pursue CFD of internal combustion engines at the Engine Research Center (ERC). Before that, I barely knew what an IC engine looked like!

JC: I still don’t know what an IC engine looks like but I’ve made it clear I’m not a car guy.

At the ERC, we mainly used a code called KIVA, which was a great code to learn on. I worked on spray modeling and introduced genetic algorithm optimization to the combustion engine community. KIVA was a good code, but it was very difficult to make meshes for complicated, moving geometries. Many students spent a large portion of their graduate school days creating their meshes as opposed to running the simulations needed to write their thesis. This bottleneck is what motivated us to write CONVERGE after we formed our company. CONVERGE is a CFD code written from the ground up to intimately tie the computational mesh to the solver. The user doesn’t have to create a mesh; the mesh is automatically made for them at runtime. Commercial sales of CONVERGE started ten years ago in 2008. Since then we’ve grown organically from a few people to over 100, with offices worldwide.

• Location: Madison, Wisconsin USA
• Current position: Co-owner
• Current computer: MacBook Pro, 3.3 GHz Intel Core i7, 16 GB RAM
• One word that best describes how you work: Passionately

JC: [Note to editor: Hey, when did we change the title of this series? What’s this “don’t mesh” business?]

How do you know Pointwise?

I dabbled in Gridgen in graduate school. I also met some of the Pointwise staff in Japan years ago when we shared the same distributor. You and I are Twitter friends. We both love meshes but have different views on the best way to create them.

JC: Dabbled? C’mon, admit that you gridded. And loved it. And still do. Seriously, I still remember corresponding with Prof. Rutland at the ERC on their Gridgen license back in the day.

KS: Yes, I definitely gridded, but only dabbled in the Gridgen software. Most of my gridding was done using in-house tools. I did not love meshing (hence the motivation to write CONVERGE), however it could be very satisfying to complete a mesh and have it run correctly, especially for complex, moving geometries. But the problem was that it took so long to create the first mesh, there was no way we were going to create more meshes with different resolutions. As a result, we really didn’t know if we were anywhere near grid convergence. Hence we would tune models to account for what was, most likely, error from being under-resolved.

JC: Grid convergence, for better or worse, remains an open issue if only from one of runtime. And the manner in which one obtains a family of meshes suitable for a grid convergence study is a bit more challenging with hybrid unstructured meshes than it was with structured grids.

KS: I agree it is more challenging with hybrid unstructured meshes. This is one of the benefits of our Cartesian meshing approaches. It is very easy to perform grid convergence studies and they are routinely done by our users.

What do you see are the biggest challenges facing CFD in the next 5 years?

Maintaining a good balance between accuracy and runtime. Industry needs faster simulations to make design decisions quicker; however, for CFD to be truly predictive we need higher mesh resolution, less empirical modeling, and fully transient simulations.

JC: I’m glad you and I agree that everyone needs more meshes and bigger meshes. But the three things you cite will impose quite a heavy computational load: more mesh, direct simulation, and time accuracy. How do we regain runtime?

KS: Scalability is key to regaining runtimes. We have spent the last few years rewriting CONVERGE such that it scales well on 1000’s of cores, for even the most complicated cases. The improvement in scalability over our current release version of CONVERGE is staggering.

What are you currently working on?

Personally, I am working on business aspects of Convergent Science, including marketing, international growth, and strategic collaborations. I still frequently sit in many meetings with our applications and development engineers and offer direction and advice as needed.

As a company, we are working hard on finishing up our next major release of our CFD software: CONVERGE 3.0. This new version includes a significant improvement to our load balancing algorithm for massively parallel calculations. It also adds some very powerful new meshing capabilities that will allow us to expand into external flow calculations, for example, with efficient cell counts and runtimes.

JC: New meshing is always awesome. Care to say more?

KS: One criticism of our current meshing approach is that in order to add more and more resolution near a boundary, the embedding occurs in all three directions. Often for boundaries, high resolution normal to the wall is good enough and keeps the cell count relatively small as the cells can be stretched in the other directions. CONVERGE 3.0 allows for ‘boundary layer meshing’ near walls, with our adaptive, Cartesian approach in the interior. The whole approach is still autonomous, and the user can choose whether they want to use boundary layer grids or not.

What project are you most proud of and why?

If I can call “Convergent Science” a project, I’ll go with that. I’m insanely proud of the company and product we’ve built, especially over the last decade. Perhaps the most rewarding part is following the evolution of our employees – starting as new hires and developing into world class engineers and business professionals. It’s legitimately fun for me to come into work (most days!) and interact with our amazing team at Convergent Science.

JC: That’s a perspective that you and I share. As our careers have advanced and time has passed it’s the relationships we’ve made, professional and personal, that matter more than any specific bit of code we wrote or simulation we ran.

KS: Well said.

If I need to dial down to a specific technical project that I worked on, I might pick the grid convergence work that I led back in the 2010 timeframe. Before this study, spray and combustion modelers tended to tune model constants to get the right “answer” without considering the large errors from being under-resolved. Now it’s commonplace to run with a resolution that is sufficiently grid converged and do much less model tuning. Our autonomous meshing makes this possible – adaptive mesh refinement automatically puts the resolution where it’s needed, while keeping the rest of the domain relatively coarse.

JC: OK, so let’s dig into your “autonomous” meshing. If I understand you correctly, autonomous implies two things: automation (i.e. without human intervention) and acting independently. The latter is the adaptation, presumably. What triggers that?

KS: Our Adaptive Mesh Refinement (AMR) can be triggered by one flow variable or a combination of flow variables, such as velocity, temperature, species, etc. We can also adapt on y+ near boundaries. AMR occurs if the value of the sub-grid field (the difference between the actual field and the resolved field) is above a specified value. We often say that it’s steep gradients in a variable that triggers AMR, but really it’s the curvature, or second derivative, of the variable that does this. AMR also gets released from areas where it is no longer needed, thus keeping the overall cell count low while maintaining the resolution where it’s needed the most.

JC: And for automation, how do you balance the need for the initial mesh to capture the physics from the start in order for the adaptation to not miss anything important?

KS: This is a great question. The user has control over the initial mesh through both an overall cell size (we call this our base mesh) and also a set of fixed embedding options. Fixed embedding is simply set through a few input fields and can be used to add resolution near boundaries, within various shapes, etc. So with fixed embedding, the user has control over what the initial mesh looks like. Fixed embedding is also used to “seed” AMR to ensure that something isn’t missed before AMR kicks in.

JC: Fixed embedding sounds very similar to our use of Shapes as clustering sources (introduced in 2016). As the name implies, a Shape is a box or cylinder or sphere onto which mesh edge length attributes are applied. The Shape is placed anywhere within the volume and influences the clustering of any volume or surface mesh it passes through.

KS: Yes, we have shapes such as boxes, cylinders, and spheres. You can embed at any level beyond the base mesh within these shapes. Fixed embedding can be turned on and off at any time during the simulation.

Are you reading any interesting technical papers we should know about?

These days when I find a good technical paper I usually hand it off to one of our rockstar development or applications engineers. However, I do have Gautam Kalghatgi’s “Is it really the end of internal combustion engines and petroleum in transport?” in Applied Energy on my short list of things to read (spoiler alert – the answer is “no”).

What software or tools do you use every day?

I can’t live without Slack. I’m forever fighting my inbox, and Slack really helps reduce a lot of my internal emails.

Even with Slack, I still spend a lot of my day in email. Airmail  is my email client of choice.

I’m trying to get better about using it consistently, but Asana really helps keep team-based projects organized.

It seems like I’m constantly making my next presentation. Powerpoint? Never heard of it. Keynote’s my go-to.

JC: Makes me wonder about the Vim vs Emacs question.

KS: When I wrote code all day I was definitely on team vi!

With offices around the world, we would be lost without a video conferencing service. GoToMeeting is our current tool for web meetings.

LinkedIn. Follow me at https://www.linkedin.com/in/senecal/ if you dare.

What does your workspace look like?

Do you plan on attending any conferences or workshops this year?

This year I attended WCX18 (SAE World Congress) in Detroit; Intermat 2018 in Paris, France; and the International Combustion Symposium in Dublin, Ireland. I gave an open seminar at the University of Oxford on the topic of combustion modeling. I will be delivering a keynote speech at the ASME ICEF conference in San Diego in November. I also attended the ribbon cutting ceremony for the Center for UAS Propulsion at Aberdeen Proving Ground in Maryland and the ARPA-E workshop “Machine Learning-Enhanced Energy-Product Development” in Falls Church, Virginia.

Convergent Science hosts meetings for our users every year in both North America and Europe. This year the CONVERGE User Conference-Europe was held in Bologna, Italy and the CONVERGE User Conference-North America was held here in Madison.  Our conferences are a great way for the CONVERGE community to learn from each other in a relaxed environment.

What do you do outside the world of CFD?

I have a lot of musical instruments but little time to play them. I love seeing live performances – concerts, musicals, almost anything live. I’m a huge Wisconsin Badgers sports fan with season tickets for both football and basketball.

I really enjoy public speaking and communicating scientific ideas to the non-scientific community. My pet project is speaking out against the demonization of the IC engine. This year, I’ve given invited talks at Argonne National Laboratory, Kohler Engines in Italy, and the Intermat conference in Paris. I will be traveling back to Italy this month to speak at the University of Modena and Reggio Emilia (UNIMORE) on this topic.

JC: Yet you continue to demonize meshing.  Interesting.

KS: I don’t demonize meshing. Using the car analogy, it’s the difference between someone driving the car themselves and having the car drive for you, autonomously. We’re not throwing away the car, just saving the driver some effort. With CONVERGE, we’re not throwing away the mesh – the mesh is an extremely important part of the CFD process – we’re just creating it in a much more efficient and (in my opinion) smarter way. Unlike with cars, our autonomous meshing is very robust and mature, but the analogy is still a good one.

JC: Yep, I get it. Autonomous meshing is like driverless cars. I’m fascinated by how we’re both moving toward the same result just from two different starting points. Pointwise is engaged in research with MIT to automate the generation of boundary-fitted hybrid meshes. Part of that work is simple reasoning about what the geometry model looks like to figure out how to resolve it. But the more interesting – to me – part is attributing the model in the design system to explicitly define how the meshing is to be performed automatically. Imagine importing your geometry model and boom – it’s automatically meshed, surface and volume. The initial results are impressive and it’s likely some of that “boom” will be added to the product in 2019.

KS: Wait a second, this is what we do! We import a geometry model and boom – it’s automatically meshed! The difference is that our mesh is intimately tied to our solver, and the “boom” happens at every time-step due to AMR. Making the boom happen very fast (which is necessary if you’re doing it every time-step) is a critical piece of our method.

What is some of the best CFD advice you’ve ever received?

It’s not advice that was given to me personally, but something I read online that helped validate what we had been doing with our CFD approach. Here’s the story: We had been developing the autonomous meshing approach (i.e., “never make a mesh again”) since the early 2000’s, with our first commercial release in 2008. When we initially brought our product – a CFD code with the mesh automatically created at each and every time-step depending on the flow conditions – we were met with skepticism by some who felt that they themselves had to have full control over the mesh generation process. Knowing we couldn’t have been the only ones to believe in autonomous meshing, I took to Google and found slides for a talk describing “meshing by guessing” by McGill University’s Wagdi Habashi. Professor Habashi asks the question: “For the same geometry, the optimum grid is different for different Reynolds numbers and Mach numbers. How can the user be asked to generate it?” Indeed, the flow itself knows better than the user where mesh resolution is needed. I still use Habashi’s terminology in some of my presentations today.

JC: I think I’ve read that same presentation by Prof. Habashi. Yet I’d make the case that we don’t have a good practical grasp of what the “optimum grid” is for any case. And in practice for many cases we can get good enough engineering results from a fixed grid generated in advance. After all, that’s the job of verification and validation, right?

KS: We don’t have a good grasp of this, which is why we should give power to the flow to help determine where resolution should go. Verification and validation is extremely important, of course, but we can only do this for some sub-set of geometries and conditions. In order to head down the path of predictability in CFD, we need to be confident that when we change the geometry or conditions such that flow patterns are very different from what we’ve validated, the mesh will automatically account for that.

JC: Here again is a case of us saying the same thing, “folds in the same cloth” as the old saying goes. Pointwise has extended the concept of clustering sources that I mentioned above to point cloud sources for mesh adaptation. The solver gives us a point cloud at which an edge length is specified. The mesher will adapt to that edge length and return the mesh to the solver. In fact, the point cloud can be used to adapt virtually any mesh, not just the one from which it was computed.

KS: Sounds like a very interesting methodology. I look forward to seeing it in action.

If you had to pick a place to have dinner, where would you go?

Madison has so many great restaurants. I love Muramoto for sushi. Other favorites are Tornado Steak House, Graze, and L’Etoile. For burgers on gameday, you can’t beat Dotty Dumpling’s Dowry.

JC: I told you that on my recent trip to Madison (when we made the infamous arm-wrestling photograph) I enjoyed dinner at Eno Vino. Now I’ve got a game plan for the next time I’m in Madison. Start thinking of ideas for our next photo shoot.

KS: You’re welcome back to our office any time. Perhaps we can get a picture of you running CONVERGE!

JC: Running an autonomous bit of software seems like it would make for a dull photo. Next time you’re in Fort Worth, we’ll get one of me forcing you to generate a mesh!

Lesson Learned: Sometimes things that seem like opposites are in perfect alignment. Kelly and I had fun writing this rather silly edition of This Is How I Mesh.