Feature request: Mass-conserving vertical regridding function

[yantosca]

Discussed in https://github.com/geoschem/gcpy/discussions/241

^{Originally posted by **pennelise** July 31, 2023} GCPy doesn't currently have a post-processing vertical regridding function. A mass conserving post-processing vertical regridding function for GEOS-Chem would be useful for: - Applying satellite averaging kernels in post-processing (for the IMI, we now apply almost all of our operators in post, but only TROPOMI currently has a post-processing operator) - Interpolating concentrations from 72 -> 47 levels in post - Comparing concentrations between two different models (is this something we do?) - Help users avoid common pitfalls which do not conserve mass (e.g., using np.interp) Hannah Nesser & I have developed python & FORTRAN code for mass-conserving vertical regridding based on the methodology in [Keppens et. al, 2019](https://doi.org/10.5194/amt-12-4379-2019), using code from Hannah's TROPOMI operator and my GOSAT + AIRS operators. Currently we are refactoring it for use as a general satellite observation operator, but we believe this code (or at least the vertical regridding portion) may belong in GCPy. [Here is a link to the draft repository. ](https://github.com/pennelise/satellite-operators) Here is a basic outline of the functionality: - Inputs: nobs x nedges for 1) satellite observations and 2) corresponding GEOS-Chem columns (requires GEOS-Chem LevelEdgeDiags output). - Outputs: GEOS-Chem concentrations interpolated to the satellite layer centers (nobs x nlayers) **or satellite layer edges** (nobs x nedges) - The code will be parallelized so it should be reasonably fast in Python as well as FORTRAN. Our questions: - Is this something that belongs in GCPy? - Is GCST interested in only the vertical regridding aspect, or also the satellite operator aspects (e.g., applying the pressure weighting + averaging kernel for individual satellites) - If so, at what stage of the project should we start developing off the GCPy codebase rather than a separate branch.

[yantosca]

Hi @pennelise and @hannahnesser. I think a vertical regridding capability would be a great addition to GCPy. I think it'd also be nice to have ability to apply the averaging kernels.

I guess we have a couple of options here.

1. We could open a branch off of dev in geoschem/gcpy and then have you add your changes there, then merge them into the develpment branch.
2. We could make your existing repository a submodule of GCPy,.. we would make a new folder that links to your repository. (Just like how HEMCO is a submodule of GEOS-Chem).

Either way is good, but I am probably leaning a bit towards the submodule approach...just for the fact that GCST's core competency is not really in averaging kernel manipulation. (Most of GCST's development in GCPy has been benchmarking related.) If people found bugs in your regridding/avg kernel code then it might be more appropriate for them to open an issue on your existing repository rather than on GCPy. I personally have never worked with averaging kernels so if I got an issue I would be at a loss how to fix it.

@msulprizio @lizziel: Thoughts?

[pennelise]

For 2) we were also concerned about maintenance - Hannah has just graduated and I'm in my 5th year, so I am not sure if we can maintain it (@hannahnesser, any thoughts?).

I think that the satellite operators will have more bugs than the vertical regridding (for example, when the products are updated). And as long as users can regrid, applying the AK is straightforward.

Would it make sense to separate the two functions: a) add the vertical regridding to GCPy and b) keep the satellite operators in a separate repository/submodule?

[yantosca]

I took a quick look at the original repo. Because it's just a few files maybe it could be brought into GCPy directly in a subdirectory.

[github-actions[bot]]

Stale issue message

[github-actions[bot]]

Stale issue message