Skip to content

(Towards #2905) mv lfric symbol creation - #3499

Open
arporter wants to merge 15 commits into
masterfrom
2905_mv_lfric_symbol_creation
Open

(Towards #2905) mv lfric symbol creation#3499
arporter wants to merge 15 commits into
masterfrom
2905_mv_lfric_symbol_creation

Conversation

@arporter

@arporter arporter commented Jul 20, 2026

Copy link
Copy Markdown
Member

Move the Symbol creation into the LFRicInvoke constructor. This then affects some tests that were having to pre-populate a table.

@arporter
arporter marked this pull request as draft July 20, 2026 10:29
@arporter arporter self-assigned this Jul 20, 2026
@codecov

codecov Bot commented Jul 20, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.99%. Comparing base (cd6df42) to head (f8bcff1).

❌ Your project check has failed because you have indirect coverage changes. Learn more about Unexpected Coverage Changes and reasons for indirect coverage changes.

Additional details and impacted files
@@             Coverage Diff             @@
##            master    #3499      +/-   ##
===========================================
- Coverage   100.00%   99.99%   -0.01%     
===========================================
  Files          397      397              
  Lines        55587    55569      -18     
===========================================
- Hits         55587    55568      -19     
- Misses           0        1       +1     

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

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@arporter arporter added in progress LFRic Issue relates to the LFRic domain labels Jul 20, 2026
@arporter
arporter marked this pull request as ready for review July 22, 2026 12:12
@arporter

Copy link
Copy Markdown
Member Author

A relatively simple PR that modernises some of the PSy-layer generation.
The LFRic ITs have passed.
One for @sergisiso @LonelyCat124 or @hiker :-)

@LonelyCat124 LonelyCat124 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Hi @arporter I think I mostly understand this, have a couple of questions and a couple of small fixes requested, and one I'm not 100% on so I'd like to rerun ITs again after just in case.

) -> None:
'''
Add compulsory arguments associated with this function space to
the list. If supplied it also stores this access in var_accesses.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Suggested change
the list. If supplied it also stores this access in var_accesses.
this argument list. If supplied it also stores this access in var_accesses.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Done.

Comment thread src/psyclone/domain/lfric/kern_call_arg_list.py
Comment thread src/psyclone/domain/lfric/kern_call_arg_list.py
f"integer(kind=i_def), pointer :: {dmap}(:,:) "
f"=> null()"))
self.symtab.add(dmap_sym, tag=dmap)
intrinsic_type = LFRicTypes("LFRicIntegerScalarDataType")()

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Certainly not one for this PR, but LFRicTypes being dependent on strings feels a bit messy somehow though I think it would require some significant rewriting and object-orientation to do much to.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Yes, LFRicTypes is a bit of an issue (e.g. #2659).

intrinsic_type,
[ArrayType.Extent.DEFERRED, ArrayType.Extent.DEFERRED]))
dmap_sym = self.symtab.find_or_create_tag(
dmap, symbol_type=DataSymbol, datatype=dtype)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Small thing - if we process code like this through the Frontend:

program x
  integer, pointer, dimension(:, :) :: a => null()


end program x

then the symbol we come across has an initial value set:

  a: DataSymbol<UnsupportedFortranType('INTEGER, POINTER, DIMENSION(:, :) :: a => null()'), Unknown, initial_value=IntrinsicCall[name='NULL']>

Could you add the initial value into this find_or_create_tag to match? If this causes issues though then we probably don't have to.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I started doing this (initial_value = IntrinsicCall.create(Intrinsic.NULL)) but then realised that will create a standard assignment rather than a pointer assignment (#2577). Therefore, I don't think we can do it currently but I'll add a TODO. I've also added partial_datatype to the other sorts of dofmap that this method creates since I'm here.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

See comment on Teams, I'd still like this to happen

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Done now - no issues so far.

self.reference_element_properties,
self.mesh_properties, self.loop_bounds,
self.run_time_checks]:
entities.invoke_declarations()

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I assume all LFRicCollections need to have their own implementation of invoke_declarations? Can you test making the one define in the LFRicCollections base class abstractmethod to ensure we can't miss it in subclasses?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

They do but the base one is not empty - it contains a check that the LFRicInvoke has been setup correctly.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Yeah, thats not an issue, you can still call super().func() up to an abstractmethod, see this example:

import abc

class base:

    @abc.abstractmethod
    def func(self):
        print("Hello from base")


class sub(base):
    def func(self):
        print("Hello from sub")
        super().func()

sub().func()

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Aha! Done now.

self,
loop: Loop,
test_all_variables: bool = False,
signatures_to_ignore: Optional[Signature] = None) -> bool:

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I did a bit of looking at this, and its another thing we'll need to update post-3.9, Optional is a bit of a misnomer, which means "can be None" and not "optional". As of 3.10 we should use Signature | None for typehints like this, I added a comment to #3416

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Thanks.

parallelised.
:param test_all_variables: if True, it will test if all variable
accesses can be parallelised, otherwise it will stop after the
first variable is found that can not be parallelised.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Can this docstirng be rewritten slightly to remove the need to specify "if True" - since its a bool I think we can do something like "whether to continue to test if all variable accesses can be parallelised once a variable has been found that can not be parallelised"?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Yes, done.

Comment thread src/psyclone/tests/core/variables_access_map_test.py
@arporter

Copy link
Copy Markdown
Member Author

Thanks @LonelyCat124, ready for another look now (CI permitting).

@LonelyCat124 LonelyCat124 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I've left a couple of things still to be resolved from last time as I think they are both possible and would improve the code.

Comment thread src/psyclone/domain/lfric/kern_call_arg_list.py
intrinsic_type,
[ArrayType.Extent.DEFERRED, ArrayType.Extent.DEFERRED]))
dmap_sym = self.symtab.find_or_create_tag(
dmap, symbol_type=DataSymbol, datatype=dtype)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

See comment on Teams, I'd still like this to happen

self.reference_element_properties,
self.mesh_properties, self.loop_bounds,
self.run_time_checks]:
entities.invoke_declarations()

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Yeah, thats not an issue, you can still call super().func() up to an abstractmethod, see this example:

import abc

class base:

    @abc.abstractmethod
    def func(self):
        print("Hello from base")


class sub(base):
    def func(self):
        print("Hello from sub")
        super().func()

sub().func()

@arporter

arporter commented Aug 6, 2026

Copy link
Copy Markdown
Member Author

Took me a while to get back to this but should be ready for another look now.

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.

2 participants