Tim:
After upgrading to v1.0l I have encountered a scripting problem. Note I upgraded directly from v1.0g to 1.0l so I do not know if this problem was present in the "in-between" versions.
The script line below analyzes 3hr PTEN, isopleths of pressure fall are in red and pressure rise in blue, the no change line, PTEN=0, is in bold black. This worked in v1.0g. The colons in the line below were commas then.
PTEN 3HR (mb) |CONT EQUA=0 COLOR=0:0:0 LINE=3 CONT GRTN=2 CINT=2 COLOR=0:0:200 LINE=1 CONT LSTN=-2 CINT=2 COLOR=200:0:0 LINE=1 PTEN
With version 1.0l this will draw the zero isopleth as specified in the script and the negative isopleths in red as specified, no pressure rise isallobars are drawn.
I have experimented with the script and find that by re-arranging the commands the results vary, so if I move the commands for pressure rises to the end of the line the zero isallobar and the pressure rise isallobars are drawn as specified but the pressure falls are not (script line below).
PTEN 3HR (mb) |CONT EQUA=0 COLOR=0:0:0 LINE=3 CONT LSTN=-2 CINT=2 COLOR=200:0:0 LINE=1 CONT GRTN=2 CINT=2 COLOR=0:0:200 LINE=1 PTEN
The results depend on position, the middle commands are not executed while the first set (zero isallobar) and the last set (either pos or neg) are executed.
A similar command for plotting dew point works perfectly in v1.0l, it is:
Dewpoint (1 deg F) |MXMN CONT EQUA=70 LINE=3 COLOR=0:60:0 CONT CINT=5 LINE =2 COLOR=0:120:0 CONT CINT=1 DASH COLOR=0:200:0 DEGF DWPT
Data source makes no difference with this problem.
Thanks
Steve Horstmeyer
SCRIPTING PROBLEM V1.0L
-
SteveHmeyer
- Member
- Posts: 12
- Joined: Wed May 26, 2004 11:42 am
- Location: Cincinnati
- Contact:
-
Wally Mayo
- Senior Member
- Posts: 254
- Joined: Thu Feb 05, 2004 11:36 pm
- Location: Roanoke, VA
- Contact:
Also,
1. Using schedule script, data retrieval window does not go away after a net upload of a map (well, not automatically - the close box works).
But more of more interest...
2. After any upload of map to net by using a schedule script,
change map, change radar set (stations chosen to get NIDS), do a get base reflectivity (or probably any radar data), now it will only get the first site, until DAWS is quit and rerun. Then it gets all of them.
I will try to give more details as I do more runs/tests.
UPDATE after release 1.0m
No change. (I know you weren't hitting this area - I just found the one line in my script file that causes the symptom:
For #2 (above), all I have to do is a simple script upload like...
upload,ftp://signon:password@ftp.site/map.gif, ... ve\map.gif
and any subsequent radar ingest stops after one site.
Interestingly, I can't get that one line to run "live" (not as a file) in the script mode (top entry place).
1. Using schedule script, data retrieval window does not go away after a net upload of a map (well, not automatically - the close box works).
But more of more interest...
2. After any upload of map to net by using a schedule script,
change map, change radar set (stations chosen to get NIDS), do a get base reflectivity (or probably any radar data), now it will only get the first site, until DAWS is quit and rerun. Then it gets all of them.
I will try to give more details as I do more runs/tests.
UPDATE after release 1.0m
No change. (I know you weren't hitting this area - I just found the one line in my script file that causes the symptom:
For #2 (above), all I have to do is a simple script upload like...
upload,ftp://signon:password@ftp.site/map.gif, ... ve\map.gif
and any subsequent radar ingest stops after one site.
Interestingly, I can't get that one line to run "live" (not as a file) in the script mode (top entry place).
Steve,
I think there are either some bugs in the scripting module or we're trying to perform operations for which it is not intended. As a simple example, I just tried contouring surface temps(F) in different colors using the GRTN operator(ie...every 10F or so and similar to the upper wind speed shading example included in DAWS, but without the color fill) and only the highest value contour ended up plotting...the rest were missing altogether.
Bob
I think there are either some bugs in the scripting module or we're trying to perform operations for which it is not intended. As a simple example, I just tried contouring surface temps(F) in different colors using the GRTN operator(ie...every 10F or so and similar to the upper wind speed shading example included in DAWS, but without the color fill) and only the highest value contour ended up plotting...the rest were missing altogether.
Bob
-
SteveHmeyer
- Member
- Posts: 12
- Joined: Wed May 26, 2004 11:42 am
- Location: Cincinnati
- Contact:
Bob
I'm leaning towards a bug in the scripting module. In my example GRTN and LSTN both work individually. If three analysis functions are on one line together (EQUA=0 LSTN and GRTN) the results are a bit complex.
If the first function is EQUA and the middle function is either LSTN or GRTN neither works in the middle position.
If the middle function is EQUA, it works in that position but the function LEFT OF it, executed after EQUA ( either LSTN or GRTN) does not work, the function RIGHT OF EQUA does work. It is executed first.
If the Last function is EQUA neither LSTN or GRTN work, seemingly because both are executed after EQUA. If the value is changed to EQUA=1 or EQUA=2...etc and EQUA remains in the last position the results are the same, neither LSTN or GRTN work preceeding it. So it is not a problem with the value assigned to EQUA.
As Tim has pointed out in the documentation the functions are executed RIGHT TO LEFT. So if we consider the scenarios above in he order of execution it makes no more sense to me because if EQUA is the left most function it is executed last, how that stops the middle function (executed fbefore EQUA) from plotting is a mystery to me.
It leads me to believe that it is not the functions that are at fault because they execute perfectly individually but a bug in the script parsing routine. But that is just a guess.
Steve Horstmeyer
I'm leaning towards a bug in the scripting module. In my example GRTN and LSTN both work individually. If three analysis functions are on one line together (EQUA=0 LSTN and GRTN) the results are a bit complex.
If the first function is EQUA and the middle function is either LSTN or GRTN neither works in the middle position.
If the middle function is EQUA, it works in that position but the function LEFT OF it, executed after EQUA ( either LSTN or GRTN) does not work, the function RIGHT OF EQUA does work. It is executed first.
If the Last function is EQUA neither LSTN or GRTN work, seemingly because both are executed after EQUA. If the value is changed to EQUA=1 or EQUA=2...etc and EQUA remains in the last position the results are the same, neither LSTN or GRTN work preceeding it. So it is not a problem with the value assigned to EQUA.
As Tim has pointed out in the documentation the functions are executed RIGHT TO LEFT. So if we consider the scenarios above in he order of execution it makes no more sense to me because if EQUA is the left most function it is executed last, how that stops the middle function (executed fbefore EQUA) from plotting is a mystery to me.
It leads me to believe that it is not the functions that are at fault because they execute perfectly individually but a bug in the script parsing routine. But that is just a guess.
Steve Horstmeyer
-
SteveHmeyer
- Member
- Posts: 12
- Joined: Wed May 26, 2004 11:42 am
- Location: Cincinnati
- Contact: