Bug or not? capgen's metadata parser assigns kind_phys to real variables without a kind definition

[climbfuji]

Description

Is this a bug or not? I have the following metadata, and I believe kind is optional for real variables. The capgen metadata parser however assigns kind_phys to the variable:

[data_array]
  standard_name = data_array_all_species
  long_name = data array in module
  units = m
  dimensions = (horizontal_loop_extent, number_of_species)
  type = real

Then:

for new_var in metadata_section.variable_list():
                standard_name = new_var.get_prop_value('standard_name')
                print(standard_name, new_var.get_prop_value('kind'))

==>

...
ccpp_t_instance ccpp_t
horizontal_loop_extent
number_of_species
data_array_all_species kind_phys
data_array kind_phys
...

Steps to Reproduce

See above

Additional Context

n/a

Output

See above

[gold2718]

It's not a bug in the sense that it was intentional. real with no kind is processor dependent in the Fortran specification. Do we want to support that? How much cleanup will that entail (all the places where no kind was entered but kind_phys is desired)?

[climbfuji]

Glad I asked! I am ok with the current behavior, hopefully we have this documented somewhere in CCPP tech doc

[climbfuji]

Is this just for real or also for complex?

[climbfuji]

Asking because capgen's metadata parser leaves kind alone for integers (i.e. doesn't assign any if not provided in the metadata).

[gold2718]

Glad I asked! I am ok with the current behavior, hopefully we have this documented somewhere in CCPP tech doc

Uh, no, not i you are talking about https://ccpp-techdoc.readthedocs.io/en/v4.0/CompliantPhysicsParams.html#metadata-rules

[gold2718]

Is this just for real or also for complex?

Also complex. See default_kind_val in var_props.py for the complete behavior.

[climbfuji]

See https://github.com/NCAR/ccpp-doc/pull/74 please