Re: OPLOT fails intermittently, any ideas?

[Paul van Delst <paul.vandelst(at)noaa.gov>]

I think IDL 5.2 plots everything in single precision - no matter what you actually arrays
are typed as. So you may be getting no valid numbers, or distinct ones, if all the digits
that matter (beyond the 6 or so available for single precision) are being truncated and
tossed. This has been talked about previously on this ng with respect to the same thing:
epoch, long digits times/dates etc.

A solution may be to test the single precision unique values of (epoch-base_epoch) before
to see if this really is what is causing it. Or, you could subtract and scale the x-axis
values so that single precision can handle any value (then just modify your axis label
with "Time (x1.0e+08)" or something like that).

cheers,

paulv


Lawrence Bleau wrote:
> 
> 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

-- 
Paul van Delst           A little learning is a dangerous thing;
CIMSS @ NOAA/NCEP        Drink deep, or taste not the Pierian spring;
Ph: (301)763-8000 x7274  There shallow draughts intoxicate the brain,
Fax:(301)763-8545        And drinking largely sobers us again.
                                         Alexander Pope.