comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » new changes to contour under IDL Version 3.1.1 (sunos sparc)
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: new changes to contour under IDL Version 3.1.1 (sunos sparc) [message #1501 is a reply to message #1302] Thu, 16 September 1993 05:24 Go to previous message
pat is currently offline  pat
Messages: 25
Registered: June 1992
Junior Member
Sylvain G. Korzennik (sylvain@cfassp45.harvard.edu) wrote:
> Despite IDL's newsletter bragging about saving someone marriage by changing
> the CONTOUR routine (sic, see IDL's newsletter "spring 1993"), I get very
> frustrated by the new version.

> 1) the userlib function MIN_CURVE_SURF is NOT equivalent to the keyword
> /spline: indeed, MIN_CURVE_SURF() takes forever to process any medium size
> array (ie a 40x20), while /splines will work fine, and. Adding a new userlib
> function is improvement, but dropping a usefull keyword definitively isn't.

MIN_CURVE_SURF is *incredibly* slow. I have a 55x81 grid that i'm
trying to contour. On a SPARC 10 it takes about a half hour. That is not
acceptable.

> 2) the /fill option is broken when trying to fill only 1 level, why so?:

> IDL> lvls=[.05,.1,.2,.5,.7,9]
> IDL> contour, zz, levels =lvls, xx, yy, /xsty, /ysty
> IDL> contour, zz, levels =[0.5], xx, yy, /xsty, /ysty, /fill, /overplot
> % Program caused arithmetic error: Integer divide by 0
> % Detected at $MAIN$ (CONTOUR).

> This sound to me like a bug (not a feature:).

The new contour,/fill code is broken in a lot of ways. We have a
couple of very simple test programs which demonstrate how screwed up it is.
We (my group) spoke with some RSI staff recently and conveyed our problems
to them. Until the contour routine works as advertised, we will *not* be
upgrading from 3.0.

We used to use NCAR graphics a lot. Even though IDL is a *much*
easier package to use than NCARG, there are a few things that IDL just
can't do. Here are a few of my gripes:

1. Get rid of /MAX_VALUE. put in code to do real handling of
missing data. In NCARG, this was called the SPV (special value) parameter.
When you're plotting satellite data, this happens all the time. This is
especially important when you contour a field of data but you *don't* want
to contour over land surfaces.
2. Put in a really slick irregular data interpolator. NCARG's
BIVAR code is pretty good.
3. Make MAP_SET more sophisticated. Allow the user to color in the
continents (another thing NCARG does well).

In case you haven't guessed, we do atmosphere and ocean modeling.
A lot of the data we look at is over an irregular grid which lays over the
North Pole. This data is a bear to contour in *any* package but IDL could
make things easier.
My solution is: Call RSI! Since we all need support contracts now,
we can all call them. They won't know what's wrong unless we tell them.
Don't assume that posting gripes here will make IDL's developers work any
faster.

--
"Now about those pictures..."
"I can explain! I was young! I needed the money!.."

patrick m. ryan
nasa / goddard space flight center / oceans and ice branch / hughes stx
pat@jaameri.gsfc.nasa.gov / patrick.m.ryan@gsfc.nasa.gov
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: pvwave & hdf
Next Topic: Problem with FFT routine in PV-Wave

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Sun Oct 26 02:37:03 PDT 2025

Total time taken to generate the page: 1.76021 seconds