[LFRic] Obtain precision map values from LFRic source.

[arporter]

In #1892 I added a map from LFRic precision symbol names to actual precision values (in bytes). To simplify things in that PR I just added it to LFRicConstants but this map should really be in the config. file.

[sergisiso]

Reviewing #1892, I think this is a good temporary solution but I am a bit worried for the 2 sources of truth of the precision symbols values. The (now LFRicConstants or future config file map) and the LFRic infrastructure/source/utilities/constants_mod.F90.

As part of this issue we should explore getting the values directly from the constants_mod module instead of replicating them in PSyclone.

[arporter]

Just a further note to say that the values of "r_tran", "r_solver" and "r_def" in constants_mod.F90 are set within CPP ifdefs and thus are only known for certain at build time.

[TeranIvy]

Update from a recently opened issue #2159: "The default precision for both [r_bl and r_phys] will be 8, but as with r_tran and r_solver, this will be configured at compile time (between 8 and 4) according to the CPP ifdefs."

Ian and I also agreed it would be good to move the DATA_TYPE_MAP to the configuration file.

[arporter]

#2364 has moved the map values into the configuration file. Next step is to obtain them from the LFRic infrastructure itself.

[arporter]

Upon discussion with @christophermaynard and @TeranIvy, we have decided that, actually, PSyclone doesn't need to know about the actual precisions that the various labels (r_def etc). We also think that the locations of the various type definitions (e.g. for field_type) could be discovered from the LFRic infrastructure.

[arporter]

When inlining a mixed-precision kernel, PSyclone has to be able to determine which implementation is being called. To do this, it examines the type of each argument supplied by the call. Unfortunately, the precision within a kernel is defined as r_double/r_single and that gives rise to, e.g.:

CallMatchingArgumentsNotFound: Argument type mismatch of call argument 'detj' (Scalar<REAL, Reference[name:'r_def']>) and routine argument 'dj' (Scalar<REAL, Reference[name:'r_single']>)

r_def is a kind parameter in constants_mod.F90 which is pre-processed to select whether it is 32- or 64-bit.

Possibly, 'all' that we need to do is improve the type comparison so that it "bottoms-out" what values the kind-parameters actually have as they can then be compared for equality.

constants_mod.F90 contains:

  ! Default real kind for application.
#if (RDEF_PRECISION == 32)
  integer,      parameter :: r_def = real32
  character(3), parameter :: PRECISION_REAL = '32'
#elif (RDEF_PRECISION == 128)
  integer,      parameter :: r_def = real128
  character(3), parameter :: PRECISION_REAL = '128'
#else
  integer,      parameter :: r_def = real64
  character(3), parameter :: PRECISION_REAL = '64'
#endif