Inability to robustly prescribe component preference
Closed this issue · 4 comments
Bug Severity
- 1 = Minor problem that does not affect total framework functionality (e.g., computation error in a POD, problem with logging output, or an issue on a single system
- 2 = Major problem that affects overall functionality, but that does not occur for all users (e.g., problems installing the framework with a specific Conda version, a framework option that causes one or more PODs to fail, or missing/incompatible Python modules).
- 3 = Catastrophic problem that occurs frequently for multiple users and/or on multiple systems (e.g.,framework consistently fails to install on multiple systems, or one or more PODs continuously fails after running successfully)
Describe the bug
The data selection heuristics for FREPP-processed data are yielding undesirable results for ocean fields. Here is a specific case example that considers the ocean variable tos
or sea_surface_temperature
. The field exists traditionally in three frepp components:
- atmos_cmip
- ocean_monthly
- ocean_monthly_1x1deg
The current heuristics would select the version from atmos_cmip (since it contains the sub-string "cmip"). This selection would be undesirable from an ocean modeler's perspective. Even if the atmos_cmip component was ignored, the second criteria of selecting the component with the shortest name (ocean_monthly in this case) would not always be appropriate for high-resolution models.
Steps To Reproduce
- Add
tos
to thefieldlist_CMIP.jsonc
file - Create a dummy POD that tries to read
tos
Environment
- GFDL central install
@wrongkindofdoctor, @aradhakrishnanGFDL, and @Wen-hao-Dong - I am working on some possible solutions to this issue. I will keep you posted.
@jkrasting Much appreciated. I will add this to the top of this week's todo list.
No action needed on your part @wrongkindofdoctor - I am close to having a fix. Once I have something, I'd like to run it by the team to make sure we are on the same page.
@jkrasting Okay. Sounds like a plan.