-
Notifications
You must be signed in to change notification settings - Fork 26
Description
Describe the Enhancement
This feature request arose via met-help for a NASA user:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=100072
While this idea arose via met-help, it would be widely useful.
When reading gridded data from NetCDF the level string defines how to index into the variable dimensions to extract the 2D field of data. For example:
name = "varname"; level = "(0,4,*,*)";
The *,* indicates the gridded dimensions, and the 0,4 indicates that the 0-th index from the first dimension and 4-th index from the second dimension should be used.
MET's NetCDF library code includes a special case for the "time" dimension. Instead of an integer index value, the user can supply a timestring in YYYYMMDD[_HH[MMSS]] format. The NetCDF library code parses the timestamp, searches the time dimension for that time, and then uses the index for that matching value.
This issue is to extend that same logic to non-time dimensions as well. For example, let's say there is a coordinate variable named "pressure", meaning there is both a variable and dimension named pressure. For example:
name = "varname"; level = "(550,d02,*,*)"; // for varname(pressure,domain,Nx,Ny)
The logic should be:
- For "550" in the first dimension, search the "pressure" coordinate variable to find the matching index.
- For "d02" in the second dimension, search the "domain" coordinate variable to find the matching index.
If either value is not found, error out with a useful error message.
The big challenge here is that 550 is an integer. So it could conceivably either specify a coordinate variable VALUE or an INDEX. The difficulty is distinguishing between them. We could consider supporting embedded single or double quotes to differentiate between strings and indices. For example:
name = "varname"; level= "(550,'d02',*,*)"; // 550 is an index
name = "varname"; level = "('550','d02',*,*)"; // 550 is a pressure level value
Recommend that we think more about this.
Time Estimate
3 days.
Sub-Issues
Consider breaking the enhancement down into sub-issues.
No sub-issues needed.
Relevant Deadlines
List relevant project deadlines here or state NONE.
Funding Source
2799991
Define the Metadata
Assignee
- Select engineer(s) or no engineer required
- Select scientist(s) or no scientist required
Labels
- Select component(s)
- Select priority
- Select requestor(s)
Projects and Milestone
- Select Repository and/or Organization level Project(s) or add alert: NEED PROJECT ASSIGNMENT label
- Select Milestone as the next official version or Future Versions
Define Related Issue(s)
Consider the impact to the other METplus components.
- METplus, MET, METdatadb, METviewer, METexpress, METcalcpy, METplotpy
Will likely need a METplus issue to support the use of this new option.
Enhancement Checklist
See the METplus Workflow for details.
- Complete the issue definition above, including the Time Estimate and Funding Source.
- Fork this repository or create a branch of develop.
Branch name:feature_<Issue Number>_<Description>
- Complete the development and test your changes.
- Add/update log messages for easier debugging.
- Add/update unit tests.
- Add/update documentation.
- Push local changes to GitHub.
- Submit a pull request to merge into develop.
Pull request:feature <Issue Number> <Description>
- Define the pull request metadata, as permissions allow.
Select: Reviewer(s) and Linked issues
Select: Repository level development cycle Project for the next official release
Select: Milestone as the next official version - Iterate until the reviewer(s) accept and merge your changes.
- Delete your fork or branch.
- Close this issue.