Custom Computer Aided Engineering: from custom physics solvers in C++ and Fortran to pre- and post-processing tooling around ANSYS, Abaqus and OpenFOAM. For engineering teams that are hitting the limits of their standard package and need specialist simulation that is accurate for their product, sector or client.
Computer Aided Engineering is a broad field: Finite Element Analysis for structural calculations, Computational Fluid Dynamics for fluid flow, electromagnetic simulation for antenna and motor design, multibody dynamics, acoustics, thermal analysis. For most standard questions, ANSYS, Siemens Simcenter, Dassault Simulia (Abaqus), Altair HyperWorks, MSC, COMSOL Multiphysics and OpenFOAM are excellent choices. We do not rebuild those packages.
We come in when something specific is needed that no vendor supplies: a solver for sector-specific physics, automation around an existing pipeline, a web portal that makes simulation accessible to non-engineers, or a C++ codebase that runs on a GPU cluster. In particular, building manufacturing software and simulation tooling around enterprise systems overlaps strongly with this service. For construction-related modelling we often see overlap with BIM software, and for connecting to the shop floor with MES systems.
Most work falls into one of these three categories. We decide together which one suits your question in the first session.
ANSYS APDL scripts, Abaqus Python API, COMSOL LiveLink, OpenFOAM dictionary generators. Repetitive setup, batch runs and post-processing fully automated, including integration with your PLM or issue tracker. The simulation keeps running in the vendor package — we build the shell around it so your team produces results faster.
Mesh generators, geometry importers, visualisation dashboards in Three.js or via VTK/ParaView, and cloud-native portals that let non-engineers start a simulation without first learning Abaqus. Typically Python on the backend, a React or Astro frontend, and integration with a Kubernetes cluster for the heavy runs.
When no vendor package covers what you want to simulate: a custom Finite Element solver with deal.II or MFEM, a specialist CEM solver, acoustic scattering, plasma physics. C++ or Fortran at the core, MPI for parallel computing, CUDA or OpenCL for GPU acceleration, and Python wrappers for scripting. A project of several sprints with close involvement from your own researchers.
Production-ready CAE software, plus everything needed to keep it running and keep developing it.
CAE work comes up in many sectors, each with its own emphasis. The common thread: a team with deep domain expertise that is hitting the limits of a commercial package and wants its own software to make a difference in its product or service.
Manufacturing and engineering firms. Machine building, automotive, aerospace. Classic FEA for stiffness, fatigue and crash; CFD for cooling, aerodynamics or internal flow; multibody dynamics for mechanisms. This often means scripting around ANSYS or Abaqus to take repetitive work out of the design process, or a custom tool that calculates parametric variants without an engineer having to set up the simulation again by hand each time.
Energy. Wind, transformers, high voltage, nuclear. Here we often see coupled problems, such as electromagnetic simulation alongside thermal and mechanical behaviour, and strict validation requirements from certification. Custom solvers or package wrappers are rarely delivered here without peer review.
Biomedical. Implants, prostheses, medical instruments. FEA for material stress, CFD for blood flow, acoustic simulation for hearing solutions. An important nuance: software that performs patient-specific calculations often falls under MDR/IVDR, which brings additional requirements for documentation, validation and risk analysis.
Defence. Ballistics, EM shielding, antenna design, radar cross-section. Sensitive work that often has to run on-premises, with security-cleared engineers and strict export-control rules. We work here on an as-needed basis, in close collaboration with your own security team.
Construction. Structural analysis for buildings and infrastructure, often linked to BIM models. This is where CAE and architectural informatics meet, for example automatic export from Revit or IFC to an FEA pre-processor.
Universities and research institutes. PhD research, TKI and EU projects. Here there is usually deep physics expertise but little capacity for software engineering. We bring in build systems, tests, CI/CD, parallel computing and code review, while the researchers keep control of the physics.
Software vendors. Companies that bring a simulation package to market themselves and need extra capacity for it, whether for the solver core, the UI or cloud deployment.
There is no fixed blueprint. We choose per project, in consultation with your researchers, based on what suits the physics and your existing infrastructure. The combinations below come up most often.
Solver core. C++ with Eigen for linear algebra, deal.II or MFEM for finite element discretisation, OpenFOAM as a starting point for CFD, and FEniCS where Python productivity is wanted. For legacy integration or demanding numerical kernels, Fortran 90/2008, often combined with BLAS/LAPACK implementations.
Parallel computing. MPI for distributed memory, OpenMP for shared memory, and hybrid combinations on modern clusters. PETSc and Trilinos where we need sparse linear algebra at scale.
GPU acceleration. CUDA for NVIDIA, OpenCL or SYCL for portable code. Kokkos or RAJA if we want to stay performance-portable across CPU and GPU targets. Profiling with NSight or nvprof, because naive porting rarely delivers the gains you would expect.
Mesh generation. Gmsh for scriptable mesh building, NetGen for tetrahedral meshes, CGAL for robust geometric operations. Sometimes a custom mesher when the standard tools cannot handle the geometry.
Visualisation. VTK and ParaView for scientific visualisation, Three.js or regl for web portals, matplotlib for reports. For large datasets, stream via VTK-XML or chunk via HDF5/CGNS rather than loading everything into memory.
Cloud HPC. AWS ParallelCluster, Azure CycleCloud, Google Cloud HPC. SLURM or PBS Pro for job scheduling, Singularity or Apptainer for reproducible runs on shared clusters. Spot instances to reduce costs where the workload can cope with checkpoint-restart.
Scripting and orchestration. Python throughout, for pre- and post-processing, batch orchestration, calling ANSYS APDL or the Abaqus Python API, and as a bindings layer on top of C++ kernels via pybind11.
AI-augmented simulation. Surrogate models built with PyTorch or TensorFlow alongside a traditional solver, to sample parametric spaces cheaply. This works well where the physics can be learned, and it must always be validated against the real solver. It is not a replacement, but an accelerator.
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →Four signals that prompt clients to contact us. If you recognise one of them, we would be glad to talk through the approach.
You do research that falls outside the standard physics of vendor packages: non-Newtonian flow, coupled multiphysics, plasma, or a sector-specific variant of Maxwell's equations that you have validated yourself.
For each project your team runs the same Abaqus setup with different parameters, or someone builds the same mesh in Gmsh by hand. Scripting and automation give that time back for the real engineering work.
Sales, design or customer teams often want to run parametric variants without a vendor licence or a week of training. A web portal with a simplified front end on top of your solver solves that.
Your simulations need GPU acceleration, better parallel decomposition or a cloud burst to hundreds of cores. Often that is a software engineering question rather than a need for more hardware.
A conversation with your R&D or engineering lead. We map out the physics involved, the vendor packages, the HPC environment and the validation requirements. Often one of our C++/Fortran engineers joins the discussion.
A short phase in which we validate the riskiest assumption — for example, whether we can run this solver on a GPU, or whether our results match a reference case in ANSYS. Only then do you commit to the wider project.
Fortnightly cycles with working releases, integrated verification cases and ongoing code review with your researchers. Performance profiling and parallel scaling early in the project, not at the end.
Verification against analytical solutions, validation against existing packages or measured data and, in regulated industries, a traceability report. This is followed by knowledge transfer and, if you wish, an ongoing maintenance track for patches and extensions.
What clients in engineering and R&D teams usually ask us before we start.
A no-obligation introductory call of half an hour. We listen to the physics, the packages you already use and what you want to achieve. We are honest about what we can and cannot build for you; sometimes the answer is a better licence, not a custom codebase.
Appfront uses cookies and similar technologies to keep the website working properly, for analytics and for marketing. You choose what you allow. Read more in our privacy policy.
