Andy Porter

`Kern.get_kernel_schedule()` (which is to be replaced/removed if/when we migrate Kern to subclass Call) currently caches the PSyIR of the kernel. `KernelModuleInlineTrans` creates a copy of this PSyIR and then inserts...

If we have an Algorithm layer that contains two `invoke`s that each call the same kernel then we attempt to apply `KernelModuleInlineTrans` to each kernel call. If the first one...

Thinking about this a bit more, I belatedly realise that if a given PSy layer routine calls the same kernel more than once then either all of them must be...

I've realised that `Kern.module_inline` sets this flag for *all* Kernels with that name in the current `InvokeSchedule`. This seems sensible but is causing me problems because we end up with...

The trouble with the LFRic example is that we have two, *separate* `invoke` calls, each with the same Kernel. The first Kernel gets module inlined but has to be modified...

With this branch and latest gpu script in lfric/examples: 

Adding RANDOM_NUMBER intrinsic to available_on_device - build still worked OK on GPU but profile didn't look much different. Need to update the Sankey diagram and see whether I've missed anything.

One of the compilation tests fail with the nvidia compiler. This same test passes with gfortran: 

``` $ nvfortran -I../dynamo_wrapper0/utilities -I../dynamo_wrapper0/field -I../dynamo_wrapper0/operator -I../dynamo_wrapper0/function_space -I../dynamo_wrapper0/mesh -I../dynamo_wrapper0/scalar -I../dynamo_wrapper0/configuration -c psy.f90 NVFORTRAN-S-0155-Ambiguous interfaces for generic procedure mixed_code (psy.f90: 289) ```

The problem is that the invoke subroutine is still importing the kernel interface, even though it has been module inlined: ```fortran SUBROUTINE invoke_1(scalar_r_phys, a, istp) USE mixed_kernel_mod, ONLY: mixed_code ```...