CAE Software Development
CAE software development is complex as hell. I decided to write down a couple of notes that resonate with me that I gathered during my 20-year involvement in it.
Follow the rules
Engineering software has one big problem: It should follow physical laws. And, Nature doesn’t want (let us) to get exploited easily. For some reason (ask the Creator), the Universe strictly insists that the physical laws are followed. Developing simulation software that perfectly mimics nature is challenging. There are no multiple ways to follow the natural laws. You either follow them or you don’t. Engineering isn’t like the arts (where everything is possible). And that brings an enormous amount of complexity and uncertainty.
Let’s kick it off with Formula One. It’s a perfect example. Everybody likes it. It’s high-tech, and so much aerodynamics is involved. For research, I asked ChatGPT 4.5 to “draw an image of Formula One with visualization of aerodynamics”. I received the following image:
Not bad. Sure, it’s complete nonsense. Knowledge required: Zero. Human effort: Almost zero. CPU power: 0.074 core*hours.
Then, I moved to Blender. I love Blender. In my opinion, it’s the best open-source software ever created, but let’s talk about it sometime next time. In Blender, I created a little project where I used the F1 tutorial (ad break: from CFDSUPPORT’s TCAE-Lite) and created a simple animation of what could look like F1 aerodynamics. Completely artificial and unphysical:
Just visualization that only looks like aerodynamics. Knowledge required: High school level. Human effort: 4 hours. CPU power: 0.2 core*hours.
Then, I moved to professional CFD software (TCAE). The same F1 model. A transient DES simulation with a 12M mesh was created and let it to simulate a few seconds of physical time.
Knowledge required: University degree (Ph.D. is beneficial). Human effort: 6 hours. CPU power: 768 core*hours.
As you can see, the CFD simulation is quite demanding on CPU power. Because it should strictly follow the physical laws. Engineering simulations are grounded in science and must follow the fundamental laws of nature. That implies that CAE software is much more science than art. There is only a very little amount of creativity involved in simulations. Software developers have to follow the rules. Strict rules. That’s the game we play.
My Journey
To give a little context, here’s a bit of my coding history. I started my CFD code development journey in 2003 at the Czech Technical University, Faculty of Mechanical Engineering, master’s degree with a specialization in Mathematical modeling in technics. I wrote my first CFD code completely from scratch to receive my master’s degree. It was a simple 2D solver of incompressible non-Newtonian flow. The code was based on a structured mesh, central-type numerical scheme (MacCormack). I used the programming language C. The implementation has taken quite a while. Several months (10 or so). And then boom, got it. I still remember that day when the code finally started working out. What a moment in the life of a soon-to-be engineer. I was proud, happy, and excited about it. My otherwise theoretical studies suddenly brought practical results. Because it’s most of all results that make engineers engineers. The world was mine for a while.
I continued with my Ph.D. at the same faculty with Mathematical Modeling in Physics, and the topic was Hemodynamics. The next challenge was a 3D code that simulated blood flow effects like variable viscosity, viscoelasticity, and coagulation. What a disappointment, when I, after a little review, realized my original 2D code can hardly be redesigned and is useless for my further research. I had to start again from scratch with a new architecture which I thought was C++ (not really, but I didn’t know at that time). I used the same numerical approach (MacCormack scheme, TVD version) in 3D. Bad news: programming a 3D code (cells now have six faces, and each face has eight dual faces) is way more complex than 2D code. The third dimension and new physics brought another level of complexity. Good news: Programming the second code somehow goes way faster than the first one. I worked as a night receptionist in a hotel in the city center (no way to survive on the Ph.D. scholarship at that time). The first working version of my 3D (much more complex) code has taken only about a week of (night) work. Why? The experience matters. A lot.
Lessons learned: Codes can die or become obsolete and must be vastly redesigned. Experience counts.
The whole third year of my Ph.D. I spent time at The von Karman Institute for Fluid Dynamics in Belgium. I worked there on the CFD FEM C++ Finite Element Solver for Variable Density Flows, a new module for their large multiphysics code, CoolFluid. This was a level up where I first learned about professional code development. About related processes, structure, tracking, versioning, testing, and so on. The biggest lesson with CoolFluid was realizing the difference between one-man-show development and team development. Developing software in a team has different dynamics and requires proper leadership, rules, structure, and regular communication.
After completing the VKI Diploma in the summer of 2009, I returned to Prague to finish my Ph.D. I have always loved practical applications. In the last year of my Ph.D., together with my like-minded colleague Jiri, we decided to found CFDSUPPORT and provide hi-tech consultancy & development for CFD research departments. (My oldest son was born here.) We thought we could disrupt the market with super high-tech programming for CFD. We wanted to create a new code with the added value of the implementation of the latest simulation methods. But it looked too long and risky to bring something completely new. Quite soon, we decided to build our work up on existing tools – open source. From there, it was quite straightforward. We started using and developing OpenFOAM to deliver OpenFOAM-based workflows. The beginnings were difficult, but after a few years, we had our team of developers, and our products were quickly improving. By that time, I realized that I could help best as a product manager rather than a coder. Leading a team of developers brings another level of complexity. And responsibility. For the team, users, company, in a wider context for a family, and for promises we gave to all sides.
With our skin in the game, we went to the market. And here we go again. A new complexity popped up in the form of interaction with software users and their expectations. The issue was that everything had worked perfectly when we coded and tested just for us and did all our consultancy projects internally. But when we handed the simulation workflow over to clients (command-line OpenFOAM-based workflows), it was a nightmare to support it. The issue is that when you develop for a broader audience, it means accounting for diverse user needs, scenarios, an extremely wide range of input data (sometimes absurd), specific hardware configurations, operating system versions, software conflicts, and more. We had to level up all the processes, especially the error handling, user-friendly design, and software testing.
CAE Market
The market with CAE technologies is quite competitive. Established tools set high standards, so breaking in requires unique features, significant improvements, or niche applications. How does one develop software for a penetrated market where “good enough” is standard? Or worse, how to develop for a market where the prevailing mindset goes like: “We always did it this way.” Many users are voluntarily “vendor-locked” and don’t seek the world outside the bars. For many reasons. Trying something new could look too risky for engineers and especially for managers.
Over the last few decades, engineering simulation software has developed tremendously. And so have the users’ expectations. Nowadays, only perfect software can succeed. This effect eventually happens in every penetrated market. I recently heard a podcast with a prominent electric carmaker CEO, who made a complaint that the car market is so competitive (which means that perfection is standard), and there is no space for errors. Ok, it was Elon, and he made a parallel that a car has about 10,000 components, and if just one component of them all is poor, the whole car (product) is poor. I think every penetrated market suffers from this effect, including CAE. There is no space for error; in other words, users do not tolerate dysfunction because it’s too easy to look after something else.
Another interesting (for some surprising) fact is that competing with low prices doesn’t work. In the B2B decision process, the software price is often a factor of 4 or 5 or even more. Businesses weigh goods by many factors. Technical specification, added value, risk of failure, time to full production, change management, total cost of ownership, individual opinions, and more. All of that has to bubble through the labyrinth of the informal enterprise structure. It’s not intuitive, but perfectly logical: software price is not a top factor in the decision process.
In the CAE market, the new entrants have to differentiate themselves. And not just a little. Slight improvements wouldn’t work. They would never overcompete established tools due to vendor lock, difficult change management, and fear of failure. For market disruption, it would only work with a 10x mindset (10x = 10 times more value, faster, better). Revolution rather than evolution.
The SaaS Trap
Over the past decade, we’ve seen the rapid growth of Software as a Service (SaaS) platforms, driven by substantial investments. At first sight, SaaS seems appealing, but it’s associated with significant issues, especially regarding long-term sustainability. Are engineers genuinely satisfied with merely accessing a service? Do you know any engineer who prefers not to have control over their processes?
Engineers typically value having direct control, customizing and constantly optimizing their workflows within their own environment. Intellectual property security is another critical concern – a silent thief of know-how that will ruin businesses in the long term.
Most of all, I think that SaaS fundamentally misunderstands and underestimates the power of the connection between engineers and their technology. This relationship is often as close and personal as that of a parent and child. Engineers nurture, refine, and grow their tools with deep care and attention. I can imagine that SaaS can eventually become a dead-end solution (not to mention a SaaS Blak Swan = AI ); it’s easy to adopt but equally easy to lose. Relying on SaaS could trap users: if the service ceases operation, engineers risk losing access to their critical technology and data entirely, leaving them empty-handed.
Software Lifecycle
Did you know software has its own lifecycle? In the beginning, software undergoes rapid development (a happy period) with significant advancements and quick feature additions. But later, as the software matures, the focus shifts toward maintenance and enhancing customer satisfaction. It’s logical. The team is motivated to keep the current users (relations have been established) rather than acquire the new anonymous ones. On top of that, every few years, the software typically needs to be redesigned to align with the latest standards and ever-changing circumstances. BTW, we’ve completely redesigned TCAE two times in the last decade. Software is never finished. It is a live entity closely tied to the ecosystem in which it lives.
CAE Software Development Challenges
CAE software development has several internal challenges. The typical one is creating departmental silos. Each team often pursues unique goals. For example, developers naturally go for perfect architectures. Technical support prioritizes resolving bugs. Users demand accuracy. Salesmen desire ease of use and rapid market availability. Aligning all these individual goals demands careful coordination and clear communication.
Productivity matters. It’s my big personal topic. Productivity is essential and not only in software development. Keeping the balance between perfection and practicality is not easy – but it is critical. Recognizing when ‘good enough’ is sufficient saves valuable time and resources. Perfecting every detail isn’t always necessary; knowing when to stop is crucial for time to market. And time is everything. In my 15-year career as a product manager, I have met a few outstandingly smart developers who constantly have been failing to be productive. Unfortunately, being smart doesn’t necessarily correlate with productivity. Not at all.
Consider the following parallel: In the manufacturing factory, at an assembly line, the best worker of them all is 30% faster than the average. In engineering development, the best developer is 300% (easily) better (faster and more productive) than the average. Mindpower operates differently than manpower. Adding more people to a team doesn’t necessarily lead to better results, especially in complex and creative environments like CAE software development. Larger teams often suffer from communication breakdowns and the “lost in translation” effect. In reality, a small, highly skilled, and well-coordinated group of motivated experts can easily outperform a larger group of average developers. Quality, focus, and alignment count twice. In other words, in software development, even small teams (like CFDSUPPORT) can be very effective because it’s all about quality – not about quantity.
Importance of Documentation
Creating documentation isn’t very popular, right? But it’s critical for long-term sustainability. Although creating documentation can feel like short-term pain, the investment pays off as a significant long-term gain, ensuring the consistency, maintainability, and longevity of software projects. For many reasons. I recommend building the documentation processes into the company’s culture as early as possible because later, the pain of starting a sustainable documentation process grows exponentially in time.
CAE Software Testing
Effective CAE software testing includes multiple layers, such as unit, integration, and system testing. Benchmarking also plays a critical role by validating simulation software accuracy against physical measurements. Comprehensive testing ensures software reliability, stability, and optimal performance for users. Any software can only be as good as its test processes. Oops, the testing topic would deserve its own article. I’m leaving it right here …
The Biggest Trade-Off in CAE
If you ask engineers what they value most in simulation software, the prevailing answer is: accuracy. Accuracy is by far the most desired feature for users. However, if you’re developing and selling engineering software, your top priority is robustness – the ability for the software to perform across a wide range of applications and usage scenarios. And that’s a problem. Robustness kills accuracy and the other way around. Improving one can harm the other. This trade-off is embedded everywhere – from geometry handling to physical models and the stability of numerical schemes. Software developers must constantly make hard choices. And that makes this balance the biggest trade-off in CAE software development.
Can Software Be Smart?
Some time ago, at a lunch with one of our top clients, I was explaining (ok, I was complaining about) the lack of experience of the software users. I wend like how it is difficult to support complex workflows if industrial users are missing time, and often knowledge and experience. The client asked me if it would be possible to build the user experience into the software. This idea has concerned me a lot since then. Now, in the age of rising AI, more than ever, you would ask yourself: Can software be smart enough to guide its users? In CAE, embedding experience directly into the software can make a substantial difference. Intelligent defaults, guided workflows, and contextual help can transform a complex simulation environment into a more intuitive and efficient experience. The more general-purpose the software is, the harder it gets. Ok, let’s work on it.
CAE Isn't a Calculator
Yes, this is my heart’s topic. I say it in the door everywhere I go: CAE isn’t just a calculator. There’s nothing like the exact answers to pair exact questions. Unlike exact arithmetic operations, engineering simulations inherently involve a certain amount (hard to quantify) of uncertainty. Simulation results will always be approximations – whether in the geometry, boundary conditions, material models, or numerical methods. Keeping this in mind is essential for both users and developers. The quality of the results depends most of all on the users’ knowledge, experience, and effort. The software only emphasizes these three.
The Ultimate Measure
It has taken me years to realize this. The true measure of success in CAE software development isn’t just about features, speed, or the most wanted guy (accuracy) – it’s about people. Happy clients who stay, evolve with the software, and genuinely trust the tools they use are the best proof that you’re doing something right. That kind of loyalty doesn’t come from marketing or buzzwords (ups, did I say that?). It comes from building real value, listening with intent, playing fair, and acting with transparency.
When you deeply understand your users’ needs and continuously innovate to meet them, then some good things eventually happen. But what makes it even better isn’t just the cold product – it’s the relationships. The laughs shared during support calls, the small celebrations when a tricky bug is finally fixed, or the joy when a user gets that “aha” moment. These little guys are the real wins.
In the end, software is written in code, but success is written in relations. If we enjoy the journey together – users and creators, engineers and developers – then we’re already winning. And if we have a bit of fun along the way? Even better.
lubos.pirkl@cfdsupport.com