stfc
Support custom function spaces in LFRic (multi-data fields, different number of layers and data)
~~Relevant LFRic documentation is in this LFRic wiki.~~
Update: The support will require a redesign of function space representation. See this new LFRic wiki.
Update, 21/10/2025: The design was discussed with STFC and the idea is to not have custom function spaces to capture the changes in nlayers and ndata as they are properties of the field and not function space continuity (the design of LFRic stores dofmaps in function space object). The current conclusion is to have additional metadata in the field argument types.
- [ ] Metadata parsing support and related documentation. LFRic design wiki for metadata.
- [ ] Kernel arguments for fields on column (declarations, call argument list, stub argument list). LFRic design wiki for fields on column.
- [ ] Kernel arguments for fields on domain (declarations, call argument list, stub argument list). LFRic design wiki for fields on domain.
- [ ] Kernel arguments for operators (declarations, call argument list, stub argument list).
- [ ] Kernel argument lists for basis functions/quadrature (declarations, call argument list, stub argument list).
For LFRic #4511, scalar arguments and multiple function spaces are required within various inter-grid kernels. The functionality of this issue could be used to generalise inter-grid kernels.
The kernels in question map between function spaces of different element orders, which are on different meshes (making it an inter-grid kernel). The requirement for a scalar argument stems from PSyclone not passing the number of DoFs of the source space, as it is assumed that the function spaces of the source and target are identical. If PSyclone were to pass in ndf_source then I would not require scalar arguments, however issue #2504 would remain.
I've given it some thought and come up with the following new version of the rules for kernel arguments:
I'm fairly happy although the fact that we're conflating dof-map with function space makes things a bit tricky wording wise.
Having discussed with @TeranIvy, we have agreed that we will need some recognised names for numbers of layers because there are physics 'kernels' with ~100 arguments but only two or three different values of nlayers - we don't want to have to extend the argument list as that would be massive.
Therefore, we need an agreed set of names that will be added to argument_mod.F90 and recognised by PSyclone (well, read from the configuration file).
On the preset arguments for number of levels, we have four hard-coded extrusions at the moment: https://code.metoffice.gov.uk/trac/lfric/browser/LFRic/trunk/infrastructure/source/mesh/extrusion_mod.f90#L30 i.e.
! Enumerators for different extrusion types
integer(i_def), parameter, public :: PRIME_EXTRUSION = 8881
integer(i_def), parameter, public :: TWOD = 6424
integer(i_def), parameter, public :: SHIFTED = 1298
integer(i_def), parameter, public :: DOUBLE_LEVEL = 734
SHIFTED is uncommon and I'm not sure that DOUBLE_LEVEL is now used anywhere.
If we go down the route of having some agreed names, would it be simplest if the PSyclone metadata names match these?
Unlike NDATA, I don't think there will be any kernels that would have more than 3 different arguments with different numbers of levels. But as per my comment here about NDATA, https://github.com/stfc/PSyclone/pull/3209#discussion_r2498750708, the most flexible system would allow runtime values to be defined locally in a kernel
