v1.32 Release Notes

Release Date: 08/28/2015

New Features

Configuration Control for Restoring Runs

Some projects make extensive use of restoring runs. Restoring runs occurs when you call the Model State API to bring an existing, persisted run from the database back into memory.

There are now two different options for how you can restore a run:

• Restore based on a "replay" of all of the end user interactions, from the creation of the run up to the time it was last persisted in the database. (This was the only option in previous versions of Epicenter; it is the default behavior.)
• Restore based on a "snapshot," only copying in the values of specific variables.

You can set this option, and specify which variables to restore during a "snapshot," in your optional model configuration file.

Use Cases for Restore Mode

Using the "snapshot" option can be significantly faster for restoring individual runs. However, it should only be used if your model's complete state can be appropriately captured in the current values of some variables. (This will depend both on the nature of your model and on how your variables are structured — for example, if your variables store only values from the most recent time step, or from all steps in the model.)

Using the "replay" option can be slower to restore runs, especially if each run has a large number of operations called on it. However, it may be required if your model's complete state can only be expressed by a combination of operations and variables.

Adding a Function for Automatic Execution at Restore

Also new in this release, you can now register a model operation (function) for automatic execution immediately after a "snapshot" restore is performed. For example, this could be used to load initial data that may not be captured in the variables being restored. See details for R, Python, or Julia.