> For the complete documentation index, see [llms.txt](https://docs.openbrim.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openbrim.org/templates/openbrimfea/loads-fea/dynamic-loads-fea/time-history-functions-fea.md). # Time History Functions \[FEA] A Time History Function is a tabulated record of a quantity against time — most often a ground acceleration accelerogram, but equally a forcing function for a machine, a blast, or any prescribed excitation. It carries the shape of the excitation; the Time History Case decides how that shape is applied, scaled by gravity, and integrated. The function itself is **input data only**. It adds nothing to stiffness or mass and generates no load until a Time History Case references it. ## General **Time vs Value:** The tabulated record — a series of (time, value) pairs. Time is in seconds and must increase monotonically; the value is whatever the record measures, most commonly ground acceleration in **g**. This is the substance of the object. The solver interpolates linearly between the tabulated points, so the sampling interval of the record sets the highest frequency the excitation can actually represent: a record sampled at 0.02 s cannot carry meaningful content above about 25 Hz, no matter how finely the analysis is stepped. Do not resample a coarse record to a fine interval and assume higher-frequency content has been recovered — interpolation adds points, not information. The record's own length determines the default analysis duration. Records that do not start and end near zero introduce an artificial initial or terminal transient; most published accelerograms are already baseline-corrected, but a hand-built or truncated record may not be. *Engineering influence.* The response is driven entirely by the interaction between this record's frequency content and the structure's periods. A record with strong energy near a structural period produces resonant amplification; the same record applied to a structure with different periods can produce an order-of-magnitude different response. This is why several records are normally run rather than one. Results sensitive to it: everything the case produces — displacements, member forces, reactions, and their peaks. **Scale:** A multiplier applied to every tabulated Y value before it is used. The default of **386.4** converts a record given in **g** into in/s² for a kip-inch model. If your record is already in the model's acceleration units, set this to **1** — otherwise the excitation is overstated by a factor of \~386 and the analysis will produce absurd displacements. *Engineering influence.* Scale acts linearly on the excitation, and for a linear structure the response scales linearly with it: doubling Scale doubles displacements and member forces. This makes it the natural place to scale a record to a target design intensity, or to apply a code-required scaling factor. In a **nonlinear** case (FNA with nonlinear links) that proportionality no longer holds — the response may change disproportionately once links gap, yield, or slip. A value of zero means no excitation and a trivially zero response. A negative value reverses the sign of the record, which is a legitimate way to check sign sensitivity in a non-symmetric structure. Note this is a **unit-and-intensity** conversion combined in one number. If you both need to convert from g and apply a design factor, multiply them together here. {% hint style="warning" %} Scale and the case's **Gravity** are different things and are not interchangeable. Scale converts the record's own values; Gravity converts nodal *weights* into masses. Setting the correct value in one does not compensate for a wrong value in the other. {% endhint %} ## Verification * Plot the tabulated record and confirm its shape, peak value, and duration match the source accelerogram. A record read in with a mis-parsed delimiter usually shows up immediately as a visually wrong plot. * Check the peak value after scaling: for a record in g with the default Scale, peak × 386.4 should be the peak acceleration in in/s². Compare against the record's documented PGA. * Confirm the time column increases monotonically and the sampling interval is what you expect. * Run a short trial case and confirm the response builds and decays in step with the record rather than starting abruptly. * Compare the computed peak response against a response-spectrum analysis using a spectrum derived from the same record — they should be of the same order. ## Common mistakes * **Leaving Scale at 386.4 for a record already in model acceleration units**, inflating the excitation by \~386×. The tell-tale is displacements that are physically impossible. * **Setting Scale to 1 for a record in g**, understating the excitation by the same factor — the more dangerous direction, because the results look plausible. * **Using a record whose sampling interval is coarser than the output step** and assuming the analysis resolves the difference. * **A record with a non-zero first value**, producing a step input and an artificial initial transient. * **Reusing one record for all directions and all sites** — real assessments require a suite of records, and single-record conclusions are not defensible. * **Editing the record's units and its scale factor at the same time** and losing track of which conversion has already been applied. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.openbrim.org/templates/openbrimfea/loads-fea/dynamic-loads-fea/time-history-functions-fea.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.