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?