Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#2711 DoF Kernel Code Generation #2712

Open
wants to merge 39 commits into
base: master
Choose a base branch
from
Open

Conversation

oakleybrunt
Copy link
Collaborator

@oakleybrunt oakleybrunt commented Sep 16, 2024

Closes #2711 which has a checklist of actions taken

Copy link

codecov bot commented Sep 16, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.86%. Comparing base (e615b2b) to head (70150d3).

Additional details and impacted files
@@           Coverage Diff           @@
##           master    #2712   +/-   ##
=======================================
  Coverage   99.86%   99.86%           
=======================================
  Files         354      354           
  Lines       48910    48933   +23     
=======================================
+ Hits        48846    48869   +23     
  Misses         64       64           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@oakleybrunt oakleybrunt self-assigned this Sep 19, 2024
@oakleybrunt oakleybrunt added ready for review LFRic Issue relates to the LFRic domain labels Sep 19, 2024
Copy link
Member

@arporter arporter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A good first step @oakleybrunt, thank you. You'll see that I think we can do away with the new property you've added and thus shorten the code and tests somewhat.

In reading the Developer Guide, I also discovered that it needs updating - please see https://psyclone-dev.readthedocs.io/en/latest/APIs.html#loop-iterators and update it slightly.

I'll launch the integration tests next time round but I don't anticipate any issues.

can be provided to the Kernel within a loop over the DoFs of a field.
6) Kernels must be written to operate on a single DoF, such that field values
at the same dof location/index can be provided to the Kernel within a loop
over the DoFs of given fields.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not yours but "...over the DoFs of the function space of the field that is being updated."

@@ -1897,8 +1892,7 @@ and their interpretation are summarised in the following table:
operates_on Data passed for each field/operator argument
=========== =========================================================
cell_column Single column of cells
dof Single DoF (currently :ref:`built-ins` only, but see PSyclone
issue #1351)
dof Single DoF (also used for :ref:`built-ins`)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you can drop the bit in brackets. You also need to update the sentence at L1887 - possibly by just removing it entirely.

this argument is simply ``undf`` without a function space suffix (as for
general purpose kernels) since all fields will be on the same function
space.
this argument is ``"undf_"<field_function_space>``.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this should be changed - since we iterate over dofs in a function space, all arguments must be on the same function space still?

# If dof kernel, add access to the field by dof ref
dof_sym = self._symtab.find_or_create_integer_symbol(
"df", tag="dof_loop_idx")
dof_sym = Reference(dof_sym)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This changes the type of dof_sym so that it is no longer a Symbol. I'd do away with this line and simply put [Reference(dof_sym)] directly in the argument list for append_array_reference.

@@ -620,6 +629,10 @@ def fs_compulsory_field(self, function_space, var_accesses=None):
sym = self.append_array_reference(map_name, [":", ":"],
ScalarType.Intrinsic.INTEGER)
self.append(sym.name, var_accesses, var_access_name=sym.name)
elif self._kern.is_dofkern:
# Dofmaps are not compatible with user-defined DoF kernels, so
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Dof-maps are not required for DoF kernels."

assert expected in code


def test_upper_bound_dofowned():
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hopefully you can merge this test with the previous one by using the dist_mem fixture.

expected = ("CALL testkern_dofs_code("
"f1_data(df), f2_data(df), f3_data(df), f4_data(df)")

assert expected in code
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please could you add a compilation check (https://psyclone-dev.readthedocs.io/en/latest/working_practises.html#compilation-testing) here as well. (Do a grep -ri compile in the tests directory to see examples.)

code = str(psy.gen)

expected = ("CALL testkern_dofs_code("
"f1_data(df), f2_data(df), f3_data(df), f4_data(df)")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For robustness, please could you extend the test kernel so that it takes a read-only scalar argument as well.

"['cell_column'] but found 'domain' in kernel "
"'testkern_dofs_code'." in str(excinfo.value))
"['cell_column', 'dof'] but found 'domain' in kernel "
"'testkern_domain_code'." in str(excinfo.value))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you are expecting this to work now, please could you add an explicit test for stub generation of a kernel which operates on dofs. If it isn't supported then that's fine but please reinstate this check and the appropriate bit of code.

" loop0_stop = f1_proxy%vspace%get_last_dof_owned()")

assert expected in code

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we also need to test the behaviour when 'annexed dofs' is switched on too. Again, there's an annexed fixture for this. See https://psyclone-dev.readthedocs.io/en/latest/APIs.html#dof-iterators for more details.

@oakleybrunt
Copy link
Collaborator Author

@arporter Can you have a look at the failing build test please? It is repeatedly tripping over on "Run examples" complaining about ACCEnterData not being able to find any data to copyin. I haven't touched any examples so don't think this is related to my changes... but I'd like your assessment, please.


self.psyir_append(Reference(sym))
if self._kern.iterates_over == "dof":
# If dof kernel, add access to the field by dof ref
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @oakleybrunt, I think your problem is here. If you look at the failing example it's because it's failing to get any fields to upload to the GPU. I think this is because your modification here (which admittedly I've reviewed once) is only listing the dof loop symbol, not the field. This method should probably just revert to what it was originally.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should therefore have a new test for this method too.

@oakleybrunt
Copy link
Collaborator Author

@arporter Did I hear right this morning that it I should ignore stub generation for now?

@arporter
Copy link
Member

arporter commented Oct 7, 2024

@arporter Did I hear right this morning that it I should ignore stub generation for now?

Yep, you should just make sure that you have a test that we refuse to generate a stub for such a kernel.

@oakleybrunt
Copy link
Collaborator Author

@arporter, I can't get Codecov to recognize that I am checking the "uncovered" line (see in src/psyclone/tests/domain/lfric/dofkern_test.py::test_function_space_bare_undf). I'm stuck and asking for some help please.

@arporter
Copy link
Member

arporter commented Oct 9, 2024

@arporter, I can't get Codecov to recognize that I am checking the "uncovered" line (see in src/psyclone/tests/domain/lfric/dofkern_test.py::test_function_space_bare_undf). I'm stuck and asking for some help please.

Unfortunately, you're a victim of the fact that DynFunctionSpaces is an old bit of the code and we don't have any unit tests for it directly. I think what you need to do is create a new test: use one of your new test examples and use get_invoke() to get hold of the invoke containing the dof kernel. You can then walk the Schedule to find the kernel. That will give you a valid kernel object which you can then give to the DynFunctionSpaces constructor.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
LFRic Issue relates to the LFRic domain ready for review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

DoF kern code generation checklist
2 participants