How Our Engine Works

LessCAD runs fast because we rebuilt the geometry kernel and the solvers from the ground up. This page explains how each piece works and what makes it different from conventional CAD and simulation tools.

Overview

Our engine is different in three fundamental ways:

Implicit Geometry

We chose implicit geometry as our primary representation. This decision shapes everything downstream, including how we run physics — and it is the reason our solver stack looks different from conventional FEA.

Two paradigms exist for representing solid geometry in CAD.

Boundary Representation (B-rep): describes geometry using surfaces, edges, and vertices that bound it. This is the convention used in CAD systems today like SolidWorks, Fusion 360, and NX. The fundamental weakness is that complex operations can create gaps or holes, and the geometry must be converted to a volume through "meshing" before running physics simulations.

Signed Distance Fields (SDF): describes geometry as a solid volume using a math function. The function returns how far any point is from the surface — negative inside, positive outside, zero on the surface. SDFs are continuous volumes by nature, which removes the need for meshing before physics.

We use SDF as our primary geometry kernel. We maintain a B-rep shadow for export to industry-standard formats (STEP, IGES) when the design is ready for fabrication; the SDF carries the authority during authoring and analysis.

Discretization

To run physics on a continuous geometry, we need to convert it into a grid of points the solver can work with. The method you choose here has major consequences for both robustness and speed.

Conforming mesh — the conventional approach. The geometry is sliced into elements (triangles, tetrahedra, or hexahedra) whose faces wrap tightly around the part's boundary. This is what Ansys, Abaqus, and every traditional FEA code does. The strength is geometric exactness. The cost is the mesh-generation pipeline: it is slow, brittle, often requires hand cleanup, and is where most "simulation broke on my model" stories come from.

Finite Cell Method (FCM) — what we use. The part is embedded in a background grid that does not align to the boundary. Cells are classified as inside, outside, or cut by the surface. There is no meshing pipeline — we go straight from the SDF to a numerical system. The tradeoff is that cells along the boundary need special handling.

An adaptive grid

The grid is not uniform. It starts coarse and splits cells where the answer needs them: along the surface, across thin walls and narrow gaps, and around holes and fillets. Each split cell becomes eight (an octree), so a part keeps small cells where its detail is and large ones through its bulk, and the cell budget goes to the features that decide the result. For stress and heat, the solver's own error estimate adds cells wherever the answer has not yet converged. The splitting is automatic, straight from the SDF: there are no sizing controls to set and no mesh to repair.

How we handle boundaries

The orange line is the implicit surface cutting through the background grid at arbitrary angles. Cells along the boundary are partially inside and partially outside the part. We handle this with specialized techniques for each challenge that arises.

Three challenges follow from the boundary not aligning to the grid:

  • Partially-cut cells. A cell that is mostly outside the part can cause numerical issues. We handle this with specialized arithmetic and grid-aware solver techniques.
  • Constraints on non-aligned surfaces. When you fix a face in place, that face does not align with grid points. We apply constraints directly on the immersed surface using a penalty-based method that stays accurate as the grid refines.
  • Surface integration. Computing forces and loads on cut surfaces requires adaptive sampling at each boundary cell.

The tradeoff is real but bounded: FCM gives up the geometric exactness of body-fit meshes in exchange for no meshing pipeline. For very thin features, a finer grid resolves the detail — the same answer as any FEA code facing the same problem.

GPU Solvers

We are building our own solvers for the GPU, from the grid up, rather than wrapping a CPU code. The discretization, the system of equations it produces and the solver that answers it are designed together, and every solver runs on your graphics card through WebGPU, in the browser or the desktop app.

A traditional direct solver works through the system one unknown after another. Ours are iterative: they refine an answer over many passes, and each pass updates every cell of the grid at once, which is exactly the work a GPU is built for.

Linear Stress

Our stress solver computes how a part deforms and where stress concentrates under applied loads and constraints. The animation shows a cantilever beam under a tip load — blue indicates low stress, red shows the high-stress region near the fixed support.

Three types of boundary conditions are supported:

  • Fixed surfaces — lock a face or region in place
  • Applied loads — forces and pressures on surfaces
  • Body forces — gravity, centrifugal loads

Steady-State Thermal

Our thermal solver computes the steady-state temperature distribution in a part. The visualized heat sink shows the result: a hot source at the base (red) loses heat through the fins (blue at the tips).

The thermal solver shares the same grid and GPU solver as stress. Three types of thermal boundary conditions are supported:

  • Fixed temperature — hold a surface at a set temperature
  • Heat flux — apply a heat input or output on a surface
  • Convection — heat transfer to a surrounding fluid at ambient temperature

Our modal solver computes the natural frequencies and vibration mode shapes of a structure. The animation shows the first bending mode of a cantilever — the mode engineers usually care about most because it sits at the lowest natural frequency and is the easiest to excite.

The solver finds the lowest natural frequencies and their corresponding mode shapes — the vibration patterns a structure is most likely to exhibit. It converges all the requested modes together rather than one at a time, which suits the GPU.

Buckling

Our buckling solver determines the load at which a structure becomes unstable and buckles. The animation shows the classic case: a column under axial compression that suddenly bows once the critical load is reached.

Buckling is a two-step process: first a stress solve computes how the part deforms under load, then the eigensolver finds the load multiplier at which the structure becomes unstable. The same eigensolver used for modal analysis drives this step.

CFD

LessCAD includes a built-in Computational Fluid Dynamics solver: a finite-volume solver on the GPU, on an adaptive grid of cells built from the same implicit geometry used for FEA. Cells that the surface passes through are cut to the part's shape, so the walls are where the part is. No export, no meshing, no separate tool. The figures below are illustrations; the CFD page shows a real run on an imported part.

Internal Flow

Simulate airflow through enclosed passages like ducts, housings, and channels. The solver automatically detects inlets and outlets from the geometry's openings, applies appropriate boundary conditions, and computes velocity and pressure fields throughout the internal volume. Useful for evaluating pressure drop, flow distribution, and recirculation zones in HVAC components, electronics enclosures, and fluid passages.

External Flow

Simulate airflow around a body — drag, lift, and wake patterns. The part is placed in a virtual wind tunnel with a uniform freestream velocity. The solver computes the flow field around the exterior surface, reporting aerodynamic forces and visualizing streamlines and pressure distributions. Useful for evaluating vehicle aerodynamics, structural wind loading, and antenna or enclosure drag.

Component Analysis

Analyze individual components within a larger assembly — fans, coils, heat exchangers, and porous media. Components are modeled as momentum and energy sources embedded in the flow domain, allowing you to evaluate system-level performance (airflow rate, pressure drop, thermal exchange) without resolving the internal geometry of every component. Useful for evaluating fan-driven cooling systems, ducted assemblies, and HVAC units where the interaction between components matters more than the detail inside each one.