[?? Probable Spam] Re: Problem on PyGrads: Exchange array data between Python and GrADS

[ph0007]

Hi, Arlindo

Thanks for your explanation. 

I have carried out sending 1 x 1 lat-lon GrADS variable to Python by setting a dummy 2 x 2 lat-lon dimensional environment and clipping in Python. Here is a my suggestion to change the name of function "exp" to "g2p" and "imp" to "p2g". These two names are maybe more easily to comprehend and memorize.

Though I use Python only a few days and have little understanding about such object-oriented programming language, I am glad to share my practical experience of PyGrADS with other PyGrADS users. Today, I have introduced the PyGrADS to others in my group.

What I am most interested in the to-be function of PyGrADS are more plot functions like GaLab.contourf and more statistical functions for analysis of climate variability like GaNum.eof.

Thanks for your excellent job.

Peter

2008-04-11 



发件人： Arlindo da Silva 
发送时间： 2008-04-11  19:23:09 
收件人： GRADSUSR at LIST.CINECA.IT 
抄送： 
主题： [?? Probable Spam] Re: Problem on PyGrads: Exchange array data between Python and GrADS 
 
On Fri, Apr 11, 2008 at 7:05 AM, $B2+J? (B <ph0007 at ustc.edu> wrote:

Hi, Arlindo

Thanks for your work on PyGrads. It is very useful.



I am glad it can be of some use.


Yet, I feel some restrictions on the exchanging array data between Python and GrADS. The only array data with nlon > 1 and nlat > 1 can be exchanged. Similarly, such data can be drawn via the GaLab. The slice data with nlon*nz, nlat*nz, nz*nt,...,ets and time index data are not supported. If the original data have more dimensions than nlon*nlat, this problem can be solved by slicing in Python and drawing via pylab. Or else, the PyGrADS will lose its unique role.


This particular restriction, that the x-y dimensions must be varying when exchanging data with python, is a development shortcut. Because of the particular way functions are executed in GrADS, exchanging x-z, y-z, x-t, y-t, z-t slices would require special handling if one is to retain symmetry of the import/export methods. (Exporting such slices from GrADS to Python would be much easier than importing into GrADS from Python.) In prioritizing development I decided to impose this restriction for now and concentrate on other aspects of the development. An overhaul of the IPC layer that manages this data exchange is in my TO DO list, but I was hoping to address it in the context of GrADS v2 when the E-dimension comes into play. 


Of course there are workarounds. You can always exchange a 2x2 lat-lon box with python, and then discard some of the points once the data has been exchanged. As I said, removing this restriction from the exp() method is more straightforward. We can always use a helping hand, if you or others with Python experience would like to contribute time to this development, just drop us a note at opengrads-devel at lists.sourceforge.net . One way people can contribute is to help with Wiki documentation and examples,



Do you have further plans for upgrading PyGrADS recently?



My immediate plans is to concentrate on making satellite imagery really easy to use, with transparent support for McIDAS AREA files and some basic kml support, so that people can tap on all the imagery that is freely available with minimum effort. Satellite imagery is a very powerful tool and something that can complement nicely all the other GrADS capabilities. (Why not implement this as a GrADS extension, you ask. Well, it is much easier to make quick progress in Python than C.)


  Thank you for you interest in PyGrADS. By far, it is still a work in progress. Jump in if you can and help us accelerate the progress.


   Arlindo

-- 
Arlindo da Silva
dasilva at alum.mit.edu 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20080412/7c75b938/attachment.html