The difficult part of shake-table test data analysis is rarely drawing the first acceleration plot. It is preserving enough context to explain what the signal represents, which specimen state produced it, how the raw values were changed, and whether a result survives testing on data that were not used to develop the method. A useful workflow keeps those questions attached to every run.
This article describes a research-data workflow. It does not operate a shake table, approve an input motion, judge structural safety, or replace the laboratory team and qualified engineers responsible for the experiment.
Identify the test before opening the signals
Give every project, experiment, specimen, configuration, and run a stable identifier. For each run, record the facility, test date, table axes, input-motion reference, commanded scale, specimen configuration, added mass, boundary conditions, and data-acquisition revision. Connect photographs, drawings, inspection notes, and test logs to that same identifier.
The channel dictionary should identify the sensor, quantity, location, orientation, sign convention, acquisition channel, native unit, calibration reference, and sampling information. Keep the table sensors distinct from specimen sensors. A label such as ACC_17 is insufficient if nobody can tell whether it measured table acceleration, roof acceleration, or a transverse response.
DesignSafe’s curation guidance structures experimental publications around information such as the facility, equipment, model configuration, sensors, events, reports, and related analyses. Using that structure during testing, rather than reconstructing it at publication time, makes later comparisons more reliable.
Run a channel, unit, and timing quality gate
Check the files before calculating response metrics. The gate should produce a machine-readable table with one row per channel and a status of pass, warning, or review required.
| Check | Question | Artifact |
|---|---|---|
| Identity | Does the file map to one documented run and sensor? | Run and channel IDs |
| Units | Are native units, calibration, and converted units explicit? | Conversion record |
| Timing | Do sample interval, start time, trigger, and record length agree? | Timing report |
| Orientation | Are axis and sign consistent with the test coordinate system? | Orientation diagram |
| Signal | Are there dropouts, clipping, repeated values, or unexpected offsets? | Flagged intervals and plots |
Do not silently repair a channel. Preserve the received file, record the issue, and create a derived version only through a named processing step. When channels use different clocks or rates, document the alignment and resampling rule instead of assuming equal row numbers mean equal time.
Separate commanded motion from measured motion
The command file describes the intended table motion. Instrumented table channels describe what was measured during the run. Store both, align them in a common coordinate system, and label them clearly.
Compare time histories and agreed motion summaries, including the frequency range relevant to the experiment. Show residuals or ratios only after defining how they were calculated. If several table sensors were used, retain their individual records before creating any combined representation. The test plan and laboratory team determine acceptable reproduction; the analysis software should expose the difference rather than declare a run acceptable.
The DesignSafe shake-table workflow example treats table-performance analysis and structural-response analysis as related, reproducible notebook tasks. That separation is useful: establish the measured input before interpreting the specimen response.
Make preprocessing visible and repeatable
Keep raw files immutable. Put every transformation in code or a declarative configuration: unit conversion, offset removal, detrending, baseline correction, filtering, padding, resampling, integration, and analysis-window selection. Record software versions and every parameter, including filter type, order, corner frequencies, and phase treatment.
Generate before-and-after plots and a processing manifest for each channel. Velocity and displacement derived from acceleration are particularly sensitive to baseline and filtering choices. USGS guidance on pads and filters explains why padding and filtered portions must be handled consistently when deriving velocity, displacement, and spectra. The right settings remain specific to the instrumentation, test, and research question.
Define each response metric as data
A results table should name the source channels, processing version, time window, coordinate direction, formula, and unit behind every value. Possible outputs include measured table peak acceleration, peak floor acceleration, relative displacement, drift ratio, residual displacement, force, strain, and frequency-response estimates. Use only the quantities supported by the sensor layout and experiment.
FEMA P-58 discusses story drift ratio, floor acceleration, and floor velocity as common demand parameters in building performance assessment. That does not make them interchangeable or automatically appropriate for a particular specimen. State exactly how a laboratory metric was derived and which damage or performance question it is intended to inform.
Treat specimen damage history as part of the input
Successive runs on one specimen are not independent copies of a pristine test. Link every run to all preceding motions, inspections, observed damage, repairs, component replacements, and configuration changes. Record whether a run followed a pause, intervention, or instrumentation change.
Keep observations separate from derived estimates. A photograph or inspection note is an observation; an estimated stiffness change is an analysis result with its own method and version. Without this distinction, a model can mistake accumulated damage for an effect of the current motion alone.
Hold out complete experimental groups
When developing a prediction or damage-classification method, avoid randomly splitting individual time windows from the same run across development and evaluation sets. Those records share the specimen, sensors, excitation, and damage history, so the reported test result can become unrealistically optimistic.
Group data by specimen, experimental campaign, or another defensible independent unit, then hold out complete groups. Freeze the preprocessing and model choices before revealing the held-out outcomes. Report performance by group, include failed and ambiguous runs, and compare the method with a simple documented baseline. A prospective test chosen before its result is known provides stronger evidence than repeatedly tuning against the same archive.
Publish the path from raw record to figure
A reusable package should contain the raw-file manifest and checksums, channel dictionary, run metadata, specimen-history table, processing configuration, executable scripts or notebooks, software environment, quality-control report, derived tables, and figure-generation code. Add a short README that reproduces one result from start to finish.
DesignSafe supports publishing analyses with referenced experimental data, reports, and persistent identifiers. Its guidance also allows versioning as a dataset develops. A notebook alone is not enough if it relies on undocumented files or manual edits; a complete package should let another authorized researcher recreate the result and see where judgment entered the workflow.
Software can check structure, preserve provenance, repeat calculations, and expose exceptions. The research team remains responsible for sensor validity, processing choices, interpretation, test acceptance, and every engineering conclusion.
A bounded first project can turn one public shake-table dataset into a source-linked, reproducible benchmark before any new predictive claim is attempted.
Explore the seismic research directionOfficial sources and further reading
- DesignSafe: Experimental Shake Table Testing, an integrated notebook workflow for table-performance and structural-response analysis.
- DesignSafe: Data curation best practices, including experimental metadata, analysis relationships, reports, citation, and versioning.
- FEMA P-58-1: Seismic Performance Assessment of Buildings, Volume 1, for the role of engineering demand parameters in performance assessment.
- USGS: On pads and filters—Processing strong-motion data, for transparent treatment of filtering, padding, and derived time series.