User guide, Part I — from your data to an FE-ready LV mesh

Sign in, and the console gives you two working surfaces. Mesh View, on the right, is where objects live: you drop files onto it, look at them in 3-D, and step between them. Runtime, the sidebar on the left, is where you act on the object you are looking at. Everything in this part of the guide happens in Mesh View.

There is exactly one place to look for progress, warnings, and failures: the status box at the top of the window. Whatever the platform is doing, it says so there. The Advanced drawer at the bottom holds the numeric progress bar and the raw, verbatim log for when a one-line message is not enough.

Three kinds of thing can become a heart mesh. You do not have to tell the platform which one you are giving it — it recognises the file and takes the matching path.

Drag the file onto the viewer, or press Upload Object in the Mesh View toolbar. A paired .xdmf must arrive together with the .h5 it names — drop both, or zip them. Anything else is refused before it is stored, so an unusable object never enters your workspace.

The mesh appears immediately, and the toolbar fills with what it found inside: the datasets it carries, and any vector fields you can display. Use Representation to switch between surface, wireframe, and points.

Where you go next depends on what the file already contains. A mesh exported from the solver usually arrives complete — surfaces already labelled, fibers already present — and is ready to simulate as-is. A bare geometry is not: run Infer LV facet regions and then Generate fiber fields from the toolbar, the same two operations that close out every other path (step 6).

Drop the cine on the viewer. Two things happen at once: the movie becomes playable in the viewport straight away, and a reconstruction begins in the background. Reconstruction reads the ventricle out of the moving image and returns a surface for every frame of the cardiac cycle.

From those surfaces the platform picks the two frames that matter, by cavity size: end-diastole is the frame whose cavity is largest, end-systole the frame whose cavity is smallest. End-diastole is the configuration your mesh is built from, because it is the one the solver treats as the loaded reference state.

One caveat governs this path. An .avi carries no physical scale. Nothing in the file says how many centimetres a pixel spans, so the reconstruction stays in nominal units. Shape is faithful; absolute volumes are not. Use this path for geometry, method development, and comparison between frames — not for a clinical volume. If you need true dimensions, bring the DICOM instead.

When reconstruction finishes, the LV mesh builds automatically through the chain in step 6 — there is no button to press.

Drop one four-chamber DICOM object. This path differs from the .avi in one decisive respect and one convenient one.

The scale is real. A DICOM echo object states its own physical calibration — how much distance each pixel covers — and the platform reads it from the file. Every reconstructed surface is rescaled into physical units before anything is built from it, so the resulting mesh has true dimensions and its volumes mean what they say. If an object arrives without a usable calibration, the upload is rejected on the spot. The platform will not guess a scale, because a silently mis-scaled mesh is worse than no mesh.

The mesh builds itself. There is no button to press. The object is decoded into a viewable echo cine, reconstructed, rescaled, and carried through the whole build chain automatically. When it settles you have three snapshots in the album, and you step between them with the ‹ n / N › control beneath the viewport.

Once a reconstruction exists, the .avi and DICOM paths are the same path. Six steps run in order; the status box names each one as it starts.

The last two steps are exactly the two you can invoke by hand on an uploaded mesh. That is what makes the three paths one path: however the geometry arrived, it earns the same labels and the same fibers by the same means.

A mesh is ready for the finite-element solver when four things are true of it. The build chain exists to make all four true at once.

The fourth is the one the platform enforces on your behalf. Every candidate mesh is measured against a fixed set of hard requirements. No inverted or degenerate elements, no abrupt size jumps between neighbours, and exactly the surfaces a hollow ventricle should have. It must also show a single apex, a real cavity, and a basal ring that closes. A mesh that violates any one of them is rejected and rebuilt, never quietly accepted.

A much broader set of quality measures is recorded alongside every build without blocking it. That distinction is deliberate: a mesh is refused only when it would actually break the solve, not for being less than perfect. So a build fails for good in only two circumstances. Either the rebuilds were exhausted without a mesh that clears the hard requirements, or facet inference could not separate the wall into an inside, an outside, and a base. Both are reported, in words, in the status box.

The status box carries the reason; the raw log inside Advanced carries the detail. Nearly everything that stops a mesh from being built is one of these.

While a mesh is loaded in the viewport, these keys and modified clicks drive facet selection, the brush, the reconstruction overlay, and undo.

With an FE-ready mesh in hand, the rest of the platform opens up: establish its resting state, fit it to your measurements, and run a full cardiac cycle. That is Part II.