Similar to the component execution framework, a data communication layer is required to enable modules to share their data. Otherwise, the framework would be robbed of the fundamental ability to combine the specialized functionalities of the modules, significantly reducing reusability as, for instance, data generated by a module can not be accessed by another one. However, where in the other case communication was restricted between the components (modules), an interactive simulation framework also requires the framework itself to have access to the data for visualization purposes. This adds an additional indirection to the data handling, thus requires a different approach than the introduced socket-based communication layer (Section 5.3.2).
Also, modules must be given control to handle the data destined to be used by other modules differently than the data used for visualization. Transferring data to the visualization backend typically requires additional copy operations, which become more significant with larger problem sizes. Furthermore, potentially not all data of interest to other modules makes sense to visualize, for instance, auxiliary data required for enabling the simulation in the first place. Overall, to minimize data transfer operations, the data communication among modules as well as between the modules and the visualization backend has to be separated.
Also, the raw data has to be coupled with additional meta information to allow for specialized visualization and to enable modules to handle input data accordingly. For example, data can be represented by tensor fields of different levels, such as scalar or vector fields and can be associated with different mesh elements such as tetrahedra, triangles, or points. This requires the meta information to contain parameters indicating the nature of the data, allowing the visualization mechanism to use the appropriate rendering method.