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

Restore access to underlying datasource object #6725

Closed
bschroeter opened this issue Jun 25, 2022 · 3 comments
Closed

Restore access to underlying datasource object #6725

bschroeter opened this issue Jun 25, 2022 · 3 comments

Comments

@bschroeter
Copy link

Is your feature request related to a problem?

Prior to #4809 it was possible to access the underlying netcdf dataset behind the xarray.Dataset object, albeit by accessing private members.

As per https://stackoverflow.com/questions/42699765/access-to-a-datasets-netcdf4-dataset, this functionality was expected to disappear, and then did.

However, me like many WRF users are starting to use xarray and wrf-python for a lot of our work, which still requires the native netCDF4.Dataset object to access most of the routines.

Although it would be great if wrf-python simply operated on xarray.Dataset objects (there are plans to do so), but there are still several use cases where accessing the underlying datastore would be useful.

I've looked through the source code with a fine-tooth comb and I cannot for the life of me figure out where the native data store goes in the flow of logic in the load, likely it just disappears once loaded through xarray. Access to the encoding object reveals only a path to the source file, not the original source file object itself.

Describe the solution you'd like

It would be really great if there were the ability to access the underlying datastore object.

For example:

ds = xr.open_dataset('/path/to/file.nc')
nc = ds.source_obj

Or something similar, maybe a method if that is required.

Alternatively, if the encoding attribute still pointed at the original object (rather than a path) then that would work too.

I know this goes against the xarray goal of protecting the original source file, but I genuinely think it would increase the utility of the library to allow users more freedom in this respect. Surely there is a mode of opening the file that is truly read-only so that we can access the native object?

Describe alternatives you've considered

I've dug into the source code to find the source object, no success.

Working with wrf-python I load with netCDF4.Dataset then assemble my xarray.Dataset after extracting diagnostics, it is important to remember to close the original nc.Dataset if you're doing anything else down the line!

Other options include creating an in-memory Dataset object from the xarray.Dataset but it feels wrong to load through xarray only to create a netCDF4.Dataset from its contents.

Additional context

I am happy to implement this change if someone can point me at the underlying datastore in the code.

@kmuehlbauer
Copy link
Contributor

Related issue: #5175

@bschroeter
Copy link
Author

@kmuehlbauer, thanks for pointing me at that issue, that is exactly what I am looking for.

I could implement a change to access those private members to get to the original store, or do we want to explore a more elegant solution?

@dcherian
Copy link
Contributor

@bschroeter Can you add your use-case to the discussion in #5175 please? I'm closing this issue since it's a duplicate of that one.

Also see https://github.com/ncar-xdev/xwrf which is a more xarray-native WRF processing toolkit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants