NCAR / NCAR/ccpp-framework

Document --kind-type in ccpp_capgen.py CLI/help, and consider reversing the syntax for external kind modules

Open
#754 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

capgen capgen-unification enhancement
Dominant language
Python
Stars
25
Forks
67
Avg merge
3d 8h
Merged PRs (30d)
2

Description

Description

The --kind-type argument for capgen accepts kind values that are defined in iso_fortran_env, and it also accepts kind_values that are defined in files provided by the user. The latter syntax, however, isn't documented.

The current syntax is, for example

--kind-type kind_phys=kind_r8:my_host_kinds

and

--kind-type kind_phys=real64

for which the code checks `iso_fortran_env.

I am suggesting to reverse the syntax to

--kind-type NAME=[MODULE:]SPEC

to match my suggestion for external ddts in #751 and because it is more intuitive given the corresponding Fortran code:

use my_host_kinds, only: kind_r8

In addition, there is also this metadata attribute that uses MODULE:SPEC in this order:

[ccpp-table-properties]
  name = temp_set
  type = scheme
  source_path = source_dir2
  kind_spec = temp_kinds:kind_temp=>temp_r8
  dependencies = temp_kinds.F90
  dependencies_path = adjust

Not sure whether anyone is using this syntax, though.

Solution

See above

Alternatives (optional)

Don't change the syntax, but update the CLI/capgen help.

Related to (optional)

#751

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in ccpp_capgen.py by locating the --kind-type argument and its CLI/help text, then compare the documented examples with the current external kind-module syntax. Review the related #751 discussion and the kind_spec metadata example before deciding whether to document the existing form or reverse it. Done means the chosen syntax is consistently documented and the help text matches the behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
fortran, python
Domain
cli, documentation
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.