LFRic reductions use default precision

[rupertford]

In PSyclone there is an assumption that the precision of a scalar reduction variable will always be the default value (currently r_def).

This needs discussing with the Met Office to determine their requirements and see whether this assumption needs changing.

[rupertford]

@christophermaynard has just found that his branch does not work with PSyclone due to him declaring a reduction scalar with precision r_solver.

[rupertford]

Here is an example of generated code to help make it clear what the issues are ...

REAL(KIND=r_def), intent(out) :: asum
...
TYPE(scalar_type) global_sum
...
asum = 0.0_r_def
!
DO df=1,f1_proxy%vspace%get_last_dof_owned()
    asum = asum + f1_proxy%data(df)*f2_proxy%data(df)
END DO
global_sum%value = asum
asum = global_sum%get_sum()

[rupertford]

If the scalar reduction variable asum was declared as r_solver then the global sum (implemented in global_sum) would still be r_def as scalar_type uses r_def so any global sums would be done with r_def precision.

However, perhaps there would be some performance gain in performing local sums in lower precision.

I think the Met Office need to decide what they want here. @christophermaynard, care to comment?

[TeranIvy]

Note that we also have r_tran_field_type to support the mixed precision transport, see issue #1632.

[TeranIvy]

Well, we need this as Tom got this error when he tried updated the CMA test algorithm to work with r_solver kind:

Generation Error: This scalar is a reduction which assumes precision of type 'r_def' but the algorithm declares this scalar with precision 'r_solver'.

We don't currently have the LFRic infrastructure support for this so I'll talk with Mike. In the meantime Tom will write PSyKAl-lite code for inner product and sum built-ins used in the CMA test algorithm and reference this issue.

[TeranIvy]

The associated LFRic infrastructure support ticket is https://code.metoffice.gov.uk/trac/lfric/ticket/3401.

[TeranIvy]

From #2342: When local reductions are performed on fields, there is currently no guarantee that the precision of the field is converted to that of the local reduction variable (l_asum e.g.). To fix this, a precision comparison should be done between the field and the local reduction variable. If the precisions do not match, the field's data should be converted to the precision of the local sum variable.

That is one solution. Another would be to add LFRic infrastructure and PSyclone support for global reductions for other precisions than r_def. We already have two, r_solver_scalar_mod.F90 and r_tran_scalar_mod.F90.

[TeranIvy]

Note the related issue to introduce GlobalReduction and the relevant API sub-classes, #2381.