division on loading loses grid

[doutriaux1]

import cdms2, os, sys
f=cdms2.open(os.path.join(sys.prefix,"share","cdutil","navy_land.nc"))
navy_frac = f("sftlf")
navy_frac.getGrid()

gives

Grid has Python id 0x7f0b03574d68.
Gridtype: generic
Grid shape: (1080, 2160)
Order: yx

Also:

navy_frac = navy_frac / 100.
navy_frac.getGrid()

gives

Grid has Python id 0x7f0b03574d68.
Gridtype: generic
Grid shape: (1080, 2160)
Order: yx

But:

navy_frac = f("sftlf")/100.
navy_frac.getGrid()

gives

None

[doutriaux1]

I'm using python3 here

[durack1]

@doutriaux1 this is likely also true for many other operations (multiplication, ...) I think I generated a bug for this, or a similar behaviour in UV-CDAT sometime ago.. CDAT/cdat#1707 CDAT/cdat#1738 CDAT/cdutil#2

[doutriaux1]

@durack1 this works currently in python2 it's coming from the unit test. I think it's py3 conversion related.

[doutriaux1]

@dnadeau4 I'm on Linux here, will try mac later.

[durack1]

@doutriaux1 @dnadeau4 both issues (CDAT/cdat#1707 CDAT/cdat#1738) include code snippets that could be added in to the test to make sure that those issues are not propagating forward to CDMS3, or is it CDMS? It'd be great to clarify those issues are no longer a problem, and if they are fix them at the same time..

[doutriaux1]

@durack1 good point. @dnadeau4 can confirm these uv-cdat are not issues anymore? Thx.

[dnadeau4]

 navy_frac=f("sftlf")/100.

works

 navy_frac.getGrid()
Grid has Python id 0x7feed003cd50.
Gridtype: generic
Grid shape: (1080, 2160)
Order: yx

works

[durack1]

@dnadeau4 do similar things happen with the below:

so: (1, 27, 180, 360)
['time', 'LEVEL', 'LATITUDE', 'LONGITUDE']
so.squeeze()
so: (27, 180, 360)
['axis_0', 'axis_1', 'axis_2']

This refers to CDAT/cdat#1738

[dnadeau4]

Got it to work. numpy introduced 2 new multiplication truedivide and floordivide. This code was going into truedivide

[dnadeau4]

37b531e

[durack1]

@dnadeau4 so the .squeeze() now doesn't strip info?

[dnadeau4]

I could not reproduce this.

[dnadeau4]

Yes it does

import cdms2
import numpy
f=cdms2.open("/software/anaconda3/envs/cdms3/share/uvcdat/sample_data/so_Omon_ACCESS1-0_historical_r1i1p1_185001-185412_2timesteps.nc")
f.listvariables()
data=f('so')
data2=data.squeeze()
print "data axis list"
print [axis.id for axis in data.getAxisList()]
print "data2 axis list"
print [axis.id for axis in data2.getAxisList()]

output

data axis list
['time', 'lev', 'j', 'i']
data2 axis list
['axis_0', 'axis_1', 'axis_2', 'axis_3']

[durack1]

@dnadeau4 exactly, so it's still a problem.. The weird thing above is that the shape of the variable is likely [2,50,300,360] so .squeeze shouldn't do anything (there are no singleton dimensions)

[dnadeau4]

Numpy is messing it up by calling it's own squeeze.

[durack1]

Just for ref this there are open issues for the .squeeze issue at CDAT/cdat#1738, #41 and CDAT/cdutil#2 so when this is fixed you're killing 3 issues with a single fix - quite the haul!

[durack1]

@dnadeau4 FYI, if in the PR for the fix for this you include

Fix CDAT/cdat#1738
Fix #41
Fix CDAT/cdutil#2

In the PR comment, it'll close these issues when the PR is merged.. Pretty clean

[dnadeau4]

197aa46