Part IV · Beyond one field

11. Reading a sequence as a curve

One field is a snapshot. What a loading test is actually for is a curve - strain against load step, elongation against time - and getting from a stack of fields to a trustworthy curve has its own ways of going wrong.

The virtual extensometer

A physical extensometer is a clip gauge: two arms attached to a specimen a fixed distance apart, reporting how that distance changes as the specimen deforms. A virtual extensometer is the same idea done in software: place two points anywhere on the measured field, and read the change in the distance between them across every frame of the sequence.

It measures the gap between the anchors, never the movement of either one

This is the rule that matters most, and it is easy to get backwards without noticing, because a common way to test the idea does not expose the mistake. A gauge has to compute the change in distance between its two anchor points, not the displacement of either anchor on its own. A specimen carried bodily across the frame - a pure rigid translation, no stretching at all - has genuinely strained by nothing whatsoever. An implementation that (by mistake) read one anchor's own displacement instead of the gap between the two would turn that rigid motion into a large, smooth-looking, entirely fictitious strain reading.

The trap in verifying this: testing only with a pure stretch centred on the origin will not catch the bug, because under that specific kind of deformation the two calculations happen to agree by coincidence. It takes a genuinely rigid translation, tested on its own, to tell the two apart.

An anchor needs real measurement on all sides to mean anything

An anchor placed between grid points does not sit exactly on a measured point; its reading is interpolated from the four points around it. If any one of those four is a gap (Chapter 3), every obvious way to paper over it is dishonest in its own way: using the three that remain quietly changes what is being averaged; reaching further out for a substitute borrows a reading from somewhere the anchor is not; filling the gap with zero drags the whole reading toward "did not move," which is the most plausible-looking wrong answer available. The honest response is to refuse the reading outright and let the anchor be moved somewhere the field can actually support it.

A gap in the curve is drawn as a gap

Some frames will not be readable - an anchor sat over a hole (Chapter 5), or that frame's field simply did not measure enough of the specimen. Dropping that frame from the curve and drawing a straight line from the frame before it to the frame after would fill territory nobody actually measured with a segment that is, on the screen, indistinguishable from real data. The honest curve breaks visibly where a frame could not be read, and says so in words, rather than smoothing over the hole.

Verified, not merely argued

A synthetic tension sequence ships with an exactly known answer for every frame, and a virtual extensometer placed on it reads 0.005, 0.010, 0.020 and 0.036 against stated strains of 0.005, 0.010, 0.020 and 0.035 across four frames - close enough, over displacements reaching tens of pixels, to trust the method rather than merely the argument for it.

A five-frame tension sequence: the displacement field over a speckled specimen with a virtual extensometer drawn across it, and beneath it a plot of engineering strain rising smoothly against frame number from near zero to about 0.055.
A loading curve from two clicks. The extensometer is the pale line drawn across the specimen; the curve beneath reads the change in the distance between its two ends across every frame. The caption above the chart states how many frames were readable, so a break in the line can never be mistaken for smoothing.

12. The field leaving the application

A result rarely stays where it was produced. It gets opened in another tool entirely - a general-purpose scientific viewer, a spreadsheet, a finite-element package - and every principle this manual has argued for has to survive that trip, or it was never really upheld at all.

Geometry says where the instrument looked; the data says what it found

An exported field's underlying mesh should cover every place a measurement was attempted, not merely every place it succeeded. If the geometry itself shrank to fit only the successful points, a difficult specimen would quietly export as a smaller, easier-looking one than it really is - the very difficulty that makes it worth studying would disappear from the file before anyone else ever saw it. The data arrays sitting on that geometry are where "attempted but not measured" actually gets stated, following the same absence-not-zero rule as everything else.

The same "not zero" rule, one file format further out

In almost any viewer, a field of zeros renders as a perfectly reasonable, uniform blue region - entirely indistinguishable from a genuine measurement of no movement. An export has to carry unmeasured values as not-a-number, exactly as the application's own screen does, and state outright, in an array of its own, which points were actually measured - rather than leaving a reader to infer it from wherever the holes happen to be. A derived quantity that was never asked for at all (strain, on a run where it was switched off) should be absent from the file entirely, not present and filled with not-a-number everywhere: an array that is entirely not-a-number reads as "we tried and failed everywhere," which is a much more alarming and much less accurate claim than "this was never attempted."

A file has to state its own coordinate frame

Chapter 4 explained why one consistent coordinate frame matters inside the application. The moment a field leaves it, that guarantee is gone: whatever opens the file next has its own default assumption about which way is up, and there is no reason to expect it matches. The file has to say, explicitly, which convention its coordinates use, so a reader - human or software - does not have to guess and does not draw the field mirrored without any way to notice.

Provenance travels with the file, captured at the moment that matters

A trustworthy result carries an account of how it was made: both source images identified precisely enough that a substitution would be caught, the settings the correlation actually ran with, the region that was used, and the exact version of the software and its engine that produced it. That account has to be captured when the run starts, not read back from an on-screen panel afterward - a panel that keeps accepting input after a run finishes will, if read late, describe a configuration that never actually produced anything, attached with complete confidence to a result that was really made under different settings entirely.

ParaView with an exported .vtu file open: the pipeline browser lists the file, the properties panel lists displacement, strain, correlation, solved and both reliability arrays, and the strain field is drawn on the specimen with unmeasured points left as visible holes.
The same field, opened somewhere else. No conversion step: the format is VTK's own, so ParaView and FreeCAD's FEM workbench read it directly. Every channel the run measured is in the array list, and the gaps are still gaps - unmeasured points arrive as not-a-number rather than as a flat blue region no reader could tell from a real measurement of no movement.

A trap worth knowing about, generally

A file-writing call that reports success is not automatically proof a file was written. It is worth checking, once, that the specific writer a pipeline depends on actually fails loudly - some report success even when the destination directory does not exist and nothing was written at all. A confirmed write, not merely an unrejected one, is the only thing that should tell a user their result is saved.