AcaysiaGEM
A spatial simulation is only ever as good as the shape you run it in. Real vessels are not boxes — they have dished bottoms, baffles, downcomers, sparger rings and nozzles set at awkward angles, and every one of those changes the answer.
GEM is the layer that builds that shape. It authors the vessel's interior as a parametric model, proves the model is fit to simulate before a GPU hour is spent on it, and hands it to AcaysiaDRT ready to run.
Model the Space, Not the Steel
Ordinary CAD describes the vessel: the shell, the flanges, the weld prep. A solver does not care about any of that. It cares about the shape of the liquid — the negative space the fluid actually occupies.
GEM models that space directly, and labels its edges as it builds them: this face is where fluid enters, that one is a wall, this volume is swept by an impeller and is not fluid at all. That is why its output drops into a solver without the usual translation losses.
How a Domain Gets Built
Four properties do most of the work here, and each one exists because the alternative fails quietly rather than loudly.
Dimensions, not drawings
A vessel is described by the numbers an engineer already has — diameter, liquid height, impeller ratio, clearance, nozzle positions — and rebuilt from them on demand. Changing a design means changing a number, not redrawing a model.
The builder knows what it built
Boundary faces get their meaning — inlet, outlet, wall, symmetry, exclusion — at the moment the builder creates them. No fragile post-hoc guessing about which surface was the inlet, and no selector language to get wrong.
Checked against real CAD
Where a trusted reference part exists, GEM's model is regression-checked against it — volume, surface area, centroid, inertia, bounding box — so a simplified flow domain stays honest about the equipment it represents.
What the solver sees, and what it doesn't
Agitator shafts, turbines, drive motors, baffles and nozzle flanges can be carried for visual fidelity without polluting the physics. A rotating impeller is handed to the solver as the volume it sweeps, which is the honest representation of it.
Eighteen Shapes, Three Families
| Family | Geometries | What it is for |
|---|---|---|
| Flow domains | Channel, cylinder in channel, backward-facing step, sudden expansion, serpentine mixer, lid-driven cavity | Lab-scale ducts — the shapes the solver is benchmarked on, where an analytic or published answer exists |
| Inline components | Tee mixer, orifice plate | Round pipe fittings — blending at a junction, and pressure loss across a restriction |
| Vessels | Stirred tank, distillation column, bubble column, packed-bed reactor, fermenter, flash drum, decanter, cyclone, drum, horizontal separator | The real equipment — internals and all, at the scale a plant actually runs |
Each geometry sweeps across its whole parameter range in the test suite, so a mis-tagged large impeller, a baffle poking through a dished bottom, or an unsealed vessel is caught automatically on any change — not discovered halfway through a run.
Fail on the Desk, Not on the Cluster
The expensive failure in spatial simulation is not a wrong answer — it is a run that consumes a night of GPU time and produces nonsense because the domain leaked. Every GEM domain has to pass a health check before it can be exported.
A real solid
Valid, watertight, a single connected body with positive volume. The check that catches a geometry which merely looks closed on screen.
Every boundary has a rule
Each boundary face must carry exactly one tag. An untagged face is a hole in the physics — a boundary the solver has no instruction for — and it leaks silently rather than erroring.
One connected fluid
The fluid must be one region with no isolated pockets, every declared opening must actually reach it, and the domain must be sealed everywhere an opening does not exist.
Internals stay inside
Anything declared as submerged has to genuinely sit within the fluid. When it doesn't, the check names the offending point rather than leaving you to find it in a render.
One Vessel Is the Primitive. A Plant Is the Point.
The same machinery that places one vessel places thirty of them. GEM grows from independent geometries into a laid-out, connected, named plant — the physical counterpart of a Rete flowsheet.
Place and orient
Units are positioned as a plot plan, with each placed unit carrying its boundary tags along with it — the detail that separates a real assembly from a pile of shapes that lost their meaning when they moved.
Routed, not drawn
Connections between units are routed through the plant as real line work rather than sketched, with nozzle-to-nozzle port matching and collision awareness.
Racks, steel and access
Pipe racks, supports and access structure come with it, so what you are looking at reads as a plant rather than as vessels floating in space.
Thirty units, eight builds
Identical units share one underlying shape, so a thirty-unit plan built from eight distinct designs costs eight builds and not thirty. That is what makes assembling a whole plant routine instead of an overnight job.
The Model Is the Picture
The geometry that runs the simulation is the same geometry that renders it. There is no separate marketing model to fall out of sync — when the design changes, the picture changes with it.
Equipment, or x-ray
The pair above is one scene rendered twice. Nothing was modelled specially for the transparent version — the internals were always in the geometry, because the solver needs them there.
Seconds, not hours
The twelve-unit plant above renders in about 6 seconds on a GPU; the thirty-unit one, at 1.6 million triangles, takes under 8. Fast enough that a render is something you do while iterating, not a deliverable you schedule a day for.
Ship the model, not a screenshot
Output is a still image, an editable scene, or a 3D file a browser can open — usually the better answer, since it is the model itself rather than a picture of it.
Drops onto a page
Renders come out on transparent backgrounds with the plant still standing on its own shadow, so it composites cleanly onto whatever sits behind it.
Straight Into the Solver
Lattice-ready, three ways
A validated domain converts into exactly what the solver consumes. Where a geometry carries an exact mathematical description of its surface, the export uses it, giving sub-cell accuracy at curved walls instead of a staircase.
No translation losses
The export encodes the solver's own conventions directly, pulled from its source rather than reimplemented — the class of mismatch that produces a simulation which runs happily and means nothing.
Then it's a DRT run
From there it is an AcaysiaDRT job: solved flow, transport, and the chemistry that AcaysiaRT supplies per cell.
Without the toolchain
AcaysiaCORE brings this into the browser — pick a geometry, set the parameters, see it in 3D, check the regions, and export it for a run without installing anything.
Build, Check, Export
Three steps, and the third one only runs if the second one passed.
from gem.geometries import Channel, ChannelParams
from gem.core.regions import collect_regions
geo = Channel()
params = ChannelParams(
length=0.10, height=0.02, width=0.02
)
part = geo.build(params) # tagged solid
meta = geo.metadata(params) # serializable
for region in collect_regions(part):
print(region.name, region.kind.value)from gem.validate import validate
from gem.export import get_exporter
result = get_exporter("voxel_flags").export(
part, meta
)
# Health + leak checks, per-check verdict
report = validate(part, result)
print(report.summary())
assert report.ok # no ERROR-severity check failed
# Solid mask in the solver's own cell order
solid = result.to_dart_linear("solid")Start From Your Geometry
Contact us about modelling your vessels — and what changes when the simulation runs in the real shape instead of an idealized one.
Contact Us