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

As a developer, I want to choose an architecture for a revamped gridded evaluation feature #268

Open
epag opened this issue Aug 21, 2024 · 2 comments

Comments

@epag
Copy link
Collaborator

epag commented Aug 21, 2024


Author Name: James (James)
Original Redmine Issue: 95166, https://vlab.noaa.gov/redmine/issues/95166
Original Date: 2021-08-13


Given a presumed need for gridded evaluations (tbd in #95165)
When I consider how to meet that need
Then the first thing I want to consider, after I understand the need itself, is the best architecture to achieve it

@epag
Copy link
Collaborator Author

epag commented Aug 21, 2024


Original Redmine Comment
Author Name: James (James)
Original Date: 2021-08-13T17:14:41Z


#95165 comes first, but I'm not going to block it because the discussion can happen in parallel, at least to some degree.

Architecture means big picture. There are many possibilities. One is to have an architecture like now with a separate piece of software inside the core wres for handling gridded ingest and retrieval. Another is to have a separate microservice for gridded evaluations (presumably requiring further disaggregation of the core service in order to promote re-use). Another is to have a single, core, architecture that deals with features and uses some sort of pre-processing of grids into features (edit: i.e., a separate piece of software or microservice that does pre-processing). There are probably others. Diagrams will help.

@epag
Copy link
Collaborator Author

epag commented Aug 21, 2024


Original Redmine Comment
Author Name: James (James)
Original Date: 2021-08-19T20:22:26Z


Noodling in #90061 confirmed that 10^2 to 10^5 features is feasible for our existing gridded evaluation capability (e.g., in cowres). A conus-wide evaluation probably wouldn't be feasible, even for a very small set of grids. To handle such an evaluation, I predict that the gridded architecture would need to be (even more of) a special snowflake, more akin to the treatment in MET, for example, and if true then wrapping MET in a microservice might be a better approach than rolling our own and trying to make it fit the feature paradigm that most users/evaluations seem to want. Likely worst case scenario for us would be a special snowflake within wres core that sucked most of our time and.... sucked.

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