Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Moving Nest Functionality #179

Merged
merged 136 commits into from
Apr 11, 2022

Conversation

wramstrom
Copy link

@wramstrom wramstrom commented Mar 10, 2022

Description

This pull request contains the dycore changes to implement moving nest functionality, as specified in Issue #1100:
ufs-community/ufs-weather-model#1100

This code implements a storm-following moving nest in regional and global configurations. Nest motion code handles prognostic variables, surface variables, and physics variables. Nest motion is configured in the namelist, with options for automated storm tracking, prescribed nest motion, and frequency of nest moves. Automated storm tracking code was ported from HWRF to operate within the FV3 framework. This code also includes filling SST in a static or moving nest by downscaling from coupled SST in the parent domain.

Moving nest code has been designed to allow prior static global or nested simulations to have identical performance and be bitwise reproducible. This has been verified with regression testing. Moving nest code is wrapped with #ifdef MOVING_NEST in existing and new code modules. The bulk of the new code is in new files in atmos_cubed_sphere/model; the main files are fv_moving_nest_main.F90, fv_moving_nest.F90, fv_moving_nest_physics.F90, and fv_tracker.F90. Additional utilities subroutines are added in new files fv_moving_nest_utils.F90 and bounding_box.F90. The existing module fv_arrays.F90 has significant additions to enable moving physics variables and the automated storm tracking. The existing module fv_control.F90 has some smaller changes to enable moving nest, and coupling SST in a static or moving nest to an ocean model.

The current code supports a single moving nest, at 3X nest refinement. Code has been designed to be extensible to multiple moving nests.

Dependencies:
This code requires the updated FMS library from PR #840 NOAA-GFDL/FMS#840 to include mpp_shift_nest_domains().

The moving nest code can only be run when the associated PR from the FV3 level calls into the moving nest subroutines added in this PR.

Fixes #1100 ufs-community/ufs-weather-model#1100

How Has This Been Tested?

This code has been tested on Orion and Hera with Intel 18 for a large number of stress cases. These exercised the moving nest functionality in regional and global configurations. Most tests were performed with a regional configuration at C512 with a 3X refinement nest that spanned 19 degrees X 19 degrees. Tests followed storms over the open ocean, through the Caribbean islands, and during continental landfall and subsequent overland passage. Tests of land interaction are important because a large number of surface fields are specified for land-only points. In addition, interaction with sharp terrain validates the stability of the model. Additional tests were performed in the Southern Hemisphere, and crossing the dateline and prime meridian. Tests focused on the FV3_HAFS_v0_gfdlmp_tedmf physics suite.

Spreadsheet of tests performed is available at: https://docs.google.com/spreadsheets/d/1FP6JReNuCX4hQnEZI1irkooMuw_DiGvXRm1_LxJHhL4/edit#gid=0

The main regression suite now has 5 cases to test moving nest functionality; those config changes will be in the FV3 level pull request for moving nest. Tests are called: hafs_regional_specified_moving_1nest_atm, hafs_regional_storm_following_1nest_atm, hafs_regional_storm_following_1nest_atm_ocn, hafs_regional_storm_following_1nest_atm_ocn_wav, hafs_global_storm_following_1nest_atm.

Moving nest development team requests that the commits that make up this PR NOT be squashed.

The moving nest capability in the model core was coded by @wramstrom at AOML/HRD with significant collaboration from @BinLiu-NOAA at EMC, and additional collaboration from AOML/HRD (@Xuejin-Zhang, @A-Kyle, Gopal,et al.), EMC (@ChunxiZhang-NOAA, @ZhanZhang-NOAA, @WeiguoWang-NOAA, @JunghoonShin-NOAA, et al.) and GFDL (@lharris4, @bensonr, @TimMarchok-NOAA, @JosephMouallem, et al.).

Checklist:

Please check all whether they apply or not

  • My code follows the style guidelines of this project
    Follows Fortran style guide, except some lines exceed 120 character length.
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
    Main fv_moving_nest*.F90 modules have been commented. Utilities modules are not yet fully commented.
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • Any dependent changes have been merged and published in downstream modules

BinLiu-NOAA and others added 30 commits May 8, 2020 00:39
…o that the

model can run with other vertical level configurations.
…static latlon grid file once. Reduced number of variables output by mn_prog_dump_to_netcdf.
…to read from static grid files for moving nest only once. Added crude scaling of nest motion speed based on timestep.
Merge branch 'feature/hafs_moving_nest' of https://github.com/hafs-community/GFDL_atmos_cubed_sphere into feature/hafs_moving_nest

Conflicts:
	driver/fvGFS/atmosphere.F90
…ed nest motion. Removed forced exit at timestep 4800.
…from edge, and block motion for the rest of model run.
…routines to moving nest interfaces. Added performance tracking to init_grid and setup_aligned_nest.
*Update the moving nesting interface.
Note: Coding session among Bill, Xuejin, Kyle, Zhan, Chunxi, Weiguo, Bin
…s. Added new subroutines for high precision physics variables.
*Add a fv_diag_tracker subroutine to obtain the tracker needed variables
*Identify and add the call interfaces for the internal vortex tracker in driver/fvGFS/atmosphere.F90.
Note: These are outcome from the coding sessions among Xuejin, Chunxi, Zhan, and Bin.
Copy link
Contributor

@lharris4 lharris4 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is much improved and what we had wanted to have implemented on this short timescale. I have some minor changes and questions to resolve. Thanks.

driver/fvGFS/atmosphere.F90 Show resolved Hide resolved
@@ -1251,6 +1254,10 @@ module fv_arrays_mod
real, _ALLOCATABLE :: peln(:,:,:) _NULL !< ln(pe)
real, _ALLOCATABLE :: pkz (:,:,:) _NULL !< finite-volume mean pk


! For downscaling coupling variables from parent to nested grids
real, _ALLOCATABLE :: downcpl2d(:,:) _NULL !< temporary 2d arrary for downscaling coupling variables
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this array need to be defined in Atm% instead of being part of (say) some coupler datatype?

Copy link
Author

@wramstrom wramstrom Mar 31, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am less familiar with the coupling code. @BinLiu-NOAA can you comment here? I think this is also applicable to static nesting, with ocean coupling at the parent grid level.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lharris4 This downcpl2d variable is currently used to downscale/pass the SST or sea surface roughness length (z0) variables from the FV3 parent grid to its nest grid. This is because currently the ocean/wave coupling only happens between the FV3atm parent domain and the ocean/wave domains. Thus, we need to pass the SST/z0 fields from the parent to the nest so that the nest domain also gets updated values from the ocean/wave model components. This is currently a temporary solution/workaround. The plan is to enable the coupling/exchange between the FV3atm nested domain and ocean/wave domains directly in future as a better solution.

Alternatively, if you do not want add this downcpl2d variable here. We can move it back inside the subroutine atmosphere_fill_nest_cpl as a temporary array.

Please feel free to let us know your preference. Thanks!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, Bill, Bin. If it doesn't need to be preserved between calls, then it doesn't need to be in fv_array, and since it is physics-specific it probably doesn't belong here anyway.

Thanks,
Lucas

Copy link

@BinLiu-NOAA BinLiu-NOAA Mar 31, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lharris4, Thanks for the comments/suggestions! As I was trying to move the downcpl2d array into the atmosphere_fill_nest_cpl subroutine, it seems to me that will make the procedure passing a variable from parent to its nest much more complicated. Thus, at this moment, I just renamed this downcpl2d array into parent2nest_2d array to reduce any potential confusion. And I also think the name of parent2nest_2d is actually more accurate, which is to assist the parent to nest downscaling procedure. It can be used for passing not only coupling variables but also any other desired dynamics/physics variables from the parent to its static/moving nest. Hopefully, this is fine for this temporary solution. And we can revisit this once the direct coupling between the FV3 nested grids and the wave/ocean domains are implemented/enabled. Thanks!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. We will revisit in a future release.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, @lharris4!

model/fv_control.F90 Show resolved Hide resolved
tools/fv_diagnostics.F90 Outdated Show resolved Hide resolved
Copy link
Contributor

@lharris4 lharris4 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am satisfied with the new changes.

Copy link
Contributor

@bensonr bensonr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is an FMS namelist option to have the diagnostic data be dumped on write as opposed to buffered until exit.

driver/fvGFS/atmosphere.F90 Outdated Show resolved Hide resolved
model/fv_control.F90 Outdated Show resolved Hide resolved
model/fv_grid_utils.F90 Outdated Show resolved Hide resolved
model/fv_grid_utils.F90 Outdated Show resolved Hide resolved
tools/fv_diagnostics.F90 Outdated Show resolved Hide resolved
tools/fv_diagnostics.F90 Outdated Show resolved Hide resolved
tools/fv_diagnostics.F90 Outdated Show resolved Hide resolved
@lharris4
Copy link
Contributor

lharris4 commented Apr 1, 2022 via email

Copy link
Contributor

@laurenchilutti laurenchilutti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@wramstrom Can you please create an issue logging the decisions we made in our meeting on March 23rd? I believe Lucas summarized this in a Google Doc, but it would be helpful to have that information in an issue on Github.

@wramstrom
Copy link
Author

@laurenchilutti I have created the issue here:
#182

@laurenchilutti
Copy link
Contributor

@laurenchilutti I have created the issue here: #182

Great! Thank you

@bensonr
Copy link
Contributor

bensonr commented Apr 5, 2022

@wramstrom - are you still planning to remove the timers from fv_grid_tools.F90 as discussed?

@wramstrom
Copy link
Author

@wramstrom - are you still planning to remove the timers from fv_grid_tools.F90 as discussed?

@bensonr I am using the timers in fv_grid_tools.F90 in my optimization work that started this week and runs through May 1. I can remove them now if it is a significant issue, but would prefer to remove them on the next pass after I have completed performance optimization work.

Copy link

@BinLiu-NOAA BinLiu-NOAA left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me for current phase clean-up. And there will be future PR(s) to further reorganize/optimize/clean up the moving-nesting related code changes.

@laurenchilutti
Copy link
Contributor

@JosephMouallem @bensonr @DusanJovic-NOAA Could you please leave a review? If you think it is ready to merge please approve. Thank You!

@laurenchilutti
Copy link
Contributor

@junwang-noaa this PR is now ready to merge.

@laurenchilutti
Copy link
Contributor

@wramstrom I see in the description of this PR you would like me to NOT squash commit this. Why is this? I want to just note that this is 136 commits.

@wramstrom
Copy link
Author

@wramstrom I see in the description of this PR you would like me to NOT squash commit this. Why is this? I want to just note that this is 136 commits.

You can squash commit this if needed; @BinLiu-NOAA showed me some other ways I can examine the evolution of the code if I need it.

@DusanJovic-NOAA
Copy link
Contributor

@laurenchilutti Please merge this PR. The ufs-weather-model passed full regression tests (ufs-community/ufs-weather-model#1104).

@laurenchilutti laurenchilutti merged commit 0b04085 into NOAA-GFDL:dev/emc Apr 11, 2022
JiliDong-NOAA added a commit to JiliDong-NOAA/GFDL_atmos_cubed_sphere that referenced this pull request Apr 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants