Accessing lfric_apps namelist in lfric_core

[Adrian Lock (Adrian-Lock)]

In MetOffice/lfric_core#374 I'm wanting to put some hardwired variables in lfric_core into a namelist. The one I've chosen lives in lfric_apps. This works fine in "normal" usage where apps and core are compiled together but, as far as I can tell, core doesn't have a dependency on lfric_apps. I've tried just adding that in to my branch's dependencies.sh but it's still failing to build because this namelist config can't be found:
dependerator.database.DatabaseException: ("Unable to find unit 'initial_temperature_config_mod'", None)
Is the lack of visibility of lfric_apps code when running core rose stem tests the correct diagnosis of my problem? Is it possible to include lfric_apps in the core dependencies.sh file, and if so, how?

[Adrian Lock (Adrian-Lock)]

Now I've written that, I guess the idea of "core" is that it shouldn't be dependent on any other code base, such as lfric_apps. And so perhaps the only solution is to move this subroutine where I want to add namelist variables into lfric_apps?

[Steve Mullerworth (stevemullerworth)]

The normal way would be to replace the hard-wired parameters with input variables.

The code that calls the routine lives in the application-specific code (in lfric_apps) and is responsible for getting the variables from its configuration namelist.

The existing subroutine remains generic and can stay in lfric_core - it can be called from any app regardless of the source of the theta perturbation values. A unit test for it can be written which can call the routine with values that only need to be included in the unit test code (and not in a namelist feign routine)

[Andrew Coughtrie (andrewcoughtrie)]

Looking at what you're doing in MetOffice/lfric_core#374 the variables you're trying to move are in a kernel which means you're going to have to pull the configuration variables all the way through from any calls in lfric_apps and down through the kernel API, you can't pass the config variables in through module use statements (as I mentioned in your other post we are trying to remove all config use statements but particularly in kernels).

[Steve Mullerworth (stevemullerworth)]

Apologies - I hadn't twigged it was a kernel. There is a slight extra complication in that when you pass arguments from the algorithm code they may come in as either single or double precision, so you will need a subroutine interface for both.

You can see many examples of this within the same directory which should make it more straightforward to implement. e.g. sci_enforce_lower_bound_kernel_mod.F90 which passes in lower_bound from the algorithm layer.

In short, two things need to be done:

• Each variable needs PSyclone metadata to mark the variable as a GH_SCALAR
• Two subroutines are required, one where the inputs are declared r_single and one where they are r_double. And an interface block will ensure the correct one is called depending on the precision of the build of the calling code.

[Adrian Lock (Adrian-Lock)]

Thanks Steve Mullerworth (@stevemullerworth) , that mainly makes sense. One question. The existing routine has reals input as kind=r_def, https://github.com/MetOffice/lfric_core/pull/374/changes#diff-c07c8b9a59179a13de93858825ce202fcaf8471dc89886c27ed70ae8cc90e825. Do I want to change those to be r_single and r_double too? I don't quite understand how the code currently manages to cope with input reals that can be of different precision but needs to have this single/double duplication when I add my scalar reals to the argument list?

[Adrian Lock (Adrian-Lock)]

I've tried that in this latest revision - is that what you had in mind?

[Steve Mullerworth (stevemullerworth)]

Quick look - it looks good.

Strictly, the requirement is only necessary where an application may call the kernel from both 32-bit and 64-bit regions. Such a possibility emerged relatively recently with the move to 32-bit testing of much of the physics codes, which is why not all existing kernels in the lfric core science component are compliant.

Given that the science component in LFRic core is intended to be generally usable, it's preferable that calls to them can be flexibly added to code without causing unexpected compile errors when people get around to mixed-precision testing.