(Towards #1824) extend get_kernel_schedule to support mixed precision kernels

[arporter]

Mixed precision kernels have multiple subroutines defined in an interface block. This PR extends get_kernel_schedule to work with such kernels.

[arporter]

I've yet to work out a way of determining which of the actual subroutine arguments have their precision determined by the arguments in the algorithm layer (i.e. to find the scalar, field and operator arguments).

[codecov[bot]]

Codecov Report

Base: 99.85% // Head: 99.83% // Decreases project coverage by -0.01% :warning:

Coverage data is based on head (5fe9287) compared to base (9d5c422). Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1892      +/-   ##
==========================================
- Coverage   99.85%   99.83%   -0.02%     
==========================================
  Files         285      285              
  Lines       40813    40867      +54     
==========================================
+ Hits        40752    40801      +49     
- Misses         61       66       +5     

Impacted Files	Coverage Δ
...mmon/transformations/kernel_module_inline_trans.py	100.00% <100.00%> (ø)
...transformations/raise_psyir_2_gocean_kern_trans.py	100.00% <100.00%> (ø)
src/psyclone/domain/lfric/kernel_interface.py	100.00% <100.00%> (ø)
src/psyclone/domain/lfric/lfric_constants.py	100.00% <100.00%> (ø)
src/psyclone/dynamo0p3.py	99.88% <100.00%> (+<0.01%)	:arrow_up:
src/psyclone/gocean1p0.py	99.87% <100.00%> (+<0.01%)	:arrow_up:
src/psyclone/psyGen.py	97.86% <100.00%> (-0.51%)	:arrow_down:
src/psyclone/psyir/frontend/fparser2.py	100.00% <100.00%> (ø)
src/psyclone/tests/dynkern_test.py	100.00% <100.00%> (ø)
src/psyclone/tests/gocean1p0_test.py	100.00% <100.00%> (ø)
... and 9 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

[arporter]

This has ended up looking quite big because it changes get_kernel_schedule which was used in a lot of tests. However, most of those changes are quite small. It also succeeds in removing the GOFparser2Reader subclass which is pleasing. CI happiness permitting, this is ready for review from @sergisiso.

[sergisiso]

respect to last time I tried (master?)

Not master, this PR makes 2 more calls able to be inlined compared to master, this means that almost all the interfaces that now succeed to be retrieved by the reader now fail at the next statement, the validate_kernel_code_args :) Therefore, it is still progress and I am happy to leave the validation issues for another PR

However, from when I tried it ~2months ago to now the kernels that pass the metadata validation have decreased from 96 to 54, with this PR it increases to 56.

A more general question is how does this validate related to the RaisePSyIR2LFRicKernTrans._validate , are they doing the same? will the second replace the first at some point?

[arporter]

the validate_kernel_code_args fails more often with e.g.:

• NotImplementedError: Evaluator shapes not implemented in kernel_interface class.
• Generation Error: Unsupported space for basis function, expecting one of ['w3', 'wtheta', 'w2v', 'w2vtrace', 'w2broken', 'w0', 'w1', 'w2', 'w2trace', 'w2h', 'w2htrace', 'any_w2', 'wchi'] but found 'any_space_1'
• KeyError: 'r_single'

Hopefully, I've fixed the last of these three now by extending the precision map. The first two are going to be harder, particularly the second one. As @hiker has noticed recently, the ArgOrdering class makes use of some of the DynCollection classes which isn't very nice. The one that's causing trouble here is the one for basis functions (DynBasisFunctions). It's complaining because it's expecting to have to provide dimension information for the basis function arrays and it can't do that if they are on any space. However, the way we're using it here means that we don't need to worry about that because we're not going to try to declare anything.

The first one is actually the subject of #928 although this isn't mentioned in the code itself (naughty).

[arporter]

I thought this was ready to go again but I've just checked with compilation and the GOcean ACCRoutineTrans is failing because the procedure specified in the metadata isn't renamed when the kernel is renamed (psyir/transformations/kernel_transformation_test.py:111). Presumably this used to work so I've broken something.

[arporter]

I've realised that I hadn't been consistent in what I'd done for GOcean and LFRic. In the former I raised the PSyIR, in the latter I didn't. I've changed the LFRic implementation so that it does now raise the PSyIR and now I get the same errors that Sergi reported about operator arguments being on any-space function spaces. I'm not sure of the best way to proceed from here unless there's something simple I can do to work around that problem for the moment.

[arporter]

I've decided that making LFRic and GOcean consistent is going to have to wait for #928 - for now I don't attempt to raise the PSyIR of an LFRic kernel. All tests now pass with compilation. CI-permitting, this is ready for another look.

[arporter]

CI-permitting, this is ready for another look now. I've added the extra validation check and a further LFRic test for the module-inline transformation to exercise it. I've also taken the opportunity to rename the new test file for GOSymbolTable so that it is in-line with the module name that Joerg has moved it to in #1918.