PSyKE for generic Fortran backend

[LonelyCat124]

I'm having a bit of a look at examples/nemo/eg5 while on the train today.

I wanted to look where we are w.r.t PSyKE and generic code extraction, including driver generation and execution.

The first (clear issue), was that the default ExtractTrans doesn't do any driver generation.

This was a relatively easy change to get something, as I just added an apply method and used the ExtractDriverCreator from domain.common to add a _driver_creator to the ExtractNode.

This gave me some output, which was mostly ok. There are a few corrections required:

1. The output Fortran gives programs like program tra_adv.F90_tra_advr1, which are not allowed program names.
2. The filename of the open output doesn't match, it has call extract_psy_data%OpenReadModuleRegion('tra_adv.F90', 'tra_adv-r1') instead of call extract_psy_data%OpenReadModuleRegion('tra_adv, 'tra_adv-r1').
3. The wp kind isn't defined, so I had to manually add integer, parameter :: wp = 8 to compile the code.

To compile, I only managed to get this by hand, but I used:

gfortran driver-tra_adv.F90-tra_adv-r0.f90 ../../../lib/extract/binary/generic/psy_data_base.o -I/home/aidan/PSyclone/lib/extract/binary/generic -L/home/aidan/PSyclone/lib/extract/binary/generic /home/aidan/PSyclone/lib/extract/binary/generic/compare_variables_mod.o /home/aidan/PSyclone/lib/extract/binary/read_kernel_data_mod.o -I/home/aidan/PSyclone/lib/extract/binary -L/home/aidan/PSyclone/lib/extract/binary -o r0.exe

I had to manually build the extract library without MPI on my laptop
and got an r0.exe.

Running this r0.exe gave me this output:

(base-env) aidan@DIN-43888:~/PSyclone/examples/nemo/eg5$ ./r0.exe
Variable      max_abs      max_rel      l2_diff       l2_cos    identical    #rel<1E-9    #rel<1E-6    #rel<1E-3
      ji .0000000E+00 .0000000E+00 .0000000E+00 .1000000E+01 .1000000E+01 .0000000E+00 .0000000E+00 .0000000E+00
      jj .0000000E+00 .0000000E+00 .0000000E+00 .1000000E+01 .1000000E+01 .0000000E+00 .0000000E+00 .0000000E+00
      jk .0000000E+00 .0000000E+00 .0000000E+00 .1000000E+01 .1000000E+01 .0000000E+00 .0000000E+00 .0000000E+00
mydomain .0000000E+00 .0000000E+00 .0000000E+00 .1000000E+01 .5000000E+03 .0000000E+00 .0000000E+00 .0000000E+00
     pun .0000000E+00 .0000000E+00 .0000000E+00 .1000000E+01 .5000000E+03 .0000000E+00 .0000000E+00 .0000000E+00
     pvn .0000000E+00 .0000000E+00 .0000000E+00 .1000000E+01 .5000000E+03 .0000000E+00 .0000000E+00 .0000000E+00
     pwn .0000000E+00 .0000000E+00 .0000000E+00 .1000000E+01 .5000000E+03 .0000000E+00 .0000000E+00 .0000000E+00
   tmask .0000000E+00 .0000000E+00 .0000000E+00 .1000000E+01 .5000000E+03 .0000000E+00 .0000000E+00 .0000000E+00
     tsn .0000000E+00 .0000000E+00 .0000000E+00 .1000000E+01 .5000000E+03 .0000000E+00 .0000000E+00 .0000000E+00
   umask .0000000E+00 .0000000E+00 .0000000E+00 .1000000E+01 .5000000E+03 .0000000E+00 .0000000E+00 .0000000E+00
   vmask .0000000E+00 .0000000E+00 .0000000E+00 .1000000E+01 .5000000E+03 .0000000E+00 .0000000E+00 .0000000E+00

which I suspect is what I want to see (@hiker I assume this is an expected "correct" output?).

This is with the tra_adv example, which is a very easy example I think (no structures, just arrays of INTEGER and REAL), so we'd need to potentially expand to support custom types later - I'm not sure how the extraction library works so I have no comment on how to do that.

I guess the good news is that this doesn't need much to get this example working probably:

1. Extend ExtractTrans to support generating the driver(s).
2. Fix the issues highlighted above.
3. Fix up the example to be able to build and run the drivers (and summarise the results?).

Once we have that, we could extend it to make a tutorial explaining a process to build KGOs, and how to create a script to validate "correctness" of code modifications (but at a kernel by kernel level as opposed to just a correct/incorrect result).

[LonelyCat124]

I think 1 and 2 can be (naively) fixed by changing get_unique_region_name to have:

        if invoke:
            module_name = invoke.invoke.invokes.psy.name
        else:
            module_name = nodes[0].root.name
            module_name = module_name[:module_name.index(".F90")]

[LonelyCat124]

3 looks to be a bit more complex.

in BaseDriverCreator._create_read_in_code it loops through:

        for module_name, signature in read_write_info.all_used_vars_list:
            if not module_name:

This adds various arrays to the symbol table that have the kind parameter required, but it doesn't find the kind parameter (since no read_write_info is defined for wp since its never read/written).
How does the kind information get pulled for GOcean/LFRic @hiker @sergisiso ?

Probably this code needs to check each added symbol for a kind definition and then add the kind into the symbol table, but I don't remember how to do this (nor know if it might break how the GOcean or LFRic implementations work)

[arporter]

I suspect that in GOcean and LFRic we 'cheat' and always add a use statement for the module that we know contains the kind parameters. Symbol.reference_accesses will tell you what other Symbols its definition depends on.

[LonelyCat124]

A potential fix for the kind is:

if isinstance(sym.datatype.precision, DataSymbol):
    orig_sym = original_symtab.lookup(sym.datatype.precision.name)
    kind_sym = orig_sym.copy()
    if symbol_table.lookup(kind_sym.name, otherwise=None) is None:
        symbol_table.add(kind_sym)

in the _create_read_in_code function. I'm not sure this fixes all cases (obviously I've not checked this in any detail, and if the kind was in a module I have no idea what it does), but these changes combined means I can just create drivers and (at least the ones I try) compile and run them with no manual code changes.

[sergisiso]

@hiker has been working on this and he is best placed to give an opinions, specially because he may have braches not merged doing these steps: #2057, #2058 (for instance the stats table now - merged this week - should be slightly different)

Speaking from memory, we agreed that want to collapse the 3 DriverCreation classes into one, as there is a lot of duplication for historical reasons that are not necessary anymore. In theory dependent symbols like wp should be dealt with automatically, since we put into the extraction driver all modules that are necessary, searching for the symbol declaration (but before collapsing the classes I don't know if this is done in the one you used). The domain-specific part is mostly in the flattening method, as we need to provide the datatype of each flattened component as we don't have have access to some infrastructure declaration. I also wanted to take the flattening out of extraction, it is an operation that can be useful elsewhere.