Summary files

Summary data are organized in summary files (which are binary, not text files). The file <root>.SMSPEC contains information on how the data is organized, while the actual results reside in a file <root>.UNSMRY if unified. If non-unified files are used, the files are called <root>.S0001, <root>.S0002, <root>.S0003,...

The file <root>.S0001 contains results from all mini steps up to the first milestone, <root>.S0002 results from the first to the second milestone etc.

The EXCEL keyword

If we want access to the summary output data to e.g. manipulate them afterwards, the summary files are not appropriate (not text files). The keyword EXCEL (no associated data) is then available, whereby Eclipse writes a file in format readable by a spreadsheet program as Excel.

Restart data and restart files

A restart file is a “snapshot” of the reservoir state at a certain time. I.e. saturation and pressure values for every grid cell are saved, in addition to other data characterising the reservoir and fluids at the time. The reason for the name “restart data”, and the original motivation for saving the reservoir state in such a manner, is to enable a “restart” of the simulation. In an ordinary run, when the simulation has arrived at some date, to advance the solution a time step to next milestone, it takes the “current reservoir state” and solves some problem to get the required solution. Whether the “current reservoir state” is stored in computer memory as in a normal run, or read from a file shouldn’t matter at all, as long as the “current reservoir state” is exactly the same in the two situations. The definition of the restart file is just to ensure that the contents of the file matches this requirement.

The reason for wanting to do such restarts is most easily given by an example. Assume we have run a simulation case for 20 years with a defined well scenario. We now want to compare the case to another case where we put an additional injection well on injection after 15 years. Obviously the first 15 (simulated) years are equal in the two cases, so we would have to perform an identical simulation for 15 years before we do the change. If total computing time for the run is in the order of minutes this wouldn’t bother us at all, but if for example simulation of the first 15 years took a couple of days of computing, then we would obviously see the rerun as a waste of time and seek alternative ways to do this. If we have stored the reservoir state after 15 years in a restart file, then we could pick up the state from there, add another well and run only the last five years anew. (Details on how to do this will come later.)

Since restart files contain a complete description of the reservoir state, they are also well suited for graphic visualisation of the state, e.g. the saturation distribution in the reservoir at the time. And by visualising several such restart data in a sequence, we can get a picture of how the reservoir state changes with time.

The dates at which restart data are stored in the restart files are called restart dates. Since restart files tend to be large they are normally generated less frequently than the milestones. Also, whether the objective is to use the restart files for proper restarts, or visualisation, they don’t need to be generated too often, as they serve their purpose best when the difference between consecutive files is not too small. Recommended intervals between restart dates are case-dependent, and would be based on how rapid the reservoir state changes, and the size of each file. Note that it is possible to specify that the restart files are only needed for visualisation purposes (not actual restarts), which results in somewhat smaller files.

Control of restart files can be done in RPTSCHED, but the alternative RPTRST is tailored for this purpose, so in these notes we will use RPTRST.

RPTRST is, as the other RPTXXX keywords controlled by a series of flags,

BASIC=m

Requests output of basic (standard) restart files (“report time” = milestone)

m = 1 Restart files are created at every report time, but only the last one is kept. (For unified files this switch is not available, and m = 2 will be used)

m = 2 Restart files are created on every report time, and all are kept.

m = 3 Restart files are created every nth report time. n is defined in flag FREQ.

64