[McIDAS #NHQ-322642]: MDX files

Hi Paul,

re:
> Ugh....they are not working again! I am not sure what is failing. I do not
> know how to check the decoders. So here is the issue today.
> 
> Yesterday the MDX files were being generated and suddenly stopped. Today,
> things are working except the surface fields
> 
> mcidas@climate:~/workdata$ dmap.k MDX
> PERM      SIZE LAST CHANGED FILENAME DIRECTORY
> ---- --------- ------------ -------- ---------
> -rw-    179632 Jan 30 21:00 MDXX0009 /home/data/mcidas
> -rw-   6036360 Jan 30 21:51 MDXX0020 /home/data/mcidas
> -rw-   1457392 Jan 30 21:51 MDXX0030 /home/data/mcidas
> -rw-   2613424 Jan 30 21:50 MDXX0039 /home/data/mcidas
> -rw-   4986832 Jan 30 21:55 MDXX0040 /home/data/mcidas
> -rw-   8316240 Jan 30 21:45 MDXX0059 /home/data/mcidas
> -rw-   8860224 Jan 30 21:55 MDXX0060 /home/data/mcidas
> -rw-   5702132 Jan 30 21:55 MDXX0070 /home/data/mcidas
> -rw-    545904 Jan 30 21:55 MDXX0080 /home/data/mcidas
> -rw-   1552384 Jan 30 21:18 MDXX0090 /home/data/mcidas
> -rw-  15298560 Jan 30 21:54 MDXX0100 /home/data/mcidas
> -rw-   7070468 Jan 30 14:57 MDXX0110 /home/data/mcidas
> -rw-  10606616 Jan 30 16:05 MDXX0120 /home/data/mcidas
> 73226168 bytes in 13 files

Hmm... the list of MD files shows that that there is no surface file
for today (it would be MDXX0010), but there are upperair, synoptic, etc.
files.

re:
> I tried restarting ldm but nothing worked.

I logged into climate and saw that the RAOB, SYNOPTIC, and MISC decoders were
running, but the surface one was not:

climate:~> ps -eaf | grep DM
ldm      14163 14158  0 21:49 ?        00:00:00 DMRAOB
ldm      14164 14158  2 21:49 ?        00:01:56 DMSYN
ldm      14165 14158  0 21:49 ?        00:00:00 DMMISC
ldm      25457  9577  0 23:01 pts/8    00:00:00 grep DM

Given your comment about stopping and restarting the LDM, I suspect that the
pointer file used for surface data file decoding by XCD (DCLSTIDX.PTR) was
damaged somehow.  So, I deleted it as follows:

<as 'mcidas'>
cd $MCDATA
decinfo.k SET DMSFC INACTIVE
rm DCLSTIDX.PTR
decinfo.k SET DMSFC ACTIVE

After waiting a bit, the surface decoder was restarted and after a bit
more, the surface MD file for today (again, MDXX0010) was created:

mcidas@climate:~/workdata$ dmap.k MDXX
PERM      SIZE LAST CHANGED FILENAME DIRECTORY
---- --------- ------------ -------- ---------
-rw-    179632 Jan 30 21:00 MDXX0009 /home/data/mcidas
-rw-  50275236 Jan 30 23:30 MDXX0010 /home/data/mcidas
-rw-     63272 Jan 30 23:30 MDXX0011 /home/data/mcidas
-rw-   6036360 Jan 30 23:29 MDXX0020 /home/data/mcidas
-rw-    112864 Jan 30 23:30 MDXX0021 /home/data/mcidas
-rw-   1457840 Jan 30 23:29 MDXX0030 /home/data/mcidas
-rw-   4985536 Jan 30 23:30 MDXX0039 /home/data/mcidas
-rw-   5200672 Jan 30 23:30 MDXX0040 /home/data/mcidas
-rw-    187952 Jan 30 23:05 MDXX0051 /home/data/mcidas
-rw-   8316240 Jan 30 23:05 MDXX0059 /home/data/mcidas
-rw-   8860224 Jan 30 23:30 MDXX0060 /home/data/mcidas
-rw-   5984900 Jan 30 23:30 MDXX0070 /home/data/mcidas
-rw-    549764 Jan 30 23:30 MDXX0080 /home/data/mcidas
-rw-   1552384 Jan 30 23:18 MDXX0090 /home/data/mcidas
-rw-  15298560 Jan 30 23:30 MDXX0100 /home/data/mcidas
-rw-   7070468 Jan 30 14:57 MDXX0110 /home/data/mcidas
-rw-  14134616 Jan 30 22:06 MDXX0120 /home/data/mcidas
130266520 bytes in 17 files

So, surface data decoding looks to be working again.

re:
> Do you know why this keeps happening?

I would think that the comment I made last time is still appropriate:
there must have been a chunk of bad data that caused the surface decoder
to crash, and before crashing, it wrote incorrect data into its
pointer file.

re:
> Also, I have a question about LSSERVE.BAT command. I assume this is a
> local version that runs DSSERVE.BAT which gets updated with new releaces?

LSSERVE.BAT is created by the 'mcxconfig' script after finding out what kinds
of data you intend to ingest and process.  You are correct that DSSERVE.BAT
gets overwritten with each new McIDAS release installation.

re:
> Where is it supposed to reside? I have two different versions in
> $MCIDAS/data and one in $MCIDAS/workdata

The installation directory is $MCIDAS/data. The copy in $MCDATA (which
is $MCIDAS/workdata) must be a copy of the one from $MCIDAS/data made
by someone locally.

re:
> Also, I see that they contain different data then NEXRADDE.BAT. I am just
> confused as to what should go where and what should and should not be
> editted.

NEXRADDE.BAT is one of a number of template BATCH files that define ADDE
datasets.  When one runs 'mcxconfig' and specifies what data are being
ingested/processed and, therefore, should be serveable, 'mcxconfig' will
concatenate appropriate *ADDE.BAT files and create LSSERVE.BAT.  'mcxconfig'
will eventually ask the user to review the contents of LSSERVE.BAT; make
any changes desired; and then activate the ADDE dataset definitions by
essentially running BATCH LSSERVE.BAT.

Old hands with McIDAS can refer to the various ADDE definition BATCH files
and extract/copy portions that they want to use and discard others (i.e.,
roll their own). The easiest thing to do is use 'mcxconfig' and let it do
the work.

re:
> Thanks Tom

No worries.

Question:

- is the data you are decoding from the COD NOAAPort ingest system?

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: NHQ-322642
Department: Support McIDAS
Priority: Normal
Status: Closed