OpenSees Cloud

OpenSees AMI

Silence Is Golden

Original Post - 14 Sep 2023 - Michael H. Scott

Visit Structural Analysis Is Simple on Substack.

Perhaps the #1 OpenSees complaint of all time is that recorder files have incomplete data–in some cases terminating midline, several time steps before the end of an otherwise successful analysis. For example, the last three lines of a recorder file from a 30 second transient analysis may look something like below.

28.94 1.2433 -0.016987
28.96 1.2356 -0.014680
28.98 1.2312

Subsequent loading into your favorite plotting software will lead to an error due to data columns of different lengths. In some edge cases, the writing would terminate mid scientific notation, e.g., 4.6534e instead of 4.6534e-04. And even if the recorder file terminated with a complete line, you wouldn’t have the entire response history anyway.

Not flushing recorder file streams is by design, not a bug. Frank didn’t want to slow down analyses by flushing file streams at every time step. Instead, the operating system can decide when is best to flush the file streams.

The best solution to incomplete recorder files has been to put the wipe command at the end of your script, forcing the recorder file streams to flush their contents one final time. The worst solution is to use the -closeOnWrite option in the recorder definition. This option closes and re-opens each recorder file after every time step, choking the operating system–and your analysis–if you have many recorders.

Although adding the wipe command is a widely known remedy–while the -closeOnWrite solution should be scrubbed from your memory–the incomplete recorder files always ensnared new OpenSees users. Every three or four weeks, essentially the same post would appear on the OpenSees message board or in the OpenSees Facebook group.

Finally, enough was enough, and Minjie added functionality (see PR #1043) to flush recorder files automatically at the end of the analyze command. For example, all recorder files will be flushed after the following command.

ops.analyze(1500,0.02)

The flush happens once, after the (in this case) 1500th time step, not once after every time step. No need to issue the wipe command.

But if you put the analyze command in a loop, the recorders will be flushed after every time step (still way better than using the -closeOnWrite recorder option). If you are worried about the small performance hit in this case, you can use the -noFlush option to keep the file streams buffering like usual.

for i in range(1500):
    ops.analyze(1,0.02,'-noFlush')

Just be sure to keep that wipe command at the end of your script.

PR #1043 would have made its first appearance in OpenSeesPy version 3.4.0.3, in OpenSees.exe version 3.5.0, and of course in all subsequent versions.

I haven’t seen any complaints in the last few months about incomplete recorder files. So, flushing after analyze must be doing its job.