arporter / nemo-dsl Goto Github PK

We need to add metadata to the Kernels. This will be based on the gocean1.0 api metadata. However this metadata was designed for 2D fields so will need to be extended to support both 2D and 3D.

In order for a code to make use of a DSL, it must make use of the infrastructure associated with the implementation of the DSL. In this issue we will start to change the code to use the infrastructure provided by https://github.com/stfc/dl_esm_inf (previously developed for 2D models in the GOcean project).

To show what the algorithm code would look like, we should add a commented-out invoke call.
At the moment we are calling the manual PSy from the algorithm layer separately for each kernel. However, after transforming from an algorithm description using PSyclone we would end up with a single call into the psy layer. Therefore we should modify the code to do this.

Silvia has committed the 'original' version of the tracer benchmark. In this issue we will add timing to this code using the dl_timer library.

We need to see what an OpenACC version would look like using the step-1 approach.

Make the step-1 version of the code OpenMP parallel.

I think we agreed that Rupert would do this. On the other hand, I can do it if required. Once this is done it will help with extending the GOcean infrastructure to 3D (stfc/dl_esm_inf#1) as I'll have an example to work from.

Andy and I have discussed ways in which we might migrate from existing NEMO code to something that is (arguably) more maintainable and supports OpenMP and OpenACC in a way that does not disturb the code too much and therefore has a chance of being adopted on the trunk. We need to discuss this further with Silvia but have not yet had the chance.

We think a good (first and possibly even final!) step would be to place all loops (and computation within them) in subroutines and to add appropriate descriptive metadata within these subroutines. This would separate the description of the algorithm from the loop bounds and array accesses allowing us to generate OpenMP and OpenACC solutions by modifying the subroutines (using a modified version of PSyclone) independently of the algorithm code. Note the generation idea needs to be proven as PSyclone does not currently support code in this form.

We would like to use this benchmark as a test case to prove the feasibility of this approach.

In #3, separate kernels were created for each loop in the original code. A few issues have arisen before the psykal version can be taken any further.

1. Are we OK to move the zdt and zbtr scalars out of the algorithm later and into the associated Kernels? We can clearly do this as they are only scalars but Silvia had them at a higher level in the loops for some reason so I would like her thoughts first.

2. Are we working towards a version that PSyclone can generate? The alternative is to explore ways in writing the psykal code that might be more amenable to the NEMO consortium? I lean to the former as it would be nice to be able to demonstrate something (at some point).

3. I've introduced two builtins which set layer values. In order to do this they must pass the actual value of the layer. What I suggest is that we have a zero_top_layer() and a zero_bottom_layer() (and similarly for multiply) as these would be descriptive, explanatory and would remove the need for passing the layer value, which we need to move away from.

4. We should remove the passing of jpk, jpk and jpi into the PSy layer from the algorithm layer as the algorithm layer is meant to work on whole fields and it also simplified the code. To do this in the short term I was going to set the values in the PSy layer directly from the algorithm layer. Are you OK with this, or is there a better way.

5. Are people happy that I'm only looking at code with the iteration at the moment. I'm not sure how this will work if we decide to change to field objects but we can cross that bridge later.

6. We already have an interesting issue emerging with the vertical dimension. The setting of top and bottom values means that we sometimes do not compute at the bottom layer and/or the top layer. I don't think this is anything to do with the Kernel code so I presume we will have to find a way to describe this at the algorithm layer!

7. The zwx2_kern kernel code writes with a k+1 index. In PSylone we made a choice to always write to I,j,k to help us work out the correct loop bounds. Is there a problem in changing the code to conform to this choice?

OK, that's enough for the moment. Agreement on these questions will drive the next set of modifications to the psykal version.