Allow declaration of a scheme-dependent kind by gold2718 · Pull Request #719 · NCAR/ccpp-framework

gold2718 · 2026-02-04T20:09:00Z

kind declaration now available in a metadata_table header.
Add test to the capgen system test (test/capgen_test)

There are two ways to use the new keyword:
kind_spec = temp_kinds:kind_temp=>temp_r8
Results in an entry in ccpp_kinds.F90:
use temp_kinds, only: kind_temp => temp_r8

kind_spec = temp_kinds:temp_r8
Results in an entry in ccpp_kinds.F90:
use temp_kinds, only: temp_r8

In both cases, the Fortran module file (temp_kinds.F90) SHOULD be added as a dependency in the
same metadata table header.

User interface changes?: Yes
A new metadata keyword

Fixes: #712

Testing:
unit tests: all PASS
system tests: all PASS

kind declaration now available in a metadata_table header. Add test to the capgen system test (test/capgen_test)

gold2718 · 2026-02-04T20:10:02Z

This PR is an alternative to #713

gold2718 · 2026-02-04T20:23:38Z

I'm not in love with the syntax I am using in the kind_spec keyword. Because kind_spec = temp_r8:temp_kinds:kind_temp and kind_spec = temp_r8:temp_kinds are allowed, and because all the RHS terms have to be pretty much any Fortran name, I do not have a good way to check what is a good set and what is not (until ccpp_kinds.F90 fails to compile).

How do folks feel about this? I thought about at least distinguishing the module name with different syntax which would make it easier to check. Something like:

kind_spec = temp_r8:kind_temp@temp_kinds

or

kind_spec = temp_r8@temp_kinds

Thoughts?

gold2718

A comment and a few changes based on test output warnings.

gold2718 · 2026-02-04T20:24:38Z

scripts/parse_tools/fortran_conditional.py

                                   '.true.', '.false.', '.lt.', '.le.', '.eq.', '.ge.', '.gt.', '.ne.',
                                   '.not.', '.and.', '.or.', '.xor.']
-FORTRAN_CONDITIONAL_REGEX = re.compile(r"[\w']+|" + "|".join([word.replace('(','\(').replace(')', '\)') for word in FORTRAN_CONDITIONAL_REGEX_WORDS]))
+FORTRAN_CONDITIONAL_REGEX = re.compile(r"[\w']+|" + "|".join([word.replace('(',r'\(').replace(')', r'\)') for word in FORTRAN_CONDITIONAL_REGEX_WORDS]))


Changed due to warnings in the test output.

gold2718 · 2026-02-04T20:24:46Z

scripts/parse_tools/parse_checkers.py


 _UNITLESS_REGEX                = "1"
-_NON_LEADING_ZERO_NUM          = "[1-9]\d*"
+_NON_LEADING_ZERO_NUM          = r"[1-9]\d*"


Changed due to warnings in the test output.

gold2718 · 2026-02-04T20:24:55Z

scripts/parse_tools/parse_checkers.py

 _UNIT_EXPONENT                 = f"({_NEGATIVE_NON_LEADING_ZERO_NUM}|{_POSITIVE_NON_LEADING_ZERO_NUM}|{_NON_LEADING_ZERO_NUM})"
 _UNIT_REGEX                    = f"[a-zA-Z]+{_UNIT_EXPONENT}?"
-_UNITS_REGEX                   = f"^({_CHAR_WITH_UNDERSCORE}|{_UNIT_REGEX}(\s{_UNIT_REGEX})*|{_UNITLESS_REGEX})$"
+_UNITS_REGEX                   = rf"^({_CHAR_WITH_UNDERSCORE}|{_UNIT_REGEX}(\s{_UNIT_REGEX})*|{_UNITLESS_REGEX})$"


Changed due to warnings in the test output.

gold2718 · 2026-02-04T20:26:20Z

scripts/ccpp_capgen.py

+        msg = f'Writing {KINDS_FILENAME} to {output_dir}'
+        run_env.logger.info(msg)


This was a change that @nusbaume made. I never saw a response as to why this is a good change. Should I set it back?

Sorry, I was assuming it would be reverted so I didn't comment on it in the previous PR, but this change was leftover from some debugging I was doing, and I just missed it when cleaning up afterwards (I have been training my brain to default to f-strings so this happens more than I care to admit).

So I am personally happy if this gets reverted. Thanks for checking though!

gold2718 · 2026-02-04T20:28:41Z

scripts/framework_env.py

 e.g., --kind-type "kind_phys=REAL64"
 Enter more than one --kind-type entry to define multiple CCPP kinds.
-<kind_val> SHOULD be a valid ISO_FORTRAN_ENV type""")
+<kind_val> MUST be a valid ISO_FORTRAN_ENV type""")


This rule only applies on the command line.

climbfuji

My immediate thought is that the kind_spec syntax would be more intuitive if it followed the Fortran syntax. For example:

use temp_kinds, only: kind_temp => temp_r8

could be

kind_spec = temp_kinds:kind_temp=>temp_r8

and

use temp_kinds, only: temp_r8

could be

kind_spec = temp_kinds:temp_r8

scripts/var_props.py

climbfuji · 2026-02-05T16:40:04Z

scripts/var_props.py

                                                      'suites':''}, \
                                               kind_types=["kind_phys=REAL64", \
-                                                           "kind_dyn=REAL32", \
+                                                           "kind_dyn=REAL32",  \


Suggested change

"kind_dyn=REAL32", \

"kind_dyn=REAL32", \

scripts/var_props.py

climbfuji · 2026-02-05T16:40:27Z

scripts/var_props.py

                                              'suites':''}, \
                                       kind_types=["kind_phys=REAL64", \
-                                                   "kind_dyn=REAL32", \
+                                                   "kind_dyn=REAL32",  \


Suggested change

"kind_dyn=REAL32", \

"kind_dyn=REAL32", \

cacraigucar · 2026-02-05T21:44:28Z

My immediate thought is that the kind_spec syntax would be more intuitive if it followed the Fortran syntax. For example:
use temp_kinds, only: kind_temp => temp_r8
could be
kind_spec = temp_kinds:kind_temp=>temp_r8
and
use temp_kinds, only: temp_r8
could be
kind_spec = temp_kinds:temp_r8

I agree with this proposal. The original format is really hard to get correct.

cacraigucar · 2026-02-05T22:56:20Z

@gold2718 - I brought your branch into my code which needs this fix and it works great. So from a proof-of-concept review, I give my approval. I'll let someone else on my team do the official "code review" review.

@climbfuji

- Modified the syntax for new-kind declaration as suggested by @climbfuji - Reverted string formatting for log message

gold2718 · 2026-02-06T15:14:01Z

My immediate thought is that the kind_spec syntax would be more intuitive if it followed the Fortran syntax. For example:
use temp_kinds, only: kind_temp => temp_r8
could be
kind_spec = temp_kinds:kind_temp=>temp_r8
and
use temp_kinds, only: temp_r8
could be
kind_spec = temp_kinds:temp_r8

Well, it's 3-0 so I went ahead and implemented this change. Thanks for the suggestion!

Co-authored-by: Dom Heinzeller <dom.heinzeller@icloud.com>

peverwhee

thanks @gold2718 !

cacraigucar · 2026-02-09T20:04:01Z

My immediate thought is that the kind_spec syntax would be more intuitive if it followed the Fortran syntax. For example:
use temp_kinds, only: kind_temp => temp_r8
could be
kind_spec = temp_kinds:kind_temp=>temp_r8
and
use temp_kinds, only: temp_r8
could be
kind_spec = temp_kinds:temp_r8
Well, it's 3-0 so I went ahead and implemented this change. Thanks for the suggestion!

@gold2718 - Could you edit the description at the top of this PR to reflect this new syntax (so when we refer back to it we get the correct way to implement it)? Thanks!

peverwhee · 2026-02-11T20:14:53Z

@dustinswales can you review this when you get time?

dustinswales

Sorry for the late review!

Allow declaration of a scheme-dependent kind

ec14e85

kind declaration now available in a metadata_table header. Add test to the capgen system test (test/capgen_test)

gold2718 requested review from climbfuji, dustinswales, nusbaume and peverwhee February 4, 2026 20:09

gold2718 self-assigned this Feb 4, 2026

gold2718 requested review from a team as code owners February 4, 2026 20:09

gold2718 added the enhancement label Feb 4, 2026

gold2718 mentioned this pull request Feb 4, 2026

Add capability to add new kind definitions to capgen #713

Closed

gold2718 commented Feb 4, 2026

View reviewed changes

climbfuji reviewed Feb 5, 2026

View reviewed changes

Modify syntax for declaring new kind

4d8b04d

- Modified the syntax for new-kind declaration as suggested by @climbfuji - Reverted string formatting for log message

climbfuji approved these changes Feb 6, 2026

View reviewed changes

gold2718 and others added 2 commits February 6, 2026 17:51

Apply suggestion from @climbfuji

26fa655

Co-authored-by: Dom Heinzeller <dom.heinzeller@icloud.com>

Apply suggestion from @climbfuji

b465661

Co-authored-by: Dom Heinzeller <dom.heinzeller@icloud.com>

peverwhee approved these changes Feb 7, 2026

View reviewed changes

dustinswales approved these changes Feb 18, 2026

View reviewed changes

nusbaume removed their request for review February 18, 2026 20:43

mkavulich merged commit 9d87be6 into NCAR:develop Feb 18, 2026
14 checks passed

		msg = f'Writing {KINDS_FILENAME} to {output_dir}'
		run_env.logger.info(msg)

Comments

Conversation

gold2718 commented Feb 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gold2718 commented Feb 4, 2026

Uh oh!

gold2718 commented Feb 4, 2026

Uh oh!

gold2718 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

climbfuji left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cacraigucar commented Feb 5, 2026

Uh oh!

cacraigucar commented Feb 5, 2026

Uh oh!

gold2718 commented Feb 6, 2026

Uh oh!

peverwhee left a comment

Choose a reason for hiding this comment

Uh oh!

cacraigucar commented Feb 9, 2026

Uh oh!

peverwhee commented Feb 11, 2026

Uh oh!

dustinswales left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

gold2718 commented Feb 4, 2026 •

edited

Loading