[McIDAS #LPP-595939]: Problems with NLDNDISP

Hi Christian,

re:
(I didn't expect a reply on a Sunday!!),

I always read email on Sunday mornings before heading off to read
the Sunday newspapers :-)

re: which ADDE server are you trying to access

> dataloc.k LIST RTPTSRC
> 
> Group Name                    Server IP Address
> --------------------         ----------------------------------------
> RTPTSRC                      KEPLER.SCA.UQAM.CA
> 
> <LOCAL-DATA> indicates that data will be accessed from the local data 
> directory.
> DATALOC -- done
> 
> It is my own local ADDE server.

OK.  After sending my reply earlier today I looked at the IDD real
time statistics pages and saw that kepler is ingesting NLDN from
the SUNY Albany machine, striker2.atmos.albany.edu.  Very good...

re: nldn2md is part of the ldm-mcidas package, not McIDAS-XCD

> It was my mistake, I assumed that nldn2md was linked with XCD, I still
> have some trouble understanding correctly all the McIDAS stuff.

This is a common mistake.  I wrote nldn2md in the days before Unidata
McIDAS contained the XCD component.  After the inclusion, I never felt
the need to try to integrate the NLDN decoding into XCD mainly because
the "typical" SSEC McIDAS site does not have free access to the NLDN
data.

> Here is some more info from the logs:
> Jun 11 12:07:13 nldn2md[4835]: Starting Up
> Jun 11 12:07:13 nldn2md[4835]: unsetting MCPATH environment variable
> Jun 11 12:07:13 nldn2md[4835]: changing to directory data/xcd
> Jun 11 12:07:13 nldn2md[4835]: NLDN2MD -- BEGIN
> Jun 11 12:07:13 nldn2md[4835]: PRODUCT CODE=LD          2006162     120000
> Jun 11 12:07:13 nldn2md[4835]: nldninput(): Product header record found
> Jun 11 12:07:13 nldn2md[4835]: Appending to MD file: 72
> Jun 11 12:07:13 nldn2md[4835]: nldninput(): EOF on stdin
> Jun 11 12:07:13 nldn2md[4835]: NLDN2MD - Flash events in file: 630560
> Jun 11 12:07:13 nldn2md[4835]: NLDN2MD -- DONE
> Jun 11 12:07:13 nldn2md[4835]: Exiting

Hmm.  The correct output file for today is MDXX0072, so your nldn2md decoder
is writing to the correct file. What is odd, however, is the total number
of 'Flash events in file' count of 630560.  This is much more than the number
being indicated by an invocation of nldn2md on motherlode.ucar.edu (aka
adde.ucar.edu) which is reporting:

Jun 11 12:07:08 nldn2md[13578]: NLDN2MD -- BEGIN
Jun 11 12:07:08 nldn2md[13578]: Appending to MD file: 72
Jun 11 12:07:08 nldn2md[13578]: NLDN2MD - Flash events in file: 149425
Jun 11 12:07:08 nldn2md[13578]: NLDN2MD -- DONE
Jun 11 12:07:33 pnga2area[13620]: Starting Up

So, I would guess that your NLDN Lightning files are not being properly
scoured.  If an MD file does not get scoured (meaning deleted or renamed)
before it gets to be 10 days old, newly decoded data will be written to
the end of an existing file.  If this is what is happening on your machine
it would mean that the beginning data in MDXX0072 is at least 10 days old.
If ADDE serving of the NLDN Lightning data was properly setup on your
ADDE server (presumably kepler), you can check this using PTLIST:

PTLIST RTPTSRC/LIGHTNING

However, I am not able to access your LIGHTNING data from kepler
even though I am able to access the SFCHOURLY, UPPERMAND, UPPERSIG,
SHIPBUOY, and SYNOPTIC data:

DATALOC ADD RTPTSRC KEPLER.SCA.UQAM.CA

PTLIST RTPTSRC/PTSRCS FORM=FILE ALL
Pos      Description                        Schema  NRows NCols Proj# Created 
DataDate
------   --------------------------------   ------  ----- ----- ----- ------- 
--------
     1   SAO/METAR data for   10 JUN 2006   ISFC       72  7000     0 2006160 
2006161
     2   SAO/METAR data for   11 JUN 2006   ISFC       72  7000     0 2006161 
2006162
    11   Mand. Level RAOB for 10 JUN 2006   IRAB        8  1500     0 2006160 
2006161
    12   Mand. Level RAOB for 11 JUN 2006   IRAB        8  1500     0 2006161 
2006162
    13   Mand. Level RAOB for 12 JUN 2006   IRAB        8  1500     0 2006162 
2006163
    21   Sig.  Level RAOB for 10 JUN 2006   IRSG       16  6000     0 2006160 
2006161
    22   Sig.  Level RAOB for 11 JUN 2006   IRSG       16  6000     0 2006161 
2006162
    23   Sig.  Level RAOB for 12 JUN 2006   IRSG       16  6000     0 2006162 
2006163
    31   SHIP/BUOY data for   10 JUN 2006   ISHP       24  2000     0 2006161 
2006161
    32   SHIP/BUOY data for   11 JUN 2006   ISHP       24  2000     0 2006162 
2006162
    51   SYNOPTIC data for    10 JUN 2006   SYN         8  6500     0 2006160 
2006161
    52   SYNOPTIC data for    11 JUN 2006   SYN         8  6500     0 2006161 
2006162
    60   SYNOPTIC data for    09 JUN 2006   SYN         8  6500     0 2006162 
2006160
PTLIST: Done

So, it is likely that you have two problems on kepler:

1) your NLDN lightning MD files are not being scoured correctly
2) ADDE serving of the NLDN Lightning data is not setup correctly

The first thing to do is get ADDE serving of NLDN lightning data setup.
To do this, you will need to make sure that your 'mcidas' login account
can "find" the NLDN lightning data files:

<login as 'mcidas'>
cd ~mcidas/workdata
dmap.k MDXX007

Examine the REDIRECT listing to see if NLDN lightning data files
are found (e.g., MDXX0071, MDXX0072, ... MDXX0080).  If your
listing is empty, then your 'mcidas' login session is not configured
to find the files being created by your nldn2md decoder.  If this
is the case, review your ~ldm/etc/pqact.conf entry for NLDN processing
for McIDAS to see where you configured the decoder to write the
output files.  Take that information back to the 'mcidas' login
and "teach" McIDAS how to find the NLDN MD files.  For instance,
if the NLDN MD files are locate in the directory /data/ldm/mcidas,
then you would "teach" McIDAS how to find the files using:

<as 'mcidas'>
cd ~mcidas/workdata
redirect.k ADD MDXX007\* \"/data/ldm/mcidas
redirect.k ADD MDXX0080 \"/data/ldm/mcidas

After doing this, rerun the DMAP invocation to make sure
that your session can successfully find the files:

dmap.k MDXX007

Once your 'mcidas' account can find the files, you need to make
sure that ADDE has been configured to serve the data:

dsserve.k LIST RTPTSRC

Make sure that there is an entry for LIGHTNING.  I feel confident
that it is there since a DSINFO command shows that the data
should be expected:

dsinfo.k POINT RTPTSRC

I feel pretty confident that the problem you are seeing is related
to your 'mcidas' session not knowing where to find the NLDN Lightning
MD files.  This would also explain why your MD files are not being
scoured correctly.

> For the restricted access, I knew about the restrictions. How can I be
> sure that it was configured correctly and that it cannot be accessed
> outside my campus?

This is a bit trickier, and it is the reason I chose to answer your
inquiry from our inquiry tracking system rather than on the mcidas-x
email list.  In versions of McIDAS previous to v2005, you would have
had to create another dataset group and served the NLDN data out of
it.  Supposedly in v2005 one can allow/disallow access to a dataset
on a finer basis than by ADDE dataset descriptor (in the ADDE dataset
name RTPTSRC/LIGHTNING,'RTPTSRC' is the ADDE dataset group name
and 'LIGHTNING' is the ADDE dataset descriptor name.  McIDAS has always
had the ability to limit access to ADDE dataset groups; the addition
of being able to limit base on the ADDE dataset descriptor is new,
and, quite frankly, I need to do some research in order to tell you
how to implement it.

> Many thanks again!

No worries.  Please let me know the results of the DMAP MDXX007
command I referred to above.

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