-
Notifications
You must be signed in to change notification settings - Fork 38
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
Too many unnessary settings in config-user.yml #93
Comments
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Setting |
With the new CLI, all |
Using these options in the configuration file instead of the diagnostic script section of the recipe would need to be deprecated in the upcoming release (2.1, planned for October 2020, feature freeze October 5th) and removed two releases later (2.3, planned June 2021), see also the release schedule. |
We would need to make sure that the |
Setting |
After looking through the code of ESMValTool to see what it would take to remove |
Superseded by #2371 |
At the moment there are many settings in config-user.yml that users will very rarely change. Therefore I propose to reduce the number of options exposed to users in the following way:
Proposed for removal (can be moved to the recipe for those diagnostics that support these options)
write_plots: true
write_netcdf: true
output_file_type: ps # [ps]/pdf/png/eps/epsi
These are options that should be implemented by diagnostic developers, so this puts a burden on diagnostic developers to implement it and in many cases it does not work, because they are either not aware of these options, or for the last option, the library they use for plotting does not support a particular plot type. The amount of time that is saved by not creating plots or netcdf files or all possible plot types is probably only a small fraction of the total runtime, so the advantage of having these settings is rather unclear, but having them creates a bad user experience because they do not work in many cases and a bad diagnostic developer experience because they have to implement and test additional requirements.
Proposed for moving to an advanced users file, e.g config-developer.yml
profile_diagnostic: false
-> only interesting for Python diagnostic developerssave_intermediary_cubes: false
-> for debugging purposes, probably only interesting for diagnostic developersexit_on_warning: false
-> specific to NCL diagnostics, probably only interesting for diagnostic developersThe text was updated successfully, but these errors were encountered: