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

Move empty and non-existent data_table handling to data_override #934

Closed
GFDL-Eric opened this issue Mar 10, 2022 · 0 comments · Fixed by #933
Closed

Move empty and non-existent data_table handling to data_override #934

GFDL-Eric opened this issue Mar 10, 2022 · 0 comments · Fixed by #933
Labels
enhancement Issue/PR for a modification that increases performance, improves syntax, or adds functionality.

Comments

@GFDL-Eric
Copy link
Contributor

Is your feature request related to a problem? Please describe.
The decision of whether to call data_override_init is currently handled within the various FMScoupler coupler_main.F90 routines (simple, full, SHiELD). Since some setups don't have a data_table or a grid_spec.nc, the current implementation is the only way to prevent a "grid_spec.nc not found" crash in data_override. While the current setup is adequate as a stop-gap measure, the handling of the data_table file's existence and contents should be done within data_override itself.

Describe the solution you'd like
Remove the checks from FMSCoupler regarding data_override_init and just call the subroutines there. Within data_override, check to see if the file exists (within the read_data subroutine for the ASCII data_table, within the yaml_parser for reading the data_table.yaml). If the file does not exist, or its contents are empty, exit out of the data_override_init routine before reading in the grid_spec.nc to avoid crashes.

Describe alternatives you've considered
Keeping it as is.

Additional context
Since this involved parser changes for any yaml inputs, and sub-module that uses the yaml parser will likewise be affected when yaml parsing is implemeted in the future (diag_manager, field_manager, etc.).

@GFDL-Eric GFDL-Eric added the enhancement Issue/PR for a modification that increases performance, improves syntax, or adds functionality. label Mar 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Issue/PR for a modification that increases performance, improves syntax, or adds functionality.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant