Welcome to PSyclone Discussions!

[rupertford]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪

[dennissergeev]

I've only recently started learning PSyclone, so this question is probably quite silly, but why do LFRic (Dynamo0.3) API built-ins only operate on DoFs? What if I want to do an operation column-wise?

[rupertford]

Hi Dennis, it is certainly not a silly question. As you probably know, there are coded kernels, that the scientist writes and there are builtin's that PSyclone recognises and adds the required code (so the scientist does not need to write the code). It was decided that it did not make sense for scientists to have to write algebraic operations as kernels so we added support for these as builtins. It so happens that these iterates over dofs. Similarly it so happens that coded kernels are written over columns. I think that PSyclone has checks that enforce this at the moment (but would need to check). However, there is no fundamental reason to limit builtins to iterating over dofs and coded kernels to iterating over columns (it would just require some additional tests and checks in PSyclone). So, to answer your question ... at the moment, if you want to do a columnwise operation you write a kernel to do it.

[arporter]

I expect (but perhaps @TeranIvy can confirm) that it's done this way as it's just a simple way of constructing a representative kernel. In reality one would actually use the setval_X builtin for this task.

[rupertford]

The structure in the example is relatively standard for a coded kernel, even if the computation (zero-ing the values) is not. The k-loop is for each element in a column and the dofs loop is for each dof within the element. So in this case we visit each column, then each element within a column, then each dof within an element. When iterating over dofs we simply go from the first dof to the last, ignoring columns and elements. You can see that the access to dofs is different in this example cf iterating over dofs, as the dofs are accessed through indirection (using the dofmap).

[dennissergeev]

Thanks @arporter!

@rupertford thanks for the clarification too. Presumably, the dofmap is such that the dofs shared between elements are not being overwritten, right?

[rupertford]

No :-). dofs shared between elements will be overwritten in this kernel. As we are writing the same value everywhere, it does not matter in terms of correctness. If you look at the kernel metadata you will see that it specifies GH_INC here, so PSyclone is not expecting the programmer to do this, it is expecting an increment, due to the shared dofs in W0. In fact PSyclone will raise an exception if you put GH_WRITE here. However, we don't currently perform any consistency checks between kernel metadata and kernel implementation so do not notice. Also, notice that in the W3 version, the metadata specifies GH_WRITE as W3 has no shared dofs so PSyclone is happy that fields can be written to (rather than incremented).

[dennissergeev]

Ah I see, many thanks for the explanation!

[dennissergeev]

And another question: what is the significance of using the code pointer in the kernel definition? In some examples it's included, in some not. For example:

PSyclone/tutorial/practicals/LFRic/building_code/1_simple_kernels/part1/setval_field_w0_kernel_mod.f90

Line 66 in 3ec0538

procedure, nopass :: code => setval_field_w0_code

vs

PSyclone/tutorial/practicals/LFRic/building_code/1_simple_kernels/part1/solutions/setval_field_w0_kernel_mod.f90

Line 66 in 3ec0538

procedure, nopass :: setval_field_w0_code

[arporter]

I think the short answer is "none." Looking at https://psyclone.readthedocs.io/en/stable/dynamo0p3.html#procedure there's no mention of the need for code and I suspect it's a hangover from an old way of doing things.