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

20040505: ADDE server question

>From: Owen Cooper <address@hidden>
>Organization: Aeronomy Laboratory/NOAA
>Keywords: 200405051932.i45JWHtK001738 McIDAS ADDE

Hi Owen,

>For this summer's pollution study in New Hampshire I will create some MD 
>files containing modeled pollution data that can be overlayed onto GOES 
>imagery.  I'd like to make these MD files available for Jennie Moody to 
>use. 

OK.

>I assume there's some way to set up an ADDE server here at the lab that 
>Jennie can access, or maybe I can pipe the data into our LDM and have 
>Jennie feed off the LDM server.

Either approach will work.

>Which approach do you think would work best, and can you point me in the 
>direction of the appropriate how-to webpages so I can read up on all 
>this before I start bombarding you with too many questions?

Let's start with sending her the data by LDM:

- first, read the man pages/LDM manual for pqinsert.  You can use it
  to inject products into an LDM queue while specifying its IDD
  datastream type and product header.  After than, any site that
  you have allowed to request data in that feed type from your LDM
  make a request for the data and have it sent to them.  Its just
  that simple

Now, for ADDE, the job is equally simple _if_ you have a machine
already setup with the remote ADDE server.  By setup, I mean configured
from the McIDAS side AND in a network where the port used by ADDE is
not blocked by a firewall.  Setting up the McIDAS remote ADDE server is
described in the McIDAS web pages which begin at:

http://www.unidata.ucar.edu/content/software/mcidas

After an ADDE server is setup and accessible from the outside, your
only job is to create an ADDE dataset that contains the files you want
to make available.  Given the generalization of data file names for MD
and GRID files that was added in v2003x, it is easy to store a lot of
files of those types in a directory without having to worry about using
the arcane MDXXnnnn and GRIDnnnn naming conventions.  For instance,
let's assume that you name your MD files something like

POL_YYYYMMDD.sfc

where:

YYYY - 4-digit year
MM   - 2-digit month
DD   - 2 digit day
.sfc - suffix that identifies the type (surface, mandatory level upper air,
       etc.)

Let's also assume that you put the files in a directory like:

/data/project

You can then create a dataset using the McIDAS DSSERVE command:

DSSERVE ADD POLUT/SFC MD DIRFILE=/data/project/POL_*.sfc TYPE=POINT "Pollution 
project surface data

or whatever.  Since you want to make the data available to remote
machines, you would create the dataset under the 'mcidas' account.  If
you follow directions for setting up the server, the access will be
through the 'mcadde' account which, I have folks create as essentially
an alias for 'mcidas'.

The online training workshop for McIDAS or the McIDAS Learning Guide
have exercises that have you create datasets from MD files.  Those
examples are still setup to use the old approach where the files are
named MDXXnnnn, but the basic procedure is the same or easier when
files have descriptive names.

So, if you want to go the ADDE route -- and I recommend this route
since it keeps the onus on you for keeping the files up to date --
is to get a machine setup with the remote ADDE server.  stratus.al.noaa.gov
is one such machine, so your giving Jenny access could be done through
it.

>Thanks!

No worries.

Tom
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically 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.