(Closes #3170) Adds support for fields and operators of explicit real32 or real64 kind.

[arporter]

No description provided.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (a7ea7cc) to head (fa07d1d).

Additional details and impacted files

@@            Coverage Diff            @@
##            master     #3455   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files          393       393           
  Lines        55067     55089   +22     
=========================================
+ Hits         55067     55089   +22     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[arporter]

ITs were all green. Ready for review. Also ready to be tested by @stevemullerworth or @tommbendall if they have time.

[LonelyCat124]

Looks good from my side - @arporter do we want to wait on testing from LFRic side before merging?

[arporter]

Yes, worth waiting for @stevemullerworth or @tommbendall if they have time? If they don't then it can go on (as it's un-used currently) and we can experiment with it later.

[stevemullerworth]

I have had a go with this, but had problems. Possibly my problems are related to not installing PSyclone correctly alongside our existing software stack that includes PSyclone. To get it to work I changed PATH, PSYCLONE_CONFIG, PSYCLONE_LIB_DIR and PYTHONPATH to point to a local clone of the branch.

I managed to build our lfric_core skeleton app with this PSyclone branch (after merging in the current psyclone_next branch into lfric_core). I then modified lfric_core/components/science/source/algorithm/sci_assign_field_random_range_alg_mod.x90 to change the variable shift to type( field_real32_type) shift, and included the required use field_real32_mod, only: field_real32_type statement. On rebuilding, I got the following stack trace:

PSyclone - global optimisation working/skeleton/algorithm/sci_assign_field_random_range_alg_mod.x90 Error, unexpected exception, please report to the authors: Traceback (most recent call last): File "/scratch/psyclone/PSyclone/src/psyclone/generator.py", line 763, in main alg, psy = generate( ^^^^^^^^^ File "/scratch/psyclone/PSyclone/src/psyclone/generator.py", line 285, in generate .create(invoke_info) ^^^^^^^^^^^^^^^^^^^ File "/scratch/psyclone/PSyclone/src/psyclone/psyGen.py", line 191, in create return PSyClass(invoke_info) ^^^^^^^^^^^^^^^^^^^^^ File "/scratch/psyclone/PSyclone/src/psyclone/domain/lfric/lfric_psy.py", line 67, in __init__ self._invokes = LFRicInvokes(invoke_info.calls, self) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/scratch/psyclone/PSyclone/src/psyclone/domain/lfric/lfric_invokes.py", line 60, in __init__ Invokes.__init__(self, alg_calls, LFRicInvoke, psy) File "/scratch/psyclone/PSyclone/src/psyclone/psyGen.py", line 312, in __init__ my_invoke = invoke_cls(alg_invocation, idx, self) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/scratch/psyclone/PSyclone/src/psyclone/domain/lfric/lfric_invoke.py", line 145, in __init__ self.proxies = LFRicProxies(self) ^^^^^^^^^^^^^^^^^^ File "/scratch/psyclone/PSyclone/src/psyclone/lfric.py", line 1298, in __init__ LFRicTypes.add_precision_symbol(ctable, arg.precision) File "/scratch/psyclone/PSyclone/src/psyclone/domain/lfric/lfric_types.py", line 627, in add_precision_symbol raise ValueError(f"'{name}' is not a recognised LFRic precision.") ValueError: 'real32' is not a recognised LFRic precision.

[arporter]

@stevemullerworth apologies - you'll need to edit your PSyclone configuration file in the same way as is done here. We were only discussing today that we need to get rid of these settings (in favour of reading constants_mod.f90)...

[stevemullerworth]

Thanks, this works - I tested changing one field to real64 and one to real32 and it all compiles (the real32 is used in a built-in so there is no clash with a kernel kind).

Also, I noticed that our build system can point to a different config using PSYCLONE_CONFIG_FILE (as opposed to PSYCLONE_CONFIG), and changing PSYCLONE_CONFIG_FILE to point to the centrally-installed version also worked. I will enquire as to why we still maintain a copy of this file in our source.

[arporter]

Back to you @LonelyCat124 now that Steve has had success :-)