-
Notifications
You must be signed in to change notification settings - Fork 13
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
Create abstract VertCoord class that all vertical coordinates inherit from #80
Comments
The need for something like this, or more generally a re-vamping of how we handle vertical coordinates, is now more acute, due to new use cases from different models, each with their own idiosyncrasies. See #184 for the WRF model and #191 for the CAM model. Another use case is sigma coordinates, i.e. pressure divided by surface pressure (confusingly we use the 'sigma' label to refer to hybrid sigma-pressure coordinates). @spencerkclark it just occurred to me that the idealized models use this, including the test data we package with aospy! How are we handling these coordinates right now? We also need to provide a public API for users to define and supply their own vertical coordinate systems, so that they don't find themselves unable to use aospy if their data uses a vertical coordinate system that aospy doesn't support. What would this look like? The only things that I think are ultimately needed for each coordinate type are methods for computing the pressure at level interfaces and level centers. (Although that pre-supposes that the vertical coordinate is ultimately pressure-related, which isn't the case for e.g. ocean models or atmospheric models that use a z coordinate). |
The FMS idealized models still output |
I see, that's a nice design. Unfortunately, this doesn't hold more generally. The idealized models at Caltech (despite being FMS-based, albeit a much older version) that I'm using these days don't use bk or pk; they have simply a 'sigma' coordinate:
So we do need to ultimately handle pure sigma. |
Yeah, I totally agree that what's in aospy now is not close to general enough.
Could a starting point simply be the paradigm that's already used for all other kinds of computed variables (i.e. user-defined |
Sorry, I'm not sure I understand what you mean. I'll provide a little more context below; hopefully that helps (me as much as you). The original motivation for our current approach, which is to pre-compute as necessary pressure fields before passing them to a variable's computation function, was to enable users to write more generic functions, i.e. ones that don't require knowledge of the coordinate type. So for potential temperature, only one function would need to be defined, with one of its arguments being a (potentially spatiotemporally varying) pressure field. One motivation for specifying the vertical data type was that sometimes I had the same quantities both pressure-interpolated and on the model native coordinates. I needed to compare how accurate things were in either coordinate system. Also, for the GFDL netCDF directory structure and file naming, the vertical datatype determines the file name and path: "atmos" for interpolated vs. "atmos_level" for model-native. But I admit that's not a super common use-case; I would be receptive to that being optional and having aospy look for one or the other by default. |
Sorry I realize what I wrote is vague. I was thinking something along the lines of replacing
Each of these would accept We already have the machinery to load the data necessary for and compute Currently the way things work if one wants to use pressure in a computation of another variable, is that in one's object library, one needs to use a Does that make a little more sense? It would be nice if we could avoid writing a new object type that the user would need to think about (though I'm not necessarily against writing a new class internally to handle these things). |
Sorry for taking a while on this. You raise some good points. I still need to think through all this; don't see one obvious best way forward yet. So mostly just more questions for now.
Would we require them to have these names, or could a user potentially name them something different? For the data loading (c.f. the GFDL example), how would one translate from these names to constructing the needed path?
This is a good point. Even if we stay with the existing
Agreed
Good point, we should add material on this to the docs once we converge on a solution |
(copied from offline convo w/ me and @spencerkclark in May)
Maybe it makes sense to create an abstract class or interface for vertical coordinates...it would have attributes and/or methods for layer interface values and layer center values. Then users could specify their own coordinates, and aospy can use them so long as they adhere to the interface. I'm sure there are other coordinate systems in use out there, especially on the ocean (or non-atmosphere more broadly) side than the pressure and hybrid sigma-pressure ones we use. And that would contribute to our broader effort to refactor the codebase to be more modular.
infinite-diff already tries to do something similar. And Iris has something of this sort implemented.
The text was updated successfully, but these errors were encountered: