>From: Jim Koermer <address@hidden>
>Organization: Plymouth State College
>Keywords: 200108251422.f7PEMS127324 McIDAS-X 7.8 NOAAPORT Unisys
Jim,
>Our Unisys NOAAPORT system are all set up to work with LDM. That is how
>I am now getting NIDS data over to PSCWX. I can tell the NOAAPORT
>systems to send all data or I can narrow it down to send only NIDS data
>as I am currently doing.
If you tell the system to send all of the data, is it separated into
logical datastreams like the old FOS ones: DDS, PPS, IDS, HRS, etc?
If so, the problem of getting XCD to work smoothly vanishes. If
all of the data comes over looking like a single datastream, then
a good bit of work has to be done to identify which products contain
textual bulletins and which ones contain binary bulletins. The
way XCD gets setup to work with the LDM is based on being able to
make this distinction.
>I configure what data that I want sent on the
>NOAAPORT machine. On the PSCWX or ingestor side, I just need to set use
>a "pqing" line(s) in my ldmd.conf to start the ingest and I use
>pqact.conf as I would for any other feed to file or perform other
>actions on the data. So, on the LDM side, my pqact.conf file would be no
>different than if I was getting the NOAAPORT or WMO feed from Unidata.
This seems to say that the data will come across logically organized into
different datastreams. Again, if this is the way it works, getting XCD
to start producing all of the decoded output for McIDAS is a no-brainer.
>Perhaps, the confusion comes about from the fact that I can easily limit
>what data are fed from the NOAAPORT side. So, I assume that if I knew
>what entries you use in pqact.conf to process all the data for XCD, I
>can set up the Unisys system to transfer the required products for LDM
>ingest on PSCWX. There are probably many other products (e.g. climate
>products) that might not be needed and I was trying to limit some of
>these to reduce network traffic.
The XCD entries in pqact.conf are significantly different than for most
packages; they are extremely simple. Here they are in total:
#
# McIDAS-XCD section
#
DDPLUS|IDS ^.* PIPE
xcd_run DDS
HRS ^.* PIPE
xcd_run HRS
That's it! xcd_run is a shell script wrapper around XCD ingestion
processes. The XCD routine ingetext.k gets run from the 'xcd_run DDS'
line, and the XCD routine ingebin.k gets run from the 'xcd_run HRS'
line. These ingestors read from stdin and write to spool files. The
spool files are, in turn, read by processes known as data monitors.
Subroutines of data monitors are decoders, so it is the data monitor
subroutines that end up producing McIDAS formatted data files:
MDXXxxxx, GRIDxxxx, and a slew of files used for rapid access to text
data. McIDAS has a whole facility that allows one to look at any raw
bulletin that is ingested; it has all of the functionality of Peter
Neilley's 'weather' program AND more (more since it can access data
from remote servers).
>Does this explain what you needed?
Yes _if_ the data flowing from the NOAAPORT system ends up looking like
logical datastreams. If this is the case, I would suggest that we
start by sending everything from the NOAAPORT system to the LDM on
PSCWX and decode everything using XCD. We could then decide what you
do not want decoded and tell the NOAAPORT system to not send those
products to PSCWX.
By sending everything, I mean everything in the TG channel, not the
GINI imagery in channels 1 and 2. -- a quick side note here: Unisys
refers to the channel numbers in a non-standard way. The standard way
is that the GOES-East channel is #1; the GOES-West channel is #2; the
channel with the text and model data is channel #3 (commonly referred
to as NWSTG or TG for short); and channel #4 contains other, mostly
experimental streams --. So, the data I am talking about sending from
your NOAAPORT system to the LDM is all of the data in channel #3.
Tom
**************************************************************************** <
Unidata User Support UCAR Unidata Program <
(303)497-8644 P.O. Box 3000 <
address@hidden Boulder, CO 80307 <
---------------------------------------------------------------------------- <
Unidata WWW Service http://www.unidata.ucar.edu/ <
**************************************************************************** <
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.