Modularization of moving nest and storm tracker functionality.

[wramstrom]

Is your feature request related to a problem? Please describe.
Modularization of moving nest and storm tracker functionality

Describe the solution you'd like
GFDL requests a code update with the following features:

1. Take moving nested grid code and move it into its own component (at the same level as atmos_cubed_sphere).
2. Physics code must be moved out of FV3 or its submodules.
3. Access FV3 exclusively through APIs defined in atmosphere.F90

Describe alternatives you've considered
AOML and GFDL agreed to initial changes for PR 179, and these additional steps to be accomplished in an upcoming release.

Additional context
Additional comments from GFDL:

You may consider promoting the moving nested grid to be a separate
component, on the same level as atmos_cubed_sphere. This would be similar to the implementation of stochastic physics. In this case, the moving nest implementation would still be dependent upon FV3 but not necessarily a part of it, and communicates with FV3 through the APIs defined in atmosphere.F90. Additionally, the vortex tracker could also be separate from the moving nest code.

While many others have implemented new capabilities within #ifdef/#endif blocks, there is a tendency to overuse this approach to mask out features which may have limited adoption. Along with the modularization recommended above, it may be acceptable to include moving nest options directly within the model without an #ifdef block.

Please note that the vast majority of FV3-based model users will not be concerned with the moving nested grids. This is especially true for our many users outside of the UFS (NASA, GFDL, NCAR, etc.) and we need to ensure the unified codebase is useful for all of our users.

Other notes:

Have computational performance (and repro?) baselines been performed to ensure other applications have not seen degraded performance?

If the simplified version of Tim’s GFDL Hurricane Tracker is useful outside of this context maybe it is better to separate it from the moving nest code

Will GFDL be responsible for maintaining the moving nested-grid code once the merge is complete? If so, it would be useful if AOML could provide some sort of documentation to explain how this works.

[lharris4]

Hi, Bill. Thanks for putting this together. This is a good summary of the needs for the November release. Lucas

…

On Fri, Apr 1, 2022 at 3:28 PM William Ramstrom ***@***.***> wrote: *Is your feature request related to a problem? Please describe.* Modularization of moving nest and storm tracker functionality *Describe the solution you'd like* GFDL requests a code update with the following features: 1. Take moving nested grid code and move it into its own component (at the same level as atmos_cubed_sphere). 2. Physics code must be moved out of FV3 or its submodules. 3. Access FV3 exclusively through APIs defined in atmosphere.F90 *Describe alternatives you've considered* AOML and GFDL agreed to initial changes for PR 179, and these additional steps to be accomplished in an upcoming release. *Additional context* Additional comments from GFDL: You may consider promoting the moving nested grid to be a separate component, on the same level as atmos_cubed_sphere. This would be similar to the implementation of stochastic physics. In this case, the moving nest implementation would still be dependent upon FV3 but not necessarily a part of it, and communicates with FV3 through the APIs defined in atmosphere.F90. Additionally, the vortex tracker could also be separate from the moving nest code. While many others have implemented new capabilities within #ifdef/#endif blocks, there is a tendency to overuse this approach to mask out features which may have limited adoption. Along with the modularization recommended above, it may be acceptable to include moving nest options directly within the model without an #ifdef block. Please note that the vast majority of FV3-based model users will not be concerned with the moving nested grids. This is especially true for our many users outside of the UFS (NASA, GFDL, NCAR, etc.) and we need to ensure the unified codebase is useful for all of our users. Other notes: Have computational performance (and repro?) baselines been performed to ensure other applications have not seen degraded performance? If the simplified version of Tim’s GFDL Hurricane Tracker is useful outside of this context maybe it is better to separate it from the moving nest code Will GFDL be responsible for maintaining the moving nested-grid code once the merge is complete? If so, it would be useful if AOML could provide some sort of documentation to explain how this works. — Reply to this email directly, view it on GitHub <#182>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMUQRVDR2UIIAPSPF7NWQTTVC5E35ANCNFSM5SJS3LUQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[DusanJovic-NOAA]

Can somebody list which specific files from this repository should be moved out to fv3atm.

[wramstrom]

The list of files would be the current contents of the atmos_cubed_sphere/moving_nest directory:

…

-rw-r----- 1 wramstro aoml-hafs1 6602 Jul 26 14:37 bounding_box.F90 -rw-r----- 1 wramstro aoml-hafs1 146758 Jul 29 17:26 fv_moving_nest.F90 -rw-r----- 1 wramstro aoml-hafs1 64700 Jul 26 14:37 fv_moving_nest_main.F90 -rw-r----- 1 wramstro aoml-hafs1 103070 Jul 26 14:37 fv_moving_nest_physics.F90 -rw-r----- 1 wramstro aoml-hafs1 27833 Jul 26 14:37 fv_moving_nest_types.F90 -rw-r----- 1 wramstro aoml-hafs1 197884 Jul 26 14:37 fv_moving_nest_utils.F90 -rw-r----- 1 wramstro aoml-hafs1 67565 Jul 26 14:37 fv_tracker.F90 Bill

On Fri, Sep 23, 2022 at 10:53 AM Dusan Jovic ***@***.***> wrote: Can somebody list which specific files from this repository should be moved out to fv3atm. — Reply to this email directly, view it on GitHub <#182 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANDHMWG725NQNONY642M3MLV7W77HANCNFSM5SJS3LUQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[laurenchilutti]

Closing this issue as PR #227 has been merged to address this.