Reading Restarted Simulation Output

An increasingly important problem that we are facing is that of reading in the output files from simulations that have been restarted (note that this is different from reading restart files). When a simulation is started, it continues a simulation previously executed, but typically writes to a completely new set of files.

A simulation that was restarted multiple times will have multiple output file sets, each containing data over a different range of time. It is usually desirable to see all of these times as one contiguous group. So far this has been done by loading files independently (i.e. doing nothing), concatenating all the data into one file (or file group), or hacking up an animation to change filenames in the reader. None of these is a good solution.

It has long been proposed to simply change the readers to select file series or series of file series. The problem is that doing so can obfuscate the GUI, an issue that has stalled the implementation for the Exodus reader for years. Furthermore, the solution would have to be reworked independently for each reader. There is already a similar request for the SPCTH reader, and more may follow.

The new pipeline time support gives us more options for allowing us to read restarted simulation outputs. This page captures the design of such a solution.

Potential Designs

So far I can think of two potential designs using the new time support. The first is to use a #Time Multiplexer Filter and the second is to use a #Time File Series Reader

Time Multiplexer Filter

A time multiplexer filter is a fairly simply filter that takes multiple inputs and has one output. Based on the time step requested down stream, this filter passes one of its inputs to the output and ignores the rest.

Pros

• Easy to implement, can be used over and over.
• No extra GUI.

The best part about this solution is its simplicity. Creating the filter is simply (I already have something that works pretty well), and it is completely agnostic to the type of reader or even the type of data. There is also no extra GUI to try to engineer or learn. Simply clamp on a filter and you are done.

Cons

• Cumbersome to set up.
• Prone to user error.
• Requires modifications of the reader (which can effect their behavior).

As I have actually tried to use this method to load output from a simulation with 12 restarts, I was disappointed at how cumbersome it was to set up. Opening all the files individually is a pain. Scripting helps a lot (it is what I ended up using), but it is not the kind of thing you want your users to have to do.

The method is also prone to user error. Generally, you want all of the readers to have the same options so that the output of each one has the same type of data (e.g. all the same variables). Filters downstream of the multiplexer will behave badly if a variable that they are using suddenly disappears when the time changes. Mismatching the parameters of the reader is an easy thing to mess up. Again, scripting helps here, but is not a great solution for most users.

Ironically, the solution that breaks the functionality away from the reader is the one that requires the most modifications to the reader. The issue that comes up is that each reader is going to create its own copy of the data. What you really want is to only read in the copy of data that is valid for the given time step. To do this, you typically have to add a feature that has the reader clear its output when reading a timestep outside of its range. Besides the pain of adding this feature, it also changes the behavior slightly. Now when you read a timestep outside of the valid range, the data disappears.