Difference between revisions of "Code coupling in Kraken"
(→giveFieldData) |
(→takeFieldData) |
||
| Line 242: | Line 242: | ||
| {{highlight|C|PaleGreen}}->{{highlight|S|tomato}} | | {{highlight|C|PaleGreen}}->{{highlight|S|tomato}} | ||
| | | | ||
| − | | NV* | + | | NV*float |
| The values for the field. | | The values for the field. | ||
|} | |} | ||
Revision as of 14:15, 13 February 2019
Basics of signalling
When the solver is executed from command line by Cerberus, the solver should read its own input and go through the basic initialization before waiting for further signals from Cerberus.
After each order received from Cerberus, the solver should fullfill the order and wait for further signals from Cerberus.
Basic "function calls"
When the solvers have completed their previous order and are waiting for the next signal from Cerberus, Cerberus will initiate the communication with a single integer indicating which "function call" should be processed.
The function calls that should be supported by the solvers are:
- terminate
- returnPresentTime
- suggestTimeStep
- setTimeStep
- solveTimeStep
- validateTimeStep
- abortTimeStep
- giveInputFieldTemplates
- giveOutputFieldTemplates
- giveFieldData
- takeFieldData
Each of these function calls corresponds to a certain integer, that are listed in some centrally located header (or some such) files for C and Fortran.
The following sections will go through the signalling for each of the function calls
terminate
When Cerberus sends the signal for a solver to terminate. The solver simply exits gracefully. Final results can be collected, processed and printed out. Memory should be freed, and the process should be terminated in the end.
No further signalling takes place after the C->S signal to terminate.
returnPresentTime
The solver should return the time corresponding to the current time point as a float.
After the S->C communication of the value. The solver should wait for further signals from Cerberus.
suggestTimeStep
The solver should return a preferred length for the next time step as a float.
After the S->C communication of the value. The solver should wait for further signals from Cerberus.
setTimeStep
The solver should receive a length for the next time step as a float.
After the C->S communication of the value. The solver should wait for further signals from Cerberus.
solveTimeStep
The solver should execute the solution for the next time step. This can include some initialization and post-processing for the current solution if needed.
After the solution has completed. The solver should wait for further signals from Cerberus.
validateTimeStep
The solver should accept the previous solution as the final solution for the previous time step. The previous time step will not be calculated again.
After any necessary processing has completed. The solver should wait for further signals from Cerberus.
abortTimeStep
The solver should reload the solution from the beginning of the previously solved time step, discarding the end-of-timestep solution. The previous time step will most likely be calculated again. The solver should update its internal time to reflect this change.
After any necessary processing has completed. The solver should wait for further signals from Cerberus.
giveInputFieldTemplates
The solver should communicate, which sorts of fields it is expecting to receive from Cerberus. The communication syntax is as follows:
| Direction | Name | Size and type | Content |
|---|---|---|---|
| S->C | NF | 1*integer | Number of fields to be provided |
| The following repeats NF times: | |||
| S->C | Lname | 1*integer | Length of field name in char excluding terminating character |
| S->C | Lname*char | Name of the field | |
| S->C | 5*integer | Unit of the field in an OpenFOAMish array (see Field unit array) | |
| S->C | 1*float | Multiplier used to convert from the base unit type specified by the unit array to the actual unit used by the solver. | |
| S->C | 1*integer | Type of the mesh that the field is on (see Mesh types). | |
| S->C | <depends on mesh> | Mesh data, see sub section Mesh types |
After the solver has finished sending data to Cerberus, it should wait for further signals from Cerberus.
giveOutputFieldTemplates
The solver should communicate, which sorts of fields it is expecting to provide to Cerberus. The communication syntax is as follows:
| Direction | Name | Size and type | Content |
|---|---|---|---|
| S->C | NF | 1*integer | Number of fields to be provided |
| The following repeats NF times: | |||
| S->C | Lname | 1*integer | Length of field name in char excluding terminating character |
| S->C | Lname*char | Name of the field | |
| S->C | 5*integer | Unit of the field in an OpenFOAMish array (see Field unit array) | |
| S->C | 1*float | Multiplier used to convert from the base unit type specified by the unit array to the actual unit used by the solver. | |
| S->C | 1*integer | Type of the mesh that the field is on (see Mesh types). | |
| S->C | <depends on mesh> | Mesh data, see sub section Mesh types |
After the solver has finished sending data to Cerberus, it should wait for further signals from Cerberus.
giveFieldData
The solver should provide the data for the field requested by Cerberus.
The communication syntax is as follows:
| Direction | Name | Size and type | Content |
|---|---|---|---|
| C->S | Lname | 1*integer | Length of name of field to be passed (in char excluding terminating character). |
| C->S | Lname*char | Name of the field to be passed | |
| S->C | NV | 1*integer | Number of values to be passed. |
| S->C | NV*float | The values for the field. |
After the solver has finished passing data to Cerberus, it should wait for further signals from Cerberus.
takeFieldData
The solver should receive the data for the field indicated by Cerberus.
The communication syntax is as follows:
| Direction | Name | Size and type | Content |
|---|---|---|---|
| C->S | Lname | 1*integer | Length of name of field to be passed (in char excluding terminating character). |
| C->S | Lname*char | Name of the field to be passed | |
| C->S | NV | 1*integer | Number of values to be passed. |
| C->S | NV*float | The values for the field. |
After the solver has finished receiving data from Cerberus, it should wait for further signals from Cerberus.
Field unit array
The field unit array consists of 5 integers (e.g. 1 -3 0 0 0 for mass density) specifying the dimension for each of the 5 SI base units for the field
| No. | Property | Unit |
|---|---|---|
| 1 | Mass | kilogram (kg) |
| 2 | Length | metre (m) |
| 3 | Time | second (s) |
| 4 | Temperature | Kelvin (K) |
| 5 | Quantity | mole (mol) |
This means that some of the basic fields that we might transfer will have types of
| Field name | SI unit | Basic unit | Unit array |
|---|---|---|---|
| Mass density | kg/m3 | kg*m-3 | 1 -3 0 0 0 |
| Temperature | K | K | 0 0 0 1 0 |
| Power (integral) | W | kg*m2*s-3 | 1 2 -3 0 0 |
| Power density | W/m3 | kg*m-1*s-3 | 1 -1 -3 0 0 |
Mesh types
Each physical data field consists of values on a specific mesh. Whereas several mesh types should be supported by Cerberus, the individual solvers typically only need to support their own mesh types. This section describes the geometry of the different mesh types supported by Cerberus and the mesh-data (the ordered list of values exactly specifying the mesh) associated with each mesh type.
Type 1 — Structured Cartesian mesh
Structured Cartesian meshes (in Kraken) are 3D meshes that cover a cuboid volume ([xmin, xmax]*[ymin, ymax]*[zmin, zmax]) and have a fixed number of cells in the x-, y- and z-direction (Nx, Ny, Nz). The total number of cells is the product of the number of cells in each of the three coordinate directions. The size/spacing of the cells need not be constant.
The mesh data for structured Cartesian meshes is as follows
| Data type/size | Data content (explanation) | Data content (example) | Notes |
|---|---|---|---|
| 1*integer | Mesh type | 1 | |
| Information on mesh size | |||
| 1*integer | Nx | 2 | Positive value indicates regular spacing, negative indicates variable spacing. |
| 1*integer | Ny | 1 | Positive value indicates regular spacing, negative indicates variable spacing. |
| 1*integer | Nz | 4 | Positive value indicates regular spacing, negative indicates variable spacing. |
| Information on mesh boundaries | |||
| either 2*float | xmin, xmax | -10.0, 10.0 | Simply the outer limits in case of regular spacing. |
| or (Nx+1)*float | x0, x1, ..., xNx+1 | -10.0, -5.0, 10.0 | The cell boundaries in case of variable spacing. |
| either 2*float | ymin, ymax | -5.0, 5.0 | Simply the outer limits in case of regular spacing. |
| or (Ny+1)*float | y0, y1, ..., yNy+1 | -5.0, 5.0 | The cell boundaries in case of variable spacing. |
| either 2*float | zmin, zmax | 0.0, 100.0 | Simply the outer limits in case of regular spacing. |
| or (Nz+1)*float | z0, z1, ..., zNz+1 | 0.0, 35.0, 50.0, 65.0, 100.0 | The cell boundaries in case of variable spacing. |
| Information on cell indexing | |||
| 1*integer | Remapping of mesh cells | 0 or 1 | 0 for normal indexing with x-running fastest and z-slowest. 1 for custom remapping. |
| If indexing type was 1: | |||
| Nx*Ny*Nz*integer | Index of each cell, order of values corresponds to normal indexing. | 7, 8, 5, 6, 3, 4, 1, 2 | Set index of a cell to 0 if no value should be provided for it. |
