Parameters for transformation scripts

[hiker]

During optimisation (including profiling runs), I ended up using three or four different versions of a transformation script (original and with tiling and profile and non_profile). This makes it sometimes hard to keep the scripts in synch.

It would be nice if options could be specified for the transformation scripts. This would allow me to have just one version of the script, and based on the command line add profiling or not (and maybe even add tiling or not).

For now I can use environment variables, but it might be a useful feature to be able to see these options in e.g. build log files.

An alternative approach might be to make transformation scripts call each other (e.g. the profiling script first calls the base script, then applies profiling to the output). But that still makes it hard to then have one profiling-function that will be added to the original and tiled version of the scripts ... unless we have user input.

[sergisiso]

I find using envvars a good solution (as you suggested), see:

PSyclone/examples/lfric/scripts/gpu_offloading.py

Line 61 in 33ff7e8

OFFLOAD_DIRECTIVES = os.getenv('LFRIC_OFFLOAD_DIRECTIVES', "none")

Also because sometimes the build system needs to adapt: link or not profiling flags, use offloading of threading flags, ... and it can read the same envvar.
Do you think we need a different mechanism?

[hiker]

There is one big advantage if the options are 'visible' on the PSyclone command line: Fab computes a hash code based on command line options (etc etc). So, changing an env variable will not change the hash code, and as a user you will have to be aware of this and trigger a clean recompile (admittedly, you might as well have two different build trees?? But if you think of lfric, you might not want to have two completely different build tree just because one file changes).

Very easy to understand would be something like:

psyclone ... -s "my_script(PROFILE=1, TILING=3)"  or so.

We could then pass the arguments as kwargs (or options dictionary? That might make it easier to reuse scripts) to the user-script when calling it (in addition to the tree information). But agreed, no rush.