The CST data export interface

This class is used to export field data from CST. It is meant to be used with Garfield++ and therefore the data export is adapted to the Garfield++ interface. This means only node positions and node potentials are exported - the information about the electric field is not directly exported. The reason for that is, that the electric field on each node is not unique and the field can be calculated from the potential values.
A complete documentation of the interface can be found here: A Garfield++ interface for CST .
The documentation in this document is based on the deprecated version of the interface, which is based on text files. Please use binary files, since they are smaller and also the precision is better. This is because no float->string and string->double conversion needs to be used. To export data you can use the program ExportFieldData.cpp. You need to compile it in VisualStudio on your Windows machine. Make sure that all CST dll files are known during runtime by adding the CST install path to the PATH variable.

Potential export

Attention: If you try to export the potentials calculated by CST the export might fail due to an internal CST bug.

To solve the problem, you have to copy the potential into another tree of your CST project. This can be done in the post processing of CST by combining to fields. You have to combine the potential with itself using a scale factor of zero for one of the potentials. This will result in a copy of the original potential (Potential [Es]) with a new name, that can be chosen by you.

Material assignment

The calculation of material properties of elements is based on a MatLab example (GetMaterialValeAtXYZ.m) that can be found in the CST installation folder (CST/ResultReaderDLL/). The assignment of a material to a CST element is based on the relative permittivity $\epsilon_r$ in case of text based data export. Here the value of $\epsilon_r$ of a certain element is compared to hard coded values for Kapton ( $3.4 < \epsilon_r < 3.6$ ), G10 ( $4.7 < \epsilon_r < 4.9$ ), Alumina ( $9.3 < \epsilon_r < 9.5$ ) and PEEK ( $3.2 < \epsilon_r < 3.4$ ). If the data export based on binary files is used the assignment can be based on the density $\rho$ or $\epsilon_r$ of the material. In this case the value of $\epsilon_r$ of a certain element is compared to values given in a material xml file that looks like:

<Materials Count="3">
  <Material ID="2" description="gas" eps="1" mue="1" rho="0" rho_set="1"></Material>
  <Material ID="0" description="PEC" eps="1000000" mue="1000000" rho="1000000" rho_set="0"></Material>
  <Material ID="1" description="kapton" eps="3.5" mue="1" rho="2.3" rho_set="2"></Material>
</Materials>

If $\rho$ is considered the values are compared to rho_set. The decision which material corresponds to a certain element is taken by calculating a probability for each material of the material file and the material with the highest probability is chosen. This works much better than the cut based approach used in case of the text file based data export, since it can happen that elements made of Kapton, that are close to PEC elements, have a permittivity of $\epsilon_r=2.6$ .
The parameters mue and rho are not used at all up to now. If you want to use the assignment based on $\rho$ make sure the values set in CST match the value of rho_set given in the material xml file. This means if the assignment based on $\epsilon_r$ is used, the values rho_set given in the material xml file are not used at all. In principle both methods lead to similar results and you can simply stick to $\epsilon_r$ . The advantage of using the density is, that you can set arbitrary values in CST (since the density does not effect the field calculation) in order to achieve a better material separation during the export step.

Calculation of an element property.

From CST you can get a material matrix via CST_GetMaterialMatrixHexMesh, which gives a value for each node. When the physical value of the element property is calculated, element specific quantities need to be calculated (see GetMaterialValeAtXYZ.m -> inv_x, inv_y, inv_z). For this calculation the indexes (i,j,k) of node 3 are required (see CST_Readout::GetNodesForElement), which ensures that the position i+1 exists in the mesh. The element material property is calculated using the element specific quantities and material matrix value of a node of the element. In principle this could be every node of the element. This is the reason why the function CST_Readout::GetMaterialPropertyFromIndex not only takes the indexes of certain node, but the indexes of node 3 and the super index of any of the element nodes.

Acknowledgment

The binary data export and the work around for the CST bug concerning the potential export is based on contributions and ideas of Yurii Piadyk.