search

xarray-contrib / xwrf

A lightweight interface for working with the Weather Research and Forecasting (WRF) model output in Xarray.
https://xwrf.readthedocs.io/
Apache License 2.0
56 stars 16 forks source link

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

Open thgeorgiou opened 1 month ago

thgeorgiou commented 1 month ago

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 commented 1 month ago

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?