gatorglaciology / gstatsim Goto Github PK

Description:

The rounding proceture in the function make_grid(xmin, xmax, ymin, ymax, res) leads to a dimension mismatch when np.reshape is applied. More precisely, the rounding done for cols (rows) does not match the size of x (y) and hence xx (yy) does not have the dimension rows*cols.

Toy-Example:

xmax=30
xmin=10
ymax=30
ymin=10
res=80

prediction_grid_xy, cols, rows=make_grid(xmin, xmax, ymin, ymax, res)

Error:

ValueError: cannot reshape array of size 1 into shape (0,1)

Reproduce Error:

xmax=30
xmin=10
ymax=30
ymin=10
res=80

cols = np.rint((xmax - xmin)/res) 
rows = np.rint((ymax - ymin)/res)  
rows = rows.astype(int)
cols = cols.astype(int)
x = np.arange(xmin,xmax,res); y = np.arange(ymin,ymax,res)
xx, yy = np.meshgrid(x,y) 

print(cols*rows)
print(x.size*y.size)
print(xx.size)

Output:

0
1
1

So the error accures here:

x = np.reshape(xx, (int(rows)*int(cols), 1)) 
y = np.reshape(yy, (int(rows)*int(cols), 1))

Suggestion

Maybe define cols and rows like this:

cols = np.ceil((xmax - xmin)/res) 
rows = np.ceil((ymax - ymin)/res) 

I'm getting this error when running mplot2_std from plot_utils.py using my dataset. It looks like the value returned from prediction_grid does not match rows * cols. Here is the error: cannot reshape array of size 78952 into shape (278,283)

I'll try to dig into this to see if I can find the problem. I tried to delete this issue until I have more information but wasn't able to do that.

The first line in code block 3 of Notebook 9_cokriging_and_cosimulation_MM1.ipynb the line with ‘Data/greenland_surface_data.csv’ should be changed to ‘data/greenland_surface_data.csv’

Great resource by the way!

Hi guys,

With an upgrade of GStatSim from 1.0.4 to 1.0.6 the Gridding.prediction_grid seems to produce different output.

Within the SciKit-GStat unittests, I run a check very similar to the minimal example below:

import gstatsim as gs
gs.Gridding.prediction_grid(8, 481, 21, 487, 5).shape. 

In version 1.0.4 this returned (9024, 2), while in version 1.0.6 the result is (9120, 2).

Is this intentionally, was there a bug? Are you aware?
Could you give me some background on this issue, as I am actively working on the Gstatsim interface for SciKit-GStat again.

Best,

Mirko