opengrads-devel — OpenGrADS development issues, with focus on interfaces and extensions

[Opengrads-devel] New Extensions module

[Arlindo da S. <da...@al...>]

All,

  I have introduced a new convenience CVS module for working with the
opengrads extensions. The self contained "Extensions" module can be checked
out and built with these commands:

% gacvs co -P Extensions  (notice capital "E")
% cd Extensions
% make install

Except for building gxyat, all you need to have around is gcc, gfortrran and
GNU make in your path. No need to have GrADS or the supplibs around if all
you want to do is to work on extensions. (Do not worry if gxyat does not
build, you need cairo for that, and cairo is available with the supplibs, or
it may be available with your Linux distribution or on darwin ports/fink.)
However, make sure the Extensions version corresponds to the grads version
being used. You can always specify a tag when checking out with the -r
option. To see a list of available tags check out from the trunk as
indicated above and issue the "cvs stat" command:

% cd Extensions
% cvs stat -v GNUmakefile

This is particularly important when COLA introduces changes in the data
structures defined in "grads.h". I heard that a big change is due soon.
Perhaps Jennifer would like to give us the heads up about what is coming up.

     Arlindo

-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] FW: problem with basemap & my data arrays, gap around plot edge

[Arlindo da S. <da...@al...>]

Pablo,
  Sorry about the delay, but I think I fixed the basemap bug. Could you get
a fresh copy from the repo?

% gacvs co -P pygrads

Besides fixing the bug, I also made a couple of other updates. In
particular, you can now enter several commands at once, e.g,

   ga("""
           set lat 30 60
           set lon -80 -50
           set t 1 3
           query dims
       """)

The default binary is now "grads" (used to be gradshdf). I also made a
couple of adjustments on the ensemble dimension handling. BTW, I found a bug
in the v2.0 of ipc_load() which I just fixed in the repo; this only import
if using ga.imp().  Pygrads should now be 100% functional with GrADS v2.0.

Mike: now query("dims") always sets the e-diemension, even in v1.0, in which
case there is only 1 ensemble member.

Let me know if I broke something else.

    Arlindo


-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] GrADS v2 development moving to the trunk

[Arlindo da S. <da...@al...>]

All,
   The CVS repository reorganization is now completed. I've added the
following "news" to our sf.net site:

Posted By: dasilva
Date: 2009-04-26 22:03
Summary: CVS Repository reorganized; GrADS v2 now on TRUNK

Since the main development has now shifted to GrADS v2 we have replaced the
GrADS v1.x sources on the TRUNK with the sources previously on
GRADS2_DEV_BRANCH.

1) If you would like to to checkout the bleeding edge GrADS v2 sources (not
recommended, you must know what you are doing):

% gacvs co -P Grads

2) If you would like to to checkout the bleeding edge GrADS v1.10 sources
(not recommended, you must know what you are doing):

% gacvs co -r GRADS1_DEV_BRANCH Grads

If you have any questions, send a note to ope...@li....

-- 
Arlindo da Silva
da...@al...

[Opengrads-devel] GrADS v2 development moving to the trunk

[Arlindo da S. <da...@al...>]

All,
  Up to now we have been doing GrADS v2.0 development on particular CVS
branch:

         GRADS2_DEV_BRANCH

  Given that most of the opengrads development will now focus on grads v2,
it is about time for us to move this development to the TRUNK. Therefore,
during the weekend I'll place the current grads v1.10 sources on its own
branch:

        GRADS1_DEV_BRANCH

and move all the sources currently under GRADS2_DEV_BRANCH to the TRUNK and
retire the old GRADS2_DEV_BRANCH. If you have any code that you would like
to check in please do so at you earliest convenience.

 Let me know if you have any concerns about this change.

 Cheers!

    Arlindo


-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] Regrid-like frontend for re()

[Ben-Jei T. <bt...@gm...>]

Dear Arlindo:

Thank you for all the efforts.

2009/3/22 Arlindo da Silva <da...@al...>

> Mike,
>
>  You may be the best person to help me out with this. My goal is to
> have a wrapper function call regrid() which behaves much like Mike's
> classic regrid2() UDF. The starting point if the re() manual page:
>
>             http://opengrads.org/doc/udxt/re/
>
> Could you help me compile the difference in syntax between re() and
> regrid2(). Here is what I am aware of:
>
> 1) Shorthand syntax.
>
> d regrid2(expr,dlon)
> d regrid2(expr,dlon,dlat)
> d
> regrid2(expr,dlon,dlat,['ig',nyig],['ba'|'bl'|'bs'|'vt',vtmax,vtmin|'ma',min])
>
> These have equivalent syntax in re(), but the behavior is not the
> same: if the input grid is global and contains the pole, the output
> grid in re() does not include the poles (pole is now a gridbox edge),
> while in regrid2() the pole is the center of the gridbox (as in many
> of the standard lat/lon reanalysis grids these days).
>
> B.-J.: Is there a good reason why you chose to shift the global grids
> off the poles? Would it make sense to have re() nehave like regrid2()
> in this regard? (Same for the longitudinal grid).
>

I use ECHAM model frequenctly. The edges of the model output are at the
poles. This is part of the reason that I shift the global grids off the
poles. But of couse, the community can decide to change it since It always
be possible to assign the desired output using the ctl-like syntax. In fact,
I think that the community should not provide many regridding functions. It
will cause confusion for users.



>
> Keeping re() as it is, the regrid() wrapper would use the long-hand
> syntax to get the same rerid2() behavior:
>
> d regrid(expr,dlon) --> d
> re(expr,nlon,'linear',lon0,dlon,nlat,'linear',lat0,dlat,'ba')
>
> where
>
> lon0 = first longitude on the globe: prime-meridian
> nlon = 1 + (lonN - lon0)/dlon,  lonN = last longitude of input grid
>

I suggest lon0 should be centered at 0 degree E.


>
> dlat = dlon
> nlat = 1 + (latN - lat0)/dlat, lat0=90S, latN=90N
>
> Note: regrid2() appears to always use 'ba' as the interpolation
> method, while re() uses either 'ba' or 'bl' depending on whether you
> are from lower to higher resolution, or vice-versa.
>

Yes. I remember that re() uses such algorithms.

>
> Mike: could you confirm that this is indeed the behavior.
>
> 2) Long-hand
>
> I personally find the ctl-like syntax of re() much more intuitive than
> the original regrid2() general syntax:
>
> regrid(G1,X1,X2,C1,X3,X4,X5,X6)
>
> G1 = a GrADS grid expression (e.g., z or ave(z.3(t+0,t=120,1yr))
> X? = a float parameter
> C1 = character string parameter
>
> REQUIRED params:  G1, X1
>
> where:
>
>   G1     =  any valid GrADS grid expression
>   X1     =  delta longitude (dlon) or # of gaussian longitudes on the
>                GLOBE
>   X2     =  delta latitude (dlat) or # of gaussian latitudes on the GLOBE
>   C1     =  character option string
>   X3     =  special case options #1
>   X4     =  special case options #2
>   X5     =  special case options #3
>   X6     =  special case options #4
>
> The only reason for supporting the C1/X3-X6 parameters is to make it
> easier for current users of regrid2() to make the transition.
>
> Mike/B.-J.:  I'll write a simple wrapper that starts handling the
> short-hand; could one of you complete the long-hand?
>
>  Thank you,
>
>      Arlindo
>
> --
> Arlindo da Silva
> da...@al...
>



-- 
Ben-Jei Tsuang
Dept. of Environmental Engineering
National Chung-Hsing University

[Opengrads-devel] GrADS regridding: handling polar winds

[Arlindo da S. <da...@al...>]

All,

 As we look more closely into re() and compare it with the classic
regrid2() the issue of "polar corrections" came to the surface. As I
understand it, both re() and regrid2() currently apply a polar
correction which consists of replacing the polar values with a single
constant value equal to the average of the interpolated values.

Mike/BJ: please jump in if I am missing something.

Jennifer/Brian: how is this handled by linterp()?

Now, the current polar correction is fine for scalars like temperature
or wind speed that are unique at the poles. This is not true, however,
for the (u,v) wind components since the unit vectors change with
longitude.  There is a simple formula for this that can be derived by
writing the wind vector in cartesian coordinates at the poles and
imposing uniqueness of the wind velocity (I have code somewhere for
doing this.) The main point is that you need to have both u & v in
order to apply this correction.

On the same subject, let's digress a bit about polar interpolation...

Case 1: Input fields contain the poles
-----------------------------------------------

Now, when the input field include the poles, there is no latitudinal
interpolation taking place, only interpolation in longitude. Rather
then force u & v to be constant over the poles (this is really wrong,
messes up vorticity/divergence terribly), it is better to apply no
correction. This would work also for scalars: the input field would
have constant values over the pole, so there would be no interpolation
error in longitude.

The upshot: if the input grid contains the poles, apply no polar
correction whatsoever. One can always provide a polar correction
functions:

   ufixpole(u,v)
   vfixpole(u,v)

if you really would like the poles to be 100% consistent, say to
ensure that the wind speed is unique.

Case 2: input fields do not contain the poles, but output fields do
--------------------------------------------------------------------------------

Now, when the input fields DO NOT contain the poles (say, offset by
half delta-lat), but the *output* fields contain the pole, one should
resist the urge to extrapolate from lower latitudes.  We can still do
interpolation because the sphere is doubly periodic after all.  A
common technique is to use hemispheric continuation to find the wind
components at the other side of the poles. For example, if last
latitude is

   latJ = 90 - dLat/2

then linear interpolation would give us

u(90N,lon) =  ( u(latJ,lon) - u(latJ,lon+180) ) / 2
v(90N,lon) =  ( v(latJ,lon) - v(latJ,lon+180) ) / 2

(notice the minus sign once you cross the pole - this is needed
because the unit vectors change directions when you are looking from
the other side of the pole.) For a scalar one would have

  h(90N,lon) = ( h(latJ,lon) + h(latJ,lon+180) ) / 2.

(notice the plus sign in this case --- the are no unit vectors
involved here.) Similar formulas hold for the South Pole, and for
bessel interpolation with an additional point across the pole being
involved.)

Pole correction: you would need it here. But it may be better to
implement this separately because it is different for vectors and
scalars. The same ufixpole/vfixpole above would be applicable, and a
specific function for scalars.

Proposal
-----------

In retrospect, here is perhaps what would make more sense. We need 2
interpolation functions (or a single function with an optional
parameter selecting the desired behavior -- I lean towards presenting
the user with 2 separate function as it makes it very clear the 2
distinct cases):

   re_scalar(expr,...)
   re_vector(expr,...)

Now, the scalar version would always apply the pole correction (simply
replace the polar value with the average value as it is currently
done). The re_vector() function would apply no polar correction, and
functions

  ufixpole(u,v)
  vfixpole(u,v)

would be provided to fix the poles since it needs both u & v to do
this. A similar approach would apply to linterp() as well.

  Any comments/suggestions greatly appreciated.

    Arlindo

-- 
Arlindo da Silva
da...@al...

[Opengrads-devel] Regrid-like frontend for re()

[Arlindo da S. <da...@al...>]

Mike,

  You may be the best person to help me out with this. My goal is to
have a wrapper function call regrid() which behaves much like Mike's
classic regrid2() UDF. The starting point if the re() manual page:

             http://opengrads.org/doc/udxt/re/

Could you help me compile the difference in syntax between re() and
regrid2(). Here is what I am aware of:

1) Shorthand syntax.

d regrid2(expr,dlon)
d regrid2(expr,dlon,dlat)
d regrid2(expr,dlon,dlat,['ig',nyig],['ba'|'bl'|'bs'|'vt',vtmax,vtmin|'ma',min])

These have equivalent syntax in re(), but the behavior is not the
same: if the input grid is global and contains the pole, the output
grid in re() does not include the poles (pole is now a gridbox edge),
while in regrid2() the pole is the center of the gridbox (as in many
of the standard lat/lon reanalysis grids these days).

B.-J.: Is there a good reason why you chose to shift the global grids
off the poles? Would it make sense to have re() nehave like regrid2()
in this regard? (Same for the longitudinal grid).

Keeping re() as it is, the regrid() wrapper would use the long-hand
syntax to get the same rerid2() behavior:

d regrid(expr,dlon) --> d
re(expr,nlon,'linear',lon0,dlon,nlat,'linear',lat0,dlat,'ba')

where

lon0 = first longitude on the globe: prime-meridian
nlon = 1 + (lonN - lon0)/dlon,  lonN = last longitude of input grid

dlat = dlon
nlat = 1 + (latN - lat0)/dlat, lat0=90S, latN=90N

Note: regrid2() appears to always use 'ba' as the interpolation
method, while re() uses either 'ba' or 'bl' depending on whether you
are from lower to higher resolution, or vice-versa.

Mike: could you confirm that this is indeed the behavior.

2) Long-hand

I personally find the ctl-like syntax of re() much more intuitive than
the original regrid2() general syntax:

regrid(G1,X1,X2,C1,X3,X4,X5,X6)

G1 = a GrADS grid expression (e.g., z or ave(z.3(t+0,t=120,1yr))
X? = a float parameter
C1 = character string parameter

REQUIRED params:  G1, X1

where:

   G1     =  any valid GrADS grid expression
   X1     =  delta longitude (dlon) or # of gaussian longitudes on the
	        GLOBE
   X2     =  delta latitude (dlat) or # of gaussian latitudes on the GLOBE
   C1     =  character option string
   X3     =  special case options #1
   X4     =  special case options #2
   X5     =  special case options #3
   X6     =  special case options #4

The only reason for supporting the C1/X3-X6 parameters is to make it
easier for current users of regrid2() to make the transition.

Mike/B.-J.:  I'll write a simple wrapper that starts handling the
short-hand; could one of you complete the long-hand?

  Thank you,

      Arlindo

-- 
Arlindo da Silva
da...@al...

[Opengrads-devel] x86_64 portability

[Arlindo da S. <da...@al...>]

Jennifer,

  I am trying to get to the bottom of the portability (or lack thereof) of
grads binaries for x86_64. Some observations:

1) In my experience, binaries linked with g++ are more vulnerable than those
linked with plain gcc.

2) The gcc version used hardly matters provided it is gcc v3 or newer.

3) The libc/libstc++ version seems to to be the key issue.

4) In some cases, providing your own libstdc++ does the trick (if the one
required is older than what is on the system), but when you bring a new
libc/libstc++ to an older installation it lead to segmentation faults.

Do you agree with 1) -4)? Could you send me the version of the libc/gcc you
use for your x86_64 builds? Just enter:

% rpm -qa | grep glibc
% gcc --version

  Thank you,

         Arlindo

-- 
Arlindo da Silva
da...@al...

[Opengrads-devel] How to upload opengrads files to sf.net

[Arlindo da S. <da...@al...>]

All,

  This is in response to Jose, but some of the info could be of
general interest. Save it as a reference in case you need to upload
files to sourceforge in the future.

On Wed, Feb 25, 2009 at 3:03 PM, Jose F. Nieves <ni...@lt...> wrote:
> Arlindo
>
> Is this the correct output?
>

Perfect!

> - Not testing GrADS binary <../src/gradsdap>, file missing
>

This is OK, gradsdap is no longer built.

> test_01_Open (TestModelFile.grads_grb) ... ok
> test_02_Printim (TestModelFile.grads_grb) ... ok
> test_02_Prints (TestModelFile.grads_grb) ... ok
> test_03_Display (TestModelFile.grads_grb) ... ok
> test_04_Write_generic (TestModelFile.grads_grb) ... ok
> test_04_Write_mean (TestModelFile.grads_grb) ... ok
> test_04_Write_sequential (TestModelFile.grads_grb) ... ok
> test_04_Write_stream (TestModelFile.grads_grb) ... ok
> test_04_stats (TestModelFile.grads_grb) ... ok
> test_05_Read_sequential (TestModelFile.grads_grb) ... ok
> test_05_Read_stream (TestModelFile.grads_grb) ... ok
> test_01_Open (TestModelFile.grads_grb2) ... ok
> test_03_Display (TestModelFile.grads_grb2) ... ok
> test_01_Open (TestModelFile.grads_nc) ... ok
> test_02_Printim (TestModelFile.grads_nc) ... ok
> test_02_Prints (TestModelFile.grads_nc) ... ok
> test_03_Display (TestModelFile.grads_nc) ... ok
> test_04_Write_generic (TestModelFile.grads_nc) ... ok
> test_04_Write_mean (TestModelFile.grads_nc) ... ok
> test_04_Write_sequential (TestModelFile.grads_nc) ... ok
> test_04_Write_stream (TestModelFile.grads_nc) ... ok
> test_04_stats (TestModelFile.grads_nc) ... ok
> test_05_Read_sequential (TestModelFile.grads_nc) ... ok
> test_05_Read_stream (TestModelFile.grads_nc) ... ok
> test_01_Open (TestModelFile.grads_url) ... ok
> test_03_Display (TestModelFile.grads_url) ... ps ... ts ... 10000*pr ... ps ... ts ... 10000*pr ... ua ... va ... zg ... ta ... 1000*hus ... ua ... va ... zg ... ta ... 10000*hus ... ok

This is a new test for OPeNDAP gridded data. It worked!

> test_01_Open (TestModelFile.grads_stn) ... ok
> test_01_Stats (TestModelFile.grads_stn) ... slp ... ts ... us ... vs ... ok

This is a new test for OPeNDAP station data. Worked as well.

> test_01_Open (TestModelFile.grads_hdf) ... ok
> test_02_Printim (TestModelFile.grads_hdf) ... ok
> test_02_Prints (TestModelFile.grads_hdf) ... ok
> test_03_Display (TestModelFile.grads_hdf) ... ok
> test_04_Write_generic (TestModelFile.grads_hdf) ... ok
> test_04_Write_mean (TestModelFile.grads_hdf) ... ok
> test_04_Write_sequential (TestModelFile.grads_hdf) ... ok
> test_04_Write_stream (TestModelFile.grads_hdf) ... ok
> test_04_stats (TestModelFile.grads_hdf) ... ok
> test_05_Read_sequential (TestModelFile.grads_hdf) ... ok
> test_05_Read_stream (TestModelFile.grads_hdf) ... ok
> test_01_Open (TestModelFile.grads_pdef) ... ok
> test_03_Display (TestModelFile.grads_pdef) ... ok
>
> ----------------------------------------------------------------------
> Ran 41 tests in 132.386s
>
> OK
> Could NOT test 1 GrADS binaries:  ['../src/gradsdap']

This is expected, no more gradsdap.

> PASS: grads_tests.sh
> ==================
> All 1 tests passed
> ==================
>
>

Great! Next I'd suggest you create a bundle by hand and try it out:

% bundle/bundle_create.sh
% cd ./opengrads/Contents
% ./merra
% ./opengrads
ga-> @ open $GADSET/model
ga-> d sh_filt(ps,6)

If all is OK, from the top

% make bundle-dist

and upload it by sftp  to frs.sf.net:uploads/

% sftp frs.sf.net
% cd uploads
% put grads-2.......tar.gz

Have you used the file release system (FRS) before? Once you upload
the files, logon to sf.net with your user name and password and go to:

  https://sourceforge.net/project/admin/editreleases.php?package_id=305032&release_id=662661&group_id=161773

to move the grads2 tarball from the upload area to the actual download
area. Follow instructions for  steps 2 and 3. The URL above is only
for the grads2 tarball. For the supplibs tarballs you go to:

    https://sourceforge.net/project/admin/editreleases.php?package_id=241681&release_id=661716&group_id=161773

and do the same. More generally, the FRS front page is:

    https://sourceforge.net/project/admin/editpackages.php?group_id=161773

from which you cal choose whether to add or edit a release. The
releases have already been created in this case, and adding files to
an existing release is considered an 'edit'. Let me know if you have
questions about the FRS. They have on-line documentation as well.

   Thanks,

           Arlindo


-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] OpenGrADS Bundle based v2.0.a5

[Arlindo da S. <da...@al...>]

All,

   As I continue to test and get feedback I have once more refreshed
the sources and binaries on sf.net. If you are working from the CVS
repository, simply update. If you got binaries, get new ones. In
particular I revised the system shared libraries I am including in the
bundle. Except for gfortran which is placed in the LD_LIBRARY_PATH,
all the others are kept under libs in case they are missing from some
system. The reason is that these shared libraries may create conflict
where they are not needed. I have not touched the supplibs this time.

   Arlindo


On Sat, Feb 21, 2009 at 11:07 PM, Arlindo da Silva <da...@al...> wrote:
> All,
> I have started uploading to sf.net sources and binaries for the OpenGrADS
> Bundle based on COLA's 2.0.a5 release.
>
> https://sourceforge.net/project/showfiles.php?group_id=161773&package_id=305032&release_id=662661
>
> The OpenGrADS Bundle is described here:
>    http://opengrads.org/wiki/index.php?title=The_OpenGrADS_Bundle
>
> Before I announce this on gradsusr, could some of you try it out and give me
> some feedback? In particular try the executable "merra" which will start the
> GUI described in this recipe:
>
> http://cookbooks.opengrads.org/index.php?title=Recipe-016:_Accessing_MERRA_data_with_a_Graphical_User_Interface
>
> Start the executable *opengrads* which comes up with colorized text as in
> the attachment. I'll now turn to the windows build and the Mac native
> package/installer. Try the extensions which are documented here:
>     http://opengrads.org/doc/#udxt
>
> In particular the spherical harmonic filter:
>   d sh_filt(ps,10)
> gxyat, re, fish, env, etc should all work, but it could always use more
> testing.
> From the NEWS file:
> This version is based on COLA's 2.0.a5 release which includes
> support for GeoTIFF and KML, in addition to some bug fixes. See
> the ChangeLog for details.
> Several important OpenGrADS additions are available with this version:
> - grads is now built with NetCDF v4.0.1beta3 which includes support
>   for NetCDF-4/HDF-5 (similar to gradsnc4 in v1.9.0-rc1) and has
>   built in OPeNDAP support.
> - gradsdap is no longer provided as its functionality is now included
>   in the single executable *grads*.
> - this is the first release of the OpenGrADS Bundle, a relocatable,
>   minimum configuration package that has all that you need to run
>   GrADS. See INSTALL for additonal information.
> - we have introduced option -C to enable colorized text
> - preview release of the OpenGrADS Extensions; the same extensions
>   available in GrADS v1.9.0-rc1 are now available with GrADS v2.0.
>   Caveat: as COLA is yet to publish the official API for User Defined
>           functions in GrADS v2.0 we have adopted here an API that
>           is based on our work vith v1.9.0-rc1. This is a very low-level
>           API that is *not* endorsed by COLA. As such, it is *not*
> advisable
>           that users adopt this API to write their own extensions.
> - These extensions are still being fully tested. Please report any problems
>   you encounter. Use them at your own risk.
>
> - The following extensions are included:
>   User
>   Defined
>   COMMAND           Short Description                Function@Library
>  ---------- -----------------------------------  --------------------------
>  gsudf      Initialize gs-function package       c_gsudf@^gsudf.gex
>  printenv   Expand environment variables         c_xenv@^env.gex
>  runenv     Expand env vars and run command      c_env@^env.gex
>  @          Expand env vars and run command      c_env@^env.gex
>  getenv     Get value of environment variable    c_getenv@^env.gex
>  setenv     Set value of environment variable    c_setenv@^env.gex
>  gxyat      Save images in PNG/SVG/PDF/PS        c_gxyat@^gxyat.gex
>  hello      Hello, World! sample command         c_hello@^libhello.gex
>  ipc_verb   IPC verbose toggle                   c_Verb@^libipc.gex
>  ipc_open   Open stream for save/load            c_Open@^libipc.gex
>  ipc_close  Close stream                         c_Close@^libipc.gex
>  ipc_save   Save expression to stream            c_Save@^libipc.gex
>  ipc_define Define variable (obsolete)           c_Define@^libipc.gex
>  ipc_error  Print IPC error message              c_Error@^libipc.gex
>  mfhilo     Find max/min or H/L in 2D field      c_mfhilo@^libmf.gex
>  cylprms    Properties relative to lon/lat       c_cylprms@^libmf.gex
>  shp_lines  Draw lines    from shapefile         c_lines@^shape.gex
>  shp_polyf  Draw polygons from shapefile         c_polyf@^shape.gex
>  ---------- -----------------------------------  --------------------------
>    User
>   Defined
>   FUNCTION          Short Description                Function@Library
>  ---------- -----------------------------------  --------------------------
>  speed      Wind-speed (sample gs-function)      f_gsudf@^gsudf.gex
>  lt         Less than operator                   f_bjt@^libbjt.gex
>  jd         Julian day                           f_bjt@^libbjt.gex
>  cosz       Cosine solar zenith angle            f_bjt@^libbjt.gex
>  dayratio   Daylight ratio                       f_bjt@^libbjt.gex
>  if         Conditional function                 f_bjt@^libbjt.gex
>  maxv       Maximum value                        f_bjt@^libbjt.gex
>  minv       Minimum value                        f_bjt@^libbjt.gex
>  which      Label gridpoints                     f_bjt@^libbjt.gex
>  ftest      F-test                               f_bjt@^libbjt.gex
>  ttest      T-test                               f_bjt@^libbjt.gex
>  tfit       Point  linear regression             f_bjt@^libbjt.gex
>  fit        Global linear regression             f_bjt@^libbjt.gex
>  tcorr2     Time correlation                     f_bjt@^libbjt.gex
>  tregr2     Point linear regression              f_bjt@^libbjt.gex
>  tmave2     Time averaging w/masking             f_bjt@^libbjt.gex
>  madvu      Calculates -d(u*EXPR)/dx             f_bjt@^libbjt.gex
>  madvv      Calculates -d(V*EXPR)/dy             f_bjt@^libbjt.gex
>  madvw      Calculates -d(W*EXPR)/dp             f_bjt@^libbjt.gex
>  muadv      Zonal advection                      f_bjt@^libbjt.gex
>  mvadv      Meridional advection                 f_bjt@^libbjt.gex
>  mwadv      Vertical advection                   f_bjt@^libbjt.gex
>  satvap     Saturated vapor pressure             f_bjt@^libbjt.gex
>  dew        Dew point temperature                f_bjt@^libbjt.gex
>  lw         Thermal infrared fluxes              f_bjt@^libbjt.gex
>  lw2        Thermal infrared fluxes v2           f_bjt@^libbjt.gex
>  pinterp    Pressure interpolation               f_bjt@^libbjt.gex
>  zinterp    Height interpolation                 f_bjt@^libbjt.gex
>  line       Draws a line                         f_bjt@^libbjt.gex
>  vint2      Mass-weighted vertical integral      f_bjt@^libbjt.gex
>  fish       Poisson solver                       f_fish@^fish.gex
>  fish_psi   Compute streamfunction               f_psichi@^fish.gex
>  fish_chi   Compute velocity potential           f_psichi@^fish.gex
>  fish_vor   Compute vorticity                    f_psichi@^fish.gex
>  fish_div   Compute divergence                   f_psichi@^fish.gex
>  hello      Hello, World! sample function        f_hello@^libhello.gex
>  ipc_save   Save expression to stream            f_Save@^libipc.gex
>  ipc_load   Load variable from file              f_Load@^libipc.gex
>  smth2d     Shuman smoother/de-smoother          f_smth2d@^libmf.gex
>  uv2trw     Find radial/tangential velocity      f_uv2trw@^libmf.gex
>  re         General interpolator                 ffre@^re.gex
>  sh_filt    Spherical harmonic filter            f_shfilt@^shfilt.gex
>  sh_power   Spherical harmonic spectra           f_shpowr@^shfilt.gex
>  ---------- -----------------------------------  --------------------------
>
> Building it
> ------------
> To build it, get pre-compiled (or build it yourself) supplibs-2.1.0 from
> https://sourceforge.net/project/showfiles.php?group_id=161773&package_id=241681&release_id=661716
>
>
>
> % gacvs co -P Grads
> % make
> % make check
> % bundle/bundle_create.sh
> Then
> % cd opengrads/
> and take a look ar README and INSTALL. Try this:
> % cd opengrads/Contents
> % ./merra
> To make a distribution tarball with the bundle
>
> % make bundle-dist
>   Let me know if you have problems.
>
>         Arlindo
> --
> Arlindo da Silva
> da...@al...
>



-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] OpenGrADS Bundle based v2.0.a5

[Arlindo da S. <da...@al...>]

On Mon, Feb 23, 2009 at 7:42 AM, Brian Doty <do...@co...> wrote:
>
> There is a major change to the gagrid structure coming soon; we will finalize the "udf" interface then.
>
> Please note that none of the internals of grads are maintained as external interfaces or callable libraries, etc.  For this reason, any code that calls back into grads or uses the grads include files (ie, grads.h) is, in my viewpoint, BEST MAINTAINED AS A SOURCE MOD. This makes it clear the code must be recompiled when new releases of grads come out, and makes it clear that different versions have to be maintained for different versions of grads.
>
> udf's will have their own include files and, where needed, supported call-back entry points.  udf's that use these interfaces will be much easier to maintain and support going forward... Brian

We are at the same page, this is very consistent with the interface
proposal I sent you a few weeks ago. For the benefit of the
opengrads-devel folks, here is the proposal.

  http://opengrads.org/wiki/index.php?title=User_Defined_Extensions_in_GrADS_v2.0

Based on the discussion we had in our last face-to-face meeting I
incorporated the notion of "API Levels" in the OpenGrADS User Defined
Extension (UDX) implementation. Level 0 is the lowest level and the
extension functions in there share the same signature as the built-in
GrADS functions, while the Level 1 API is along the lines you you
describe: independent of the grads non-public internals. Therefore,
Level 0 UDFs are *always* bound to a particular version of GrADS. For
this reason, I am no longer distributing these as separate packages,
but always in the context of a full grads source tree. They are still
extensions n the sense that they are deployed by a UDX gateway called
from gauser.c/gafunc.c (just a couple of lines in each), this way
making much easier for us to catch up with each new COLA release of
GrADS. Really, they are add-ons to whatever COLA puts out. The goal is
to retain 100% compatibility with COLA releases. So we are not
modifying grads (behavior) but extending it --- this is the whole
point of the OpenGrADS effort.

Given all the maintainability risk of Level 0 UDFs there is one
positive characteristic, though. Since the signature is the same as
the built-in grads functions, it is trivial to turn any Level 0 UDF
into a grads intrinsic function as my recent re() experience
demonstrated. Therefore, the Level 0 API  provides a framework for
experimenting with new functions being proposed for GrADS and also a
mechanism for people to write variations of the functions already
built in GrADS --- enhancements that later could be submitted to COLA
for inclusion in the main codebase.

  I look for forward to COLA's  Level 1 API.

  Cheers!

      Arlindo


>
> On Feb 21, 2009, at 11:07 PM, Arlindo da Silva wrote:
>
>> All,
>>
>> I have started uploading to sf.net sources and binaries for the OpenGrADS Bundle based on COLA's 2.0.a5 release.
>>
>>   https://sourceforge.net/project/showfiles.php?group_id=161773&package_id=305032&release_id=662661
>>
>> The OpenGrADS Bundle is described here:
>>
>>   http://opengrads.org/wiki/index.php?title=The_OpenGrADS_Bundle
>>
>> Before I announce this on gradsusr, could some of you try it out and give me some feedback? In particular try the executable "merra" which will start the GUI described in this recipe:
>>
>> http://cookbooks.opengrads.org/index.php?title=Recipe-016:_Accessing_MERRA_data_with_a_Graphical_User_Interface
>>
>> Start the executable *opengrads* which comes up with colorized text as in the attachment. I'll now turn to the windows build and the Mac native package/installer. Try the extensions which are documented here:
>>
>>    http://opengrads.org/doc/#udxt
>>
>> In particular the spherical harmonic filter:
>>
>>  d sh_filt(ps,10)
>>
>> gxyat, re, fish, env, etc should all work, but it could always use more testing.
>>
>> From the NEWS file:
>>
>> This version is based on COLA's 2.0.a5 release which includes
>> support for GeoTIFF and KML, in addition to some bug fixes. See
>> the ChangeLog for details.
>>
>> Several important OpenGrADS additions are available with this version:
>>
>> - grads is now built with NetCDF v4.0.1beta3 which includes support
>>  for NetCDF-4/HDF-5 (similar to gradsnc4 in v1.9.0-rc1) and has
>>  built in OPeNDAP support.
>>
>> - gradsdap is no longer provided as its functionality is now included
>>  in the single executable *grads*.
>>
>> - this is the first release of the OpenGrADS Bundle, a relocatable,
>>  minimum configuration package that has all that you need to run
>>  GrADS. See INSTALL for additonal information.
>>
>> - we have introduced option -C to enable colorized text
>>
>> - preview release of the OpenGrADS Extensions; the same extensions
>>  available in GrADS v1.9.0-rc1 are now available with GrADS v2.0.
>>
>>  Caveat: as COLA is yet to publish the official API for User Defined
>>          functions in GrADS v2.0 we have adopted here an API that
>>          is based on our work vith v1.9.0-rc1. This is a very low-level
>>          API that is *not* endorsed by COLA. As such, it is *not* advisable
>>          that users adopt this API to write their own extensions.
>>
>> - These extensions are still being fully tested. Please report any problems
>>  you encounter. Use them at your own risk.
>>
>> - The following extensions are included:
>>
>>  User
>>  Defined
>>  COMMAND           Short Description                Function@Library
>>  ---------- -----------------------------------  --------------------------
>>  gsudf      Initialize gs-function package       c_gsudf@^gsudf.gex
>>  printenv   Expand environment variables         c_xenv@^env.gex
>>  runenv     Expand env vars and run command      c_env@^env.gex
>>  @          Expand env vars and run command      c_env@^env.gex
>>  getenv     Get value of environment variable    c_getenv@^env.gex
>>  setenv     Set value of environment variable    c_setenv@^env.gex
>>  gxyat      Save images in PNG/SVG/PDF/PS        c_gxyat@^gxyat.gex
>>  hello      Hello, World! sample command         c_hello@^libhello.gex
>>  ipc_verb   IPC verbose toggle                   c_Verb@^libipc.gex
>>  ipc_open   Open stream for save/load            c_Open@^libipc.gex
>>  ipc_close  Close stream                         c_Close@^libipc.gex
>>  ipc_save   Save expression to stream            c_Save@^libipc.gex
>>  ipc_define Define variable (obsolete)           c_Define@^libipc.gex
>>  ipc_error  Print IPC error message              c_Error@^libipc.gex
>>  mfhilo     Find max/min or H/L in 2D field      c_mfhilo@^libmf.gex
>>  cylprms    Properties relative to lon/lat       c_cylprms@^libmf.gex
>>  shp_lines  Draw lines    from shapefile         c_lines@^shape.gex
>>  shp_polyf  Draw polygons from shapefile         c_polyf@^shape.gex
>>  ---------- -----------------------------------  --------------------------
>>
>>   User
>>  Defined
>>  FUNCTION          Short Description                Function@Library
>>  ---------- -----------------------------------  --------------------------
>>  speed      Wind-speed (sample gs-function)      f_gsudf@^gsudf.gex
>>  lt         Less than operator                   f_bjt@^libbjt.gex
>>  jd         Julian day                           f_bjt@^libbjt.gex
>>  cosz       Cosine solar zenith angle            f_bjt@^libbjt.gex
>>  dayratio   Daylight ratio                       f_bjt@^libbjt.gex
>>  if         Conditional function                 f_bjt@^libbjt.gex
>>  maxv       Maximum value                        f_bjt@^libbjt.gex
>>  minv       Minimum value                        f_bjt@^libbjt.gex
>>  which      Label gridpoints                     f_bjt@^libbjt.gex
>>  ftest      F-test                               f_bjt@^libbjt.gex
>>  ttest      T-test                               f_bjt@^libbjt.gex
>>  tfit       Point  linear regression             f_bjt@^libbjt.gex
>>  fit        Global linear regression             f_bjt@^libbjt.gex
>>  tcorr2     Time correlation                     f_bjt@^libbjt.gex
>>  tregr2     Point linear regression              f_bjt@^libbjt.gex
>>  tmave2     Time averaging w/masking             f_bjt@^libbjt.gex
>>  madvu      Calculates -d(u*EXPR)/dx             f_bjt@^libbjt.gex
>>  madvv      Calculates -d(V*EXPR)/dy             f_bjt@^libbjt.gex
>>  madvw      Calculates -d(W*EXPR)/dp             f_bjt@^libbjt.gex
>>  muadv      Zonal advection                      f_bjt@^libbjt.gex
>>  mvadv      Meridional advection                 f_bjt@^libbjt.gex
>>  mwadv      Vertical advection                   f_bjt@^libbjt.gex
>>  satvap     Saturated vapor pressure             f_bjt@^libbjt.gex
>>  dew        Dew point temperature                f_bjt@^libbjt.gex
>>  lw         Thermal infrared fluxes              f_bjt@^libbjt.gex
>>  lw2        Thermal infrared fluxes v2           f_bjt@^libbjt.gex
>>  pinterp    Pressure interpolation               f_bjt@^libbjt.gex
>>  zinterp    Height interpolation                 f_bjt@^libbjt.gex
>>  line       Draws a line                         f_bjt@^libbjt.gex
>>  vint2      Mass-weighted vertical integral      f_bjt@^libbjt.gex
>>  fish       Poisson solver                       f_fish@^fish.gex
>>  fish_psi   Compute streamfunction               f_psichi@^fish.gex
>>  fish_chi   Compute velocity potential           f_psichi@^fish.gex
>>  fish_vor   Compute vorticity                    f_psichi@^fish.gex
>>  fish_div   Compute divergence                   f_psichi@^fish.gex
>>  hello      Hello, World! sample function        f_hello@^libhello.gex
>>  ipc_save   Save expression to stream            f_Save@^libipc.gex
>>  ipc_load   Load variable from file              f_Load@^libipc.gex
>>  smth2d     Shuman smoother/de-smoother          f_smth2d@^libmf.gex
>>  uv2trw     Find radial/tangential velocity      f_uv2trw@^libmf.gex
>>  re         General interpolator                 ffre@^re.gex
>>  sh_filt    Spherical harmonic filter            f_shfilt@^shfilt.gex
>>  sh_power   Spherical harmonic spectra           f_shpowr@^shfilt.gex
>>  ---------- -----------------------------------  --------------------------
>>
>>
>> Building it
>> ------------
>>
>> To build it, get pre-compiled (or build it yourself) supplibs-2.1.0 from
>>
>> https://sourceforge.net/project/showfiles.php?group_id=161773&package_id=241681&release_id=661716
>>
>>
>>
>> % gacvs co -P Grads
>> % make
>> % make check
>> % bundle/bundle_create.sh
>>
>> Then
>>
>> % cd opengrads/
>>
>> and take a look ar README and INSTALL. Try this:
>>
>> % cd opengrads/Contents
>> % ./merra
>>
>> To make a distribution tarball with the bundle
>>
>> % make bundle-dist
>>
>>  Let me know if you have problems.
>>
>>        Arlindo
>>
>> --
>> Arlindo da Silva
>> da...@al...
>> <colorized.tiff>
>



--
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] OpenGrADS Bundle based v2.0.a5

[Brian D. <do...@co...>]

There is a major change to the gagrid structure coming soon; we will  
finalize the "udf" interface then.

Please note that none of the internals of grads are maintained as  
external interfaces or callable libraries, etc.  For this reason, any  
code that calls back into grads or uses the grads include files (ie,  
grads.h) is, in my viewpoint, BEST MAINTAINED AS A SOURCE MOD. This  
makes it clear the code must be recompiled when new releases of grads  
come out, and makes it clear that different versions have to be  
maintained for different versions of grads.

udf's will have their own include files and, where needed, supported  
call-back entry points.  udf's that use these interfaces will be much  
easier to maintain and support going forward... Brian

On Feb 21, 2009, at 11:07 PM, Arlindo da Silva wrote:

> All,
>
> I have started uploading to sf.net sources and binaries for the  
> OpenGrADS Bundle based on COLA's 2.0.a5 release.
>
>    https://sourceforge.net/project/showfiles.php? 
> group_id=161773&package_id=305032&release_id=662661
>
> The OpenGrADS Bundle is described here:
>
>    http://opengrads.org/wiki/index.php?title=The_OpenGrADS_Bundle
>
> Before I announce this on gradsusr, could some of you try it out  
> and give me some feedback? In particular try the executable "merra"  
> which will start the GUI described in this recipe:
>
> http://cookbooks.opengrads.org/index.php? 
> title=Recipe-016:_Accessing_MERRA_data_with_a_Graphical_User_Interface
>
> Start the executable *opengrads* which comes up with colorized text  
> as in the attachment. I'll now turn to the windows build and the  
> Mac native package/installer. Try the extensions which are  
> documented here:
>
>     http://opengrads.org/doc/#udxt
>
> In particular the spherical harmonic filter:
>
>   d sh_filt(ps,10)
>
> gxyat, re, fish, env, etc should all work, but it could always use  
> more testing.
>
> From the NEWS file:
>
> This version is based on COLA's 2.0.a5 release which includes
> support for GeoTIFF and KML, in addition to some bug fixes. See
> the ChangeLog for details.
>
> Several important OpenGrADS additions are available with this version:
>
> - grads is now built with NetCDF v4.0.1beta3 which includes support
>   for NetCDF-4/HDF-5 (similar to gradsnc4 in v1.9.0-rc1) and has
>   built in OPeNDAP support.
>
> - gradsdap is no longer provided as its functionality is now included
>   in the single executable *grads*.
>
> - this is the first release of the OpenGrADS Bundle, a relocatable,
>   minimum configuration package that has all that you need to run
>   GrADS. See INSTALL for additonal information.
>
> - we have introduced option -C to enable colorized text
>
> - preview release of the OpenGrADS Extensions; the same extensions
>   available in GrADS v1.9.0-rc1 are now available with GrADS v2.0.
>
>   Caveat: as COLA is yet to publish the official API for User Defined
>           functions in GrADS v2.0 we have adopted here an API that
>           is based on our work vith v1.9.0-rc1. This is a very low- 
> level
>           API that is *not* endorsed by COLA. As such, it is *not*  
> advisable
>           that users adopt this API to write their own extensions.
>
> - These extensions are still being fully tested. Please report any  
> problems
>   you encounter. Use them at your own risk.
>
> - The following extensions are included:
>
>   User
>   Defined
>   COMMAND           Short Description                Function@Library
>  ---------- -----------------------------------   
> --------------------------
>  gsudf      Initialize gs-function package       c_gsudf@^gsudf.gex
>  printenv   Expand environment variables         c_xenv@^env.gex
>  runenv     Expand env vars and run command      c_env@^env.gex
>  @          Expand env vars and run command      c_env@^env.gex
>  getenv     Get value of environment variable    c_getenv@^env.gex
>  setenv     Set value of environment variable    c_setenv@^env.gex
>  gxyat      Save images in PNG/SVG/PDF/PS        c_gxyat@^gxyat.gex
>  hello      Hello, World! sample command         c_hello@^libhello.gex
>  ipc_verb   IPC verbose toggle                   c_Verb@^libipc.gex
>  ipc_open   Open stream for save/load            c_Open@^libipc.gex
>  ipc_close  Close stream                         c_Close@^libipc.gex
>  ipc_save   Save expression to stream            c_Save@^libipc.gex
>  ipc_define Define variable (obsolete)           c_Define@^libipc.gex
>  ipc_error  Print IPC error message              c_Error@^libipc.gex
>  mfhilo     Find max/min or H/L in 2D field      c_mfhilo@^libmf.gex
>  cylprms    Properties relative to lon/lat       c_cylprms@^libmf.gex
>  shp_lines  Draw lines    from shapefile         c_lines@^shape.gex
>  shp_polyf  Draw polygons from shapefile         c_polyf@^shape.gex
>  ---------- -----------------------------------   
> --------------------------
>
>    User
>   Defined
>   FUNCTION          Short Description                Function@Library
>  ---------- -----------------------------------   
> --------------------------
>  speed      Wind-speed (sample gs-function)      f_gsudf@^gsudf.gex
>  lt         Less than operator                   f_bjt@^libbjt.gex
>  jd         Julian day                           f_bjt@^libbjt.gex
>  cosz       Cosine solar zenith angle            f_bjt@^libbjt.gex
>  dayratio   Daylight ratio                       f_bjt@^libbjt.gex
>  if         Conditional function                 f_bjt@^libbjt.gex
>  maxv       Maximum value                        f_bjt@^libbjt.gex
>  minv       Minimum value                        f_bjt@^libbjt.gex
>  which      Label gridpoints                     f_bjt@^libbjt.gex
>  ftest      F-test                               f_bjt@^libbjt.gex
>  ttest      T-test                               f_bjt@^libbjt.gex
>  tfit       Point  linear regression             f_bjt@^libbjt.gex
>  fit        Global linear regression             f_bjt@^libbjt.gex
>  tcorr2     Time correlation                     f_bjt@^libbjt.gex
>  tregr2     Point linear regression              f_bjt@^libbjt.gex
>  tmave2     Time averaging w/masking             f_bjt@^libbjt.gex
>  madvu      Calculates -d(u*EXPR)/dx             f_bjt@^libbjt.gex
>  madvv      Calculates -d(V*EXPR)/dy             f_bjt@^libbjt.gex
>  madvw      Calculates -d(W*EXPR)/dp             f_bjt@^libbjt.gex
>  muadv      Zonal advection                      f_bjt@^libbjt.gex
>  mvadv      Meridional advection                 f_bjt@^libbjt.gex
>  mwadv      Vertical advection                   f_bjt@^libbjt.gex
>  satvap     Saturated vapor pressure             f_bjt@^libbjt.gex
>  dew        Dew point temperature                f_bjt@^libbjt.gex
>  lw         Thermal infrared fluxes              f_bjt@^libbjt.gex
>  lw2        Thermal infrared fluxes v2           f_bjt@^libbjt.gex
>  pinterp    Pressure interpolation               f_bjt@^libbjt.gex
>  zinterp    Height interpolation                 f_bjt@^libbjt.gex
>  line       Draws a line                         f_bjt@^libbjt.gex
>  vint2      Mass-weighted vertical integral      f_bjt@^libbjt.gex
>  fish       Poisson solver                       f_fish@^fish.gex
>  fish_psi   Compute streamfunction               f_psichi@^fish.gex
>  fish_chi   Compute velocity potential           f_psichi@^fish.gex
>  fish_vor   Compute vorticity                    f_psichi@^fish.gex
>  fish_div   Compute divergence                   f_psichi@^fish.gex
>  hello      Hello, World! sample function        f_hello@^libhello.gex
>  ipc_save   Save expression to stream            f_Save@^libipc.gex
>  ipc_load   Load variable from file              f_Load@^libipc.gex
>  smth2d     Shuman smoother/de-smoother          f_smth2d@^libmf.gex
>  uv2trw     Find radial/tangential velocity      f_uv2trw@^libmf.gex
>  re         General interpolator                 ffre@^re.gex
>  sh_filt    Spherical harmonic filter            f_shfilt@^shfilt.gex
>  sh_power   Spherical harmonic spectra           f_shpowr@^shfilt.gex
>  ---------- -----------------------------------   
> --------------------------
>
>
> Building it
> ------------
>
> To build it, get pre-compiled (or build it yourself) supplibs-2.1.0  
> from
>
> https://sourceforge.net/project/showfiles.php? 
> group_id=161773&package_id=241681&release_id=661716
>
>
>
> % gacvs co -P Grads
> % make
> % make check
> % bundle/bundle_create.sh
>
> Then
>
> % cd opengrads/
>
> and take a look ar README and INSTALL. Try this:
>
> % cd opengrads/Contents
> % ./merra
>
> To make a distribution tarball with the bundle
>
> % make bundle-dist
>
>   Let me know if you have problems.
>
>         Arlindo
>
> -- 
> Arlindo da Silva
> da...@al...
> <colorized.tiff>

[Opengrads-devel] Supplibs-2.1.0 refreshed

[Arlindo da S. <da...@al...>]

All,
  I have refreshed both binaries and sources for the supplibs-2.1.0 on
sf.net:

https://sourceforge.net/project/showfiles.php?group_id=161773&package_id=241681&release_id=661716

 In particular I added freebsd binaries and made several adjustments, mostly
by including -fPIC all over and some adjustments around cairo.

 If you are intending to build by all means checkout from the CVS repo, do
not use the sources that I just posted. This way you will be able to easily
update when other patches are committed, and most importantly, you will be
able to check in your own patches.

 Let me know if you have questions.

    Arlindo

-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] New release GrADS version 2.0.a5

[Arlindo da S. <da...@al...>]

On Wed, Feb 18, 2009 at 12:58 PM, Jose F. Nieves <ni...@lt...>wrote:

> Arlindo
>
> I compiled the supplibs on Freebsd-7.0-i386. At the end I get
>
> -------+---------+--------------
> Config | Install |   Package
> -------+---------+--------------
>  ok   |   ok    | pkg-config
>  ok   |   --    | udunits
>  ok   |   ok    | zlib
>  ok   |   ok    | szlib
>  ok   |   ok    | libpng
>  ok   |   ok    | jpeg
>  ok   |   ok    | jasper
>  ok   |   ok    | tiff
>  ok   |   --    | geotiff
>  ok   |   ok    | gd
>  ok   |   ok    | hdf4
>  ok   |   ok    | grib2c
>  ok   |   ok    | xml2
>  ok   |   ok    | curl
>  ok   |   --    | dap
>  --   |   --    | gadap
>  ok   |   --    | hdf5
>  --   |   --    | netcdf
>  ok   |   --    | ncurses
>  ok   |   ok    | readline
>  ok   |   ok    | libsx
>  ok   |   ok    | fontconfig
>  --   |   --    | freetype
>  ok   |   ok    | pixman
>  --   |   --    | cairo
>  ok   |   ok    | shp
>
> I don't understand it completely. For example, the "Install" column
> would appear to indicate the udunits and geotiff were not installed,
> but I checked in
>
>    i386-unknown-freebsd7.0/lib/
>
> and they are there. What is the correct interpretation of these columns?
>
>
Yes, your interpretation is correct. However, it just means that the "make
install" did not complete without errors. Sometimes it just fails to install
the manual pages, However, it is usually a good idea to check why it did not
complete. For example,

% make install ALLDIRS=udunits

may reveal something easy to fix.

       Arlindo

-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] Supplibs 2.1.0 being uploaded

[Arlindo da S. <da...@al...>]

All,
   Here is a quick trick for building COLA's v2.0.a5 with the new
supplibs-2.1.0:

% ./configure
% make

and it will fail trying to build grads; then

% cd src
% make (it will compile and fail during link)
% make grads CC=g++ LIBS="`../../supplibs/bin/nc-config-nc --libs` -lm"

and you will have a grads binary that are netcdf-3, netcdf-4/hdf-5, hdf-4
and opendap (gridded) enabled. Pretty cool.

Jennifer,

   As for revising your config.ac: a simple trick is to key into the
nc-config-nc script which is available with the latest netcdf-4. If it is
available then you know it is netcdf-4, and from it you can find out what is
available with that netcdf build:

% nc-config-nc:

Usage: nc-config [OPTION]

Available values for OPTION include:

  --help      display this help message and exit
  --all       display all options
  --cc        C compiler
  --cxx       C++ compiler
  --fc        Fortran compiler
  --cflags    pre-processor and compiler flags
  --fflags    flags needed to compile a Fortran program
  --has-dap   whether OPeNDAP is enabled in this build
  --has-nc2   whether NetCDF-2 API is enabled
  --has-nc4   whether NetCDF-4/HDF-5 is enabled in this build
  --has-hdf5  same as --has-nc4
  --has-f77   whether Fortran 77 API is enabled in this build
  --has-f90   whether Fortran 90 API is enabled in this build
  --has-c++   whether C++ API is enabled in this build
  --libs      library linking information for libnc-dap
  --flibs     libraries needed to link a Fortran program
  --prefix    Install prefix
  --version   Library version


  Let me know if you have questions,

      Arlindo


On Tue, Feb 17, 2009 at 3:28 PM, Arlindo da Silva <da...@al...>wrote:

> All,
>
>   I just finished a major upgrade of the supplibs, see ChangeLog bellow.
> Pre-compiled tarballs are on sf.net:
>
>
> https://sourceforge.net/project/showfiles.php?group_id=161773&package_id=241681&release_id=661716
>
> There are now 2 packages: supplibs-*.tar.gz  which includes the lib/,
> include/ and a few files in bin/ needed to build grads (e.g., pkg-config).
> The supptools-*.gz package includes the remaining bin/, etc/ , share/ which
> is a product of the build that some people may find useful (ncdump, for
> example). The "supplibs" package is now much smaller, < 20MB.
>
>  The main change is that netcdf has been upgraded to v4.0.1 which includes
> opendap and hdf-5 support. Therefore, I have omitted libnc-dap and removed
> the previous netcdf4 package that I had been using for experimental netcdf-4
> builds in the past couple of years.  The upshot is that we no longer need to
> build a separate gradsdap: the single executable grads now can have it all:
> netcdf-3, netcdf-4/hdf-5, hdf-4,  grib-1/2.  I say more about that on a
> follow on message regarding v2.0.a5.oga.1.
>
> Caveat: by setting LIBS properly one may be able to build grads v2.0.a5
> with supplibs-2.0.1.  It will not build "gradsdap" and the binary *grads*
> will say that opendap is not enabled, although gridded dap is.
>
> Other niceties,
>
> % make lib-dist
> % make bin-dist
> % make src-dist
>
> will create the respective tarballs. The "make src-dist" only works with
> supplib sources that have been checked out from CVS. Also,
>
> % make verify
>
> will produce a summary of which package passed or  failed config, install.,
> eg.,
>
> -------+---------+--------------
> Config | Install |   Package
> -------+---------+--------------
>   ok   |   ok    | pkg-config
>   ok   |   ok    | udunits
>   ok   |   ok    | zlib
>   ok   |   ok    | szlib
>   ok   |   ok    | libpng
> ...
>
> Jennifer,
>
>   Per your request, I have created a special CVS module,
>
>   % gacvs co -P supplibs_fixture
>
>   which allows you to checkout only a "shell" of the supplibs, with the top
> GNUmakefile, but with sources only for pkg-config (which is a must have for
> ensurance the self-consistency of the build.) Now, say, you want to build
> jasper, then you enter:
>
>   % make co_jasper
>   % make install
>
> This will bring the jasper sources and build it. I wrote in some dependency
> tracking, so co_hdf4 would also check out zlib, szlib, etc, although I have
> not tested this dependency feature fully.
>
>   Let me know of any problems,
>
>   Cheers!
>
>     Arlindo
>
> ChangeLog
>
> 2009-02-16 Arlindo da Silva (da...@op...)
>     * Version 2.1.0
>     * CVS Tag: supplibs-2_1_0
>     * GNUmakefile:
>       - adjusted to reflect new packages
>       - added verify target to summarize what has been built
>           - added *-dist targets for distribution tarballs
>       - added target for CVS checkout
>     * make_ppc.sh: script for cross-compilation of Powerpc/Darwin
>     * relocate.sh: new script to rename files when relocating
>       supplibs installation.
>         Updated packages:
>     * netcdf: updated to v4.0.1beta3
>     * hdf5: updated to v1.8.2
>     * dap: updated to v3.8.2, then downgraded to v3.7.10 for
>       compatibility with NetCDF-4
>     * nc-dap: updated to v3.7.3 (then removed altogether)
>     * gadap: merged with COLA v2.0 and patched
>         New packages;
>     * tiff: added v3.8.3 (for GrADS v2.0.a5)
>     * geotiff: added v1.2.5 (for GrADS v2.0.a5)
>     * cairo: added v1.8.6 (for gxyat and future use)
>     * pixman: added v0.13.2 (needed by cairo)
>     * fontconfig: added v2.6.0 (needed by cairo)
>     * freetype: added v2.3.8 (needed by cairo)
>     * shp: added v1.2.10 added, w/ addition of GNUmakefile
>     * hdf4-nc: not a real package, but a recompilatin of hdf4
>       with the NetCDF API enabled.
>         Removed packages:
>     * nc-dap: netcdf 4.0.1 includes this functionality
>     * netcdf4: removed (main netcdf is now has v4.0.1)
>     * neXtaw: removed as it does not work with Ubuntu and Xaw
>       works just fine
>     * esmf.mk: removed as ESMF is not at the supplibs
>     * hdfeos: ditto
>
> --
> Arlindo da Silva
> da...@al...
>



-- 
Arlindo da Silva
da...@al...

[Opengrads-devel] Supplibs 2.1.0 being uploaded

[Arlindo da S. <da...@al...>]

All,

  I just finished a major upgrade of the supplibs, see ChangeLog bellow.
Pre-compiled tarballs are on sf.net:


https://sourceforge.net/project/showfiles.php?group_id=161773&package_id=241681&release_id=661716

There are now 2 packages: supplibs-*.tar.gz  which includes the lib/,
include/ and a few files in bin/ needed to build grads (e.g., pkg-config).
The supptools-*.gz package includes the remaining bin/, etc/ , share/ which
is a product of the build that some people may find useful (ncdump, for
example). The "supplibs" package is now much smaller, < 20MB.

 The main change is that netcdf has been upgraded to v4.0.1 which includes
opendap and hdf-5 support. Therefore, I have omitted libnc-dap and removed
the previous netcdf4 package that I had been using for experimental netcdf-4
builds in the past couple of years.  The upshot is that we no longer need to
build a separate gradsdap: the single executable grads now can have it all:
netcdf-3, netcdf-4/hdf-5, hdf-4,  grib-1/2.  I say more about that on a
follow on message regarding v2.0.a5.oga.1.

Caveat: by setting LIBS properly one may be able to build grads v2.0.a5 with
supplibs-2.0.1.  It will not build "gradsdap" and the binary *grads* will
say that opendap is not enabled, although gridded dap is.

Other niceties,

% make lib-dist
% make bin-dist
% make src-dist

will create the respective tarballs. The "make src-dist" only works with
supplib sources that have been checked out from CVS. Also,

% make verify

will produce a summary of which package passed or  failed config, install.,
eg.,

-------+---------+--------------
Config | Install |   Package
-------+---------+--------------
  ok   |   ok    | pkg-config
  ok   |   ok    | udunits
  ok   |   ok    | zlib
  ok   |   ok    | szlib
  ok   |   ok    | libpng
...

Jennifer,

  Per your request, I have created a special CVS module,

  % gacvs co -P supplibs_fixture

  which allows you to checkout only a "shell" of the supplibs, with the top
GNUmakefile, but with sources only for pkg-config (which is a must have for
ensurance the self-consistency of the build.) Now, say, you want to build
jasper, then you enter:

  % make co_jasper
  % make install

This will bring the jasper sources and build it. I wrote in some dependency
tracking, so co_hdf4 would also check out zlib, szlib, etc, although I have
not tested this dependency feature fully.

  Let me know of any problems,

  Cheers!

    Arlindo

ChangeLog

2009-02-16 Arlindo da Silva (da...@op...)
    * Version 2.1.0
    * CVS Tag: supplibs-2_1_0
    * GNUmakefile:
      - adjusted to reflect new packages
      - added verify target to summarize what has been built
          - added *-dist targets for distribution tarballs
      - added target for CVS checkout
    * make_ppc.sh: script for cross-compilation of Powerpc/Darwin
    * relocate.sh: new script to rename files when relocating
      supplibs installation.
        Updated packages:
    * netcdf: updated to v4.0.1beta3
    * hdf5: updated to v1.8.2
    * dap: updated to v3.8.2, then downgraded to v3.7.10 for
      compatibility with NetCDF-4
    * nc-dap: updated to v3.7.3 (then removed altogether)
    * gadap: merged with COLA v2.0 and patched
        New packages;
    * tiff: added v3.8.3 (for GrADS v2.0.a5)
    * geotiff: added v1.2.5 (for GrADS v2.0.a5)
    * cairo: added v1.8.6 (for gxyat and future use)
    * pixman: added v0.13.2 (needed by cairo)
    * fontconfig: added v2.6.0 (needed by cairo)
    * freetype: added v2.3.8 (needed by cairo)
    * shp: added v1.2.10 added, w/ addition of GNUmakefile
    * hdf4-nc: not a real package, but a recompilatin of hdf4
      with the NetCDF API enabled.
        Removed packages:
    * nc-dap: netcdf 4.0.1 includes this functionality
    * netcdf4: removed (main netcdf is now has v4.0.1)
    * neXtaw: removed as it does not work with Ubuntu and Xaw
      works just fine
    * esmf.mk: removed as ESMF is not at the supplibs
    * hdfeos: ditto

-- 
Arlindo da Silva
da...@al...

[Opengrads-devel] Directory structure for distribution tarballs

[Arlindo da S. <da...@al...>]

All,
  I am thinking about providing opengrads tarballs with full installations
for all platforms, not only win32; I'll call these "bundles". I also would
like to have the ability to have a single DVD or USB mem stick with multiple
versions on it. I have a proposal directory structure here:

  http://opengrads.org/wiki/index.php?title=The_OpenGrADS_Bundle

  I really would appreciate your comments.

  Thank you,

    Arlindo


-- 
Arlindo da Silva
da...@al...

[Opengrads-devel] ga.blue_marble(Filename="custom.jpg") ignores Filename for basemap=cyl

[Daniel da S. <dda...@um...>]

 Arlindo,

If the basemap is "cyl" and you specify a custom blue marble backround
image, PyGRADS will ignore the custom background image and use the default
blue marble image. However, if the background is "geos", it will work
properly.


 [1] ga-> oo aero.nc

 [2] ga-> ga.basemap('cyl')

 [3] ga-> ga.blue_marble('on', Filename='/home/daniel/Pictures/car.jpg')

 [4] ga-> ga.contour('h500')


Can you look into this? Being able to specify a custom background image
properly is an excellent feature, because it allows us to set map
backgrounds as WMS-retrieved images with layers relevant to the plot.


Daniel

-- 
Daniel da Silva
dda...@um...
NASA GFSC, GES DISC 601.2

Re: [Opengrads-devel] Java client/server

[pedro t. <ped...@ya...>]

hi Arlindo,

Yes, I think it is ok, I should be able to help with the Java implementation.  

In regard to 'would the server be able to handle requests from multiple clients', the current description 'GBS' will not.  To handle multiple clients, usually what is done is (using traditional Unix client-server design, at least from old Unix code I seen):  a parent process which we call 'mother' is initially started, the 'mother' is listening on a port, when a client make a connection on that port, the mother will create a child process(via fork()).  In the child process, it does a exec() to run the actual code (in this case, it would be the 'GBS').  For each client connection, there is 'GBS' instance interacting with that remote client. When the remote client exits, the child process (e.g., GBS instance) terminates and resource is freed.  The mother does not exit, it is always running and listening on the port for an incoming connection.    

Pedro



--- On Mon, 1/19/09, Arlindo da Silva <da...@al...> wrote:
From: Arlindo da Silva <da...@al...>
Subject: Re: Java client/server
To: "pedro tsai" <ped...@ya...>
Cc: ope...@li...
Date: Monday, January 19, 2009, 11:21 AM

Pedro,

   This looks like a great design. I like the fact that the GrADS Backend Server (let's call it GBS) uses sockets, so in principle the front end could be implemented in other languages, for example, python. This is good because later on I could hook up PyGrADS to the GBS as well.  For performance critical applications, at the expense of security, one might be able to replace the NextVM portion with the actual GrADS C implementation with some form of JNI glue. A quick question: would the server be able to handle requests from multiple clients? This would be important if one wants to provide GBS as a web service. Also, having the GBS and a thin client as you propose would make it very feasible to have a cell phone implementation of the client. I'd love to plan a route on Google Maps and have a Meteogram plotted along the route.


  Would you have any time to help out with the Java implementation? I have limited Java/socket programming experience. I suppose you could reuse some of your previous Java code, correct?

  Thank you for the thoughtful response.


  Cheers!

     Arlindo


On Mon, Jan 19, 2009 at 12:22 PM, pedro tsai <ped...@ya...> wrote:


Dear Arlindo,

Here is my suggestion/approach regarding this issue about client-server and non-blocking behavior.   

For the purpose of discussion, I will use the term java-client process 
and c-code server process.  These 2 processes can be running on 

different machines or on the same machine.

1. For the Java client process, I think this process needs 2 execution 
contexts (e.g, 2 threads).  
   
   (a) thread 1 is a command processor, this corresponds to the part of code that use

       JReadline to get the user input:
       
    if ((cmd = reader.readLine("ga-> "))==null) break;
            rc =
 ga.call("gaCmd",ga.strdup(cmd));

        Now instead of calling GrADS runtime under NextedVM,  it will sends the
        command to the C-code server process.

    if ((cmd = reader.readLine("ga-> "))==null) break;

            rc = Send_command_and_c_code_process("gaCmd",ga.strdup(cmd));

    For now, we don't need the detail for 'Send_comand_to_c_code_process', 
        most likely it will be implemented on standard 'socket API' in Java,

        using TCP or UDP connection.

   (b) thread 2 is described later.

2. C-code server process :  this process consists of 'grads c-code' component 
   running under NextedVM and a wrapper layer, this is the
 'GradsVM' wrapper
   in your e-mail:

   (a) In the GradsVM component, it performs 'socket' read function 
       get the command string from the Java client process, and it then
       calls 'ga.call("gaCmd,ga.strdup(cmd))' to pass the command

       to the 'grads c-code'. 

   (b) After the execution is done by 'grads c-code', the graphics primitives
       commnads are returned to the GradsVM wrapper via the callback function 
       (this corrsponds to the Runtime.CallJavaCB() in the existing

       JGrads.java code).  In this function, we will buffer the graphics 
       primitive commands,  for example,  

       In the
 Runtime.CallJavaCB(),  if we receive a GXDWID, instead of 
       calling g.gxdwid(a), we will add the GXDWID command and its 
       parameters to the buffer:

          (......, 
          GXDWID+parameters,

                  GXDMOV+parameters,
          GXDDRW+parameters, 
          GXDFRM
          )

       When the graphics primitive 'GXDFRM' is encountered, then the content of
       the buffer can be send back to the Java client process 

       (again, omitting the detail for network socket
 operation)

3.  In the Java client process, the second execution context (thread 2) is 
    the graphics primitives processing thread.
    
    (a) In thread 2, it listen for graphics primitives requests from the 

        C-code server process.  When the requests arrive, it processes
        the graphics primitive commands by calling gxJ() functions: 

    g.gxdwid, g.gxdmov, ..... gxdfrm.

Attached files are drawing showing this program flow (If you can not open the vizio file, then just open jpeg file).


best regards,

Pedro




--- On Thu, 1/15/09, Arlindo da Silva <da...@al...> wrote:

From: Arlindo da Silva
 <da...@al...>
Subject: Java client/server
To: ped...@ya...
Cc: ope...@li...

Date: Thursday, January 15, 2009, 8:42 AM

Dear Pedro,

I have a question for you regarding a client/server split of GrADS, much along the lines of what youy did 10 years ago.  My main
interest is to be able to run the core GrADS on the machine where the
data resides and do the plotting locally on my laptop while sipping coffee
at Starbucks. Of course OPeNDAP allow some of this functionality, but doing server-side operations in GDS is just a bit restricted. 



My current approach for grads.jar is  based on NestedVM and creates sort of a "single
executable". Strictly speaking, it is not client-server. However, there
is a very natural "fold" for a client/server split: most of the system
is based on the C sources compiled into java byte code through
NestedVM; I'll refer to this part of the system loosely as the "C code". There are only 2 files with actual java code: 

JGrads.java which contains main(): the NestedVM class
"grads" is called several times: once for initialization and then in a
while loop (function GaCmd) so that I can use JLine (readline
replacement). 

  gxJ.java: adaption of your original code. These gets called from within the "C code" through a  callback setup that gets done in JGrads.java.
Therefore, one could say that the "C code" part of the system is the
server, while JGrads.java is the client. This split is very different
from what you have conceived originally because now most of the graphics is
done server-side, only the final rendering using the gx primitives
is done client-side. A good thing about it is that any improvements Brian makes to the plotting routines are readily available. The graphics primitives are much less likely to change, so it is much easier to maintain. On the down side, the server does most of  the work. 



Now, the thorny issue: how to handle the fact that the "C code" calls back
java for the graphics primitives.  Although it is not setup this way right now,
perhaps we could have some non-blocking way of calling GaCmd with
subsequent queries to the server for the graphics primitives requests/end
of command events. I was thinking about a GradsVM.java class that wraps
around the "C code " and provides what is necessary for implementing
this (for example, buffering the graphics primitives' requests.) 



How would you do it? I have close to zero experience in Java, there is probably more elegant ways of doing this.

   Thanks,

        Arlindo

-- 
Arlindo da Silva
da...@al...








      


-- 
Arlindo da Silva
da...@al...




      

Re: [Opengrads-devel] Java client/server

[Arlindo da S. <da...@al...>]

Pedro,

   This looks like a great design. I like the fact that the GrADS Backend
Server (let's call it GBS) uses sockets, so in principle the front end could
be implemented in other languages, for example, python. This is good because
later on I could hook up PyGrADS to the GBS as well.  For performance
critical applications, at the expense of security, one might be able to
replace the NextVM portion with the actual GrADS C implementation with some
form of JNI glue. A quick question: would the server be able to handle
requests from multiple clients? This would be important if one wants to
provide GBS as a web service. Also, having the GBS and a thin client as you
propose would make it very feasible to have a cell phone implementation of
the client. I'd love to plan a route on Google Maps and have a Meteogram
plotted along the route.

  Would you have any time to help out with the Java implementation? I have
limited Java/socket programming experience. I suppose you could reuse some
of your previous Java code, correct?

  Thank you for the thoughtful response.

  Cheers!

     Arlindo


On Mon, Jan 19, 2009 at 12:22 PM, pedro tsai <ped...@ya...> wrote:

> Dear Arlindo,
>
> Here is my suggestion/approach regarding this issue about client-server and
> non-blocking behavior.
>
> For the purpose of discussion, I will use the term java-client process
> and c-code server process.  These 2 processes can be running on
> different machines or on the same machine.
>
> 1. For the Java client process, I think this process needs 2 execution
> contexts (e.g, 2 threads).
>
>    (a) thread 1 is a command processor, this corresponds to the part of
> code that use
>        JReadline to get the user input:
>
>     if ((cmd = reader.readLine("ga-> "))==null) break;
>             rc = ga.call("gaCmd",ga.strdup(cmd));
>
>         Now instead of calling GrADS runtime under NextedVM,  it will sends
> the
>         command to the C-code server process.
>
>     if ((cmd = reader.readLine("ga-> "))==null) break;
>             rc = Send_command_and_c_code_process("gaCmd",ga.strdup(cmd));
>
>     For now, we don't need the detail for 'Send_comand_to_c_code_process',
>         most likely it will be implemented on standard 'socket API' in
> Java,
>         using TCP or UDP connection.
>
>    (b) thread 2 is described later.
>
> 2. C-code server process :  this process consists of 'grads c-code'
> component
>    running under NextedVM and a wrapper layer, this is the 'GradsVM'
> wrapper
>    in your e-mail:
>
>    (a) In the GradsVM component, it performs 'socket' read function
>        get the command string from the Java client process, and it then
>        calls 'ga.call("gaCmd,ga.strdup(cmd))' to pass the command
>        to the 'grads c-code'.
>
>    (b) After the execution is done by 'grads c-code', the graphics
> primitives
>        commnads are returned to the GradsVM wrapper via the callback
> function
>        (this corrsponds to the Runtime.CallJavaCB() in the existing
>        JGrads.java code).  In this function, we will buffer the graphics
>        primitive commands,  for example,
>
>        In the Runtime.CallJavaCB(),  if we receive a GXDWID, instead of
>        calling g.gxdwid(a), we will add the GXDWID command and its
>        parameters to the buffer:
>
>           (......,
>           GXDWID+parameters,
>                   GXDMOV+parameters,
>           GXDDRW+parameters,
>           GXDFRM
>           )
>
>        When the graphics primitive 'GXDFRM' is encountered, then the
> content of
>        the buffer can be send back to the Java client process
>        (again, omitting the detail for network socket operation)
>
> 3.  In the Java client process, the second execution context (thread 2) is
>     the graphics primitives processing thread.
>
>     (a) In thread 2, it listen for graphics primitives requests from the
>         C-code server process.  When the requests arrive, it processes
>         the graphics primitive commands by calling gxJ() functions:
>
>     g.gxdwid, g.gxdmov, ..... gxdfrm.
>
> Attached files are drawing showing this program flow (If you can not open
> the vizio file, then just open jpeg file).
>
> best regards,
>
> Pedro
>
>
>
>
> --- On *Thu, 1/15/09, Arlindo da Silva <da...@al...>* wrote:
>
> From: Arlindo da Silva <da...@al...>
> Subject: Java client/server
> To: ped...@ya...
> Cc: ope...@li...
> Date: Thursday, January 15, 2009, 8:42 AM
>
>
> Dear Pedro,
>
> I have a question for you regarding a client/server split of GrADS, much
> along the lines of what youy did 10 years ago.  My main interest is to be
> able to run the core GrADS on the machine where the data resides and do the
> plotting locally on my laptop while sipping coffee at Starbucks. Of course
> OPeNDAP allow some of this functionality, but doing server-side operations
> in GDS is just a bit restricted.
>
> My current approach for *grads.jar* is  based on NestedVM and creates sort
> of a "single executable". Strictly speaking, it is not client-server.
> However, there is a very natural "fold" for a client/server split: most of
> the system is based on the C sources compiled into java byte code through
> NestedVM; I'll refer to this part of the system loosely as the "C code".
> There are only 2 files with actual java code:
>
>    1. *JGrads.java *which contains main(): the NestedVM class "*grads*" is
>    called several times: once for initialization and then in a while loop
>    (function *GaCmd*) so that I can use JLine (readline replacement).
>    2. *gxJ.java*: adaption of your original code. These gets called from
>    within the "C code" through a  callback setup that gets done in *
>    JGrads.java.*
>
> Therefore, one could say that the "*C code*" part of the system is the *
> server*, while *JGrads.java* is the *client*. This split is very different
> from what you have conceived originally because now most of the graphics is
> done server-side, only the final rendering using the gx primitives is done
> client-side. A good thing about it is that any improvements Brian makes to
> the plotting routines are readily available. The graphics primitives are
> much less likely to change, so it is much easier to maintain. On the down
> side, the server does most of  the work.
>
> Now, the thorny issue: how to handle the fact that the "C code" calls back
> java for the graphics primitives.  Although it is not setup this way right
> now, perhaps we could have some non-blocking way of calling *GaCmd *with
> subsequent queries to the server for the graphics primitives requests/end of
> command events. I was thinking about a *GradsVM.java* class that wraps
> around the "C code " and provides what is necessary for implementing this
> (for example, buffering the graphics primitives' requests.)
>
> How would you do it? I have close to zero experience in Java, there is
> probably more elegant ways of doing this.
>
>    Thanks,
>
>         Arlindo
>
> --
> Arlindo da Silva
> da...@al...
>
>
>


-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] running CVS command on cygwin on Window Vista.

[Arlindo da S. <da...@al...>]

On Wed, Jan 14, 2009 at 4:54 PM, pedro tsai <ped...@ya...> wrote:

>  hi Arlindo,
>
> Yes,  I finally fixed my problem running cvs on cygwin last night (around
> mid-night).  I was able to download the opengrads source code on to my
> laptop.  I will commit the modification I did for window resizing issue
> tonight.   Is there a commit/change log somewhere I can update to keep track
> the code modification?
>

Yes, there is a standard ChangeLog file at the top directory. Also, as you
check in, prefix the log message with your initials, for example

% cvs ci -m 'pt: fixed window resizing problem' gxJ.java

  Arlindo



     Arlindo

-- 
Arlindo da Silva
da...@al...

[Opengrads-devel] Java client/server

[Arlindo da S. <da...@al...>]

Dear Pedro,

I have a question for you regarding a client/server split of GrADS, much
along the lines of what youy did 10 years ago.  My main interest is to be
able to run the core GrADS on the machine where the data resides and do the
plotting locally on my laptop while sipping coffee at Starbucks. Of course
OPeNDAP allow some of this functionality, but doing server-side operations
in GDS is just a bit restricted.

My current approach for *grads.jar* is  based on NestedVM and creates sort
of a "single executable". Strictly speaking, it is not client-server.
However, there is a very natural "fold" for a client/server split: most of
the system is based on the C sources compiled into java byte code through
NestedVM; I'll refer to this part of the system loosely as the "C code".
There are only 2 files with actual java code:

   1. *JGrads.java *which contains main(): the NestedVM class "*grads*" is
   called several times: once for initialization and then in a while loop
   (function *GaCmd*) so that I can use JLine (readline replacement).
   2. *gxJ.java*: adaption of your original code. These gets called from
   within the "C code" through a  callback setup that gets done in *
   JGrads.java.*

Therefore, one could say that the "*C code*" part of the system is the *
server*, while *JGrads.java* is the *client*. This split is very different
from what you have conceived originally because now most of the graphics is
done server-side, only the final rendering using the gx primitives is done
client-side. A good thing about it is that any improvements Brian makes to
the plotting routines are readily available. The graphics primitives are
much less likely to change, so it is much easier to maintain. On the down
side, the server does most of  the work.

Now, the thorny issue: how to handle the fact that the "C code" calls back
java for the graphics primitives.  Although it is not setup this way right
now, perhaps we could have some non-blocking way of calling *GaCmd *with
subsequent queries to the server for the graphics primitives requests/end of
command events. I was thinking about a *GradsVM.java* class that wraps
around the "C code " and provides what is necessary for implementing this
(for example, buffering the graphics primitives' requests.)

How would you do it? I have close to zero experience in Java, there is
probably more elegant ways of doing this.

   Thanks,

        Arlindo

-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] running CVS command on cygwin on Window Vista.

[Arlindo da S. <da...@al...>]

On Wed, Jan 7, 2009 at 11:14 AM, pedro tsai <ped...@ya...> wrote:

>  hi,
>
> I installed Cygwin on my Window Vista.  But when I try the following
> command using 'bash' on Cygwin to download Grads development code, I get an
> error (Window Vista pops up a window and says: cvs.exe has stop working ).
>
> Has anyone got suggestion?   Thanks,
>
> >> export CVS_RSH=ssh
> >> cvs -z3 -d :ext:ped...@op...:/cvsroot/opengrads
> co -r GRADS2_DEV_BRANCH grads
> If I type just 'cvs -version',  it also failed.
>
>

I never seen this problem before. This seems like a question for the cygwin
folks. Unfortunately (or fortunately) I do not have access to a Windows
Vista box.

-- 
Arlindo da Silva
da...@al...

[Opengrads-devel] running CVS command on cygwin on Window Vista.

[pedro t. <ped...@ya...>]

hi,
 
I installed Cygwin on my Window Vista.  But when I try the following command using 'bash' on Cygwin to download Grads development code, I get an error (Window Vista pops up a window and says: cvs.exe has stop working ).  
 
Has anyone got suggestion?   Thanks,
 
>> export CVS_RSH=ssh
>> cvs -z3 -d :ext:ped...@op...:/cvsroot/opengrads co -r GRADS2_DEV_BRANCH grads

If I type just 'cvs -version',  it also failed.
 
Pedro
 
 
 
 


      

Re: [Opengrads-devel] Proof of concept: grads under JVM: Window Resize issue

[pedro t. <ped...@ya...>]

Arlindo,
 
Thanks for detailed information.  Fortunately,  I am quite familiar with CVS (it is what I used at work).  I will get familiarize with the documents and development guidelines.
 
Right now, I don't have the environment to check in the mod to CVS.  (My laptop is Window Vista, do you know any free CVS tool that work on Window Vista?).  I will be able to check in the mod when I get back to CA next week.  But if you need the latest changes now, I can send the files to you.
 
Pedro
 


--- On Tue, 12/30/08, Arlindo da Silva <da...@al...> wrote:

From: Arlindo da Silva <da...@al...>
Subject: Re: Proof of concept: grads under JVM: Window Resize issue
To: ped...@ya...
Cc: ope...@li...
Date: Tuesday, December 30, 2008, 7:48 PM


Pedro,


   You are in. For the bulk of the OpenGrADS documentation go to


           http://opengrads.org


and click on documentation on the left. You should receive the wiki password on a separate e-mail; user name is same as on sf.net.


To check out bleeding edge sources:



export CVS_RSH=ssh
 
cvs -z3 -d:ext:ped...@op...:/cvsroot/opengrads co 
-r GRADS2_DEV_BRANCH grads


Look under grads/src for C and java sources.  Are you familiar with CVS? If so, please check in your mods to the Java sources. You will need additional info in order to build grads.class (which derives from C sources using the NestedVM toolchain); in particular the supplibs for NestedVM and a patched NestedVM installation (mostly additions to .h files).  What is your development platform? If using Mac OS 10.5 I can share my binaries with you.  Otherwise, build the NestedVM toolchain from:


            http://nestedvm.ibex.org/



However, as you have already figured out,  the JGrads.class can be developed separately from the grads.class.


    Arlindo






On Tue, Dec 30, 2008 at 2:14 PM, pedro tsai <ped...@ya...> wrote:






hi Arlindo,
 
The 'Unix Name',   I think it is 'pedro_tsai'.
 
pedro


--- On Tue, 12/30/08, Arlindo da Silva <da...@al...> wrote:


From: Arlindo da Silva <da...@al...>
Subject: Re: Proof of concept: grads under JVM: Window Resize issue
To: ped...@ya...
Date: Tuesday, December 30, 2008, 12:37 AM








On Tue, Dec 30, 2008 at 1:48 AM, pedro tsai <ped...@ya...> wrote:






hi Arlindo,
 
My sourceforge ID is 2343265. 


Actually, I need your "Unix username".


  Thanks,


    Arlindo
 







thanks,

 
Pedro

--- On Mon, 12/29/08, Arlindo da Silva <da...@al...> wrote:


From: Arlindo da Silva <da...@al...>
Subject: Re: Proof of concept: grads under JVM: Window Resize issue
To: ped...@ya...
Date: Monday, December 29, 2008, 4:21 PM 






On Mon, Dec 29, 2008 at 4:07 PM, pedro tsai <ped...@ya...> wrote:






hi Arlindo,
 
No problem.   I am on vacation in Seattle this week, but with so much snow and ice last few days, I am pretty much stay inside the house, so I have more time to work this :-)).  
 
I will investiage packaging issue with data.



Do you have a sourceforge user id? I'd like to give you developer privileges to the OpenGrADS CVS repositoy so you can check in your mods.


  Arlindo




 





 
best regards,
 
Pedro 


--- On Mon, 12/29/08, Arlindo da Silva <da...@al...> wrote:


From: Arlindo da Silva <da...@al...>
Subject: Re: Proof of concept: grads under JVM: Window Resize issue 

To: ped...@ya...
Date: Monday, December 29, 2008, 8:08 AM 




Pedro,

Thank you for the bug fixes. I'll get back to you on this, I have some
pressing deadlines in the enxt couple of days...

  Cheers!

         Arlindo


On Sun, Dec 28, 2008 at 7:57 PM, pedro tsai <ped...@ya...> wrote:
> hi Arlindo,
>
> I found a bug fix which would probably help with the window resizing
issue:
>
> In the JGrads.java file,   in the function "private static void
> redraw_if_needed() ",
> There is a line that determines if it needs to call setCanvassize(...).
>
> if ( fSize.width!=now.width && fSize.height!=now.height )
>
> This line I think this line should be:
>
> if ( fSize.width!=now.width || fSize.height!=now.height )
>
> Otherwise, if window frame is only re-size in one direction, the Canvas
size
> will not be re-set to the new sizes.
>
> Pedro
>
> --- On Sun, 12/21/08, Arlindo da Silva <da...@al...> wrote:
>
> From: Arlindo da Silva <da...@al...>
> Subject: Re: [Opengrads-devel] Proof of concept: grads 2.0.a3 100% under
JVM
> To: ped...@ya...
> Cc: "Love, Mr. Gary, Contractor, Code 7542"
<gar...@nr...>,
> "Brian Doty" <do...@co...>,
ope...@li...
> Date: Sunday, December 21, 2008, 8:08 PM
>
> All,
>
>   Weekend update: I did some work on the Java graphics and added a
> readline replacement. The graphics look quite descent,  even nicer
> than X on my Mac. I am using the same trick I used for gxyat: lines
> are drawn with anti-aliasing, while polygon fills are not (or else you
> get those funny horizontal lines).
>
>  I'd appreciate any feedback regarding performance compared to the C
> version with *your* data on *your* platform. Of course, this is Java,
> it is supposed to be slower. The queston is: is it usable?
>
>    Thanks,
>
>         Arlindo
>
>
> On Fri, Dec 19, 2008 at 4:59 AM, Arlindo da Silva
<da...@al...>
> wrote:
>> On Thu, Dec 18, 2008 at 1:03 AM, pedro tsai
<ped...@ya...>
> wrote:
>>>
>>> Dear Arlindo, Gary, Brian
>>>
>>> I apologized that I have been silent for many years.  I went to do
>>> commercial software in Silicon Valley since 2000 (except for 2003,
> when I
>>> was laid-off during the last collapse of bubble, I was fortunate
that
> I was
>>> able to went back to Monterey to work on weather model for a
year).
> Now
>>> days, I work for IC chip design company (for cell phone chips,
digital
> TV
>>> chip, etc).  That, pretty much sum up the last 8-9 years.
>>>
>>> Anyway,  I think I still remember the GrADS code I work on with
Brian.
>>> Let me known if I can be of some help.
>>
>> Nice to hear from you! I have studied your code in the last couple of
days
>> (great job, BTW) and I have been able to extract the low level gxJ
class
>> that I needed
>> for adding graphics to grads v2 under the JVM. The latest is here:
>>        http://opengrads.org/devel/grads2/grads.jar
>>
>> To run the main application:
>>    java -jar grads.jar
>> For running the utilities,
>>    java -cp grads.jar gxeps myfile.gm
>> It now has basic graphics with animation and double buffer; no
widgets,
>> though. I am pretty sure there are lots of fine tuning still to be
done,
>> since there are still many of the gxX() routines that are stubs. On my
>> immediate list:
>>   - window resizing
>>   - grads-superpack.jar including fonts, map data, etc -- all that is
> needed
>>     to run grads
>>   - command line parsing, including initial window size
>>   - Jline (readline replacement)
>>   - Try to build opendap (or else wait for NetCDF-4)
>> Anybody willing to help with the following?
>>   - Swing based console, IDE (?)
>>   - JNLP/web start
>>   - Eclipse plug in?
>> Brian: I may need your help to implement the widget stuff.
>>    Let me known of bugs...
>>      Arlindo
>>
>>>
>>> Pedro
>>>
>>>
>>>
>>>
>>> --- On Wed, 12/17/08, Love, Mr. Gary, Contractor, Code 7542
>>> <gar...@nr...> wrote:
>>>
>>> From: Love, Mr. Gary, Contractor, Code 7542
>>> <gar...@nr...>
>>> Subject: RE: [Opengrads-devel] Proof of concept: grads 2.0.a3 100%
> under
>>> JVM
>>> To: "Arlindo da Silva" <da...@al...>
>>> Cc: "Brian Doty" <do...@co...>,
> ped...@ya...
>>> Date: Wednesday, December 17, 2008, 2:47 PM
>>>
>>> Arlindo,
>>>
>>> Here's Pedro's email: ped...@ya....  It's been
> almost 10 years
>>> since he wrote the Java-Grads code, I hope he remembers what he
did.
>>>
>>> Good Luck,
>>> Gary
>>> ________________________________
>>> From: arl...@gm... [mailto:arl...@gm...]
On
>>> Behalf Of Arlindo da Silva
>>> Sent: Wednesday, December 17, 2008 7:19 AM
>>> To: Love, Mr. Gary, Contractor, Code 7542
>>> Cc: ope...@li...; Brian Doty
>>> Subject: Re: [Opengrads-devel] Proof of concept: grads 2.0.a3 100%
> under
>>> JVM
>>>
>>> On Mon, Dec 15, 2008 at 4:10 PM, Love, Mr. Gary, Contractor, Code
7542
>>> <gar...@nr...> wrote:
>>>>
>>>> Brian, Arlindo,
>>>>
>>>> I believe Pedro's code is at 
ftp://www.iges.org/grads/gaserv/
>>>
>>> This is very helpful, I shall be able to reuse some of this code,
> although
>>> I have a much simpler problem. Does anybody know Pedro
whereabouts?
>>>
>>>       Arlindo
>>>
>>>
>>>
>>>>
>>>> Gary
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Brian Doty [mailto:do...@co...]
>>>> Sent: Saturday, December 13, 2008 3:29 AM
>>>> To: Arlindo da Silva
>>>> Cc: ope...@li...
>>>> Subject: Re: [Opengrads-devel] Proof of concept: grads 2.0.a3
100%
> under
>>>> JVM
>>>>
>>>> Hi Arlindo, this seems to have potential implications for the
GDS.
>>>> Regarding java graphics, there are no doubt some nice
libraries
> out
>>>> there these days but I have not been keeping up with that
area.
>>>> Pedro Tsai, about 10 years ago, wrote a grads client/server
setup
> in
>>>> java which included some graphics output of the grads graphics
>>>> primitives (this was a precursor to the GDS).  I have that
code
> around
>>>> somewhere and I can find it if you think it might be useful
for
> this.
>>>> You don't need to support a whole lot to get most of the
> graphics output
>>>> working.
>>>>
>>>> Take a look in gxmeta.c, at function gxhdrw.  It redraws the
> internal
>>>> buffer and draws all the primitives.  Look at the code
starting
> with the
>>>> comment "Get message type".  If you support color,
> polygon, rectangle
>>>> (separate from polygon for performance), and line drawing, you
get
>>>> almost all of the graphics.  Line thickness is also nice (can
> easily be
>>>> soft generated too).
>>>>
>>>> Even though GrADS has been all X11 for a while now, it
didn't
> start that
>>>> way and I have wanted to avoid being locked into that, thus
this
> fairly
>>>> simple interface has survived.  I don't expect to redesign
> this in any
>>>> substantial way but I do want to add text strings and font
> selection as
>>>> new primitives (with appropriate fall-back to the Hershey
fonts
> when
>>>> needed).  Anyone out there still using gv32?  It's not
going
> to work
>>>> much longer.... Brian
>>>>
>>>> On Dec 12, 2008, at 11:17 PM, Arlindo da Silva wrote:
>>>>
>>>> > All,
>>>> >
>>>> >    I just refreshed
>>>> >
>>>> >        http://opengrads.org/devel/grads2/grads.jar
>>>> >
>>>> > It is getting quite functional now: grib-1, grib-2,
netcdf,
> hdf,
>>>> > printim. Still no readline, x11 or opendap; see output of
> "q config"
>>>> > below. This is all 100% java (no JNI), it should run
> anywhere.
>>>> >
>>>> > Brian:  I know you are thinking about redesigning the
> graphical engine
>>>>
>>>> > in grads. Do you have any thoughts on how one could
handle
> the
>>>> > graphics in Java? Currently, I have gxX.c stubbed out. I
was
> thinking
>>>> > about implementing "gxX.c" in java around
JPanel.
>>>> >
>>>> >     Arlindo
>>>> >
>>>> >
>>>> > ga>  q config
>>>> > Config: v2.0.a3.oga.2dev big-endian printim grib2 netcdf
> hdf4-sds Grid
>>>>
>>>> > Analysis and Display System (GrADS) Version
2.0.a3.oga.2dev
> Copyright
>>>> > (c) 1988-2008 by Brian Doty and the Institute for Global
> Environment
>>>> > and Society (IGES) This program is distributed WITHOUT
ANY
> WARRANTY
>>>> > See file COPYRIGHT for more information.
>>>> >
>>>> > Built Sat Dec 13 00:32:59 BRST 2008 for mips-unknown-elf
>>>> >
>>>> > This version of GrADS has been configured with the
following
> options:
>>>> >   o Built on a BIG ENDIAN machine
>>>> >   o Command line editing DISABLED
>>>> >   o printim command for image output ENABLED
>>>> >       http://www.zlib.net
>>>> >       http://www.libpng.org/pub/png/libpng.html
>>>> >       http://www.libgd.org/Main_Page
>>>> >   o GRIB2 interface ENABLED
>>>> >       http://www.ijg.org
>>>> >       http://www.ece.uvic.ca/~mdadams/jasper
>>>> >       http://www.nco.ncep.noaa.gov/pmb/codes/GRIB2
>>>> >       g2clib-1.0.5
>>>> >   o NetCDF interface ENABLED
>>>> >       http://www.unidata.ucar.edu/software/netcdf
>>>> >       netcdf "3.6.2" of Dec 11 2008 22:17:25 $
>>>> >   o NCSA HDF interface ENABLED
>>>> >       http://hdf.ncsa.uiuc.edu
>>>> >       HDF4.2r3
>>>> >   o Athena Widget GUI DISABLED
>>>> >   o OPeNDAP gridded data interface DISABLED
>>>> >   o OPeNDAP station data interface DISABLED
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > On Thu, Dec 11, 2008 at 12:38 AM, Arlindo da Silva
>>>> > <da...@al...> wrote:
>>>> > Hi,
>>>> >
>>>> >   I was able to created a prototype build of grads v2
that
> runs
>>>> > entirely under the JVM:
>>>> >
>>>> >        http://opengrads.org/devel/grads2/grads.jar
>>>> >
>>>> >   To try it out:
>>>> >
>>>> >       java -cp grads.jar grads
>>>> >
>>>> >   Most external libraries have been disabled at this
point,
> even X.
>>>> > However, you can do things like
>>>> >
>>>> >   ga> open model.ctl
>>>> >   ga> d ts
>>>> >   ga> print ts.eps
>>>> >
>>>> > It feels quite usable on my MacPro laptop, speed-wise I
mean.
> What do
>>>> > you think? Here is the best part of it:
>>>> >
>>>> >   numer of grads source code lines modified: 0, except
for
> the
>>>> > replacing gxX.c with the attached stubs.
>>>> >   number of build script lines modified: 0
>>>> >
>>>> > Jennifer: you may want to carry the gxX.c stubs along
with
> the sources
>>>>
>>>> > code and have a --disbale-X11 during configure. This is
very
> useful to
>>>>
>>>> > create binaries for machines that do not provide X11 (say
> many
>>>> > computer centers disable X11 at the compute nodes).
>>>> >
>>>> > Here is the tool that I used:
>>>> >
>>>> >        http://nestedvm.ibex.org/
>>>> >
>>>> > Building this gcc toolchain on Mac OS X 10.5  is kind of
> tricky, talk
>>>> > to me before attempting to do it yourself. I'll post
> notes about it at
>>>>
>>>> > some point. It may be simpler on Linux, but I have not
tried
> it
>>>> > myself.
>>>> >
>>>> > Beware: this is rough, just a proof of concept for now;
> however I'd be
>>>>
>>>> > interested in hearing about problems. Soon we may be able
to
> run grads
>>>>
>>>> > on cell phones.
>>>> >
>>>> >   Arlindo
>>>> >
>>>> >
>>>> > --
>>>> > Arlindo da Silva
>>>> > da...@al...
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Arlindo da Silva
>>>> > da...@al...
>>>>
>>>>
>>>>
> ------------------------------------------------------------------------
>>>> ------
>>>> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las
> Vegas,
>>>> Nevada.
>>>> The future of the web can't happen without you.  Join us
at
> MIX09 to
>>>> help
>>>> pave the way to the Next Web now. Learn more and register at
>>>>
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.
>>>> com/
>>>> _______________________________________________
>>>> Opengrads-devel mailing list
>>>> Ope...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/opengrads-devel
>>>
>>>
>>>
>>> --
>>> Arlindo da Silva
>>> da...@al...
>>>
>>
>>
>>
>> --
>> Arlindo da Silva
>> da...@al...
>>
>
>
>
> --
> Arlindo da Silva
> da...@al...
>
>



-- 
Arlindo da Silva
da...@al...




-- 
Arlindo da Silva
da...@al...




-- 
Arlindo da Silva
da...@al...




-- 
Arlindo da Silva
da...@al...