Open TeranIvy opened 3 years ago
Following on from our chat in the telco this morning, it sounds as though the random-number initialisation functionality needed for PSyAD should also be a dof-wise kernel. In fact, for the simplest case it could just be a built-in? I guess it depends on what Ben's existing kernel code already does?
LFRic builtins use the LFRicKernelMetadata
to store and validate their metadata. However, user-defined kernels use the newer LFRicKernMetadata
, LFRicKern
, and LFRicArgDescriptor
to store and validate their metadata. This means that no checks are required to be added to LFRicKernelMetadata
to validate user-defined kernels that operate on dofs since this isn't touched by LFRicKern
.
'dof'
to the list of USER_KERNEL_ITERATION_SPACES
in LFRic Constantsiterates_over
is equal to dof
and modify loop_type
to equal dof
. This will then be picked up by LFRicLoop
and set the iterator tag to df
.operates_on = 'dof'
is used by Builtins validating their metadata through LFRicKernelMetadata
. Should just add a one line conditional to LFRicKern
to check if self.name
is the name of a builtin. This should add a little bit of protection.domain/lfric/lfric_arg_descriptor.py
:
# Test allowed accesses for fields
field_disc_accesses = [AccessType.READ, AccessType.WRITE,
AcessType.READWRITE]
domain/lfric/lfric_arg_descriptor.py
:
# Test allowed accesses for scalars (read_only or reduction)
scalar_accesses = [AccessType.READ] + AccessType.get_valid_reduction_modes()
Originally we had preliminary support for user-defined kernels that operate on DoFs. However, it produced incorrect code and we removed it until the need arises.
There are several LFRic PSyKAl-lite routines that could be removed with this support, hence this issue. Furthermore, it seems that we need to differentiate between
operates_on = DOF
andoperates_on = DOF_COLUMN
.