[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20010223: graphic line width/dash pattern; proftomd decoding bug; day differencing



>From: "Paul L. Sirvatka" <address@hidden>
>Organization: College of DuPage
>Keywords: 200102162013.f1GKD9L01250 McIDAS-X SFCCON GRDDISP

Paul,

Just to catch up on a couple of things:

re: graphic line width/dash patterns
>Well...on a different computer I did not get dots rather than dashes. All
>I can say is ?!?!?! I did get it before. Weird!

Since the setting of the dashed line pattern is a global thing in
almost all McIDAS routines, it is possible that you ran a command that
set the dashed line pattern before you ran the other one where you got
dots and not the expected dashes.  It could be the case that the first
routine (whatever it was) saved the global dashed line pattern and then
changed it for its own use and then bombed before it could change the
dashed line pattern back.  Just specualtion...

re: plotting wind profiler time-height cross sections
>Well...today things seem to work OK. I was doing it right...you will have
>to trust me.

I do.  Again, the problem may be cropping up when you try to plot a
cross section for one of the stations that is at a column position in
the MD file that is greater than the CMAX setting in the MD file row
header.

>If I find anything else I will let you know. I will be
>running a batch file to plot them out automatically.

OK.

re: possibility of upgrading your ldm-mcidas 'proftomd' decoder to take
care of the CMAX bug
>Hmmm...if I run into more troubles I will answer these questions when I
>talk with Dave. For the time being I will send him a copy of this.

OK.

>Any word on the day differencing?

I got the chance to look at the problem this afternoon, and I found and
fixed the bug.  The modified code will be made available in the next
addendum.  Until then, you could make the fix yourself and get things
working like they should.

The following must be done by the user 'mcidas':

cd ~mcidas/mcidas7.7/src
-- edit sfccon.pgm
  at about line 3267 (the line number might be different in your copy
  since I have made other changes), you will see a section of code
  that looks like:

  ...
c ------ time decrement
         if( minus.ne.0 ) then
            ib = minus+1
            ie = right-1
            if( ie.gt.ib ) then
               chour = cday(ib:ie)
               status = mcstrtoint( chour, ihour )
  ...

The offending line is the one with the 'if' statement.  The '.gt.' thest
is incorrect; it should be '.ge.'.  A test for '.gt.' was ignoring 
cases where the time difference was less than two digits -- like 3
in (NOW-3) for P3DIF:

P3DIF  FORMAT=I3 \
       MATH='P1-P2' \
       ISFC='P1=PSL {TIME (NOW);DAY (NOW)}' 'P2=PSL {TIME (NOW-3);DAY (NOW-3)}'\
       SVCA='na'\
       SYN= 'P1=PSL {TIME (NOW);DAY (NOW)}' 'P2=PSL {TIME (NOW-3);DAY (NOW-3)}'\
       ISHP='P1=PSL {TIME (NOW);DAY (NOW)}' 'P2=PSL {TIME (NOW-3);DAY (NOW-3)}'

Changing the test to '.ge.' will allow for time differences of 1 digit (0 - 9).

After changing:

            if( ie.gt.ib ) then

to:

            if( ie.ge.ib ) then

you need to rebuild and install the sfccon.k executable:

make sfccon.k
rm ~/bin/sfccon.k; ln sfccon.k ~/bin

After this, your SFCCON P3DIF invocations that span a day boundary will
work as they should.

Tom


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.