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

division on loading loses grid #190

Closed
doutriaux1 opened this Issue Nov 8, 2017 · 18 comments

Comments

Projects
None yet
3 participants
@doutriaux1
Member

doutriaux1 commented Nov 8, 2017

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 doutriaux1 added this to the 3.0 milestone Nov 8, 2017

@doutriaux1

This comment has been minimized.

Member

doutriaux1 commented Nov 8, 2017

I'm using python3 here

@durack1

This comment has been minimized.

Member

durack1 commented Nov 8, 2017

@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

This comment has been minimized.

Member

doutriaux1 commented Nov 8, 2017

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

@doutriaux1

This comment has been minimized.

Member

doutriaux1 commented Nov 8, 2017

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

@durack1

This comment has been minimized.

Member

durack1 commented Nov 8, 2017

@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

This comment has been minimized.

Member

doutriaux1 commented Nov 8, 2017

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

@dnadeau4

This comment has been minimized.

Contributor

dnadeau4 commented Nov 15, 2017

 navy_frac=f("sftlf")/100.

works

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

works

@durack1

This comment has been minimized.

Member

durack1 commented Nov 15, 2017

@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

This comment has been minimized.

Contributor

dnadeau4 commented Nov 15, 2017

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

@dnadeau4

This comment has been minimized.

Contributor

dnadeau4 commented Nov 15, 2017

@durack1

This comment has been minimized.

Member

durack1 commented Nov 15, 2017

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

@dnadeau4

This comment has been minimized.

Contributor

dnadeau4 commented Nov 15, 2017

I could not reproduce this.

@dnadeau4

This comment has been minimized.

Contributor

dnadeau4 commented Nov 16, 2017

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

This comment has been minimized.

Member

durack1 commented Nov 16, 2017

@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

This comment has been minimized.

Contributor

dnadeau4 commented Nov 16, 2017

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

@durack1

This comment has been minimized.

Member

durack1 commented Nov 16, 2017

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

This comment has been minimized.

Member

durack1 commented Nov 16, 2017

@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

This comment has been minimized.

Contributor

dnadeau4 commented Nov 16, 2017

This was referenced Nov 16, 2017

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