[gradsusr] OpenGrADS 2.01.oga.1 Bundle for Linux - Ubuntu issues

Arlindo da Silva dasilva at alum.mit.edu
Tue Nov 1 17:13:55 EDT 2011


On Tue, Nov 1, 2011 at 3:51 PM, Jennifer Adams <jma at cola.iges.org> wrote:

> "shp_lines" is part of a deprecated shapefile interface and should not be
> in any new build of opengrads. Take it out of your script and use the 'draw
> sip' command instead. Remove the call to gxyat as well. Then try again and
> see if it still hangs. --Jennifer
>
>
Oops, you are right! The documentation says that the old shape extension is
gone, and I verified that I  am no longer building it.  What happened is
that the shape directory was lying around from the 2.0.a9 build and I
accidentally ended including an older build of shape.gex  which does not
work with 2.0.1.oga.1 (extensions must be compiled for a given version of
grads).

Kevin: Please delete shape.gex from your gex/ directory and use the "draw"
command instead as Jennifer suggests.

   Arlindo


>
> On Nov 1, 2011, at 2:27 PM, Kevin M Levey wrote:
>
> TUE 01NOV11: 1035PDT
>
> Hi Arlindo
>
> OK - I've nailed down the issue a little more with further testing of
> various other scripts. It appears the script WILL successfully run the
> first time form the command line, however, if you try running it a second
> time that is when 2.0.1.oga.1 simply freezes. I've attached a simple script
> that opens up the 06UTC GFS template CTL file and produces the expected MAX
> temp for 01H00 CDT today. It runs just fine in 2.0.a9.oga.1. It runs the
> first time in 2.0.1.oga.1, but there is another issue too with your
> "shp_lines" routine:
>
> <Screen Shot 2011-11-01 at 10.21.01 AM.png>
>
> I've attached the script for you to look at.
>
> Here is screen output of a session showing you exactly what happens:
>
> weather:fweather1 /prod/custom/Input/modelplots/GRADS/scripts > g2
>
>               Welcome to the OpenGrADS Bundle Distribution
>               --------------------------------------------
>
> For additional information enter "grads -h".
>
> Starting
> "/usr/local/src/grads-2.0.1.oga.1/Contents/Linux/Versions/2.0.1.oga.1/x86_64/grads
>   " ...
>
>
> Grid Analysis and Display System (GrADS) Version 2.0.1.oga.1
> Copyright (c) 1988-2011 by Brian Doty and the
> Institute for Global Environment and Society (IGES)
> GrADS comes with ABSOLUTELY NO WARRANTY
> See file COPYRIGHT for more information
>
> Config: v2.0.1.oga.1 little-endian readline printim grib2 netcdf hdf4-sds
> hdf5 opendap-grids,stn athena geotiff shapefile
> Issue 'q config' command for more detailed configuration information
> Loading User Defined Extensions table
> </usr/local/grads2/Linux/Versions/2.0.1.oga.1/x86_64/gex/udxt> ... ok.
> Landscape mode? ('n' for portrait):
> GX Package Initialization: Size = 11 8.5
> ga-> test_GFS.gs
> No hardcopy metafile open
> All files closed; all defined objects released;
> All GrADS attributes have been reinitialized
> Using shapefile /var/data/lookup/shape/admin00
> Shapefile Type: Polygon   # of Shapes: 2606
> File Bounds: ( -180.000,  -90.000 ) to (  180.000,   83.624 )
> Done shapefile /var/data/lookup/shape/admin00
> ga-> test_GFS.gs
> No hardcopy metafile open
> All files closed; all defined objects released;
> All GrADS attributes have been reinitialized
>
> This is the point at which it merely hangs. This behavior is exactly the
> same using the 32-bit Ubuntu version of GRADS 2.0.1 that John Huddleston
> suggested I use to test, so this may not be an issue of your build, but in
> the general GRADS/COLA build. Likewise with your i686 build. It makes no
> difference what script I run, always the same result - hangs. Although,
> there is an issue with your "shp_lines" routine as you have seen above.
>
> Cheers
> Kevin
>
> <test_GFS.gs>
>
>
>
> On Nov 1, 2011, at 11/01/11 - 5:29 AM, Arlindo da Silva wrote:
>
> On Mon, Oct 31, 2011 at 9:36 PM, Kevin M Levey <klevey at customweather.com>wrote:
>
>> MON 31OCT11: 1830PDT
>>
>> Hi all and Arlindo
>>
>> Not sure if anyone else has upgraded to this latest version on an Ubuntu
>> system. I upgraded our dev/test machine and other than having to add a
>> missing library, the upgrade seemed fine. It loaded up just fine. However,
>> when running a simple test script which I always use to ensure everything
>> works as it should, opengrads simply froze. Has anyone else had this
>> problem with this latest version? I had to revert back to 2.0.a9.oga.1 and
>> my script worked just fine.
>>
>>
> I need just a bit more information in order to diagnose the problem. Can
> you share the test script with me? Can you tell the specif line where it is
> hanging? Have you tried the i686 build to rule out that this is not a
> x86_64 specific issue? Every binary we put out passes our unit tests, but
> any such collection of tests only covers a limitted set of features.
>
>      Arlindo
>
>
>
>> All our backend servers are set up identically to our dev/test server:
>>
>> Linux cumulonimbus 2.6.32-33-server #72-Ubuntu SMP Fri Jul 29 21:21:55
>> UTC 2011 x86_64 GNU/Linux
>> Ubuntu 10.04.3 LTS
>>
>> weather:cumulonimbus ~ > uname -m
>> x86_64
>>
>> weather:cumulonimbus ~ > ldd --version
>> ldd (Ubuntu EGLIBC 2.11.1-0ubuntu7.8) 2.11.1
>> Copyright (C) 2009 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>> PURPOSE.
>> Written by Roland McGrath and Ulrich Drepper.
>>
>> Arlindo, any ideas why this is happening? This is the first time I've
>> ever had an issue with any of your distributions.
>>
>> Thanks
>>
>> Regards,
>>
>> Kevin M Levey, MSc in Oceans and Atmospheric Sciences (University of Cape
>> Town)
>> Vice President of Operations
>> CustomWeather, Inc.
>> San Francisco, California, USA
>>
>> "Taking the World by Storm!"
>>
>> http://www.customweather.com
>> http://www.myforecast.com
>> http://www.1stweather.com
>>
>> cell: 415-794-0411
>> work: 415-777-3566
>> email: klevey at customweather.com
>>
>> On Oct 29, 2011, at 10/29/11 - 1:45 PM, Arlindo da Silva wrote:
>>
>> Dear GrADS Linux Users,
>>
>>   This message is intended for those users downloading the OpenGrADS
>> bundle for Linux. As of this writing there are 2 binary tarballs at
>> sf.net:
>>
>> - 32-bit version (i686):
>>
>>        grads-2.0.1.oga.1-bundle-i686-glibc2.5-linux-gnu.tar.gz<http://sourceforge.net/projects/opengrads/files/grads2/2.0.1.oga.1/Linux/grads-2.0.1.oga.1-bundle-i686-glibc2.5-linux-gnu.tar.gz/download>
>>
>> -  64-bit version (x86_64):
>>
>>         grads-2.0.1.oga.1-bundle-x86_64-glibc2.5-linux-gnu.tar.gz<http://sourceforge.net/projects/opengrads/files/grads2/2.0.1.oga.1/Linux/grads-2.0.1.oga.1-bundle-x86_64-glibc2.5-linux-gnu.tar.gz/download>
>>
>> (You can determine if your machine is 32 or 64 bits with the uname
>> command:
>>
>> % uname -m
>> )
>>
>> Now, the i686 binary will usually work on a x86_64 machine, but the
>> native build will be a bit faster.
>>
>> Notice that we do not label the opengrads binary tarball with the name of
>> Linux distribution where we built it on. The reason is that these
>> (statically linked) binaries will usually work on a number of different
>> Linux distributions. (The usual error message saying  that a
>> "libWhatever.so" cannot be found is easily fixed in the opengrads builds;
>> see the Troubleshooting section of the INSTALL file.) The main factor
>> determining whether a binary will work or not is the version of the GNU C
>> Library (glibc). You can find the glibc version on your computer with the
>> ldd command:
>>
>>  % ldd --version
>>
>> The opengrads binaries for now on will show its own version of glibc in
>> the file name. Usually, if your linux installation matches the glibc of the
>> opengrads binaries (or if it is newer) you should be fine. If you have an
>> older llinux distribution with a previous version of glibc there is a very
>> good chance that the binaries will not work.
>>
>> At this point in time, 2.5 is the older version of glibc I can build for;
>> however other people in this list may have older hardware available and be
>> kind enough to contribute builds. Otherwise, If you have an older version
>> of glibc building from sources (or upgrading your OS) may be your best
>> option. (Or else, run a previous version of grads).
>>
>>   Good Luck,
>>
>>     Arlindo
>>
>> --
>> Arlindo da Silva
>> dasilva at alum.mit.edu
>>  _______________________________________________
>> gradsusr mailing list
>> gradsusr at gradsusr.org
>> http://gradsusr.org/mailman/listinfo/gradsusr
>>
>>
>>
>> _______________________________________________
>> gradsusr mailing list
>> gradsusr at gradsusr.org
>> http://gradsusr.org/mailman/listinfo/gradsusr
>>
>>
>
>
> --
> Arlindo da Silva
> dasilva at alum.mit.edu
> _______________________________________________
> gradsusr mailing list
> gradsusr at gradsusr.org
> http://gradsusr.org/mailman/listinfo/gradsusr
>
>
> _______________________________________________
> gradsusr mailing list
> gradsusr at gradsusr.org
> http://gradsusr.org/mailman/listinfo/gradsusr
>
>
> --
> Jennifer M. Adams
> IGES/COLA
> 4041 Powder Mill Road, Suite 302
> Calverton, MD 20705
> jma at cola.iges.org
>
>
>
>
> _______________________________________________
> gradsusr mailing list
> gradsusr at gradsusr.org
> http://gradsusr.org/mailman/listinfo/gradsusr
>
>


-- 
Arlindo da Silva
dasilva at alum.mit.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20111101/384b9ea5/attachment-0003.html 


More information about the gradsusr mailing list