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 to find more efficient method for selecting chosen physics suite from user_nl_cam #154

Closed
nusbaume opened this issue Sep 15, 2021 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@nusbaume
Copy link
Collaborator

The addition of the SE dycore will bring in the new ccpp_phys_set function in cam_config.py, which allows a user to select which physics suite they would like to run by adding a physics_suite = X entry into user_nl_cam. However, the python code needed to check for this entry is quite expensive, and thus it would be good to find an alternative method.

One possibility may be to use the new ParamGen system to do this namelist check for us.

Another possibility may be to add a build cache-like entry such that this check is only done if the user modifies user_nl_cam between various case script calls.

Either way, the fix for this issue will hopefully be included in the PR that introduces ParamGen and the capability to manage multiple namelist definition files.

@nusbaume nusbaume added the enhancement New feature or request label Sep 15, 2021
@nusbaume nusbaume self-assigned this Sep 15, 2021
@gold2718
Copy link
Collaborator

Why is it expensive? Isn't there a list of all compiled suites?
I agree that lots of things will get easier in ParamGen and there is no super hurry to having multiple suites.

@nusbaume
Copy link
Collaborator Author

I believe the expense comes from the parsing of the user_nl_cam entry itself, although to be honest I mostly just created this issue because you explicitly asked me to in the SE dycore review (PR #135), to quote:

Also, this is an expensive check. Be on the lookout to see if it could be replaced with something more efficient as we move to the RPS namelist system. Open an issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants