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

#1312: metadata for read-only arrays #2173

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

Conversation

mo-lottieturner
Copy link
Collaborator

@mo-lottieturner mo-lottieturner commented Jun 12, 2023

.

@codecov
Copy link

codecov bot commented Jun 19, 2023

Codecov Report

Attention: 4 lines in your changes are missing coverage. Please review.

Comparison is base (b393e04) 0.00% compared to head (fe4baf9) 99.84%.

Files Patch % Lines
...psyclone/domain/lfric/kernel/array_arg_metadata.py 94.00% 3 Missing ⚠️
...ne/domain/lfric/kernel/common_meta_arg_metadata.py 92.30% 1 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff             @@
##           master    #2173       +/-   ##
===========================================
+ Coverage        0   99.84%   +99.84%     
===========================================
  Files           0      353      +353     
  Lines           0    47511    +47511     
===========================================
+ Hits            0    47438    +47438     
- Misses          0       73       +73     

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

@mo-lottieturner
Copy link
Collaborator Author

(all tests pass except codecov)

@mo-lottieturner
Copy link
Collaborator Author

I think I've removed all of the NRANKS mentions, back to @arporter for review

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.

Thanks for those changes @mo-lottieturner. The docs are looking pretty good now although I realise that the section describing the detailed rules for the subroutine arguments of a kernel also need to be updated.
I've now gone through the code changes but not the test files. Generally speaking it looks good although you'll see that I'm suggesting (another?) name change for clarity as I keep getting confused about distinguishing an 'array' from a 'field'. We'll need to agree any name change with at least @TeranIvy and whoever else she thinks might care!

operator <lfric-cma-operator>`. All of them except the field vector are
represented in the above example. ``qr`` represents a quadrature object which
provides information required by a kernel to operate on fields (see section
:ref:`dynamo0.3-quadrature` for more details).
Copy link
Member

Choose a reason for hiding this comment

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

Sphinx complains about this link:

user_guide/dynamo0p3.rst:116: WARNING: undefined label: 'dynamo0.3-quadrature'

Copy link
Member

Choose a reason for hiding this comment

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

Probably you're just a victim of renaming that's happened since you did this change and it just needs to be reverted back to lfric-quadrature?

Array
+++++

In the LFRic API a scalar array represents a multi-valued Fortran array of
Copy link
Member

Choose a reason for hiding this comment

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

It may yet become clear to me (or I might remember) but what is a "multi-valued Fortran array"? Do you mean "multi-dimensional" or perhaps something else?

fourth is an operator. The third entry is a field vector of size 3.
As an example, the following ``meta_args`` metadata describes 5
entries, the first is a scalar, the second is an array, the next two
are fields and the fifth is an operator. The third entry is a field vector
Copy link
Member

Choose a reason for hiding this comment

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

"...fourth entry is a field..."

@@ -1193,16 +1210,17 @@ For example::
does not yet support ``integer`` and ``logical`` reductions.

For a scalar, the argument metadata contains only these three entries.
However, fields and operators require further entries specifying
However, arrays, fields and operators require further entries specifying
Copy link
Member

Choose a reason for hiding this comment

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

I'm guessing that the extra info for an array is unrelated to function space? If so I would delete the remainder of the sentence after "...require further entries."

subsection :ref:`lfric-function-space`.
In the case of an operator, the fourth and fifth arguments describe the ``to``
and ``from`` function spaces respectively. In the case of a field the fourth
argument specifies the function space that the field lives on. In the case of
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 move the sentence about array to the start of this paragraph so as to preserve the function-space related flow into the last sentence.

@@ -658,7 +761,7 @@ def function_space(self):
depending on the argument type: a single function space for a field,
function_space_from for an operator and nothing for a scalar.

:returns: function space relating to this kernel argument or \
:returns: function space relating to this kernel argument or
None (for a scalar).
Copy link
Member

Choose a reason for hiding this comment

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

"scalar or ScalarArray)."

@@ -695,6 +800,8 @@ def function_spaces(self):
if self._argument_type in const.VALID_OPERATOR_NAMES:
# Return to before from to maintain expected ordering
return [self.function_space_to, self.function_space_from]
if self._argument_type in const.VALID_ARRAY_NAMES:
return [self.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.

Should be empty list. Alternatively, could merge this and the next clause like so:

if self._argument_type in const.VALID_ARRAY_NAMES + const.VALID_SCALAR_NAMES:
    return []

(and ditto for the previous one too)

@property
def array_ndims(self):
'''
Returns the array size of the argument. This will be 1 if ``*n``
Copy link
Member

Choose a reason for hiding this comment

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

s/size/rank/

Copy link
Member

Choose a reason for hiding this comment

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

Oh, I see where the "default value of 1" comes from now. Do we need this method to support arguments of type other than ArrayScalar though?

has not been specified for all argument types except scalars
(their array size is set to 0).

:returns: array size of the argument.
Copy link
Member

Choose a reason for hiding this comment

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

s/size/rank/

@@ -153,6 +158,11 @@ def __init__(self):
LFRicConstants.VALID_FIELD_INTRINSIC_TYPES = ["real", "integer",
"logical"]

# Valid intrinsic types for array kernel argument data
# ('real', 'integer', and 'logical').
Copy link
Member

Choose a reason for hiding this comment

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

You don't need this line :-)

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

Successfully merging this pull request may close these issues.

4 participants