Use PSyIR to generate the LFRic algorithm layer - Githubissues

stfc / PSyclone

Domain-specific compiler and code transformation system for Finite Difference/Volume/Element Earth-system models in Fortran

BSD 3-Clause "New" or "Revised" License

103 stars 28 forks source link

Use PSyIR to generate the LFRic algorithm layer #2343

Open rupertford opened 11 months ago

rupertford commented 11 months ago

This issue captures the outstanding problems when using PSyIR to generate the algorithm layer.

This option can be switched on by setting LFRIC_TESTING to True in generator.py.

Originally the code to create PSyIR versions of kernel metadata had to be removed (commented out) as it did not support multi-precision kernels. However, as multi-precision kernels are now supported, this is no longer required.

Running the following miniapps; skeleton, gungho. gravity-wave, shallow water, simple-diffusion the following errors are observed. There may be more as I was not able to run past the errors below.

[x] gungho/source/orography/surface_altitude_alg_mod.x90 : l_def should be r_def. Error observed in 2 miniapps
[x] gungho/source/algorithm/transport/mol/reconstruct_w3_field_alg_mod.x90 : no symbol for "point". However point does not exist in the file. Observed in 3 miniapps. > psyclone reconstruct_w3_field_alg_mod.x90 -d ../../../kernel/
[x] gungho/source/algorithm/map_fd_to_prognostics_alg_mod.f90: schedule object has no attribute 'name'. > psyclone map_fd_to_prognostics_alg_mod.x90 -d ../kernel -d ../../../components/science/
[x] x_innerproduct_x error - due to commented out code. This is no longer a problem.
[ ] generator.py message error - see issue #2390
[ ] errors in LFRic algorithm layer - submitted as an LFRic issue
[ ] LFRic algorithm layer invoke's in codeblocks due to PSyIR not supporting select case - see issue #2229

rupertford commented 10 months ago

The x_innerproduct_x problem was due to the generator.py lines being commented out as suggested in the first comment.These comments stop PSyclone from translating invoke's into specific calls to the PSy-layer. However, the comments were only required when there was no support for multi-precision kernels. These are now supported. By removing the comments suggested above the latest version of PSyclone now compiles and runs the skeleton miniapp successfully.

rupertford commented 10 months ago

The strange error in map_fd_to_prognostics_alg_mod.x90 was down to an error message failing as one of the results it was trying to output was raising an exception. Once this was fixed the error showed that the enforce_bc_kernel_type was not declared in subroutine hydrostatic_balance, so this needs changing in the LFRic algorithm code. The (working) error is quite good I think Kernel functor 'enforce_bc_kernel_type' in routine 'hydrostatic_balance' from algorithm file 'map_fd_to_prognostics_alg_mod.x90' must be named in a use statement ...

rupertford commented 10 months ago

The gravity wave miniapp also has the same error in a different file ...

Kernel functor 'dg_inc_matrix_vector_kernel_type' in routine 'back_substitute' from algorithm file 'working/algorithm/iterative_solvers/mixed_schur_preconditioner_alg_mod.x90' must be named in a use statement

rupertford commented 10 months ago

The gravity wave miniapp also has a missing r_def declaration error in working/algorithm/moist_dyn_factors_alg_mod.x90 ... The following symbols are not explicitly declared or imported from a module and there are no wildcard imports which could be bringing them into scope: 'r_def'. The i_def declaration was not used to just changed this to r_def.

rupertford commented 10 months ago

PSyclone is failing to modify all algorithm invoke's into calls to the PSy-layer in field_vector_mod. My initial guess is that some of them end up in code blocks so are not seen when transforming the code.

rupertford commented 10 months ago

The file is in infrastructure/source/field/field_vector_mod.x90 and can be run directory with PSyclone psyclone field_vector_mod.x90. As expected the problem is to do with code blocks. Many of the invoke's in this routine are surrounded by select type constructs () which are currently translated to codeblocks. For example ...

  SELECT TYPE(source)
  TYPE IS (...)
      CALL invoke(...)
  CLASS DEFAULT
  ! ...
END SELECT

rupertford commented 10 months ago

I see that this issue has already been captured in #2229

rupertford commented 10 months ago

The error in gungho/source/algorithm/transport/mol/reconstruct_w3_field_alg_mod.x90 has gone away with the latest version of PSyclone.