20010226: zero and negative wind speed contours (cont.)

>From: "Paul L. Sirvatka" <address@hidden>
>Organization: College of DuPage
>Keywords: 200102252359.f1PNxUL00972 McIDAS-X RAOBCON PTCON speed contours

Paul,

>Area 51! That would explain it. Although...it is relatively close to
>Roswell!

That's what I used to think.  AREA 51 is actually pretty close to Las
Vegas, NV.  I learned this by listening to late night talk radio :-)

>The same was true in Canada with a contour of 0 kts (implying interior
>values less than 0. I noticed that it did this when the map coordinates
>were detailed enough to allow it. When I did the TX one with a US view, I
>did not notice it. Only when I zoomed in.

OK.  I got a reply back from SSEC on this phenomena:


  >Date: Mon, 26 Feb 2001 16:52:26 +0000
  >Subject: Re: 20010225: RAOBCON producing 0 and negative contours for wind 
speed
  
  Hi Tom,
  
  I asked RussD and ScottL about this and they both agreed that it's an
  artifact of PTCON's interpolation scheme (the objective analysis may
  give physically inappropriate values). It's more likely to occur with
  RAOB data (than, say, METAR data) because the of the sparse nature of
  data points in some areas.
  
  You can avoid 0 or negative contours altogether by making a string with
  the exact values you want to contour and specify that string name in the
  CINT= keyword. For example, 
  TE SPEEDS "5 10 15 20 30 50
  then
  RAOBCON SPD 850 ... CINT=SPEEDS
  
  Another option Scott mentioned that reduces the likelihood of 0 or
  negative contours is to specify DIST=2 or 3 so that grid points in large
  data void areas are assigned missing values (instead of getting
  interpolated values).
  
  Barry Roth
  McIDAS Help Desk

I agree with RussD and ScottL's comments.  In order to make your plots
reasonable (i.e., NOT from AREA 51 ;-), you would do well to adopt the
CINT=SPEEDS (i.e., define a string that has the contour values that
you want) and/or DIST= approach.

>I am working on doing 500mb height falls, and am getting stuck with the
>definition (like P3DIF).
>
>In the file RAOBCON.SITE (like SFCCON.SITE) I have
>
>DELTZ  UNIT=M \
>       FORMAT=I3 \
>       MATH='P1-P2' \
>       IRAB='P1=Z {TIME (NOW);DAY (NOW)}' 'P2=PSL {TIME (NOW-12);DAY
>(NOW-12)}'\
>       RAOB='P1=Z {TIME (NOW);DAY (NOW)}' 'P2=PSL {TIME (NOW-12);DAY
>(NOW-12)}'

One thing I see right off is that you will be attempting to take the
difference of Z (geopotential) and PSL (altimeter setting).  Since these
parameters do not have the same units, it _should_ fail.  I think that
you want P2=Z ...

>What is TIME and DAY? THey are not strings I take it. Is that like LATEST?

TIME and DAY are not McIDAS strings.  They are actions that should be
interpreted as:

TIME (NOW) -> current TIME
DAY(NOW)   -> current DAY

Now, I was under the impression that:

TIME (NOW-12) -> current TIME minus 12 hours
DAY (NOW-12)  -> current DAY minus 12 hours

where both the TIME and DAY would be adjusted to the correct TIME and
day even when going over a DAY boundary.  Since this is not working,
I will have to see if something I introduced into SFCCON (like LATEST
for the TIME) is changing this.  This will take some digging...

>When I run:
>raobcon.k DELTZ 500 SURFACEMAP
>
>I get:
>Accessing Dataset Name = RTPTSRC/UPPERMAND.ALL
>PTCON: No data found matching search conditions
>PTCON:  Done
>raobcon.k: PTCON command failed

I am not sure, but I think you may want:

raobcon.k DELTZ 500 SURFACEMAP 12

Also, given your P2=PSL, it may be failing since the two things that
the difference is being done on do not have compatible units.

>Everything else is coming along slowly but surely. I have a lot of great
>images!

Good.  I will try to get to the P3DIF not working across 0Z problem today
(but I have been swamped with the upper air serving problem on Linux).

>Hoep your weekend was good.

Yes, finally a weekend where I didn't work more than 4 hours!

Tom