[McIDAS #XLJ-825608]: Trouble setting up ADDE service for IDV use

Hi Art,

re: my suggestion about grabbing the latest release

> Okay, I got the new one again.  How often do these get updated?

After the dust dies down, not that often.  The changes I have made since the 
original
release have been the result of finding and fixing bugs or seeing the use of 
mcxconfig
from the user's perspective.  I am hoping that these changes are behind me now 
so that
the next addendum will contain package upgrades, the first set of which will be 
the
incorporation of the ldm-mcidas decoders (e.g., lgt2md (an nldn2md replacement),
proftomd (NOAA wind profiler data), pnga2area (PNG-compressed AREA file 
uncompressor),
pngg2gini (PNG-compressed FNEXRAD GINI uncompressor), and zlibg2gini 
(Zlib-compressed
NOAAPORT GINI image uncompressor)).

> BTW, regarding bugs, I noticed in the mcxconfig script the word "recirect"
> which I suspect is supposed to be "redirect", in case you're interested.

Thanks for reporting this typo.  Luckily, it does not affect what mcxconfig 
does,
so there is no need to issue a new addendum to fix it.

re: To get a listing out of SERVER.LOG, run the routine ADDEINFO:

> <as 'mcidas'>
> cd $MCDATA
> addeinfo.k       <- summary listing

> Okay... thanks.

ADDEINFO (addeinfo.k) is very useful for tracking use of the ADDE server.
I keep the file in the ~ldm/logs directory and rotate it once per week:

<as 'mcidas'>
cd $MCDATA
redirect.k ADD SERVER.LO\* \"/usr/local/ldm/logs

<as 'ldm'>
-- add the following log file rotation to 'ldm's crontab:

#
# McIDAS ADDE Remote Server Logging
#
1 0 * * 6 bin/newlog logs/SERVER.LOG 3; chmod 666 logs/SERVER.LOG

re: I see a big problem here: ...
> Actually, the ~mcidas/mcidas2007 was the install directory and
> ~mcidas/dist/mcidas2007 was the distribution directory where I did the
> build, so I don't think there would have been a problem.  One could argue
> the naming was a bit confusing...

I should have said that I see a "potentially" big problem.

re: switching to a standard McIDAS installation
> Okay, that's what I've done now... McINST_ROOT is ~mcidas and the
> package distribution is in ~mcidas/mcidas2007.

Excellent.  Your life will be easier from now on.

re: HOWTO adjust /etc/xinetd.d to reflect your old setup
> Okay, I tried the above modifications to /etc/xinetd.d with a kill -HUP,
> but it still didn't work.

OK.

> However, after the reinstall to standardize the
> install, I ran the mcxconfig script (which you suggested below and I
> hadn't done before) and I noticed it configured a lot more environment
> variables in ~mcidas/.mcenv and now its working... yipeee!

Excellent!  The benefits of having a standard installation are showing
benefits already :-)

> A couple of questions:
> 
> 1) The mcxconfig script only asked for a data location once (definition
> for XCDDATA) for which I used "/data/ldm/mcidas".  When I looked in the
> data/LOCAL.NAM file, it seems all the McIDAS data files are referenced to
> be in one flat location, /data/ldm/mcidas.  Is this normal?  I.e., do all
> McIDAS data files normally reside in one directory, or am I supposed to
> edit this if I want something different?

Most of the REDIRECTions set in LOCAL.NAM are for XCD-produced files (GRID*,
*.XCD, *.IDT, *.IDX, etc.).  There are also REDIRECTions for AREA files
which are written using the McIDAS routing table (ROUTE.SYS and SYSKEY.TAB)
concepts.  Other data, like NEXRAD Level III products, NEXRCOMP NEXRAD Level III
composites (in FNEXRAD IDD feed), UNIWISC images, and NIMAGE images would get
written to directories like /data/ldm/mcidas/images/sat, 
/data/ldm/mcidas/images/NEXRCOMP,
and /data/ldm/mcidas/images/NIDS.  Since most Unidata McIDAS sites also use
GEMPAK, mcxconfig pauses after letting the user know that s/he should review
the contents of LOCAL.NAM, LSSERVE.BAT, and LOCDATA.BAT and make modifications
where necessary.  The McIDAS only user will be able to go with what mcxconfig 
creates
for him/her.  The site that is actively using GEMPAK will, at a minimum, need
to review how the various feeds of satellite images are being processed for it
and adjust LSSERVE.BAT entries to match their setup.  McIDAS is very flexible
in how it can serve data...

> 2) It appears that GRIB data must be decoded with the XCD deocders in
> order to be available via ADDE... is this correct?

Correct.

> Or can I serve up GRIB data undecoded some other way?

I recommend that _if_ you want to serve model data using ADDE then you should
install MySQL (server, client, and development RPMs) and process the data
using the GRIB filer, DMBIN, and serve the data that way.  The GRIB filer
cracks each GRIB[12] message; saves metadata into the MySQL database; and
then files the raw GRIB[12] messages into the directory where the REDIRECTion
for *.gr* points.  It also files BUFR data, but there is no BUFR ADDE server
to take advantage of this yet.  By the way, the access to the model data
processed by DMBIN is _very_ fast.  It has me rethink the entire model data
support in McIDAS and my GUI (MCGUI).  I will likely come out with upgrades
to the MCGUI that open up the data to the end user in the easy way thta
it already does for image data.

> What format does the IDV expect for gridded data?

The IDV accesses model data through THREDDS servers.  It does this since
the THREDDS servers can serve up chunks of 3D and 4D data which the IDV
can then use for great visualizations.

> 3) In my test, I pulled up GINIEAST data for 1km VIS and noticed that it
> seems lacking in resolution, i.e. gets blocky when I zoom in.  When I view
> the same data in garp, it's crisp.  I notice the same result when I pull
> data from adde.cise-nsf.gov.

> Is this something the IDV is doing with the data,

Yes, the IDV is asking for sampled data from the server _unless_ you tell
it not to.  If you tell it not to, then the displays will be equally
as crisp as GEMPAK and McIDAS.

> some inadequacy with my workstation/video card, or something else?

Nope, it is just a function of asking for samples of the data instead
of all of it.  Please check the IDV Users Guide for more information on
controlling sampling of images for display.

> Thanks again for your help...

No worries.  I am glad to hear that you are up and running now.

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