The questions you're legitimately asking about Open Source simulation

You may have been using Ansys, Abaqus or COMSOL for years. Your teams know them inside out, your processes are locked in, your clients accept the results. Considering open source, even partially, raises legitimate questions.

Here are the most common ones.

"Is it as accurate as a commercial solution?"

Yes. And this isn't a leap of faith: it's both verifiable and verified.

Take the example of Avnir Energy, an engineering consultancy specialising in the nuclear sector. Their challenge: reducing their dependency on proprietary licences without sacrificing the accuracy and reliability of their simulations. Pipe support calculations to RCCM standards (nuclear) are complex studies requiring a very low level of uncertainty.

The approach was methodical. First, conversion scripts were developed to automatically translate Ansys input files into code_aster format, making the transition seamless. Then, rigorous verification: same geometry, same boundary conditions, systematic comparison of results. The discrepancies observed between the two solvers were minimal — on the order of what you'd see between two competing commercial software packages.

The Polish engineering firm Fortlab Polska followed a similar approach. Before adopting code_aster, the team conducted "several tests on reduced models, comparing code_aster with other open source solutions and proprietary software." Their conclusion: code_aster met their accuracy requirements for complex dynamic analyses — non-uniform support excitation, advanced material models — that commercial solutions did not cover.

This result is hardly surprising. Code_aster benefits from a level of Validation & Verification (V&V) that few software packages, commercial or otherwise, can claim. code_aster has a base of over 4,000 documented test cases, covering all its capabilities: linear and non-linear mechanics, thermal analysis, contact, fatigue, dynamics, and more. Each new release is tested against this entire base. Any regression is detected immediately.

It is this rigour that allows engineering firms like Avnir Energy, and any industrial player, to migrate to open source with confidence. This validation rigour is not an isolated French case, nor is it limited to code_aster. NRG Pallas, in the Netherlands, also uses openTELEMAC for its estuary dispersion studies — an independent validation of the code's robustness in a demanding regulatory context.

"Is it complicated to install?" "Do I need a PhD in Linux systems?"

Of course not — it installs like an app on your phone. But even when it doesn't, it's not an insurmountable or extremely costly hurdle.

In practice, Simvia provides pre-configured environments and packaged installations. Aether Engineering uses "the Docker images and Singularity solution provided by Simvia," allowing them to deploy code_aster on a local workstation, on a server, or via the web.

Typical transition timeline:

STEP DURATION Installation and configuration 1 to 2 days Initial team training 2 to 4 days First calculations on real cases 2 to 3 weeks Autonomy on standard cases 1 to 3 months Advanced proficiency 6 to 12 months

At Holcim, adoption happened organically: "The group adopted SALOME and code_aster on the recommendations of people internally. By capitalising on their knowledge and expertise with these solutions, they gradually trained other people within the group."

"Who do you call when it doesn't work?"

The code_aster and code_saturne forums have thousands of discussion threads. Answers come from EDF R&D engineers, researchers, and other industrial users. Every exchange is public and archived, forming a living knowledge base. Holcim's experience confirms this: for a team that can't always arrange specialised training, community documentation and forums are a major asset. (See Arnaud Delaplace's full testimonial in Part IV.)

Simvia also offers contractual support: technical assistance with guaranteed response times, priority fixes, and help resolving complex problems. This is professional support, sized for industry and delivered by engineers experienced in modelling and scientific computing.

The difference from conventional proprietary support? At Simvia, the people who answer are the same ones who know the code from the inside. No Level 1 support reading from a script, no ticket lost in an anonymous queue.

"Will my teams be able to use it?"

Your engineers know their current tools — the shortcuts, the pitfalls. Switching software means losing those bearings, at least temporarily.

But this concern often rests on a false assumption: that open source is harder to learn than commercial software. In reality, the fundamental concepts are the same. An engineer who understands continuum mechanics, meshing, and boundary conditions in Ansys will find the same concepts in code_aster. What changes is the interface and the syntax, not the engineering.

What makes the difference is the support. A successful migration involves:

Targeted initial training: a programme focused on the team's actual use cases. Avnir Energy's example illustrates this: four two-hour sessions were enough to make a team autonomous on their pipe support calculations. Operational mentoring: an expert available on demand to unblock real-world situations, review early models, encourage teams to push further, and validate practices and results. Transition tools: conversion scripts, input file templates, libraries of test cases tailored to the business context. Everything that reduces the friction of the first few days. After a few months, most teams find that they have not only recovered their previous level of productivity, but gained a deeper understanding of what the solver actually does. Because open source, by nature, exposes more of the underlying physics. It's an investment — but one that makes your teams more competent.

This is confirmed by Ioannis Christovasilis of Aether Engineering: "The main challenge isn't financial — it's above all a human one. Adopting open source solutions requires a significant investment in time and skills. But this approach delivers a return on investment that proprietary solutions simply cannot match: upskilling of teams, development of cross-disciplinary skills, and gains in time and productivity."

"Do we have to migrate everything at once?" / "What about our existing models?"

Most of our clients start with a targeted scope: a type of calculation, a team, a project. This is exactly the approach Fortlab Polska took: "Initially, we ran several tests on reduced models, comparing code_aster with other solutions. In parallel, we worked on a script to convert our own models and automate the creation process." A methodical approach that allowed them to validate their choice before scaling up.

Conversion tools exist for the main formats. Simvia can also develop bespoke scripts. This is what was done for Avnir Energy, with automatic converters from Ansys to code_aster. Model migration is a project, not an insurmountable wall.

Some clients never fully migrate, in fact. This is the case at Holcim: "Within the Group, we use proprietary solutions and applications, as well as open source applications such as code_aster and SALOME."

As we like to say: open source doesn't lock you into anything. Not even into open source.

"If it's so good, why isn't everyone already using it?"

Because the simulation market has been structured around the proprietary model for thirty years.

Commercial vendors have built powerful ecosystems: polished interfaces, certified training programmes, reseller networks, presence in university curricula. That's a real legacy, and these solutions continue to meet legitimate needs.

What's changing is the context. Licence costs are rising faster than budgets. Dependency on foreign vendors raises sovereignty questions that nobody was asking ten years ago. And open source solutions have reached a level of maturity that makes them viable for daily industrial use.

The shift is underway. From large corporations to innovative SMEs, a growing number of players are making this choice — not out of ideology, but out of industrial pragmatism.

"Will these software packages still be around in 10 years?"

Investing in a migration, training your teams, adapting your processes… none of this makes sense unless the tool will still be maintained over the long term. The romanticised image of open source — projects carried by passionate volunteers in their spare time — can legitimately raise doubts about longevity.

But the software we're talking about here is anything but amateur. They have been developed for decades by EDF (sometimes in consortia, such as SALOME with the CEA) and are used daily to design nuclear power plant components — equipment with lifespans measured in decades. EDF has a direct strategic interest in maintaining and evolving these software packages. These are not "side projects": they are critical industrial assets. As such, the group invests between 3 and 5 million euros per year in the development of each of its codes, sometimes supplemented by consortium funding.

This reality offers a guarantee of longevity that many commercial vendors cannot claim. How many proprietary software packages have been abandoned, acquired, or merged in the course of market consolidation? Open source backed by industrial players avoids this risk: even if a contributor withdraws, the code remains available, documented, and maintainable by others.

This stability also attracts the academic world. Aarhus University in Denmark has integrated code_aster into its structural mechanics research programmes. A choice that ensures their doctoral students work with a tool they will find in industry, and whose source code they can explore. When a university makes that bet, it's a strong signal: they are backing a tool that will still be relevant in ten, twenty years.

The real question is therefore not "Will open source still be around?" but rather "Will your current vendor still be independent?"