When performing high-level data I/O, as is offered by a package such as get_snap.c and put_snap.c, there is an automated way to keep track of data history.
When a NEMO program is invoked, the program name and command line arguments are saved by the initparam() in a special history database. Most NEMO programs will write such history items to their data-file(s) before the actual data. Whenever a data-file is then opened for reading, the programmer should first read these data-history items. Conversely, when writing data, the history should be written first. In case of the get/put_snap package:
get_history(instr);
get_snap(instr, &btab, &nbody, &time, &bits);
/* process data */
put_history(outstr);
put_snap(outstr,&btab, &nbody, &time, &bits);
Private comments should be added with the app_history() 6.12When a series of snapshot is to be processed, it is recommended that the program should only be output the history once, before the first output of the snapshot, as in the following example:
get_history(instr);
put_history(outstr);
for(;;) {
get_history(instr); /* defensive but in-active */
get_snap(instr, &btab, &nbody, &time, &bits);
/* process data and decide when done */
put_snap(outstr,&btab, &nbody, &time, &bits);
}
Note that the second call to get_history(), within the for-loop, is really in-active. If there happen to be history items sandwiched between snapshots, they will be read and added to the history stack, but not written to the output file, since put_history() was only called before the for-loop. It is only a defensive call: get_snap() would fail since it expects only pure SnapShot sets (in effect, it calls get_set(instr,"SnapShot") first, and would call error() if no snapshot encountered).