| OPLOT fails intermittently, any ideas? [message #25807] |
Mon, 16 July 2001 12:05  |
bleau
Messages: 24
Registered: November 1993
|
Junior Member |
|
|
Hello, IDLers, I have a tricky problem here. First, my config: I'm on OpenVMS
7.1-2, running IDL 5.2. I'm using PLOT and OPLOT to generate a graph for
display on a web page. Most of the time this works well. Once in a while,
though, with no change in the IDL code, I get the error message
% OPLOT: No valid points, must have at least 2 distinct points
% Execution halted at: $MAIN$ 253
DISKM1:[SOHO.TEST]SEM4HRPLOT_MAIN.PRO;27
Line 253 is the oplot command. Here it is:
oplot, epoch-base_epoch, values(*,k), $
max_value = 9999998., $
psym = 8, $ ; plots a circle (user defined)
symsize = .4, $ ; scale factor for plot symbol
thick = plot_thickness(k), $
color = 13 ; change this for colored data line
A word here about the odd construct. The X array is a double precision vector
(epoch) containing times minus a scalar (base_epoch), which is slightly less
than the first (lowest) value of epoch, which is monotonically increasing.
Since plot and oplot convert from double to single internally, when labelling
the time axis this causes incorret labels to be used. By passing the
difference this puts the values to be plotted in a range in which roundoff is
not a problem. The X range that was set on the previous plot command has been
adjusted similarly.
Here's a diagnostic output; the first column is the date in Gregorian format,
the second in Epoch format, and the third in Epoch format minus the base_epoch
value. The two lines are the low and high end used for the x-axis range; the
third colum is what I passed to the previous call to plot for the x_range
keyword.
range used on X-axis is:
2001/07/16 11:00:00 3.6412920e+08 0.00000000
2001/07/16 15:00:00 3.6414360e+08 14400.000
I checked the arrays being passed to oplot; both are vectors of length 410.
I also dumped a couple points in the x-axis vector (epoch) to make sure they
are different; they are. The y-axis values look fine, too. Here's the output
of the following commands:
help,epoch-base_epoch
<Expression> DOUBLE = Array[409]
help,values(*,k)
<Expression> FLOAT = Array[409]
print,values(0,k)
2186.24
print,fmtepoch(epoch(0))
2001/07/16 11:00:46
print,fmtepoch(epoch(408))
2001/07/16 15:03:01
print,fmtepoch(base_epoch)
2001/07/16 11:00:00
print,epoch(409)-base_epoch
14581.000
I'm puzzled by the error message that oplot gave me (No valid points, must have
at least 2 distinct points). The obvious reason - one of the vectors has only
one point - is false, as seen above.
The second reason I thought might be the case is that the range given to the
plot command, and therefore in use for the call to oplot, did not contain the
values passsed to oplot for the x-axis. This, too, is shown to be false.
I'm out of ideas. What's worse, this problem is not consistent. It appears
every few days, once that day, then goes away. This IDL code is called from a
procedure that runs hourly and works on slightly different data each time. So
it would appear to be data dependent. I managed to save a copy of the data set
that caused it to fail today, and can reproduce the failed behavior, so I have
a chance at diagnosing this. I just need some hints at where to look next.
Thanks.
Lawrence Bleau
University of Maryland
Physics Dept., Space Physics Group
301-405-6223
bleau@umtof.umd.edu
|
|
|
|
| Re: OPLOT fails intermittently, any ideas? [message #25841 is a reply to message #25807] |
Thu, 19 July 2001 14:52  |
Dave Greenwood
Messages: 33
Registered: October 2000
|
Member |
|
|
In a previous article, bleau@umtof.umd.edu (Lawrence Bleau) wrote:
> In article <3B5748F3.F55D02AF@lheapop.gsfc.nasa.gov>, tam <tam@lheapop.gsfc.nasa.gov> writes:
>>
>> Purely as a possible workaround...
>>
>> If you're running on a platform with X-windows and your IDL sessions are
>> running in an environment in which the console is known, then you could probably
>> use X-window PIXMAPs instead of the Z buffer. E.g.,
> [snip]
>
> This has to work in a batch job environment, no access to X-window display (or
> *any* display). Good thought, though.
That might depend on how you define "no access" ;-) You can issue
SET DISPLAY/CREATE within a batch job. You'd only need an X terminal
which would accept a connection from IDL. Using /TRANSPORT=TCPIP
would mean you wouldn't have to worry about username checking - just
the node on which the batch queue is running.
Dave
--------------
Dave Greenwood Email: Greenwoodde@ORNL.GOV
Oak Ridge National Lab %STD-W-DISCLAIMER, I only speak for myself
|
|
|
|
| Re: OPLOT fails intermittently, any ideas? [message #25842 is a reply to message #25807] |
Thu, 19 July 2001 14:49 |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
bleau@umtof.umd.edu (Lawrence Bleau) writes:
> In article <3B558E4C.15326C2C@fz-juelich.de>, Reimar Bauer <r.bauer@fz-juelich.de> writes:
>> If you are able to make sav files of the data when it happens,
>> some of us in this news group probably could see if it will be a problem
>> in idl5.4 /idl5.4.1 too.
>>
>> We need for this test a small programm script and the sav data.
>
> Done. Go to umtof.umd.edu, anonymous ftp, and get the files bug.pro and
> oplot_saveall.sav . Do a .run bug.pro, it'll do the restore and the plot/oplot
> pair.
>
> I'm using Z-buffer, btw.
Lawrence, I tried downloading your code and save file. [ In the
future, please do not save system variables, because, *poof* there
goes my path! ]
I did not get the error message you reported. The resulting image I
got, when I TVRD()'d the Z buffer, was a plot from 1100 to 1400 hours.
The data was a wiggly trace that ranged from about 600 to 2000. The
image was clipped slightly on the bottom. Other than that, it seemed
fine. Feel free to forward this information to RSI.
IDL> print, !version
{ x86 linux unix 5.3 Nov 11 1999}
Craig
--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
|
|
|
|
|
|
| Re: OPLOT fails intermittently, any ideas? [message #25844 is a reply to message #25807] |
Thu, 19 July 2001 13:54 |
tam
Messages: 48
Registered: February 2000
|
Member |
|
|
Lawrence Bleau wrote:
>
...>
> My thanks to Doug for confirming this is a problem elsewhere. Now to fix
> it.... If any of you comes up with a combo that works around the bug, please
> inform this group and I'll test it on my system. I use the Z-buffer to have
> IDL prepare - in a noninteractive session - a plot to be written to a disk file
> in GIF format.
>
> Lawrence Bleau
Purely as a possible workaround...
If you're running on a platform with X-windows and your IDL sessions are
running in an environment in which the console is known, then you could probably
use X-window PIXMAPs instead of the Z buffer. E.g.,
set_plot,'X'
window,1,/pixmap,xsize=nx, ysize=ny
... plotting ...
c = tvrd()
write_gif,...
shouldn't actually send anything to the display.
However if the IDL session doesn't know about an X-windows device
this won't work. So if by non-interactive session you mean a job
on a batch queue this probably doesn't help, but if you just mean
that you're running IDL from a script it might do the trick.
Tom McGlynn
NASA/GSFC
Posted and Mailed
|
|
|
|
| Re: OPLOT fails intermittently, any ideas? [message #25845 is a reply to message #25807] |
Thu, 19 July 2001 12:04 |
bleau
Messages: 24
Registered: November 1993
|
Junior Member |
|
|
In article <3B558E4C.15326C2C@fz-juelich.de>, Reimar Bauer <r.bauer@fz-juelich.de> writes:
> If you are able to make sav files of the data when it happens,
> some of us in this news group probably could see if it will be a problem
> in idl5.4 /idl5.4.1 too.
>
> We need for this test a small programm script and the sav data.
Done. Go to umtof.umd.edu, anonymous ftp, and get the files bug.pro and
oplot_saveall.sav . Do a .run bug.pro, it'll do the restore and the plot/oplot
pair.
I'm using Z-buffer, btw.
> And you should give this to technical support at rsinc too.
I already did. Actually, I just received a reply from them this morning, not
good. Here's what Doug Loucks, Technical Support Engineer for RSI, said:
> Thank you for helping out with a test case.
>
> We verified that this is a bug and it appears in IDL 5.5 as well, so it
> isn't restricted to the VMS platform.
>
> Unfortunately, we don't know of a way to work around the problem at this
> time. You might try removing the PSYM; we found that the problem did not
> occur if PSYM is not used. If you can find another approach that doesn't use
> the Z Buffer, that might help.
>
> This bug may be very difficult to track down, since it seems to be related
> to combinations of OPLOT, PSYM, and the Z Buffer.
>
> Apologies for any inconveniences ths may have caused. The information and
> test case you have provided are valuable and we appreciate your efforts in
> putting them together.
My thanks to Doug for confirming this is a problem elsewhere. Now to fix
it.... If any of you comes up with a combo that works around the bug, please
inform this group and I'll test it on my system. I use the Z-buffer to have
IDL prepare - in a noninteractive session - a plot to be written to a disk file
in GIF format.
Lawrence Bleau
University of Maryland
Physics Dept., Space Physics Group
301-405-6223
bleau@umtof.umd.edu
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
