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

20001231: McIDAS 7.7 ADDE setup at UGa (cont.)

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.

  • Subject: 20001231: McIDAS 7.7 ADDE setup at UGa (cont.)
  • Date: Tue, 02 Jan 2001 09:14:04 -0700
>From: "Thomas L. Mote" <address@hidden>
>Organization: U. Georgia
>Keywords: 200012282251.eBSMpko24860 McIDAS-X 7.70 ADDE

Tom,

>Regarding NIDS... I assumed there would be some mechanism 
>but haven't had the time this semester to look into it. I 
>will read the links you provided in the forwarded e-mail 
>and think about it. I suspect we will mostly be interested 
>in getting feeds for Peachtree City, GA, (KFFC) and 
>possibly Greer, SC. We could simply point McIDAS to an 
>appropriate ADDE server for other sites as needed.

Sounds good.

re: XCD surface decoding not working correctly
>I had noticed this before and even mentioned it to you in a 
>previous e-mail some time ago. You asked me for more 
>information, and I never got around to replying to you.

Thanks for reminding me of this; I had forgotten.

>Can 
>you tell me what the problem/fix was. I'm trying to learn 
>from past mistakes. I do seem to be accomplishing that. I 
>am tending to make brand new mistakes rather than repeat 
>past mistakes ;-)

What I did was remake the rapid access and rapid access pointer
files used by XCD.  These are the *.R* files in the XCD output
data directory.  I have noticed over time that when the surface
decoding is bad, that remaking these files would fix the problem.
In the past, however, I thought I had to have input to XCD routines
totally stopped.  This would mean stopping the LDM and making sure
that all of the 'xcd_run' invocations had exited.  This time,
since I did not have the login for 'ldm' on your system, I did
the following as 'mcidas':

cd workdata
decinfo.k SET DMSFC INACTIVE
decinfo.k SET DRAOB INACTIVE
decinfo.k SET DSYN INACTIVE
decinfo.k SET DMMISC INACTIVE

I set all three of these active, but not DMGRID, so that there would
be nothing active that reads the text spool file (*.XCD for the day).
I then did:

pushd /data/mcidasd
rm *.R*
popd
te.k XCDDATA \"/data/mcidasd
batch.k XCD.BAT
batch.k XCDDEC.BAT

The XCDDEC.BAT invocation recreates the rapid access files from
scratch along with a couple of others).

I then turned decoding back on with:

decinfo.k SET DMSFC ACTIVE
decinfo.k SET DRAOB ACTIVE
decinfo.k SET DSYN ACTIVE
decinfo.k SET DMMISC ACTIVE

After waiting a bit, I could list surface data for various stations
that previously had bad data to check to see if things had improved.

>I noticed that most of the erroneous data was showing 
>temperatures (in Celsius) that matched the day of the 
>month. That was probably why you were seeing temps in the 
>80s (30th day translating to 30C = 86F).

I had never made this connection!  This means that the problem is most
likely related to a change in the structure of one or more rapid access
or IDXALIAS.DAT files.  Recreating them above apparently puts the needed
words in the correct location for the decoder.  I will have to touch
base with SSEC folks about this to see if it rings a bell.

>Thanks again.

Talk to you later...

Tom