Static build: no cdata to store and retrieve variables #168
Conversation
…d thrd_no to type ccpp_t
…variable as a kind or type definition (as opposed to an instance), add new print statement using intents instead of pointers for static build; modification of Cap class: auto-generate module use information instead of receiving it from hard-coded value in CCPP prebuild config
…eceive all required arguments (parents/DDTs of variables that are members of DDTs, individual variables, indices) via the argument list instead of pulling them out of cdata; modify API to import the required variables from the host model instead of getting them from cdata (this requires to move the ccpp_static_api.F90 compilation into the host model)
…s to subroutine calls for static build w/o using cdata, and for dynamic build without using hard-coded module use statements
climbfuji
requested review from
gold2718,
grantfirl and
llpcarson
as code owners
…onfig to work with new static build version of ccpp_prebuild.py
|
Note: these changes also fix the GNU compiler crash when compiling NEMSfv3gfs with CCPP (introduced by https://github.com/NCAR/NEMSfv3gfs/pull/88 and associated PRs). |
|
Testing: these changes were tested for bit-for-bit identical results for all build options manually on MacOSX/GNU for fv3_control and fv3_gfdlmp, and on Cheyenne/Intel for fv3_gfdlmp. |
|
For a better understanding, here are auto-generated caps for the various groups and the suite (in ccpp/physics/physics), for the GFDLMP suite (I had to add .txt to be able to attach them): ccpp_group_fast_physics_cap.F90.txt This is the auto-generated static API (in FV3/gfsphysics/CCPP_layer) for the same suite (and with .txt at the end): |
|
Reopen, change target to master branch |
Codecov Report
@@ Coverage Diff @@
## master #168 +/- ##
=======================================
Coverage 44.96% 44.96%
=======================================
Files 16 16
Lines 1401 1401
=======================================
Hits 630 630
Misses 771 771
Continue to review full report at Codecov.
|
…no-cdata-for-static-build
|
Update: in order to deal with some of the difficulties around the missing data-laundering functionality in the static/no-cdata version, and to accommodate the bit-for-bit modifications in the next weeks, updates have been pushed to the different PRs that make use of a new NEMSfv3gfs MAKEOPT (TRANSITION=Y, default is N), which also translates into a CPP directive -DTRANSITION. This new MAKEOPT and the CPP directive will allow making selective modifications of the code to achieve bit-for-bit identical results on Theia with Intel 15 in PROD mode. These updates require rerunning all relevant tests, I am thus deleting the above regression test logs. |
|
Output of standard regression test logs (Theia, Intel 18, REPRO mode). All tests pass. rt_ccpp_hybrid.log |
|
Output of CCPP acceptance tests (Theia, Intel 15, PROD mode). The result is the same as before introducing the new static build w/o cdata: The basic fv3_control tests pass, all other tests fail (in particular the GFDL-MP based tests). This means that this PR and related PRs are good to merge. rt_ccpp_ref_for_acceptance_create.log |
|
Thanks Laurie and Steve for approving. The purpose of this PR was to remove the need for using cdata to store variables from the host model in the lookup table "standard_name" -> "location in memory". There are two reasons for making this change, (1) performance and (2) preparation for using capgen in the future. As we have seen at the last meeting, the auto-generated caps of this new no-cdata static build and of capgen are quite similar. Several of the issues addressed in this PR here would have come up in the future when switching over to capgen. Doing it here allows us to split this huge upcoming change into smaller chunks. |
This PR and associated PRs remove the need to store host model variables in the cdata structure and retrieve them in the physics for the static build only.
For this to work, and in the absence of a central host model registry in FV3, the following major changes are required:
Further, these PRs remove several of the hard-coded module use statements, previously defined in ccpp_prebuild_config.py, which required
These PRs are also one step towards removing the IPD legacy. Once the hybrid build is removed, the remaining call to IPD_initialize can be substituted by a direct call of GFS_initialize (or some other method, to be discussed) and IPD_Control etc can be renamed into GFS_Control etc.