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 
Switch to threaded view of this topic Create a new topic Submit Reply
Re: OPLOT fails intermittently, any ideas? [message #25784] Tue, 17 July 2001 13:10 Go to next message
bleau is currently offline  bleau
Messages: 24
Registered: November 1993
Junior Member
In article <3B54747B.A6F1C983@fz-juelich.de>, Reimar Bauer <r.bauer@fz-juelich.de> writes:
>
> Hope I can give some hints
>
> max_value is a double but will be interpreted as float.
>
> a=9999998.
[snip]

That is correct, but doesn't address the problem. The typical data values are
far, far below the value specified for max_value. Unless you are postulating
that a conversion from double to single will change the value by several orders
of magnitude, this isn't the reason.

Typical Y data values to be plotted are between 1000. and 50000.

No, this is something subtler (or more obvious, depending on one's view).

Btw, the not-enough-data error occurred twice more yesterday. We thought it
was related to a gap in our data, but in these last two errors there was no
gap, so that theory is shot down. The IDL code in each of the last errors read
in over 900 data points. The same code reads in another 900 data points an
hour later and plots them without error, though. Really strange!

Lawrence Bleau
University of Maryland
Physics Dept., Space Physics Group
301-405-6223
bleau@umtof.umd.edu
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 next 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
Re: OPLOT fails intermittently, any ideas? [message #25805 is a reply to message #25794] Mon, 16 July 2001 13:26 Go to previous messageGo to next message
Paul van Delst is currently offline  Paul van Delst
Messages: 364
Registered: March 1997
Senior Member
Larry Bleau wrote:
>
>> It depends. It could be that every couple of days the values get *just* a little too big
>> for their difference (epoch-base_epoch) to "fit" in a single precision format, hence the
>> apparent intermittent failure. You only have 6 or 7 significant digits, e.g.
>>
>> IDL> x=8348374.3947d0
>> IDL> x2=8348374.3954d0
>> IDL> print, float(x2)-float(x)
>> 0.00000
>> IDL> print, float(x2-x)
>> 0.000700000
>
> Good example in the abstract, wrong in this particular case. We're doing a 4
> hour plot. The epoch time is in seconds. That means over the course of the
> plot the difference between firrst and last x-values will be 14400. We have no
> problem distinguishing these times on other plots. Indeed, the only problem we
> had with the single vs. double precision was labelling the x-axis: using the
> unscaled x values the time axis would be labelled 1100, 1159, 1300, 1359, etc.
> In other words, we'd sometimes be off 1 minute (numeric value of 60). Once we
> went to scaling (just subtracting a constant) the labelling problem was fixed.
>
> This is a different problem, long lasting, just doesn't happen very often.

O.k. Well, then you have a mighty weird error! I'm sure someone out there will have
another idea. I'll post this to the ng so others will know it wasn't a precision problem.

(Crap, I just reread your original email where you specifically mention this! Man! Sorry
for the run-around)

> Once we had this problem when there really wasn't any data for that time
> period: there was a gap in the data sent from the satellite. I checked that
> first thing, though, and while there is a 1-hour data gap, we still have 3
> hours of data; we'd need a 4-hour gap for that to be the cause.

paulv

--
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.
Re: OPLOT fails intermittently, any ideas? [message #25806 is a reply to message #25805] Mon, 16 July 2001 12:39 Go to previous messageGo to next message
Paul van Delst is currently offline  Paul van Delst
Messages: 364
Registered: March 1997
Senior Member
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.
Re: OPLOT fails intermittently, any ideas? [message #25871 is a reply to message #25784] Wed, 18 July 2001 06:26 Go to previous message
R.Bauer is currently offline  R.Bauer
Messages: 1424
Registered: November 1998
Senior Member
Which device are you using?
Z-Buffer?

regards
Reimar


Lawrence Bleau wrote:
>
> In article <3B54747B.A6F1C983@fz-juelich.de>, Reimar Bauer <r.bauer@fz-juelich.de> writes:
>>
>> Hope I can give some hints
>>
>> max_value is a double but will be interpreted as float.
>>
>> a=9999998.
> [snip]
>
> That is correct, but doesn't address the problem. The typical data values are
> far, far below the value specified for max_value. Unless you are postulating
> that a conversion from double to single will change the value by several orders
> of magnitude, this isn't the reason.
>
> Typical Y data values to be plotted are between 1000. and 50000.
>
> No, this is something subtler (or more obvious, depending on one's view).
>
> Btw, the not-enough-data error occurred twice more yesterday. We thought it
> was related to a gap in our data, but in these last two errors there was no
> gap, so that theory is shot down. The IDL code in each of the last errors read
> in over 900 data points. The same code reads in another 900 data points an
> hour later and plots them without error, though. Really strange!
>
> 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
Re: OPLOT fails intermittently, any ideas? [message #25872 is a reply to message #25784] Wed, 18 July 2001 06:25 Go to previous message
R.Bauer is currently offline  R.Bauer
Messages: 1424
Registered: November 1998
Senior Member
Lawrence Bleau wrote:
>
> In article <3B54747B.A6F1C983@fz-juelich.de>, Reimar Bauer <r.bauer@fz-juelich.de> writes:
>>
>> Hope I can give some hints
>>
>> max_value is a double but will be interpreted as float.
>>
>> a=9999998.
> [snip]
>
> That is correct, but doesn't address the problem. The typical data values are
> far, far below the value specified for max_value. Unless you are postulating
> that a conversion from double to single will change the value by several orders
> of magnitude, this isn't the reason.
>
> Typical Y data values to be plotted are between 1000. and 50000.
>
> No, this is something subtler (or more obvious, depending on one's view).
>
> Btw, the not-enough-data error occurred twice more yesterday. We thought it
> was related to a gap in our data, but in these last two errors there was no
> gap, so that theory is shot down. The IDL code in each of the last errors read
> in over 900 data points. The same code reads in another 900 data points an
> hour later and plots them without error, though. Really strange!
>
> Lawrence Bleau
> University of Maryland
> Physics Dept., Space Physics Group
> 301-405-6223
> bleau@umtof.umd.edu


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.

And you should give this to technical support at rsinc too.


regards
Reimar


--
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
  Switch to threaded view of this topic Create a new topic Submit Reply
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: Sat Oct 11 11:48:09 PDT 2025

Total time taken to generate the page: 0.95761 seconds