New implementation of differing module name#646
Conversation
climbfuji
left a comment
There was a problem hiding this comment.
Apologies if I am not seeing it, but where in the updated tests is the new functionality (scheme name different from file name) tested? I see it for the DDT module name (not equal to file name), though.
Good catch! I started with the test mods from #637, however, I just added one (and fixed an error message that I found in the process). |
climbfuji
left a comment
There was a problem hiding this comment.
I am withdrawing my approval for the moment solely based on the conversation in #637 (comment)
climbfuji
left a comment
There was a problem hiding this comment.
@dustinswales, the other CCPP framework developers, and I discussed that we should fix the CCPP physics so that no host model DDTs need to be passed to the physics instead of updating capgen. I did this in ufs-community/ufs-weather-model#2651 and PRs linked in the description. Therefore, I don't see any problems with this PR.
|
I uploaded a change that allows schemes to use host model DDTs but I now have a conflict in the var_compatibility test that I have to resolve. |
c864640 to
f4e57b1
Compare
|
@climbfuji @peverwhee @mkavulich |
## Summary Allow for sub components of a DDT to be passed into the Group caps from the Host cap . ## Description This PR adds recursive searching for DDTs when creating the call strings to the Group caps. This preserves the full reference in the call string. Snippet from `test_host_ccpp_cap.F90` before the change to ddt_library.py: `sfc_up_sw=phys_state%sfc_up_sw(col_start:col_end)` After, with full reference in call string: `sfc_up_sw=phys_state%fluxSW%sfc_up_sw(col_start:col_end)` User interface changes?: No Fixes: #639 This is built on #646 Testing: New testing added to pass subfields of DDT into scheme. --------- Co-authored-by: Steve Goldhaber <stevenng@met.no> Co-authored-by: Dom Heinzeller <dom.heinzeller@icloud.com>
New implementation of differing module name
Implement a solution that allows a Fortran module name to differ from the filename.
User interface changes?: Yes
An optional
module_namekeyword is added to theccpp-table-properties(MetadataTable) section that allows the user to specify a Fortran module name that is independent from the name of the enclosing file.I feel this PR is a cleaner solution to #636 and should replace #637.
Fixes: #636
Testing:
test removed: NA
unit tests: PASS
system tests: PASS
manual testing: manually ran Fortran and unit tests