GMTDataArrayAccessor doesn't work for temporary files that have been sliced #524
Comments
Good spotting, this won't be specific to just Lines 114 to 115 in f401f85 There's 2 solutions I can see:
Which would you prefer? Or is there a third way to resolve this? |
We probably don't want to maintain a list of temporary files.
It sounds a good way, but how to trigger it? BTW, at least we need to check if the netCDF source exists in GMTDataArrayAccessor. |
Simply by calling
Yes, the error message could be improved, will see how best to do this in the PR. |
Do you mean the following code? It's a little weird. |
|
I think just |
Perhaps we can add |
|
Ok, I'll try and do that tonight after dinner. |
|
Keep the issue open, since we don't really like the workaround. |
|
It still doesn't work for a slice of a grid. For example: In [1]: import pygmt
In [2]: grid = pygmt.grdcut("@earth_relief_01d", region="0/90/0/90")
In [3]: grid.gmt.registration
Out[3]: 1
In [4]: grid2 = grid[10:41,30:101]
In [5]: grid2
Out[5]:
<xarray.DataArray 'z' (lat: 31, lon: 60)>
array([[ 482. , 435. , 391.5, ..., -3402.5, -3340.5, -3281. ],
[ 731. , 571. , 393. , ..., -3303.5, -3228.5, -3176. ],
[ 543. , 490. , 395.5, ..., -3166.5, -3132. , -3066.5],
...,
[ 1312.5, 1136.5, 1058. , ..., 1514.5, 3121. , 3689.5],
[ 1104.5, 993.5, 1084.5, ..., 875.5, 815.5, 894.5],
[ 623. , 1156. , 1329. , ..., 861.5, 836. , 822. ]],
dtype=float32)
Coordinates:
* lon (lon) float64 30.5 31.5 32.5 33.5 34.5 ... 85.5 86.5 87.5 88.5 89.5
* lat (lat) float64 10.5 11.5 12.5 13.5 14.5 ... 36.5 37.5 38.5 39.5 40.5
Attributes:
long_name: elevation (m)
actual_range: [-5122. 5651.5]
In [6]: grid2.gmt.registration
grdinfo [ERROR]: File /var/folders/mz/d3wtwjtx4fg8qlds5lgt1c240000gn/T/pygmt-15alnpr7.nc was not found
grdinfo [ERROR]: Cannot find file /var/folders/mz/d3wtwjtx4fg8qlds5lgt1c240000gn/T/pygmt-15alnpr7.nc
grdinfo [ERROR]: Must specify one or more input files |
|
Can't say I didn't see this one coming. I'm tempted to go with Solution 2 "Don't delete the tempfile, maybe keep it somewhere while the session is still running." now, since there's no easy way for to transfer the registration/gtype info from the original Another option is to check explicitly if the |
|
The ultimate goal is to avoid temporary files. It's only possible if PyGMT supports GMT data types |
|
That's definitely a long term thing (for PyGMT > v0.3.0). Would need someone familiar with both Python and C I think, the new postdoc might the one to do it 😆 |
|
I'll need to do more investigation, but there's some discussion in Anyways, I think approving PR #873 and solving #870 is fine for now. But we'll see if users come up with problems down the line. |
weiji14
changed the title
|
Cross-referencing a related bug reported at https://forum.generic-mapping-tools.org/t/how-to-get-metadata-and-plot-grid-from-xarray-dataset/2010. In that case, an |
|
I ran into the following today when trying to use some data via OPeNDAP. The try/except strategy in the accessor leads to a successful figure, but gmt's error messages are confusing. If we are expecting the call to fail every once in a while and have a fall back, we could add Lines 30 to 39 in 951d30a time = '2011-01-20T18:00:00'
param = 'vwnd'
level = 250
ds = xr.open_dataset(f'https://www.esrl.noaa.gov/psd/thredds/dodsC/Datasets/ncep.reanalysis/pressure/{param}.{time[:4]}.nc').sel({'level': level, 'time': time})
fig = pygmt.Figure()
fig.grdimage(ds['vwnd'], frame=True, projection="H15c")
fig.show()Error messages: |
|
For xarray.DataArray objects, currently PyGMT relies on the output of the See what GMT does at It seems GMT has its own logic to detect a netCDF file's grid registration. I think PyGMT should follow the same logic. It would be easier if GMT can provide an API function for this. |
|
Re-read the posts above again. I feel the main point is that, in previous versions, any grd* operations rely on temporary files, and grdinfo can't find temporary files to determine gtype/registration. As tracked in #2730, most PyGMT functions/methods no longer use temporary files, so the issue can be closed. |
|
Ok, we can close after we edit the note that says slicing causes accessor info to be lost? |
Not yet. For tiled grids, currently the source encoding is None, so the accessor info is still lost, as shown below. I guess we need to have #3932 merged first, in which path to the first tile is stored in source encoding. Then we should be able to edit the note and close this PR. In [1]: from pygmt.datasets import load_earth_relief
In [2]: grid = load_earth_relief(resolution="01d", registration="pixel")
In [3]: grid.gmt.registration
Out[3]: <GridRegistration.PIXEL: 1>
In [4]: grid.gmt.gtype
Out[4]: <GridType.GEOGRAPHIC: 1>
In [5]: grid2 = grid[0:10, 0:10]
In [6]: grid2.gmt.registration
Out[6]: <GridRegistration.PIXEL: 1>
In [7]: grid2.gmt.gtype
Out[7]: <GridType.GEOGRAPHIC: 1>
In [8]: grid = load_earth_relief(resolution="05m", registration="pixel", region=[0,
...: 10, 0, 10])
In [9]: grid.gmt.gtype
Out[9]: <GridType.GEOGRAPHIC: 1>
In [10]: grid.gmt.registration
Out[10]: <GridRegistration.PIXEL: 1>
In [11]: grid2 = grid[0:10, 0:10]
In [12]: grid2.gmt.gtype
Out[12]: <GridType.CARTESIAN: 0>
In [13]: grid2.gmt.registration
Out[13]: <GridRegistration.GRIDLINE: 0> |
seisman
removed
help wanted
Description of the problem
It may be a GMTDataArrayAccessor bug, or maybe we should update
grdcut()to work with GMTDataArrayAccessor. The problem is that the temporary netCDF file is already deleted when GMTDataArrayAccessor tries to access it.Full code that generated the error
Full error message
System information
Please paste the output of
python -c "import pygmt; pygmt.show_versions()":The text was updated successfully, but these errors were encountered: