Problem on PyGrads: Exchange array data between Python and GrADS

[Arlindo da Silva]

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/20080411/4c4f7fd7/attachment.html