Suggested improvements for GFS debugging routines: specify lat-lon region, others?

[climbfuji]

Feedback from @junwang-noaa regarding the use of the GFS-specific debugging routines GFS_diagtoscreen and GFS_interstitialtoscreen in GFS_debug.F90:

I am not sure if there is a way to add function print_var_points with lat_min, lat_max, lon_min, lon_max as input. But I feel that will be a popular debug tool as most of time we are looking the variables in a small region or several points.

I think this can be implemented easily ... is this something other developers would want, too? Any additional requests?

Before asking for features, documentation and how to use the schemes, please make sure to read chapter 11 of the CCPP Technical Documentation (https://ccpp-techdoc.readthedocs.io/en/latest/CCPPDebug.html). Thanks!

[yangfanglin]

I think the latest dycore and IPD already support this function (developed at GFDL). Probably can be extended for CCPP.

…

On Mon, Sep 27, 2021 at 1:40 PM Dom Heinzeller ***@***.***> wrote: Feedback from @junwang-noaa <https://github.com/junwang-noaa> regarding the use of the GFS-specific debugging routines GFS_diagtoscreen and GFS_interstitialtoscreen in GFS_debug.F90: I am not sure if there is a way to add function print_var_points with lat_min, lat_max, lon_min, lon_max as input. But I feel that will be a popular debug tool as most of time we are looking the variables in a small region or several points. I think this can be implemented easily ... is this something other developers would want, too? Any additional requests? Before asking for features, documentation and how to use the schemes, please make sure to read chapter 11 of the CCPP Technical Documentation ( https://ccpp-techdoc.readthedocs.io/en/latest/CCPPDebug.html). Thanks! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#744>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKY5N2MZCA2ZZNWJVMAA7I3UECUA7ANCNFSM5E3C7JHA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- *Fanglin Yang, Ph.D.* *Chief, Model Physics Group* *Modeling and Data Assimilation Branch* *NOAA/NWS/NCEP Environmental Modeling Center* *https://www.emc.ncep.noaa.gov/gmb/wx24fy/fyang/ <https://www.emc.ncep.noaa.gov/gmb/wx24fy/fyang/>*

[climbfuji]

Clarification: this is about augmenting the existing capability in ccpp-physics. ccpp-physics are and must remain independent of the dycore, even in the use case of the UFS. Even if we implemented a dycore dependency only when used by UFS (that is technically no problem), it wouldn't work. This is because the dycore in the UFS depends on ccpp-physics for the fast physics code, and we would create circular dependencies that would break the build system.