How it works

The Result's cache mechanism allows the analysis and visualization of lots of results which, otherwise, could not be held entirely in memory.

Instead of loading all results from the file(s), a certain amount of memory, a memory pool, is reserved and used to load and unload the result values as they are needed.

When this mechanism is enabled, with the indexed options enabled, and a result's file is opened for the first time, GiD verifies the correctness of the file and gets some information about the results, such as minimum and maximum values, amount of memory needed, position in file; and this information is stored in the index file. The next time the same result's file is opened, only the index file is loaded, reducing the load time considerably. But no results are loaded, they are loaded only on-demand.

If the indexed options are off, then no index file is created or read, and so the parsing of the result's file is perfomed each time is openend, but no results is loaded in memory. They are loaded on demand.

Note: the index file is not created for gidpost HDF5 files.

If a result is selected to do, for instance, a contour fill visualization and it's not in memory, then GiD checks if there is enough space in the memory pool and loads it. If it's already in memory, the time-stamp of the result is actualized.

If there is not enough space in the memory pool to load the desired result, then the oldest results are unloaded and their memory freed until there is enough memory to load the desired result.

What's cached: Only results which are already stored in files are cached, i.e. files read with Files --> Open, Open multiple or Merge.

What's not cached: When cuts, extrusions are done or isosurfaces are converted to full featured meshes the generated results are held in memory. Results created in GiD using the Window --> Create result, Create statistical result are held in memory. Also results imported using Files --> Import or using the plug-in mechanism or the TCL procedure GiD_Result create ... are held in memory too.

In order to cache these results, save the model with Files --> export --> Post information --> whole model and open it again.


Results' cache options can be found it Preferences --> Postprocess --> Post files: Post files

  • The user can enable the Result's cache in the postprocess panel of the Utilities --> Preferences window.
  • The size of the memory pool can also be adjusted by selecting one of the predefined memory sizes or entering the desired amount in the same entry. The size can be adjusted according to not only the amount of memory the computer has, but also the memory used by a single result.
  • Using indexed binaries, will speed up the access of the results on huge file, more over if the user access them randomly.
  • Using indexed results information stored in the indices, will speed up the loading of huge results files, as the results information, except values, are already stored in the index files.

Note: if for some reasons GiD has problems reading the index files, or the information stored in these files are not actualized, the user can recreate these index file in the File --> Open dialog box, see Open.

For instance a mesh with one million nodes with a vector result at each step, the amount of memory needed to hold the nodal vector result of a single step will be: 4 components * 4 bytes per float * 1 million nodes = 16 MBytes of memory. If there are 100 steps in the analysis and an animation of these vectors is desired, to get a fluid animation the memory pool must be set to 16 * 100 = 1.6 GBytes of memory. But if the desired animation is of a contour fill or an iso-surface, then the amount of memory needed is reduced by 4, to 400 MBytes.


When the result's cache is used, the result's files remains opened, to make the retrieval of the results faster.

If a simulation is done on a cluster where the model is partitioned in 1024 pieces then 1024 separated result's files are generated.

When these 1024 result's files are merged in GiD with the result's cache mechanism enabled, then the 1024 files will still be opened!

Usually in Linux the maximum number of opened files are, precisely, 1024, and some of them are already used, causing GiD to display an error when the user tries to merge these 1024 result's files.

This limit on the number of open file descriptors is one of the limits imposed by the system, like the cputime, coredumpsize, datasize, etc. There are two types of limits in Linux, soft limits and hard limits. Usually the soft limits can be changed by the user, but administration privileges are needed to change the hard limits.

Sometimes soft and hard limit are not the same, and the user is able to raise the number of open file descriptors to its hard limit. If the user uses the bash shell, then the commands ulimit -Sn ( open files soft limit) or the ulimit -Hn ( open files hard limit) should be checked. An additional parameter can be entered to modify the limit, for instance ulimit -Sn 2048. In csh/tcsh the command is limit [ -h] openfiles


  • if we convert a cut mesh, see Do Cuts Menu, to a full featured mesh, then the results for this cut are created and are not cached.
  • If this information is saved using the Files --> Export --> Post information --> whole model' and read again, then the results on the cut mesh will cached as the other results too, and GiD will again use a modest amount of memory.
How it works