# Data Structure

Kratos data structure is capable of store any kind of data for Nodes, Elements, Conditions, or even for any solution process. This includes the historical and no histroical data and any other information necessary for new algorithms.

## Global Organization of the Data Structure

There are two major ways to organize data in a finite element program, the variable base and the entity base structure. Both structures offer good features but for two very different type of algorithms. The first structure is optimized for domain based algorithms and also when some variable has to be added or removed from data structure. While the second structure is better for entity based algorithms and is more flexible for adding or removing entities.

Kratos is designed to support an elemental-based formulation for multi-disciplinary finite element applications and also started with mesh adaptivity as one of its goals. So the entity based data structure becomes the best choice. First because elemental algorithms are usually entity based and can be optimized better using this type of structure. The second reason is the good performance and flexibility this structure offers, in order to add or remove Nodes and Elements. Beside this entity base structure Kratos also offers different levels of containers to organize and group geometrical and analysis data. These containers are helpful in grouping all the data necessary to solve some problems and for simplifying the task of applying a proper algorithm to each part of the model in multi-disciplinary applications.

Nodal, elemental and conditional data containers are the basic units of this entity base structure. In Kratos each Node and Element has its own data. In this manner an Element can access easily the nodal information just by having a reference to its Node and without any complications. Properties also is a block of this structure as a shared data between Element or Condition. Figure \ref{FigureDSKratosDataStructure1} shows these basic units and their relations to different entities.

\begin{figure}[ht] \begin{center}

 \includegraphics{DataStructure/DSKratosDataStructure1.pdf}\\
\caption{Nodal, elemental and conditional data containers
with properties are the basic units of Kratos data structure.}
\label{FigureDSKratosDataStructure1}


\end{center} \end{figure}

Separate containers for Node, Properties, Element and Condition are the first level of containers defined in Kratos. These containers are just for grouping one type of entity without any additional data associated to them. These containers can be used not only to work over a group or entities but also to modify their data while each entity has access to its own data. These containers are useful when we want to select a set of entities and process them. For example giving a set of Node to nodal data initialization procedure, sending a set of Element to assembling functions, or getting a set of Condition from a contact procedure. Figure \ref{FigureDSKratosDataStructure2} shows these containers and their accessible data.

\begin{figure}[ht] \begin{center}

 \includegraphics{DataStructure/DSKratosDataStructure2.pdf}\\
\caption{Separate containers for Node, Properties,


Element and Condition can be used to group each type of entities and then process themselves or their accessible data.}

 \label{FigureDSKratosDataStructure2}


\end{center} \end{figure}

Mesh is the second level of abstraction in the data structure which hold Node, Element and Condition and their Properties. In other word, Mesh is a complete pack of all type of entities without any additional data associated with them. So a set of Element and Condition with their Node and Properties can be grouped together as a Mesh and send to procedures like mesh refinement, material optimization, mesh movement or any other procedure which works on entities without needing additional data for their processes. Figure \ref{FigureDSKratosDataStructure3} shows Mesh with its components.

\begin{figure}[ht] \begin{center}

 \includegraphics{DataStructure/DSKratosDataStructure3.pdf}\\
\caption{ Mesh is a complete pack of all types of


entities without any additional data associated with them.}

 \label{FigureDSKratosDataStructure3}


\end{center} \end{figure}

The next container is ModelPart which is a complete set of all entities and all categories of data in the data structure. It holds Mesh with some additional data referred as ProcessInfo. Any global parameter related to this part of the model or data related to processes like time step, iteration number, current time, etc. can be stored in ProcessInfo. ModelPart also manages the variables to be hold in Node, Element and Condition. For example all the Node belonging to one ModelPart sharing the nodal variables list hold by it. From another point of view ModelPart is the nearest container to the domain concept in the multi-disciplinary finite element method. Figure \ref{FigureDSKratosDataStructure4} shows the ModelPart with its components.

\begin{figure}[ht] \begin{center}

 \includegraphics{DataStructure/DSKratosDataStructure4.pdf}\\
\caption{ModelPart}holds <tt>Mesh with some


 \label{FigureDSKratosDataStructure4}


\end{center} \end{figure}

In the first implementation, ModelPart was able to keep the history of data and also the Mesh if it is changing. But in practice this capability became the bottleneck of Kratos performance and was also considered to be unnecessary for our problems. So this feature was removed from ModelPart. However each ModelPart still can hold more than one Mesh which comes from the first implementation and can be used for representing the partitions in parallel computation.

Finally Model is a group of ModelPart's and represents the finite element model to be analyzed. It can be useful for some procedures that requires the whole data structure like saving and loading procedures. As processes in Kratos use ModelPart as their work domain, this container is not implemented yet but it is necessary to complete the data structure of Kratos.

Spatial containers are separated so can be used just when they are needed. This strategy also allows Kratos to use external libraries implementing general spatial containers like Approximate Nearest Neighbor (ANN) library \cite{mount1997ann}.

%To achieve more generality, Kratos has to support nodal or other %type of formulation. According to this it will be mentioned that %adding a separate variable base structure for optimizing this type %of formulation is practically easy.