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

[MISC]: Split _wrf_grid_from_dataset in projection and grid parts, add to public API #175

Open
thgeorgiou opened this issue May 21, 2024 · 1 comment

Comments

@thgeorgiou
Copy link

thgeorgiou commented May 21, 2024

What is your issue?

Hello all!

In a recent project, I started by doing some preliminary post-processing of all my wrfout files (running them through xwrf, destaggering, removing some variables and computing some others, concatenating) and storing the intermediate files before continuing with my analysis. The WRF projection is helpfully added in the wrf_projection variable but that can't be stored in a netCDF file, so you have to drop it before writing your output.

ds = (
    xr.open_dataset(
        "/path/to/wrfout"
    )
    .xwrf.postprocess()
    .xwrf.destagger()
)

# Do some more processing...

# Write to netCDF
ds.drop_vars('wrf_projection').to_netcdf("/path/to/output")

At this point, if you open your file again, there is no point in running .xwrf.postprocess() because everything is ready. But you also don't have the proj object and you can't make it with xwrf._wrf_grid_from_dataset() since it tries to find the west_east/south_north dimensions for making the grid.

The proposal here is to split _wrf_grid_from_dataset() into two functions, one for creating the proj object (e.g. get_wrf_proj()) and one for creating the (x, y) grid _get_wrf_grid(). The first could be useful outside .xwrf.postprocess() so it would be nice for it to be part of the public API.

I would be happy to write a pull request about this but I didn't want to jump the gun since it adds stuff to the public API.

Thank you for your great work :)

@lpilz
Copy link
Collaborator

lpilz commented May 24, 2024

Hey @thgeorgiou,

thanks for the issue! We were already planning on splitting those two functionalities as part of refactor #173 so that's a great idea :)

As to what is supposed to be in the public API, we tried to keep it as simple as possible for now but tbh, I think we should reconsider adding some more stuff exactly for these kinds of usecases. I also had the problem a couple of weeks ago that I wanted to use some of the diagnostics calculations independently of .xwrf.postprocess() and that wasn't really possible.

What I would find interesting is to have all self-contained routines which are run as part of .xwrf.postprocess() be public-facing functions which you could also import and run on your own.

But maybe @jthielen or @mgrover1 also have some opinions on this?

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

2 participants