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

[McIDAS #JRF-883135]: problem: old data showing on mcidas 2006

Hi Steve,

re:
> I have recently compiled/installed Mcidas 2006 and mcidas xcd (and ldm 6.4.5) 
> at SUNY
> Nassau Community College (on a intel based server running on Linux: CentOS v 
> 3.8).

Very good.

> I am however getting some odd behaviour displaying data from the "RTIMAGES" 
> catagory in
> mcidas.

Just to make sure that we are on the same page on this, McIDAS-XCD decoding has
nothing to do with the imagery included in the RTIMAGES ADDE dataset.  Those 
images
are decoded from the Unidata-Wisconsin IDD datastream (feed type UNIWISC aka 
MCIDAS)
by the ldm-mcidas decoder pnga2area.

> For ex. displaying data from GE-VIS is showing old data, data from oct 9th, 
> both as loop and
> single frame mode. (In loop mode it only shows 2 frames)

The first thing to look at is which ADDE server you are pointing at for RTIMAGE
data.  You do this from any McIDAS session as follows:

DATALOC LIST RTIMAGES

If this shows that you the dataset is defined locally (i.e., the source of 
RTIMAGES
images is 'LOCAL-DATA' or the machine being pointed at is your machine running
the LDM), then the next step is to review the ADDE dataset definition for
the RTIMAGES dataset.  You do this from the 'mcidas' account on your LDM 
machine:

<as 'mcidas'>
cd $MCDATA                    <- MCDATA should be defined to be ~mcidas/workdata
dsserve.k LIST RTIMAGES       <- this invocation is from the Unix/Linux command 
line
 -- or --
DSSERVE LIST RTIMAGES         <- this invocation is from within a running 
McIDAS session

Look through the output to see how your RTIMAGES dataset is defined.  In 
particular,
look at the set of images in which you are seeing old data.  It is likely the 
case
that your RTIMAGES dataset definition is pointing at a set of files that is not
being updated by the ingest of UNIWISC images that are decoded by the ldm-mcidas
process 'pnga2area'.

> I looked in the ldm mcidas data directory and I don't even have AREA files 
> from oct. 9th
> anymore (I had run scour)

Please check the pqact.conf file in the ~ldm/etc directory to see how you 
configured
your system to process the UNIWISC images.  Also remember that you may have more
than one action that will process any particular type of image.  For instance, 
the
following entry would process all of the Unidata-Wisconsin images using as a 
template
the McIDAS routing table, ROUTE.SYS:

# CIMSS and UW Products decoded into AREA files using McIDAS routing table
MCIDAS  ^pnga2area Q. (..) (.*) (.*) (.*) (.*) (........) (....)
        PIPE    -close
        decoders/pnga2area -vl logs/ldm-mcidas.log
        -d data/mcidas -r \1,\2

In this case, the McIDAS routing table would need to be located in the output 
data
directory which is ~ldm/data/mcidas in this example.  The routing table would 
need
to be set to be readable AND writable by the user running your LDM and by your 
'mcidas'
user.  Accompaning ROUTE.SYS should be the McIDAS System Key Table, SYSKEY.TAB. 
 It
should also be located in the output data directory, and it must also be 
readable
and writable by the user running your LDM and the user 'mcidas'.

There is another way that png2area can be run to "decode" (it is actually 
uncompressing,
not really decoding) the UNIWISC images.  Here are several examples that 
illustrate
the alternate way of processing the images:

#
# RTIMAGES GW-VIS
UNIWISC ^pnga2area Q. (U9) (.*) (.*) (.*) (.*) (........) (....)
        PIPE    -close
        util/pnga2area -vl /usr/local/ldm/logs/ldm-mcidas.log
        -d /data/ldm/pub/decoded/mcidas/RTIMAGES/GW-VIS -r \1,\2
#
# RTIMAGES GW-IR
UNIWISC ^pnga2area Q. (U5) (.*) (.*) (.*) (.*) (........) (....)
        PIPE    -close
        util/pnga2area -vl /usr/local/ldm/logs/ldm-mcidas.log
        -d /data/ldm/pub/decoded/mcidas/RTIMAGES/GW-IR -r \1,\2
#
# RTIMAGES GE-VIS
UNIWISC ^pnga2area Q. (UV) (.*) (.*) (.*) (.*) (........) (....)
        PIPE    -close
        util/pnga2area -vl /usr/local/ldm/logs/ldm-mcidas.log
        -d /data/ldm/pub/decoded/mcidas/RTIMAGES/GE-VIS -r \1,\2
#
# RTIMAGES GE-39
UNIWISC ^pnga2area Q. (UD) (.*) (.*) (.*) (.*) (........) (....)
        PIPE    -close
        util/pnga2area -vl /usr/local/ldm/logs/ldm-mcidas.log
        -d /data/ldm/pub/decoded/mcidas/RTIMAGES/GE-39 -r \1,\2

etc.

The ldm-mcidas distribution includes example pqact.conf actions
that can be copied to the ~ldm/etc/pqact.conf file.

The point of the above is that you may be writing the new images into
a directory that you are not searching in your ADDE dataset setup.

> The really odd thing is that if I pick GE-VISTOPO then recent data is being 
> displayed (in both
> single and loop mode)

The composite images (GE-VISTOPO is a composite of GOES-East imagery and 
topography
imagery) must be handled through the McIDAS routing table.  It is most likely
that the composite images are being written to the output data directory.

By the way, the other thing needed for ADDE dataset definitions to work is
your McIDAS account must be able to locate the images.  This is done in
one of two ways:

- the ADDE dataset definition uses a regular expression that defines the list
  of images in the set

- the ADDE dataset definition refers to the McIDAS images as a range of
  AREA file numbers.  In this case, your McIDAS session must "know" how
  to locate those images.  This is done through McIDAS file REDIRECTions
  and/or through the MCPATH definition in the 'mcidas' account.  This
  way of locating files is the oldest and still most used method in
  McIDAS.

When you get your dataset definition listing through the DSSERVE listing
above, you will know which method is being used.  If you are using the
second method (likely), then you need to check that your 'mcidas' account
is configured to locate the images.  This is done using the McIDAS utility
DMAP:

<as 'mcidas'>
cd $MCDATA
dmap.k AREA

If the dmap.k listing does not find the AREA files that are supposed to
be included in the ADDE datasets, then you need to "teach" McIDAS how
to find the files.  This is done by:

<still as 'mcidas'>
cd ~mcidas/data
cp EXAMPLE.NAM LOCAL.NAM
-- edit LOCAL.NAM and set the directory where the AREA files are located
cd ~mcidas/workdata
redirect.k REST LOCAL.NAM

After doing this, you should again run the DMAP invocation to see if your
'mcidas' account can find the images.

> This occurs for GW images also,

The same comments apply.

> This is not limited to just the visible images, it is also occuring with 
> other images such as
> water vapor.

Same comment.

> The same odd problem is occuring with IR images.

Ditto.

> I would apreciate any help in what I should check and do to correct this 
> problem.

Please let me know if the above explanation is clear enough.

> I did look at the LOCAL.NAM file and it seems to be ok but I can send any 
> files needed for
> verification.

The settings in LOCAL.NAM need to be made active in your McIDAS setup.  This is
done by the REDIRECT REST step:

cd ~mcidas/workdata
redirect.k REST LOCAL.NAM

> Thanks!

No worries.  Please let me know if this gets you going.  If it doesn't, I am 
willing
to logon to your machine to take a look around to see what may be misconfigured.

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: JRF-883135
Department: Support McIDAS
Priority: Normal
Status: Closed