This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>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