matplotlib-users Mailing List for matplotlib

I guess sometimes its best to dig into ipython. I apparently
misunderstood interp, but it seems it doesn't need to be used only
with grids created from a Basemap instance. I created the following
function which accomplishes my goals (I know this shouldn't all be in
one function, I'll look into making it more 'general' as a next step).
If I get around to cleaning it up, I'll repost. --john
def create_land_veg_mask():
 """ Process to convert Gaussian grid data to lat lon (0.5 deg)
 for gridded data inside the grib2 ncep files available here:
 ftp://ftp.ncep.noaa.gov/pub/data/nccf/com/gfs/prod/
 """
 from mpl_toolkits.basemap import interp, shiftgrid
 import pygrib
 def interp_shift(data,lslons,lslats,lonsg,latsg,lons):
 dataout = interp(data.values,lslons[0,:],lslats[:,0],lonsg,latsg)
 data_shft,lon_shft = shiftgrid(-180,dataout.T,lons)
 return lon_shft, lats, data_shft
 grbs = pygrib.open('gfs.t00z.sfluxgrbf03.grib2')
 lsmask = grbs.select(name='Land-sea mask')[0]
 vegtypes = grbs.select(name='Vegetation Type')[0]
 lslats,lslons = lsmask.latlons() #same for vegtypes
 reg_lons = np.arange(-360,0,0.5)
 reg_lats = np.arange(-90,90,0.5)
 latsg,lonsg = np.meshgrid(reg_lats,reg_lons)
 lonsout, lats, vegout =
interp_shift(vegtypes,lslons,lslats,lonsg,latsg,reg_lons)
 lonsout, lats, lsmaskout =
interp_shift(lsmask,lslons,lslats,lonsg,latsg,lons)
 return lonsout,lats,vegout,lsmaskout

On 11/02/2010 04:39 AM, Alan G Isaac wrote:
> On 11/2/2010 10:06 AM, Benjamin Root wrote:
>> I have personally seen significant progress in this area, but there are a few backends that aren't quite right (MacOSX backend, I believe?).
>
>
> I believe multiple uses of ``show`` fail and are expected to fail
> for the foreseeable future when using IDLE to run a script.
This may be true in general; the effort has gone, and will continue to 
go, into getting consistent behavior in ipython and in standalone 
scripts, not in idle. Nevertheless, the simple test running the 
attached script with idle on my linux machine (ubuntu 10.10), with mpl 
from svn, succeeded. This might depend on the default backend, gtkagg 
in my case.
Eric
>
> fwiw,
> Alan Isaac

Hello, I have a set of data on a Gaussian grid. I have a latitude
array, a longitude array, and a data array:
In [121]: vlats.shape
Out[121]: (880, 1760)
In [122]: vlons.shape
Out[122]: (880, 1760)
In [123]: vtypes.shape
Out[123]: (880, 1760)
The longitude seems to go from -360 to 0.6, the latitude is more regular:
In [124]: vlons.min(); vlons.max()
Out[124]: -360.0
Out[124]: 0.59499999999880615
In [125]: vlats.min(); vlats.max()
Out[125]: -89.843513517868473
Out[125]: 89.843513517868473
I thought (and it was also suggested) I could use 'interp' from the
mpl_toolkits.basemap package, but I'm not sure how to do this. Does
anyone have experience with this? An alternative suggestion was to use
the scipy interp capabilities; again, I'm not certain I know how to go
about this.
Thanks,
john

I have a file now, that I created from a NCEP grib file. I'm trying to
get the land sea mask and the veg types into 0.5x0.5 lat/lon regular
grids. However, they are still in Gaussian Grids, but at least I have
it assembled into netcdf files! I'll follow up on a post about the
conversion. but I would be interested in knowing if what I have done
below fits the 'Convention 1.4' definitions:
In [64]: vegtype = grbs.select(name='Vegetation Type')[0]
In [65]: vlats,vlons = vegtype.latlons()
In [67]: vtypes = vegtype.values
In [70]: vtypes.shape
Out[70]: (880, 1760)
In [89]: nco = NetCDFFile('/wrk/jfb/DATASETS_TEMPLATES/JFB_vegtypes.nc','w',format='NETCDF4',zlib=True)
In [91]: nco.createDimension('nrows', 880)
Out[91]: <netCDF4.Dimension object at 0x8365550>
In [92]: nco.createDimension('ncols',1760)
Out[92]: <netCDF4.Dimension object at 0x8365b50>
In [93]: lat = nco.createVariable('lat','f8',('nrows','ncols'),zlib=True)
In [94]: lat[:] = vlats
In [95]: lon = nco.createVariable('lon','f8',('nrows','ncols'),zlib=True)
In [96]: lon[:] = vlons
In [97]: data = nco.createVariable('data','int',('nrows','ncols'),zlib=True)
In [98]: data[:] = vtypes
In [99]: nco.history="Creating a vegetation types mask from the NCEP
ncep.sfluxgrbf03.grb file"
In [100]: nco.units="Integer(0-13)"
In [101]: nco.close()
In [102]: nco =
NetCDFFile('/wrk/jfb/DATASETS_TEMPLATES/JFB_vegtypes.nc',format='NETCDF4',zlib=True)
In [103]: nco.variables.keys()
Out[103]: ['lat', 'lon', 'data']
In [104]: nco.close()
I guess officially, I should add something along the lines of:
float lat(lat) ;
 lat:long_name = "latitude" ;
 lat:units = "degrees_north" ;
 lat:standard_name = "latitude" ;
Thank you,
john
-- 
Configuration
``````````````````````````
Plone 2.5.3-final,
CMF-1.6.4,
Zope (Zope 2.9.7-final, python 2.4.4, linux2),
Python 2.6
PIL 1.1.6
Mailman 2.1.9
Postfix 2.4.5
Procmail v3.22 2001年09月10日
Basemap: 1.0
Matplotlib: 1.0.0

Visit our website at http://www.ubs.com 
This message contains confidential information and is intended only 
for the individual named. If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail. Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system. 
E-mails are not encrypted and cannot be guaranteed to be secure or 
error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or contain viruses. The sender 
therefore does not accept liability for any errors or omissions in the 
contents of this message which arise as a result of e-mail transmission. 
If verification is required please request a hard-copy version. This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities 
or related financial instruments. 
UBS Limited is a company limited by shares incorporated in the United 
Kingdom registered in England and Wales with number 2035362. 
Registered office: 1 Finsbury Avenue, London EC2M 2PP. UBS Limited 
is authorised and regulated by the Financial Services Authority. 
UBS AG is a public company incorporated with limited liability in 
Switzerland domiciled in the Canton of Basel-City and the Canton of 
Zurich respectively registered at the Commercial Registry offices in 
those Cantons with Identification No: CH-270.3.004.646-4 and having 
respective head offices at Aeschenvorstadt 1, 4051 Basel and 
Bahnhofstrasse 45, 8001 Zurich, Switzerland. Registered in the 
United Kingdom as a foreign company with No: FC021146 and having a 
UK Establishment registered at Companies House, Cardiff, with No: 
BR 004507. The principal office of UK Establishment: 1 Finsbury Avenue, 
London EC2M 2PP. In the United Kingdom, UBS AG is authorised and 
regulated by the Financial Services Authority.
UBS reserves the right to retain all messages. Messages are protected 
and accessed only in legally justified cases. 

> From: Nikolaus Rath [mailto:Nik...@ra...] 
> Sent: Saturday, October 30, 2010 16:17
> 
> but if I try to do the same think with the Y axis, everything looks
> messed up (e.g. the matrix is no longer square):
The matrix remains square for me using a build from Subversion. What's your
matplotlib.__version__?

From: Gino Serpa [mailto:gin...@gm...] 
Sent: Sunday, October 31, 2010 13:52
 
I am trying to change the format of the tick labels in a loglog plot from
exponential to decimal.
Right now the labels are 10^2 10 1 10^-1 10^-2
and I would like them to be 100 10 1 0.1 0.01
I tried finding easy explanations in the web with no luck. By the way I have
no clue what a class is and the word instantiation makes me crossed eyed
I hope you don't mind instantiating a class. See the documentation for tick
formatters [1], particularly FormatStrFormatter, and the major_minor_demo1
example [2].
[1] http://matplotlib.sourceforge.net/api/ticker_api.html#tick-formatting
[2]
http://matplotlib.sourceforge.net/examples/pylab_examples/major_minor_demo1.ht
ml

Hi
Thank you.
I installed the latest from svn and it now works.
Regards
Pål
On 2 November 2010 15:21, Benjamin Root <ben...@ou...> wrote:
> On Tue, Nov 2, 2010 at 8:20 AM, Pål Gunnar Ellingsen <pa...@gm...>wrote:
>
>> Hi
>>
>> I'm trying to use the linthershy option for symlog in
>> matplotlib.axes.Axes.set_yscale() <http://matplotlib.sourceforge.net/api/axes_api.html#matplotlib.axes.Axes.set_yscale>for
>> values smaller than 1, but the plot then shows large values (vertical lines)
>> for the points which should have been in the linear range. My code is:
>>
>> import matplotlib.pyplot as plt
>> import numpy as np
>>
>>
>> f1 = np.loadtxt('someDataFile.txt') # file has all y values smaller than 1
>>
>> fig1 = plt.figure(1)
>> ax1 = fig1.add_subplot(111)
>>
>> ax1.plot(f1[:, 0], f1[:, 1])
>>
>> ax1.set_yscale('symlog', linthreshy = 1e-3)
>> ax1.set_ylim(1e-4, 1)
>> ax1.autoscale(enable = True, axis = 'x', tight = True)
>>
>> plt.draw()
>> plt.show()
>> ---------------
>> Another and testable code is
>>
>> import matplotlib
>> matplotlib.use('Qt4Agg')
>> import matplotlib.pyplot as plt
>> import numpy as np
>>
>> fig1 = plt.figure(1)
>> A = 10 + 9.999999999 * np.sin(2 * np.pi * np.arange(0.01, 1, 0.01))
>>
>> ax1 = fig1.add_subplot(111)
>> ax1.plot(A)
>>
>> ax1.set_yscale('symlog', linthreshy = 1e-6)
>> ax1.set_ylim(0, 20) # change this to ax1.set_ylim(0, 0.7) for strange
>> lines
>>
>>
>> fig2 = plt.figure(2)
>> ax2 = fig2.add_subplot(111)
>> ax2.plot(A)
>> ax2.set_yscale('log')
>> ax2.set_ylim(0, 20)
>> ax2.autoscale(enable = True, axis = 'both', tight = True)
>>
>> plt.draw()
>> plt.show()
>>
>> Which does not show correct labels and the linear part is gone (only a
>> straight line).
>> Does anyone have a solution for these problems?
>>
>> Regards
>>
>> Pål
>>
>>
> This was a bug found fairly recently. In the case where the linthresh was
> less than 1.0:
>
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=3081451&group_id=80706&atid=560720
>
> I don't know if the patch was backported to the maintenance branch, but I
> am fairly sure it would have been.
>
> I hope this was helpful,
> Ben Root
>
>

On 11/2/2010 10:06 AM, Benjamin Root wrote:
> I have personally seen significant progress in this area, but there are a few backends that aren't quite right (MacOSX backend, I believe?).
I believe multiple uses of ``show`` fail and are expected to fail
for the foreseeable future when using IDLE to run a script.
fwiw,
Alan Isaac

On Tue, Nov 2, 2010 at 8:20 AM, Pål Gunnar Ellingsen <pa...@gm...>wrote:
> Hi
>
> I'm trying to use the linthershy option for symlog in
> matplotlib.axes.Axes.set_yscale() <http://matplotlib.sourceforge.net/api/axes_api.html#matplotlib.axes.Axes.set_yscale>for
> values smaller than 1, but the plot then shows large values (vertical lines)
> for the points which should have been in the linear range. My code is:
>
> import matplotlib.pyplot as plt
> import numpy as np
>
>
> f1 = np.loadtxt('someDataFile.txt') # file has all y values smaller than 1
>
> fig1 = plt.figure(1)
> ax1 = fig1.add_subplot(111)
>
> ax1.plot(f1[:, 0], f1[:, 1])
>
> ax1.set_yscale('symlog', linthreshy = 1e-3)
> ax1.set_ylim(1e-4, 1)
> ax1.autoscale(enable = True, axis = 'x', tight = True)
>
> plt.draw()
> plt.show()
> ---------------
> Another and testable code is
>
> import matplotlib
> matplotlib.use('Qt4Agg')
> import matplotlib.pyplot as plt
> import numpy as np
>
> fig1 = plt.figure(1)
> A = 10 + 9.999999999 * np.sin(2 * np.pi * np.arange(0.01, 1, 0.01))
>
> ax1 = fig1.add_subplot(111)
> ax1.plot(A)
>
> ax1.set_yscale('symlog', linthreshy = 1e-6)
> ax1.set_ylim(0, 20) # change this to ax1.set_ylim(0, 0.7) for strange lines
>
>
> fig2 = plt.figure(2)
> ax2 = fig2.add_subplot(111)
> ax2.plot(A)
> ax2.set_yscale('log')
> ax2.set_ylim(0, 20)
> ax2.autoscale(enable = True, axis = 'both', tight = True)
>
> plt.draw()
> plt.show()
>
> Which does not show correct labels and the linear part is gone (only a
> straight line).
> Does anyone have a solution for these problems?
>
> Regards
>
> Pål
>
>
This was a bug found fairly recently. In the case where the linthresh was
less than 1.0:
http://sourceforge.net/tracker/index.php?func=detail&aid=3081451&group_id=80706&atid=560720
I don't know if the patch was backported to the maintenance branch, but I am
fairly sure it would have been.
I hope this was helpful,
Ben Root

On Tue, Nov 2, 2010 at 9:00 AM, John <was...@gm...> wrote:
> Thanks Ben!
>
> I guess where I am with this now is that I have found, as you say, the
> VGTYP in the
> operational products (the *sflux* grib files), but I don't find it on
> any of the 0.5 x 0.5 degree files. Which means, that as you say, I'll
> have to figure out how to reproject the data from the Gaussian grid to
> a regular grid with 0.5x0.5 lat lon coordinates.
>
> Any thoughts on that process?? :D
>
> Thanks again,
> john
>
>
>
I haven't tried doing conversions between two different projections, but
maybe the Basemap package might be useful?
http://matplotlib.sourceforge.net/basemap/doc/html/
Basically, you could get the arrays of x and y positions of your data, and
then determine what would be the x and y positions of the projection that
you want, and then use scipy's griddata to produce the results on the grid
you want:
http://docs.scipy.org/doc/scipy/reference/generated/scipy.interpolate.griddata.html#scipy.interpolate.griddata
This is a bit brute-force, and I am sure there are more elegant solutions,
but that should work in a pinch.
Ben Root

On Tue, Nov 2, 2010 at 8:31 AM, Daπid <dav...@gm...> wrote:
> On Tue, Nov 2, 2010 at 12:49 PM, David Kremer <dav...@gm...>
> wrote:
> > Personally I used show() yesterday, and it blocks the execution until
> > the figure's window is closed. It is of perfect convenience I think,
> > as a default behavior.
>
> Yes, this is the optimal behavior, but it is not fully implemented, as
> seen in the documentation.
>
>
I have personally seen significant progress in this area, but there are a
few backends that aren't quite right (MacOSX backend, I believe?). Anyway,
some effort was made right before the 1.0.0 release, but it was soon
discovered that it was still not right (and even caused some regressions, I
believe). So, shortly there-after, a lot of work went into making the
behavior more uniform across all backends.
If the show() behavior is currently not working properly for you, I would
suggest building from source (if possible) the maintenance v1.0.0 branch
which has it mostly right (I believe the only exception is the macosx
backend). If that isn't possible, there have been talks of soon releasing a
v1.0.1 package which would contain all of those fixes.
Note, I am not an authority in this matter as I was only just joining the
development group at around that time, but I hope this answers your
question.
Ben Root

Thanks Ben!
I guess where I am with this now is that I have found, as you say, the
VGTYP in the
operational products (the *sflux* grib files), but I don't find it on
any of the 0.5 x 0.5 degree files. Which means, that as you say, I'll
have to figure out how to reproject the data from the Gaussian grid to
a regular grid with 0.5x0.5 lat lon coordinates.
Any thoughts on that process?? :D
Thanks again,
john
>
> John,
>
> GRIB files are an interesting beast. It has been awhile since I have dealt
> with them, but I will try to help you with what I can recall. First, the
> data records in the files are indicated by:
>
> 1. Record number
> 2. Position in bytes
> 3. Date (YYMMDDHH).
> 4. Parameter name (LAND=land/sea mask)
> 5. Indicator of parameter and units (grib PDS octet 9)
> 6. Type of level/layer (grib PDS octet 10)
>
>
> 7. Height, pressure, etc (grib PDS octets 11-12)
> 8. Time Range (grib PDS octet 21)
> 9. Period of time 1, (grib PDS octet 19)
> 10. Period of time 2, (grib PDS octet 20)
> 11. Forecast time unit (grib PDS octet 18)
>
>
> 12. level
> 13. anl=analysis, fcst=forecast
> 14. NAve (number of grids used to make average)
>
> The "type of level/layer" I believe is the grid projection type. Anyway,
> these things can be mixed and matched, so all we need to do is find your
> parameter in the grid projection that you want (or you will have to
> re-project the data).
>
> The operational models appear to have VGTYP, but the reanalysis products do
> not appear to have this. Maybe this is causing your confusion?
>
> This page might be more useful to you:
> http://www.cpc.noaa.gov/products/wesley/wgrib.html
>
> I hope this is useful,
> Ben Root
>
>
-- 
Configuration
``````````````````````````
Plone 2.5.3-final,
CMF-1.6.4,
Zope (Zope 2.9.7-final, python 2.4.4, linux2),
Python 2.6
PIL 1.1.6
Mailman 2.1.9
Postfix 2.4.5
Procmail v3.22 2001年09月10日
Basemap: 1.0
Matplotlib: 1.0.0

On Tue, Nov 2, 2010 at 5:19 AM, John <was...@gm...> wrote:
> Maybe I should also follow up on this and indicate that one variable I
> really want is the Veg Type defiinitions from the files. It exists in
> the file from joewheatley's example, (VGTYP_P0_L1_GGA0) but it is on a
> Gaussian lat/lon grid. I've downloaded some of the gfs files from the
> 0.5 x 0.5 degree output, but I don't find the variable.
>
> Thanks again!
>
> On Tue, Nov 2, 2010 at 10:33 AM, John <was...@gm...> wrote:
> > Folks,
> >
> > I'm trying to find documentation online that provides guidance on what
> > all the variables are that are in the NCEP model output grib files.
> > There are many NCEP models, so to be clear, I'm referring to the GFS
> > 0.5x0.5 degree product. I was looking at this nice blog:
> >
> > http://joewheatley.net/ncep-global-forecast-system/
> >
> > and the files that are available here:
> > ftp://ftp.ncep.noaa.gov/pub/data/nccf/com/gfs/prod
> >
> > And I see this link:
> > http://www.nco.ncep.noaa.gov/pmb/products/gfs/
> >
> > But looking at a file and the variables:
> > In [112]: ncep.variables.keys()
> > Out[112]:
> > ['PRES_P8_L223_GLL0_avg',
> > 'TOZNE_P0_L200_GLL0',
> > 'PRES_P0_L242_GLL0',
> > 'HGT_P0_L100_GLL0',
> > 'VVEL_P0_L100_GLL0',
> > 'UGRD_P0_L6_GLL0',
> > 'HGT_P0_L7_GLL0',
> > 'CIN_P0_2L108_GLL0',
> > 'ULWRF_P8_L8_GLL0_avg',
> > 'PRES_P0_L109_GLL0',
> > (snip)
> >
> > is somewhat clear in most cases, but is there a table which directly
> > maps these online?. Also, you can of course look at the 'long_name',
> > 'level', and 'level_type' attributes of each variable, but I'm looking
> > more or less for an online table showing all this. Maybe I need to
> > script it quickly ;)
> >
> > Thanks,
> > john
> >
>
>
John,
GRIB files are an interesting beast. It has been awhile since I have dealt
with them, but I will try to help you with what I can recall. First, the
data records in the files are indicated by:
 1. Record number
 2. Position in bytes
 3. Date (YYMMDDHH).
 4. Parameter name (LAND=land/sea mask)
 5. Indicator of parameter and units (grib PDS octet 9)
 6. Type of level/layer (grib PDS octet 10)
 7. Height, pressure, etc (grib PDS octets 11-12)
 8. Time Range (grib PDS octet 21)
 9. Period of time 1, (grib PDS octet 19)
 10. Period of time 2, (grib PDS octet 20)
 11. Forecast time unit (grib PDS octet 18)
 12. level
 13. anl=analysis, fcst=forecast
 14. NAve (number of grids used to make average)
The "type of level/layer" I believe is the grid projection type. Anyway,
these things can be mixed and matched, so all we need to do is find your
parameter in the grid projection that you want (or you will have to
re-project the data).
The operational models appear to have VGTYP, but the reanalysis products do
not appear to have this. Maybe this is causing your confusion?
This page might be more useful to you:
http://www.cpc.noaa.gov/products/wesley/wgrib.html
I hope this is useful,
Ben Root

On Tue, Nov 2, 2010 at 12:49 PM, David Kremer <dav...@gm...> wrote:
> Personally I used show() yesterday, and it blocks the execution until
> the figure's window is closed. It is of perfect convenience I think,
> as a default behavior.
Yes, this is the optimal behavior, but it is not fully implemented, as
seen in the documentation.

Hi
I'm trying to use the linthershy option for symlog in
matplotlib.axes.Axes.set_yscale()
<http://matplotlib.sourceforge.net/api/axes_api.html#matplotlib.axes.Axes.set_yscale>for
values smaller than 1, but the plot then shows large values (vertical lines)
for the points which should have been in the linear range. My code is:
import matplotlib.pyplot as plt
import numpy as np
f1 = np.loadtxt('someDataFile.txt') # file has all y values smaller than 1
fig1 = plt.figure(1)
ax1 = fig1.add_subplot(111)
ax1.plot(f1[:, 0], f1[:, 1])
ax1.set_yscale('symlog', linthreshy = 1e-3)
ax1.set_ylim(1e-4, 1)
ax1.autoscale(enable = True, axis = 'x', tight = True)
plt.draw()
plt.show()
---------------
Another and testable code is
import matplotlib
matplotlib.use('Qt4Agg')
import matplotlib.pyplot as plt
import numpy as np
fig1 = plt.figure(1)
A = 10 + 9.999999999 * np.sin(2 * np.pi * np.arange(0.01, 1, 0.01))
ax1 = fig1.add_subplot(111)
ax1.plot(A)
ax1.set_yscale('symlog', linthreshy = 1e-6)
ax1.set_ylim(0, 20) # change this to ax1.set_ylim(0, 0.7) for strange lines
fig2 = plt.figure(2)
ax2 = fig2.add_subplot(111)
ax2.plot(A)
ax2.set_yscale('log')
ax2.set_ylim(0, 20)
ax2.autoscale(enable = True, axis = 'both', tight = True)
plt.draw()
plt.show()
Which does not show correct labels and the linear part is gone (only a
straight line).
Does anyone have a solution for these problems?
Regards
Pål

2010年11月2日 Michael Droettboom <md...@st...>:
> On 11/02/2010 07:49 AM, David Kremer wrote:
>> Personally I used show() yesterday, and it blocks the execution until
>> the figure's window is closed. It is of perfect convenience I think,
>> as a default behavior.
>>
>> However, I would like to add an option to show() like eg :
>>
>>
>>> show( save_image = True , format = 'eps' )
>>>
> Do you mean this to do what savefig() already does?
>
> Mike
>
Yes sorry I was wrong.

On 11/02/2010 07:49 AM, David Kremer wrote:
> Personally I used show() yesterday, and it blocks the execution until
> the figure's window is closed. It is of perfect convenience I think,
> as a default behavior.
>
> However, I would like to add an option to show() like eg :
>
> 
>> show( save_image = True , format = 'eps' )
>> 
Do you mean this to do what savefig() already does?
Mike
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Personally I used show() yesterday, and it blocks the execution until
the figure's window is closed. It is of perfect convenience I think,
as a default behavior.
However, I would like to add an option to show() like eg :
> show( save_image = True , format = 'eps' )
As it permits to mix the two behavior : interrupt script execution and
let the execution be continued if the user decides so.
I don't know if it's possible, but I would like it be.
Kind regards.
David
2010年11月2日 Daπid <dav...@gm...>:
> Hello.
>
> It is stated that show() should be the last function in a script, as
> long as it will stop the execution of the program. Nevertheless, I
> have seen that the current behavior is just a pause in the flow, and
> it will be restored when the window is closed. The documentation says:
>
>
> "Many users are frustrated by show because they want it to be a
> blocking call that raises the figure, pauses the script until the
> figure is closed, and then allows the script to continue running until
> the next figure is created and the next show is made.[...]
>
> This is not what show does and unfortunately, because doing blocking
> calls across user interfaces can be tricky, is currently unsupported,
> though we have made some progress towards supporting blocking events."
>
> My question is: what is the real state of the art of the feature? Is
> this something that could be safely exploited, or just an experimental
> property not recommended?
>
>
> I am using Matplotlib v.1.0 and Python 2.5 over Windows XP and TkAgg backend.
>
>
> Thanks in advance.
>
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
> 10ドル million total in prizes - 4ドルM cash, 500 devices, nearly 6ドルM in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Hello.
It is stated that show() should be the last function in a script, as
long as it will stop the execution of the program. Nevertheless, I
have seen that the current behavior is just a pause in the flow, and
it will be restored when the window is closed. The documentation says:
"Many users are frustrated by show because they want it to be a
blocking call that raises the figure, pauses the script until the
figure is closed, and then allows the script to continue running until
the next figure is created and the next show is made.[...]
This is not what show does and unfortunately, because doing blocking
calls across user interfaces can be tricky, is currently unsupported,
though we have made some progress towards supporting blocking events."
My question is: what is the real state of the art of the feature? Is
this something that could be safely exploited, or just an experimental
property not recommended?
I am using Matplotlib v.1.0 and Python 2.5 over Windows XP and TkAgg backend.
Thanks in advance.

Maybe I should also follow up on this and indicate that one variable I
really want is the Veg Type defiinitions from the files. It exists in
the file from joewheatley's example, (VGTYP_P0_L1_GGA0) but it is on a
Gaussian lat/lon grid. I've downloaded some of the gfs files from the
0.5 x 0.5 degree output, but I don't find the variable.
Thanks again!
On Tue, Nov 2, 2010 at 10:33 AM, John <was...@gm...> wrote:
> Folks,
>
> I'm trying to find documentation online that provides guidance on what
> all the variables are that are in the NCEP model output grib files.
> There are many NCEP models, so to be clear, I'm referring to the GFS
> 0.5x0.5 degree product. I was looking at this nice blog:
>
> http://joewheatley.net/ncep-global-forecast-system/
>
> and the files that are available here:
> ftp://ftp.ncep.noaa.gov/pub/data/nccf/com/gfs/prod
>
> And I see this link:
> http://www.nco.ncep.noaa.gov/pmb/products/gfs/
>
> But looking at a file and the variables:
> In [112]: ncep.variables.keys()
> Out[112]:
> ['PRES_P8_L223_GLL0_avg',
> 'TOZNE_P0_L200_GLL0',
> 'PRES_P0_L242_GLL0',
> 'HGT_P0_L100_GLL0',
> 'VVEL_P0_L100_GLL0',
> 'UGRD_P0_L6_GLL0',
> 'HGT_P0_L7_GLL0',
> 'CIN_P0_2L108_GLL0',
> 'ULWRF_P8_L8_GLL0_avg',
> 'PRES_P0_L109_GLL0',
> (snip)
>
> is somewhat clear in most cases, but is there a table which directly
> maps these online?. Also, you can of course look at the 'long_name',
> 'level', and 'level_type' attributes of each variable, but I'm looking
> more or less for an online table showing all this. Maybe I need to
> script it quickly ;)
>
> Thanks,
> john
>
-- 
Configuration
``````````````````````````
Plone 2.5.3-final,
CMF-1.6.4,
Zope (Zope 2.9.7-final, python 2.4.4, linux2),
Python 2.6
PIL 1.1.6
Mailman 2.1.9
Postfix 2.4.5
Procmail v3.22 2001年09月10日
Basemap: 1.0
Matplotlib: 1.0.0

Folks,
I'm trying to find documentation online that provides guidance on what
all the variables are that are in the NCEP model output grib files.
There are many NCEP models, so to be clear, I'm referring to the GFS
0.5x0.5 degree product. I was looking at this nice blog:
http://joewheatley.net/ncep-global-forecast-system/
and the files that are available here:
 ftp://ftp.ncep.noaa.gov/pub/data/nccf/com/gfs/prod
And I see this link:
http://www.nco.ncep.noaa.gov/pmb/products/gfs/
But looking at a file and the variables:
In [112]: ncep.variables.keys()
Out[112]:
['PRES_P8_L223_GLL0_avg',
 'TOZNE_P0_L200_GLL0',
 'PRES_P0_L242_GLL0',
 'HGT_P0_L100_GLL0',
 'VVEL_P0_L100_GLL0',
 'UGRD_P0_L6_GLL0',
 'HGT_P0_L7_GLL0',
 'CIN_P0_2L108_GLL0',
 'ULWRF_P8_L8_GLL0_avg',
 'PRES_P0_L109_GLL0',
(snip)
is somewhat clear in most cases, but is there a table which directly
maps these online?. Also, you can of course look at the 'long_name',
'level', and 'level_type' attributes of each variable, but I'm looking
more or less for an online table showing all this. Maybe I need to
script it quickly ;)
Thanks,
john

I attempted to install Pylab on my own computer and so far have had no
success. I followed these steps:
1) downloaded Python 2.6 for OS 10.4
2) downloaded the corresponding numpy and installed it (successfully)
3) downloaded the corresponding matplotlib
(matplotlib-1.0.0-python.org-py2.6-macosx10.4.dmg) and installed it [One
possible cause for the error is that, though the package includes
"macosx10.4", the actual installing package (which one can see if one tries
a customized install) says "macosx10.5".]
4) Attempted to run Python and import Pylab. I got an error related to
_tkinter not being found (even though it is installed). I looked all over
the forums for this error, and it seems that the only solution is to edit
the setup.py file and recompile matplotlib. However, because I installed
from a binary, I cannot do this. So I attempted to install from source:
5) I downloaded matplotlib-1.0.0.tar.gz and untarred it. Then I ran:
'make' (which supposedly takes care of finding out where all the Mac stuff
is located) and 
'python setup.py build', the default command for building Python modules.
Now I get a ton of errors, the first one being:
freetype2: found, but unknown version (no pkg-config)
* WARNING: Could not find 'freetype2' headers in any
* of '.', './freetype2'.
As a third try, I attempted to install using easy_install, a tool for
installing Python modules:
6) I ran 'easy_install matplotlib'. This runs very quickly (suspicious)
7) The same error as in step 4 comes up when trying to import pylab
 I went into
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/
and deleted all matplotlib-related stuff, thinking that maybe easy_install
didn't do anything because matplotlib was already installed
9) Repeated step 6, and saw the same errors that came up when trying to
install from source
Any ideas?
Thanks,
Pablo
-- 
View this message in context: http://old.nabble.com/Installing-matplotlib-on-Tiger-tp30112187p30112187.html
Sent from the matplotlib - users mailing list archive at Nabble.com.