What does the kernel interface look like? Every kernel's argument list must correspond to this one.
Adhere to the below naming convection for the kernel names
mus_advRel_k
Examples: mus_advRel_kFluid_rBGK_vStd_lD3Q19 mus_advRel_kFluidIncomp_rBGK_vStd_lD3Q19 mus_advRel_kFluid_rBGK_vHRR_lD3Q19
For non-specific implementation leave names out. So we do not use generic keyword in the kernel names anymore. Examples: mus_advRel_kFluid_rBGK_vStd_l mus_advRel_kMsLiquid_rBGK_vStd_l
| Type | Intent | Optional | Attributes | Name | ||
|---|---|---|---|---|---|---|
| type(mus_field_prop_type), | intent(in) | :: | fieldProp(:) |
Array of field properties (fluid or species) |
||
| real(kind=rk), | intent(in) | :: | inState(nElems*varSys%nScalars) |
input pdf vector |
||
| real(kind=rk), | intent(out) | :: | outState(nElems*varSys%nScalars) |
output pdf vector |
||
| real(kind=rk), | intent(inout) | :: | auxField(nElems*varSys%nAuxScalars) |
Auxiliary field computed from pre-collision state Is updated with correct velocity field for multicomponent models |
||
| integer, | intent(in) | :: | neigh(nElems*layout%fStencil%QQ) |
connectivity vector |
||
| integer, | intent(in) | :: | nElems |
number of elements in state Array |
||
| integer, | intent(in) | :: | nSolve |
number of elements solved in kernel |
||
| integer, | intent(in) | :: | level |
current level |
||
| type(mus_scheme_layout_type), | intent(in) | :: | layout |
current layout |
||
| type(mus_param_type), | intent(in) | :: | params |
global parameters |
||
| type(tem_varSys_type), | intent(in) | :: | varSys |
variable system definition |
||
| type(mus_derVarPos_type), | intent(in) | :: | derVarPos(:) |
position of derived quantities in varsys for all fields |
The common subroutine interface for compute kernels. All kernels have to implement this interface in order to be callable via mus_scheme_type%compute function pointer.