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

20000306: NIDS and NOWrad setup (cont.)

>From: "Karli Lopez (McIDAS)" <address@hidden>
>Organization: University of Puerto Rico
>Keywords: 200002010754.AAA03412 datastreams ROUTE PP BATCH LDM

Karli,

re: point BLIZZARD to ADDE.UNIDATA.UCAR.EDU
>done.

OK, thanks.

re: WSI NOWrad (tm) data is expensive
>Yeah we don't have them... not now at least : )

In the fall, the National Weather Service will start broadcasting two
different radar composites in NOAAPORT.  This will be in addition to
select products from all NIDS sites.  All of these free products will
be accessible in McIDAS through my ADDE NIDS and NOWRAD servers.

>> WSI     ^NEX/(.*)/(.*)/([1-2][0-9])([0-9][0-9])([0-1][0-9])([0-3][0-9])([0-2
> ][0-
>> 9])([0-6][0-9])
>>         FILE    data/nexrad/NIDS/\1/\2/\2_\3\4\5\6_\7\8

>Ok I've found the WSI lines for NIDS however, there is an entry for each
>image, and one general entry at the top:

The reason that there is one for each image is there needed to be one
for the nids2area decoder.  The reason is that the decoder needed to
be told which McIDAS ROUTE entry to use to file the product in AREA
files.  Since the ADDE setup reads the NIDS files directly, these entries
are not needed.


What is this-
              \
               \

>#                        Composite Reflectivity
>#-------------------------------<ERROR>-------------------------------------
>WSI ^NEX/(...)/(CREF)/..([0-9][0-9])([0-1][0-9])([0-3][0-9])([0-2][0-9])([0-6]
> [0-9])
>
> PIPE -close nids2area
> -l /unidata/ldm/data/logs/ldm-mcidas.log   -vx
> -d /unidata/ldm/data/mcidasd/ 8005 \1 DIALPROD=R5 \3%j \6\700 DEV=CCN

It looks like the error might have been the blank line before the PIPE line.

>and in the example you supplied there is only one line... so:

Right.  When simply filing the raw products, there needs to be only one
action.

>- do I replace everything with that one line? or,

Yes.  I suggest you comment out, not delete, the nids2area entries.
NOTE: after editing ~ldm/etc/pqact.conf, you should always run

ldmadmin pqactcheck

to verify that your editing did not introduce errors into pqact.conf.

>- do I replace the top line only, or
>- do I need to make similar changes to every single line?
>as you already know I don't wanna screw up this configuration...

Comment out the existing lines, and put in the single line for NIDS
that I sent.

re: where is the data really being stored
>yes, actually ~ldm us /unidata/ldm and ~ldm/data points to
>/user2/unidata/data.

OK.  This is the typical kind of setup.

>The NIDS files are stored in ~ldm/data/mcidasd, so should I then write:
>  - DIRMASK=/unidata/ldm/data/mcidasd/NIDS^ID^TYPE/*
>  - DIRMASK = /user2/unidata/data/mcidasd/NIDS^ID^TYPE/* (my guess)

Perhaps there is an email problem here.  The '^' characters are not
what are wanted.  You would set DIRMASK to:

DIRMASK=/user2/unidata/data/mcidasd/NIDS/\ID/\TYPE

and FILEMASK to:

FILEMASK=\TYPE_*

>(or will either work?)[ or does it have to be: = /data/mcidasd/... ]
>I didn't fully understand what you were saying about /data.

My comment about /data was that IF ~ldm/data was actually /data
(~ldm/data is most always a link to another directory; on your system
it is a link to /user2/unidata/data) then your DIRMASK and FILEMASK
would look like:

DIRMASK=/data/nexrad/NIDS/\ID/\TYPE/*
FILEMASK=\TYPE_*

One last comment.  The ADDE access to the NIDS data will work in the
Unidata Fkey menu but not in the Undiata MCGUI.  If you have been using
the MCGUI, you will want to keep decoding NIDS data into AREA files
(at least until I upgrade MCGUI to ADDE).  This does not mean, however,
that you can not/should not setup saving NIDS data directly into raw
files and setting up the NIDS ADDE server configuration file,
~mcidas/workdata/NIDS.CFG.  You can have both things working and then
turn off the converting to AREA files when MCGUI gets ADDEized.
Of course, if you do not use MCGUI, you can turn off the AREA file conversion
right now.

>Thanks!

There will be one more step in the saving of NIDS files directly that you
will have to do.  Since there could be 12 products per hour for 20 NIDS
products per site, there could be 240 NIDS products filed every hour for
every NIDS site that you are receiving.  If these files do not get scoured,
then you will be saving 5760 NIDS product files per site per day.  This is
a LOT of data files!  I will be sending you a script that you can run
from cron that is used to scour NIDS products back to about 60 for each
type for each station later today.

Tom