of an equation
system 
to a linear solver sketches this requirement. As can be seen from this
example, the communication mechanism has to support an arbitrary number of input and
output dependencies for each component (Figure 5.9).
Strongly related to the component system is the ability of components to share data. The
already discussed example of an assembly component forwarding of an equation
system to a linear solver sketches this requirement. As can be seen from this
example, the communication mechanism has to support an arbitrary number of input and
output dependencies for each component (Figure 5.9).
An important aspect is the support of arbitrary datatypes for the communication layer, to avoid confining the use of a fixed pre-defined set of types. This would otherwise limit the applicability - as potentially utilized external libraries typically offer their own data types - and also triggers costly data transfer operations to move data from unsupported datatypes to new objects based on supported types.
Furthermore, it is required to associate the individual dependencies with an additional dynamic identifier, as using merely type-based identifiers might not offer a unique identification. For instance, a component might provide two matrices, both of the same type but holding different data. Merely using the type as identifier would thus not allow to distinguish the data and would consequently require manual connection.
The challenge of a data communication layer is primarily to provide a type-safe approach offering a convenient setup of input and output data communication among the components. In essence a generic mechanism has to be implemented, capable of linking input and output data communications of each component. This link in essence can be implemented by a generic object which needs to be aware of the data type transmitted via the link as C++ is a statically typed language. Implementing such a generic object capable of representing data of arbitrary type requires so-called type-erasure techniques, effectively removing the type information from an object to transform it into a typeless object. This transformation allows to handle objects of arbitrary types in a unified manner, for instance, a homogeneously-typed container, such as a vector can hold such typeless objects which originally differed in the type and thus would not have been possible to store them together in such a container. As a consequence arbitrary yet unforeseen data types can be processed. However, usually the challenge is not to lift the actual type from an object - basically removing the type information from the object - but to access the object from a type-erased state again appropriately. Therefore, the access mechanisms need to be as safe as possible, i.e., allowing for correct data retrieval. Other projects, like the ESMF [29] approach this problem by supporting a predefined set of datatypes for data communication. However, as already indicated, such an approach limits usability.