| new changes to contour under IDL Version 3.1.1 (sunos sparc) [message #1302] |
Wed, 15 September 1993 17:15  |
sylvain
Messages: 2
Registered: September 1993
|
Junior Member |
|
|
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.
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:).
3) why add the /dowhill keyword and not fix the contour labeling as to be
oriented in such a way as to indicates the downhill direction?
BTW, the hints in notes/sun_motif.doc to get rid of the "harmless, but
anoying" warning about osf keysyms when using the Sun-Motif 3.1.1 executable
are not working. I'm running MIT's X11r4, twm, and have OPENWINHOME defined.
Note that OPENWINHOME is NOT /usr/openwin on our machines!
--
Sylvain G. Korzennik
Harvard-Smithsonian Center for Astrophysics
Solar and Stellar Physics Division. Mail Stop 16.
60 Garden Street, Cambridge, MA 02138.
(617) 495-7451, FTS 830-7451, FAX (617) 495-7049
(sylvain@cfassp.harvard.edu Internet/Arpanet)
or
(sylvain@cfa.harvard.edu Internet/Arpanet)
(cfa::sylvain SPAN/DECnet)
(sylvain@cfa Bitnet/Earn)
(skorzennik SolarMail)
|
|
|
|
| Re: new changes to contour under IDL Version 3.1.1 (sunos sparc) [message #1459 is a reply to message #1302] |
Mon, 04 October 1993 12:06  |
turet
Messages: 7
Registered: January 1993
|
Junior Member |
|
|
It's nice (not good) to hear about similar problems I've been having with
filled contours, etc.
I've got many gripes but I'll just run off a few at the top before I have
to leave for a class.
The color fills aren't working for me... on one set of plots I couldn't get
the lowest level to fill, one that happened to intersect the plot boundary,
i.e. if level=[-2,-1,0,1,2] and there was a region of -0.5, say that inter-
sected the boundary (and that was the minimum on the plot), then that region
wouldn't be filled at all. I tried fooling around with the colors keyword
with no success (the documentation for color contouring seems obscure to me).
I also had problems with a contour filling in the wrong color, i.e.
1 1 1 1 1 1 1 1 1 1 1
1 0 0 0 0 0 0 0 0 0 1
1 0 0 1 1 1 1 1 0 0 1
1 0 0 1 1 1 1 1 0 0 1
1 0 0 0 0 0 0 0 0 0 1
1 1 1 1 1 1 1 1 1 1 1
then the center block would be colored wrong.
I'm not happy with the downhill keyword, at least it should be adjustable,
e.g. downhill=2 or -3 for different length ticks (and uphill)
Speed up MIN_CURVE_SURF or else I'll go to Numerical Recipes (a pain).
I agree with a previous poster about NCAR graphics. The old (v1.0) IDL
had some contour stuff that appeared to be right out of NCAR graphics.
I could really use the markings of highs and lows with the values, and
perhaps symbols H and L.
Contour annotation positioning control is also very important to me. I got
a review of a paper back saying that I should line up the contour labels
so they're not jumbled around the page. I contacted RSI but was told that
contour label positions are determined by a "complicated heuristic", in other
words S.O.L. In one case I couldn't suppress the contour labels outside
the range I used to clip the contours themselves and I ended up with labels
crammed into the edges of the plot. I used a lot of white-out, ended up
losing the labels altogether and having them drawn in.
That reminds me, clip doesn't seem to work at all with color fills, although
I've just been working with v3.1 for a week.
What else? I had the same problem as a previous poster about the misalignment
using MAP_IMAGE with PostScript. RSI suggested that I just measure the
misalignment and apply some type of scaling to get it back in shape. I would
like to have a bit more control of the device parameters.
It also be nice to have the !MAP system variable documented a bit better,
perhaps to use parts of the structure to do some graphics transformations.
Also, it looks like !MAP gets set when you use a MAP_ call but it doesn't
get unset or any other changes made when you do an ordinary graphics call
after that. I would like to have the !MAP variable reflect the current
state of the graphics so I build other routines around this.
One more I promise: I had a routine that did some plotting on top of
graphics that had some xyouts and plots using /normal coordinates. When
the map was set I couldn't plot in normal coordinates outside the [0,1]
range, i.e. xyouts,.1,-.1,'*',/normal wouldn't work. Not only didn't it
work but it froze up my IDL session, I couldn't even Control-C, I had to
Control-\ or kill my window to get out.
What say? do we have a movement here. IDL is starting to set us back some
bucks. I read in the paper that there are all sorts of joint ventures going
on (IBM?) so IDL is starting to go big time. All us readers here are in it
pretty much on the ground floor (quite a way from the LASP days, eh Dave?).
Let's get this thing working right. Also, check out IVE, developed at the
U. of Washington Atm. Sci. department. I don't know the status/availability
of it, but it's a window/interactive thing for NCAR graphics, and it's
beautiful
--Phil Turet
turet@pmel.noaa.gov
|
|
|
|
| Re: new changes to contour under IDL Version 3.1.1 (sunos sparc) [message #1498 is a reply to message #1302] |
Thu, 16 September 1993 09:43 |
thompson
Messages: 584
Registered: August 1991
|
Senior Member |
|
|
rfinch@water.ca.gov (Ralph Finch) writes:
> patrick> 1. Get rid of /MAX_VALUE. put in code to do real handling of
> patrick> missing data.
> Right on! I asked them about doing this some months ago but never got
> a reply.
I suspect that MAX_VALUE was put in to handle a specific project whose missing
data was all above a given value--perhaps Pioneer Venus, but I'm only guessing.
I know that it has been a part of CONTOUR for a long, long time.
Missing data can be handled in a number of ways, but I suspect that the system
I use is similar to what most people do. In my own IDL software, mainly
concerned with image display, I signal missing data values with a single
special value which can be set with the MISSING keyword. Actually the MISSING
keyword also shows up in some of the routines in the User's Library, such as
ROT or MAP_IMAGE.
FITS data files also allow for a single special value to signal missing data.
In the FITS header the particular special value for that data array is given by
the BLANK keyword. Pixels whose value is the same as that of BLANK are
considered to have no data.
If the special value signalling missing data is larger than any value in the
array, then it is consistent with IDL's MAX_VALUE keyword. However, it is
often more convenient to make the special flag value smaller than any possible
data value. For instance, in data arrays whose allowed values can only be
positive, I often set missing pixels to -1.
I think it would be a good idea if the IDL routines that currently accept the
MAX_VALUE keyword would also accept a MISSING keyword (or something like it) as
an alternative. That should be a relatively easy thing to do. Various
names for this keyword could be used, but I think MISSING would be the best,
because it would be consistent with routines already in the IDL User's Library.
Bill Thompson
|
|
|
|
|
|
| Re: new changes to contour under IDL Version 3.1.1 (sunos sparc) [message #1500 is a reply to message #1302] |
Thu, 16 September 1993 07:48 |
andy
Messages: 31
Registered: November 1993
|
Member |
|
|
In article <CDF7EC.E7z@cfanews.harvard.edu>, sylvain@cfassp45.harvard.edu (Sylvain G. Korzennik) writes:
> 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.
>
> 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:).
>
> 3) why add the /dowhill keyword and not fix the contour labeling as to be
> oriented in such a way as to indicates the downhill direction?
>
> --
>
> Sylvain G. Korzennik
>
Amen, brother! We have been on the phone with RSI's phone support, but
after numerous attempts to get sympathy (and a working version of contour),
we have received nothing which is beneficial to us. It's very frustrating
since I have to stick with work-arounds using version 3.0 (an altered polycontour)
and some of our machines are licensed only for version 3.1. If the problems
we have faced are indicative of other users', I doubt that anyone's marriage
has been saved with the release of version 3.1. Let alone 3.11.
))))/ Andy Loughe
, , Goddard Space Flight Center
J Code 971 Bldg. 22 Room 380-B phone : (301) 286-3995
\_/ Greenbelt, MD 20771 e-mail: andy@toto.gsfc.nasa.gov
__/__/ __/ __/ __/__/__/ __/ __/
__/ __/ __/__/ __/ __/ __/ __/ __/
__/ __/ __/ __/ __/ __/ __/ __/ __/
__/__/__/__/ __/ __/ __/ __/ __/ __/
__/ __/ __/ __/__/ __/ __/ __/
__/ __/ __/ __/ __/__/ __/ __/
|
|
|
|
| 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 |
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
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
