Stencil definitions
A stencil is basically a set of element-offsets $(s_x, s_y, s_z)$, describing the relative positions of all required elements for a given element.
Type | Visibility | Attributes | Name | Initial | |||
---|---|---|---|---|---|---|---|
character(len=labelLen), | public | :: | label |
a stencil label |
|||
integer, | public | :: |
number of directions |
||||
integer, | public | :: | QQN |
Todo HK: do we really need this? It is mostly confusing, and solver specific! number of directions excluding the central (0,0,0) |
|||
integer, | public | :: | nDims | = | 0 | ||
integer, | public, | allocatable | :: | cxDir(:,:) |
cartesian directions of discrete velocities. Integer number version. Size is (3,nDir) |
||
real(kind=rk), | public, | allocatable | :: | cxDirRK(:,:) |
Cartesian directions of discrete velocities. Real number version. Size is (3,nDir) |
||
integer, | public, | allocatable | :: | cxDirInv(:) |
inverted cartesian direction indices. this is well defined for symmetric stencils only. |
||
real(kind=rk), | public, | allocatable | :: | cxcx(:,:) |
2nd order tensor of discrete velocities Size is (6,QQ) for 3D: xx, yy, zz, xy, yz, xz (3,QQ) for 2D: xx, yy, xy (1,QQ) for 1D: xx |
||
integer, | public, | allocatable | :: | map(:) |
mapping of stencil entries to treelm definition, if possible entry is zero if nothing defined,
|
||
integer, | public, | allocatable | :: | map2treeDef(:) |
mapping of treelm definition to stencil entries, if possible entry is zero if nothing defined |
||
integer, | public | :: | restPosition |
Rest-density position in stencil |
|||
integer, | public | :: | depStencil |
the stencil on which the current one depends this is required for boundary stencils which elements actually require the neighbors of the compute stencil |
|||
logical, | public | :: | useAll |
use this stencil for all elements |
|||
logical, | public | :: | requireNeighNeigh | = | .false. |
requires valid neighbors of the stencil neighbors |
|
logical, | public | :: | requireAll | = | .false. |
requires valid neighbors of the stencil neighbors |
|
integer, | public | :: | nElems |
the number of elements using this stencil |
|||
type(grw_intarray_type), | public, | allocatable | :: | elemLvl(:) |
list of elements on which this stencil should be applied Both elemLvl and elem array are used for stencil other than fluid stencil |
||
type(grw_intarray_type), | public | :: | elem |
list of elements on which this stencil should be applied In build_BCstencil they point to original treeID list and used in tem_initelemLevels. Later this position is updated such that they point to the level wise total list in update_elemPosToTotalPos. |
type tem_stencilHeader_type !> a stencil label character(len=labelLen) :: label !> number of directions integer :: QQ !>@todo HK: do we really need this? It is mostly confusing, and solver !! specific! !! !! number of directions excluding the central (0,0,0) integer :: QQN integer :: nDims = 0 !> cartesian directions of discrete velocities. !! Integer number version. !! Size is (3,nDir) integer, allocatable :: cxDir(:,:) !> Cartesian directions of discrete velocities. !! Real number version. !! Size is (3,nDir) real(kind=rk), allocatable :: cxDirRK(:,:) !> inverted cartesian direction indices. !! this is well defined for symmetric stencils only. integer, allocatable :: cxDirInv(:) !> 2nd order tensor of discrete velocities !! Size is (6,QQ) for 3D: xx, yy, zz, xy, yz, xz !! (3,QQ) for 2D: xx, yy, xy !! (1,QQ) for 1D: xx real(kind=rk), allocatable :: cxcx(:,:) !> mapping of stencil entries to treelm definition, if possible !! entry is zero if nothing defined, !! @todo: SZ: is this really the case? !! -1 if a stencil entry with entries further than neighbor are encountered integer, allocatable :: map(:) !> mapping of treelm definition to stencil entries, if possible !! entry is zero if nothing defined integer, allocatable :: map2treeDef(:) !> Rest-density position in stencil integer :: restPosition !> the stencil on which the current one depends !! this is required for boundary stencils which elements actually require !! the neighbors of the compute stencil integer :: depStencil !> use this stencil for all elements logical :: useAll !> requires valid neighbors of the stencil neighbors logical :: requireNeighNeigh = .false. !> requires valid neighbors of the stencil neighbors logical :: requireAll = .false. !> the number of elements using this stencil integer :: nElems ! @todo: SZ: elemLvl and elem host more or less the same data maybe one ! of them could be removed. ! - elem is used in tem_construction (not in musubi, as far as ! I saw) ! - elemLvl is used in the tem_construction (not in musubi, as ! far as I saw) !> list of elements on which this stencil should be applied !! Both elemLvl and elem array are used for stencil !! other than fluid stencil type(grw_intArray_type), allocatable :: elemLvl(:) !> list of elements on which this stencil should be applied !! In build_BCstencil they point to original treeID list !! and used in tem_initelemLevels. !! Later this position is updated such that they point to !! the level wise total list in update_elemPosToTotalPos. ! KM: changed from allocatable array to growing array since ! musubi needs to create growing array of stencil headers ! and element list for each stencil header type(grw_intArray_type) :: elem end type tem_stencilHeader_type