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

Need a clean solution to read CCPP namelist option #88

Open
climbfuji opened this issue Mar 29, 2021 · 0 comments
Open

Need a clean solution to read CCPP namelist option #88

climbfuji opened this issue Mar 29, 2021 · 0 comments

Comments

@climbfuji
Copy link

PR #86 implements a workaround for reading the ccpp_suite namelist option before initializing CCPP physics. This is not an ideal solution, but given the upcoming changes wrt physics in the dycore, it minimizes the amount and frequency of changes that impact developers and users.

Background: The future implementation will use a generic interface in the dycore to either call the original GFDL fast physics (for SHIELD models etc) or the CCPP fast physics (for UFS etc), and will separate the existing suite definition files (SDFs) into two SDFs each (one for the dycore = fast physics, one for fv3atm = traditional physics). This means that we will have two ccpp_suite options in the namelist, one in the section relevant for the dycore (fv_core_nml?), one in the section relevant for physics (currently gfs_physics_nml). It doesn't make sense to change each namelist template in the repository and instruct all developers to change their namelists twice - better do it once.

climbfuji pushed a commit to climbfuji/GFDL_atmos_cubed_sphere that referenced this issue Apr 24, 2024
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

No branches or pull requests

1 participant