lharris4
commented
2 years ago 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:
- Take moving nested grid code and move it into its own component (at the same level as atmos_cubed_sphere).
- Physics code must be moved out of FV3 or its submodules.
- 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 https://github.com/NOAA-GFDL/GFDL_atmos_cubed_sphere/issues/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
wramstrom
laurenchilutti
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:
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.