[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[McIDAS #LPP-595939]: Problems with NLDNDISP
- Subject: [McIDAS #LPP-595939]: Problems with NLDNDISP
- Date: Sun, 11 Jun 2006 15:40:59 -0600
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