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

Extend/Fix Vertical Grid capability/logic for History Collections #3020

Open
bena-nasa opened this issue Sep 9, 2024 · 2 comments
Open

Extend/Fix Vertical Grid capability/logic for History Collections #3020

bena-nasa opened this issue Sep 9, 2024 · 2 comments
Assignees
Labels
📈 MAPL3 MAPL 3 Related 🎁 New Feature This is a new feature

Comments

@bena-nasa
Copy link
Collaborator

bena-nasa commented Sep 9, 2024

Now that stuff is happening with vertical grids, a few issues that need sorting out in History3G

  1. Looks we need fix it up so proper metadata is added for each grid class (basic, fixelevels, others...), although only probably basic and fixedlevels (well, once the PR for that is in) could be done now, others not so much. Right now adds a dimension of the proper size
  2. Right now, each collection makesVariableSpecs for the import state. For the vertical right now it just says, VERTICAL_DIM_MIRROR, but now this can't be. For example, if the collection is on fixed levels we are interpreting those as the "centers" at least that's how I think of them... so if that's the collection vertical grid, the specs need to be created with VERTICAL_DIM_CENTER.
  3. Actually brings up another point, what is user says VERTICAL_DIM_EDGE, but the vertical grid is fixed levels. Error? Should be one in my mind.
  4. Others?
@bena-nasa bena-nasa added 🎁 New Feature This is a new feature 📈 MAPL3 MAPL 3 Related labels Sep 9, 2024
@bena-nasa bena-nasa changed the title Extend Vertical Grid Extend/Fix Vertical Grid capability/logic for History Collections Sep 9, 2024
@tclune
Copy link
Collaborator

tclune commented Sep 9, 2024

Re (3): There are multiple ways to approach it, but we need to choose and then be clear about it.

First, are the fixed levels "centers" or "edges". I think the existing practice makes them more akin to centers. And then that flows well into the statement that fields defined on FixedLevels must also VERT_DIM_CENTER.

The problem is then whether to allow an export on FixedLevels to be regridded to something else? My preference would be to keep all regridding to use source node points that are edges. Makes me head hurt.

@bena-nasa
Copy link
Collaborator Author

bena-nasa commented Sep 9, 2024

@tclune I think the existing practice makes the fixed levels akin to centers as you say. That's how I think of them. We may have offline use cases that would be regridding fixed levels to model levels. Like I think Scott or Bill may get EC data that is at say 1000mb, 950mb, etc... and want to convert this into something the model can use. We should ask them. At one point Andrea and Jules wanted to use fixed pressure level data as inputs to ExtData for use in the CTM and I had something working in the old extdata (but never really bothered to get working in ExtData2G) to regrid this to model levels. @JulesKouatchou wrote the code that did this that still lives in MAPL, but I'm almost 100% sure the assumption was the source was centers, i.e. there was no "thickness" associate with the source. Also the were some things that you had to do different depending on the physical quantity, I know Jules put the hooks in his interface for that, but not sure if I worried about that in practice when used.

I don't think assuming all source node are edges is practical.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
📈 MAPL3 MAPL 3 Related 🎁 New Feature This is a new feature
Projects
None yet
Development

No branches or pull requests

3 participants