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

Home » Public Forums » archive » Re: OPLOT fails intermittently, any ideas?
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: OPLOT fails intermittently, any ideas? [message #25794 is a reply to message #25784] Tue, 17 July 2001 10:23 Go to previous messageGo to previous message
R.Bauer is currently offline  R.Bauer
Messages: 1424
Registered: November 1998
Senior Member
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
>

Hope I can give some hints

max_value is a double but will be interpreted as float.

a=9999998.
IDL> help,a
A FLOAT = 1.00000e+07


For example I don't know if you did so

x=findgen(10)+9999998.
print,x
1.00000e+07 1.00000e+07 1.00000e+07 1.00000e+07 1.00000e+07
1.00000e+07
1.00000e+07 1.00000e+07 1.00000e+07 1.00000e+07


If you like to calculate in double you should do

x=findgen(10)+9999998.D
print,x
9999998.0 9999999.0 10000000. 10000001.
10000002. 10000003. 10000004. 10000005.
10000006. 10000007.



regards
Reimar






> 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

--
Reimar Bauer

Institut fuer Stratosphaerische Chemie (ICG-1)
Forschungszentrum Juelich
email: R.Bauer@fz-juelich.de
http://www.fz-juelich.de/icg/icg1/
============================================================ ======
a IDL library at ForschungsZentrum Juelich
http://www.fz-juelich.de/icg/icg1/idl_icglib/idl_lib_intro.h tml

http://www.fz-juelich.de/zb/text/publikation/juel3786.html
============================================================ ======

read something about linux / windows
http://www.suse.de/de/news/hotnews/MS.html
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Re: Ug...Floating Illegal Operand...leave me alone!
Next Topic: EPS problem

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

Current Time: Sun Oct 12 19:03:53 PDT 2025

Total time taken to generate the page: 0.56303 seconds