The new GTV overview

In the previous version of the GTV, the metacode describing the plots was stored in several chunks of memory. The current chunk was contiguously filled with all the incoming data: directory descriptors, segments descriptors, segment data, or image descriptors. When the current chunk was (nearly) full, it was copied to a newly allocated chunk, and reset for new use. This had 3 major limitations:

• it was a permanent worry to make sure that the incoming data will fit in the remaining place of the current chunk,
• the tree size and the numbers of images in the tree were limited by hard coded parameters in the source code,
• the various links in the tree between the directories, the segments, and their data, were remembering the chunk number and the position in the chunk. Deleting an object and freeing its associated memory was just a nightmare: links could not be updated easily.

Figure: The tree and linked lists structure of the metacode storing the plots in the GTV, with a basic example of top directories, subdirectories, and segments. The relationship presented here between the various elements is not exhaustive.

Given these limitations, the choice was made to fully rewrite the way the metacode data is stored in memory. Appropriate Fortran derived types were defined: they describe the various links an object can have with others in the tree. Figure  shows an example of the various kind of data which can be encountered in the metacode.

All the links are made with allocatable pointers, which are allocated in real time, on-demand. The tree is thus now growing dynamically in memory. Deleting an object is just as easy as deallocating a pointer to it, after having taken care that the surrounding elements in the tree are correctly updated. Furthermore, deallocation can be delayed (i.e. put in the event stack) after all the events which need it are done, without altering the normal life of the tree (as ruled by the commands executed).