"John" <[EMAIL PROTECTED]> wrote
> In all it's glory: I'm just a bit embarrassed because I'm sure it's > poor > coding: > Thats what we're here for... The first thing to note is that gridarea is here a function object. So are you assigning the function object to area[x,y]. Is that what you intend? > def gridarea(H): > """ returns an array of area corresponding to each nx,ny,nz > % input > % - H : Header dict object with nx, ny, nz > % output > % - Numpy array area corresponding to nx,ny,nz > """ > import math > import numpy as N It's traditional to put the imports outside the function, especially if they will always be called. > pih=math.pi/180. > r_earth=6.371e6 > cosfunc = lambda y : math.cos(y*pih)*r_earth You could use the more conventional def cosfunc(y): return math.cos(y*pih)*r_earth lambda is fine by me but some folks find them harder to read. > nz=H['nz'] > nx=H['nx'] > ny=H['ny'] > outlat0=H['outlat0'] > dyout=H['dyout'] > dxout=H['dxout'] > area=N.zeros((nx,ny)) #creates numpy array > > for iy in range(ny): > ylata=outlat0+(float(iy)+0.5)*dyout > ylatp=ylata+0.5*dyout > ylatm=ylata-0.5*dyout > if (ylatm<0 and ylatp>0): hzone=dyout*r_earth*pih > else: > cosfact=cosfunc(ylata) > cosfactp=cosfunc(ylatp) > cosfactm=cosfunc(ylatm) > if cosfactp < cosfactm: > hzone=math.sqrt(r_earth**2-cosfactp**2)-math.sqrt > (r_earth**2-cosfactm**2) > else: hzone=math.sqrt(r_earth**2-cosfactm**2)-math.sqrt > (r_earth**2-cosfactp**2) > More whitespace will help readability and avoid errors! please... > gridarea=2.*math.pi*r_earth*hzone*dxout/360. This is a bit iffy since you are creating a variable gridarea inside a function gridarea. That effectively removes the possibility of using recursion, although otherwise I don't *think* it should cause a problem in itself. > for ix in range(nx): > print nx, ix, iy > area[ix,iy]=gridarea And here looks like we have the dodgy line because you are assigning the internal variable not the function after all. So gridarea is actually the result of that big calculation. That is a float value and potentially big, I don't know. Did you try printing the value of gridarea in your debug trace? But that shouldn't cause the error since you aren't trying to convert it to an int. Very odd. iy is set in the loop up to ny. But how does it compare to the original ny parameter you passed to N.zeros at the top? Is this a numpy index error we are actually seeing? I don't know how numpy's zeros function works... I'm clutching at straws here... > return area #returns numpy array of area > Here's the traceback: > > ... > > 360 357 9 > 360 358 9 > 360 359 9 > 360 0 10 So this is where we loop all the way back to the outer loop and then start the second loop again.. Can you add gridarea and ny to the debug data? > OverflowError: long int too large to convert to int > Traceback: > File "<string>", line 1, in ? > File "c:\07\Programming\Python\mod_fp\getfp.py", line 11, in ? > H,fail=readheader(pathname,1,0) > File "c:\07\Programming\Python\mod_fp\mod_fp.py", line 170, in > readheader > H['area'] = gridarea(H) > File "c:\07\Programming\Python\mod_fp\mod_fp.py", line 332, in > gridarea > area[ix,iy]=gridarea Personally I'd change gridarea() to take the individiual parameters rather than the dictionary. There is a shortcut way of doing that using **kwords which means you canb pass the dictionary but the unpacking will be done for you by Python... But most of my comments are stylistic, I have no real idea whats going wrong here. Sorry. -- Alan Gauld Author of the Learn to Program web site http://www.freenetpages.co.uk/hp/alan.gauld _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
