Our simulation tools

We are an independent, consultancy: we do not sell software and we do not distribute equipment. Therefore, we have no interest in prescribing one tool over another, and we choose the one that allows us to address the problem and justify the result.

This position has a practical consequence for our clients who do not have a simulation environment. Depending on the need, we deliver either the result alone, accompanied by its calculation note and assumptions, or the complete model. In the latter case, the model is open source: your teams can open it, read it, modify it and run it without acquiring a licence, and without depending on us to operate it.

The transparency of the equations is not just a principle. It is what makes a justification readable by a third party and a tool qualification achievable, where closed code forces trust in its publisher.

If you already have dedicated tools, we adapt to your environment. We notably hold a licence for Dymola for Modelica led in the chains of our clients: open source is for us a methodological choice, not a budget constraint.

A study rarely mobilises a single tool. 3D calculation feeds the system model, the input data feeds the model and the note, the results feed the report. Each manual transfer between these steps is both a delay and a risk of discrepancy between what has been calculated and what is written.

We have therefore built our tools to communicate. The models are generated and driven by scripts, exchanges between codes go through open standards, the input data comes from a single source, and the notes automatically retrieve the results. The following blocks describe these building blocks.

The benefit is measured at the moment the project changes. A revised hypothesis, a modified interface, or an added calculation case results in a restart of the chain, not a reconstruction of the study.

We conduct our system studies in language Modelica which is adapted to system modelling and component coupling. The 0D/1D approach allows simulating an entire system (production, distribution, consumers, regulations) with computation times compatible with campaigns of several hundred cases.

This is what makes possible what a 3D calculation does not allow: exploring parameter ranges, comparing architectures, quantifying sensitivities, and identifying the truly dimensioning quantities before finalising the design.

The interest of these models lies in the mastery of assumptions. We know what each component contains, which phenomenon is represented and which is neglected, and we can therefore state the validity domain of the model condition for a result to be defensible in instruction.

Our Modelica libraries are developed in-house. TAeZoSysPro, dedicated to the simulation of ventilation systems, is co-developed with EDF R&D and qualified in the sense of guide no. 28 of the ASN, with theoretical note, component validation, reference cases, and non-regression tests. ChillerSysPro covers the behaviour of refrigeration units with different fluids and operating conditions. We also contribute to the OpenModelica consortium.

The same logic applies to CFD. We develop user functions in code_saturne to adapt the models to the encountered problems and reduce computation times, and we communicate directly with its developers about the tool's developments.

For a client, the difference is concrete: a limitation of the tool is not a limitation of the study. When a phenomenon is not represented by standard models, we implement and validate it, instead of circumventing the problem with an upper hypothesis whose cost no one can quantify.

The system approach relies on volumes considered homogeneous. Certain configurations invalidate this assumption: natural convection, stratification, spatial distribution of sources, flows strongly dependent on geometry. 3D calculation then becomes necessary, not to replace the system model, but to verify or correct what it assumes.

We use code_saturne, developed by the R&D of EDF, for thermo-aerodynamic and fluid simulations, and code_aster for mechanical analyses: forces, displacements, stresses and eigenmodes.

These calculations do not remain isolated. The 3D results are reinjected into the system models in the form of exchange coefficients or adjusted correlations, so that sizing studies rely on a representative local behaviour while maintaining the speed of the 0D approach.

We develop in Python the specific models for which neither a system library nor a 3D calculation is the right tool, as well as all of our tooling for automation : 

• generation of models and test cases,
• launching campaigns,
• post-processing and production of figures.

A study structured this way can be resumed in a few hours when a data point changes, whereas a manual chain would require everything to be redone.

The standard FMI allows us to export our models to communicate with each other or with your own tools — neutronics, thermohydraulics, control-command — while keeping each discipline in its reference environment. Coupled with Python, it also allows for the construction of graphical interfaces that exploit the models in real time, useful for decision support as well as for training operational teams.

This automation finally opens access to probabilistic studies. With Persalys, we propagate uncertainties on input data to distinguish what falls within physical margins from what is due to conservatism in assumptions.

In a project where input data evolves, the same value ends up being copied into a model, a spreadsheet, and several notes. When it changes, the update is partial and the discrepancy only appears at the final review, or even in instruction. This mechanism is one of the primary causes of error in long studies.

We have developed SAPPHIRE, our Python tool for a single source of data. Each input variable is defined once, with its unit, origin, and status, and then referenced by the models as well as by the documents.

The writing of the notes relies on Typst, which directly queries this source and automatically integrates the results and figures produced by the models. A data revision then becomes a re-triggering of the chain, rather than a manual check of each document.

Models, scripts, and documents are versioned under Git, on our instance of Gitea. Each modification is dated and attributed, the changes are reviewed, and regression tests are executed on the libraries. A delivered result can be linked to a specific version of the model and the data that produced it.

This traceability is what makes the qualification process possible, and what allows a study to be revisited several years after its delivery — a common situation when a file returns for processing or when an installation evolves.

The choice of open and lightweight tools also contributes to this. A text model, a Python script, and a Typst note remain readable and executable without depending on the commercial roadmap of a publisher or an obsolete proprietary format.