Limitations of Checkpoint Files
Limitations of checkpoint files
Although they are a powerful tool for recovering from crashes checkpoint files are not perfect. In particular they do not include any information about elapsed time between commands, which can lead to differences during playback in two situations:
-
When D3PLOT animates each frame is displayed in the "dead"
time between user commands. In effect the code says "Has the user
given a command? No? Good, let's animate another frame while they are thinking."
Animation will not actually commence during checkpoint file playback,
even if
has been recorded,
as there is no "dead" time between successive commands in
which to execute it.
Therefore if the session included animation the image which is on the screen may be different to that when the checkpoint file was recorded, and this may affect the outcome of any screen picking operations. Some more subtle consequences may also arise: for example contour bands may be different because the code has not yet decided to autoscale bands over all frames in an animation sequence.
-
When the T/HIS <=> D3PLOT link is used this too may not play
back correctly. The reason is that the two codes run independently and
talk to one another via inter-process communication. Because checkpoint
file playback leaves no intervals between successive commands, the remote
programme (T/HIS) may not have had time to perform the operations requested,
and return results, so the sequence of stored commands may "run
ahead" of what is actually happening on the display and effectively
give answers to questions that have yet to be asked.
Therefore checkpoint file playback of all but the simplest "linked" sessions is likely to fail because of the asynchronous way in which the two codes are running.
We hope to address the issue of asynchronous behaviour in future releases,
but for the time being these limitations apply.