Difference between revisions of "Code coupling in Kraken"

From Kraken Wiki
Jump to: navigation, search
(Created page with " == 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 wai...")
 
(giveInputFieldTemplates)
Line 119: Line 119:
 
| Mesh data, see sub section Mesh types  
 
| Mesh data, see sub section Mesh types  
 
|}
 
|}
 +
 +
After the solver has finished sending data to Cerberus, it should wait for further signals from Cerberus.
  
 
== Field unit array ==
 
== Field unit array ==

Revision as of 12:54, 23 March 2018

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 fulfill 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 double.

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 double.

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 double.

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 subsection "Field unit array")
S->C 1*integer Type of the mesh that the field is on (see subsection 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.

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