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

20050121: Unidata McIDAS-XCD Trouble (cont.)



>From: "James T. Brown" <address@hidden>
>Organization: Michigan State University
>Keywords: 200501201933.j0KJXOv2020815 McIDAS-XCD ADDE

Hi Jim,

>I would have never thought of McIDAS needing permissions to write to
>the "/data/mcidas" folder.  Files were be written by the LDM so I
>thought all was well.

The *.RA[TP] files in /data/mcidas need to be created by 'mcidas'
for the decoding to proceed correctly.  After they are created,
one probably could turn off write permission for 'mcidas' to the
output data directory, but I would not recommend doing this.

>I made the requested permission changes to "/data/mcidas" and ran the
>two batch program (XCD.BAT, XCDDEC.BAT).  After completing the two
>batch programs, the following shows the contents of the "/data/mcidas"
>directory:
>
>   % ls -lm
>   -rw-rw-r--   1 mcidas   wx        460292 Jan 21 13:28 ETAMOS.RAP
>   -rw-rw-r--   1 mcidas   wx        142596 Jan 21 13:28 FOUS14.RAP
>   -rw-rw-r--   1 mcidas   wx        460292 Jan 21 13:28 GFSMOS.RAP
>   -rw-rw-r--   1 mcidas   wx         24804 Jan 21 13:28 IDXALIAS.DAT
>   -rw-rw-r--   1 mcidas   wx       4978692 Jan 21 13:28 RAOB.RAP
>   -rw-rw-r--   1 mcidas   wx         16896 Jan 21 13:26 ROUTE.SYS
>   -rw-rw-r--   1 mcidas   wx       40576772 Jan 21 13:28 SAOMETAR.RAP
>   -rw-rw-r--   1 mcidas   wx        465408 Jan 21 13:27 SCHEMA
>   -rw-rw-r--   1 mcidas   wx       6896772 Jan 21 13:28 SYNOPTIC.RAP
>   -rw-rw-r--   1 mcidas   wx         24000 Jan 21 13:26 SYSKEY.TAB
>   -rw-rw-r--   1 mcidas   wx       4896388 Jan 21 13:28 TERMFCST.RAP
>   drwxrwxr-x   2 mcidas   wx           512 Jan 21 12:38 bufr
>   drwxrwxr-x   2 mcidas   wx           512 Jan 21 12:38 grib

This now looks correct.

>After a few minutes, some new MDxx files appeared.  Here is a recent
>listing:
>
>   % ls -lm MD*
>   -rw-rw-r--   1 ldm      wx       39304936 Jan 21 13:47 MDXX0001
>   -rw-rw-r--   1 ldm      wx         44560 Jan 21 13:30 MDXX0011
>   -rw-rw-r--   1 ldm      wx         16640 Jan 21 13:30 MDXX0021
>   -rw-rw-r--   1 ldm      wx       7777968 Jan 21 13:48 MDXX0051
>   -rw-rw-r--   1 ldm      wx       4663768 Jan 21 13:48 MDXX0061

Looks promising...

>One thing that is a little puzzling is the output from "stat.k":
>
>   pileus% stat.k
>             Decoder Status Display       2005021     185123
>  
>   ## Src  Ingestor   Time       Byte    Index    Index file   Origin  
>Wmo  Product
>   -- ---- --------  ------  ----------- -------  -----------  ------  
>---- -------
>   1  DDS  INGETEXT  185115  105553840   56464    SM05021.IDX   KSCS   SXUS   
> 56
>   4  HRS  INGEBIN   185115  5922828              HRS.SPL
>  
>                                         GridF/  Grid
>   ## Decoder    Time   Begptr  Lasptr     MD    Row    Col       
>Text       Index
>   -- --------  ------  ------- -------  ------  ----   -----  
>------------ -------
>   1  SAODEC   *183045  2480    2560     1       55     3940                
> SA05021
>   2  RABDEC   *183045  416     704                                         
> UJ05021
>   3  SYNDEC   *183045  8352    10128    51      7      966                 
> SM05021
>   4           *183015  8048    8048                                        
> SM05021
>   7  PIRDEC   *183045  560     1040     61      19     18                  
> UA05021
>   8           *183015  368     368                                         
> FT05021
>   stat.k: Done
>
>
>Shouldn't the times listed in the decoders display the time the most
>recent productwas decoded?

Yes.

>When running "statdisp", all of the
>entries for the Decoders are listed in "red".
>
>I may be a little impatient, but a "latest" surface temperature plot
>still shows up blank.   Seems like there some data values would appear
>by now.  The SAO/METAR plot for 18:00 UTC show some temperature data
>values from Cuba, but nothing in the U.S. and haven't seen anything yet
>for 19:00 UTC.    I will give it a little more time.

I just looked and only see a hand full of decoded observations for 18Z
and none for 19Z.  This does indicate a continuing problem with
decoding.

Could I get a login as 'ldm' so I can get a better idea of exactly what
is "bound up"?

>Thanks for the suggestion on editing my "LOCDATA.BAT" file.   I will
>definitely make some of the changes to setup remote access for data
>sources that I do not have access to.   I would like to setup local
>access to the products that I can create and store locally, but I am
>taking that one step at a time.

OK, this is the best strategy.  I just wanted to make sure that you
knew which data products end up in which ADDE datasets.

>I have some of the RTIMAGES products
>setup (GE-VIS, GE-IR, etc...).  I have also setup local access to the
>RTNEXRAD group.

OK, I didn't know that you were getting NNEXRAD data products.  I see
that they are available in subdirectories of /data/nawips/nexrad and
that you have correctly configured ~mcidas/workdata/NNEXRAD.CFG's
DIRMASK and FILEMASK.  I would like to convince you, however, that you
now have to worry about losing the configuration information in
NNEXRAD.CFG the next time you do a McIDAS installation.  I suggest
solving this problem by doing the following:

<as 'mcidas'>

cd ~mcidas/workdata
cp NNEXRAD.CFG MSUNEXR.CFG

cd ~mcidas/data

edit LSSERVE.BAT and change all occurrances of NNEXRAD.CFG to MSUNEXR.CFG.

cd ~mcidas/workdata
batch.k LSSERVE.BAT

>Haven't had any troubles with those two.  The highest
>priority right now for an instructional lab is access to the RTPTSRC
>group which lead to the original support email yesterday.   If there
>are products that are only accessible via remote ADDE servers, I will
>be sure to point to the servers that you suggested.

OK.

>Just checked another SAO/METAR plot and still all blank.  All of the
>decoder listing in "statdisp" are still red.   Seems like I am still
>having some trouble.

Yes, I agree.  I would really appreciate being able to look at this
from both a 'mcidas' and 'ldm' perspective.  One thing that jumped
out at me is how slowly McIDAS programs are running.  I snagged
our sysadmin (Mike Schmidt) to take a look, but we have not come
to any conclusions yet.

Cheers,

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.