Add input variables to FV3_GFS_v16beta_fast_physics_run_cap or other functions

Submitted by Qingfu.Liu on Wed, 12/02/2020 - 10:34
Forum: CCPP User Support | CCPP Framework

Dear Sir/Madam,

     I am working to debug the GFSv16 RRTMGP code, and trying to add more variables (in order to print out) to the auto-generated functions. Not sure how to do it. For example, in the code:

ccpp/physics/ccpp_static_api.F90

         subroutine ccpp_physics_run(cdata, suite_name, group_name, ierr)

                  ierr = FV3_GFS_v16beta_fast_physics_run_cap(CCPP_interstitial=CCPP_interstitial,cdata=cdata)

I hope to add data "GFS_Control" to this function and make it like this:

                 ierr = FV3_GFS_v16beta_fast_physics_run_cap(CCPP_interstitial=CCPP_interstitial,cdata=cdata,GFS_Control=GFS_Control)

Where should I change (which script or code) in order to have the new autogenerated code? Thanks you very much.

Qingfu

Permalink

Submitted by dom.heinzeller on Fri, 12/04/2020 - 10:35

Hi Qingfu,

in order to get variables passed to the autogenerated functions, at least one scheme called in those functions must request the variable (or a constituent of a DDT). If you wanted to add GFS_control to an autogenerated function, then something in that function will have to require it (for example, some physics scheme underneath needs to look for Model%kdt). You can of course manually add GFS_control to that list and bypass the code generation.

But:

- I strongly recommend to not modify the autogenerated code. You can call debugging schemes in the SDF as per our CCPP technical documentation that print the data you are interested in (but see below).

- Your particular example will not work, regardless which way you take. Recall that the fast physics are called form the dycore. The dycore does not know about the GFS data types. This is in my opinion a poor design of the FV3 model (fv3atm) that dates back to the IPD implementation. dycore and physics are not sharing variables.

- A consequence of this second bullet is that you cannot use the debugging routines described in the technical documentation for the fast_physics group.

 

Permalink

Submitted by Qingfu.Liu on Fri, 12/04/2020 - 12:50

Dom,

    Thank you very much for your suggestions and commends. I did add the debug subroutine call, but could not figure out why the subroutine (GFS_debug_rrtmgp2_run) runs twice by the same processor. I looked the cap file and there is only one call (I have printouts before and after this call, there are two printout by the same processor before the next printout). The first run GFS_debug_rrtmgp2_run is OK, but during the second run, the active_gases_array become garbage. 

The debug file I created like this:

/scratch1/NCEPDEV/global/Qingfu.Liu/gfsv16_ccpp/sorc/fv3gfs.fd/FV3/ccpp/physics/physics/GFS_debug_rrtmgp.F90

and the cap file generated as:

/scratch1/NCEPDEV/global/Qingfu.Liu/gfsv16_ccpp/sorc/fv3gfs.fd_failed/tests/build_fv3_2/FV3/ccpp/physics/ccpp_FV3_GFS_v16beta_RRTMGP_radiation_cap.F90

The output shows that the subroutine GFS_debug_rrtmgp2_run is called twice by the same processor (only call once in the cap file).

/scratch1/NCEPDEV/stmp2/Qingfu.Liu/ROTDIRS/ccpp_rrtmgp/logs/2020011212/gfsfcst.log_save

    I have another question: the active_gases_array is declared as:

active_gases_array=GFS_Interstitial(cdata%thrd_no)%active_gases_array

Is it possible that GFS_Interstitial variables lost during the next time step?

Again, thank you very much

Qingfu

Sitemap

Contact

303.497.8921
dtcenter@ucar.edu

Addresses

mailing:
PO Box 3000
Boulder, CO 80307-3000

Shipping:
3090 Center Green Dr.
Boulder, CO 80301

Follow Us

YouTube Icon
Twitter Icon

Copyright © 2024. All rights reserved.