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

[McIDAS #XGD-732939]: McIdas and LDM

Hi Ben,

re:
> Wow, what service.  :)

We aim to please :-)

> I knew having you look at our setup would be a good thing, I just didn't 
> realize
> how many things you'd be able to find.  Thank you for your help.

No worries.

> Your login key is welcome to reside on our system.

Thanks.  This will speed up logging in...

> The compositing is now working great, thanks for those instructions you sent 
> me
> (I hadn't set up ROUTE.SYS to do it).

Very good.

> You mentioned that you needed root access to be able do some things (among 
> which was
> fixing logging to ~ldm/log/ldmd.log).

Thanks.  A quick look at your /etc/syslog.conf file showed that I need to do 
some
reading to get syslogd-based logging.  I hadn't realized that you are running
Ubuntu Linux!

> I did have a few questions that I was hoping you could answer to help me 
> understand
> what was going on a little better, and possibly fix some things that we still 
> want
> to do.

The more you understand, the less we have to intefere :-)

> First, it would be well if all of the imagery we wanted to generate in mcidas 
> could
> be done from our local data.  Thanks to you, we can and are using our local 
> data for
> most of it.  However, I am unable to generate GOESEAST imagery (ie IMGDISP 
> GOESEAST/WH-1KVIS ...)
> using the ADDE server "LOCAL-DATA".  I get the error message

> "Image data server unable to resolve this dataset: GOESEAST/WH-1KVIS".

> I have to use UNIDATA2.SSEC.WISC.EDU as the ADDE server in order to 
> successfullly generate
> that imagery.  From the error message I'm guessing its something to do with 
> my setup, but
> I'm not familiar enough with mcidas yet to know which file I'd need to hit.  
> Any help you
> can give me here is appreciated.

The GOESEAST dataset is only available on unidata2.ssec.wisc.edu.  You are not 
receiving
the images necessary to create this dataset.  You could be, but the setup would 
still
require you to access imagery from a remote machine (in particular, the images 
from
the EAST dataset which is hosted on unidata2.ssec.wisc.edu).  Suffice it to say 
that
you should "point" at unidata2.ssec.wisc.edu for the GOESEAST images.  Also, 
please
note that the only image in the GOESEAST dataset that is not in the UNIWISC feed
is the 1 km Visible image.  All of the IR images in GOESEAST are sent out in 
UNIWISC
IDD feed in the same resolution as the ones available in GOESEAST.  And, those 
images
are available in the RTIMAGES dataset that you are now accessing locally.

> The second question is regarding Lightning data.  I have an entry in my 
> pqact.conf
> and my ldmd.conf to ingest Lightning data, but when I try to display 
> lightning data
> in mcidas I get the error, "NLDNDISP: Failed at SERVER REQUEST step".  I'm 
> not sure
> what needs to be done with this one.

Hmm...  your pqact.conf entry for NLDN lightning data looks OK, but I don't see
any decoding going on.  I'll have to investigate further.

re: FNEXRAD radar composites

> (this question is going to betray my "newbieness")  Am I to understand from
> this that I should have another entry in my ldmd.conf file along the lines of
> "REQUEST FNEXRAD...", and that I need to make sure webcat is also requesting 
> that
> from their upstream provider?

Yes.  The LDM is a point-to-point data transfer mechanism.  You will not get any
FNEXRAD data from webcat if it is not getting it from somewhere else.

> Also, is there a good document/resource I could get my hands on that would 
> help
> me acquire the same type of understanding that allows you to know things like
> the FNEXRAD feed contains NEXRAD composites (ie, I don't know which feed type
> [and pqact entry to ingest it, etc] I need for a particular mcidas command to
> be able to function correctly).

FNEXRAD is an IDD feedtype like UNIWISC. The feed types are defined in the LDM
portion of our site.

The web pages for the ldm-mcidas decoders mention which datastreams the decoders
will work on.

The McIDAS command you would use for any imagery served through ADDE is IMGDISP.

Your question makes it apparent that a high level docuement that puts everything
into perspective is needed.

> Finally, just a "help me understand" question.  As you know, in ldm's data 
> directory
> (/usr/local/ldm/data) I have a mcidas directory and a gempak directory.  From 
> the
> entries provided in the file "pqact.conf_ldm-mcidas" it appears there is one 
> type of
> entry "using McIDAS-X routing table for product naming" (these go to 
> data/mcidas) and
> another type for "decoding UW datastream imagery (...) into a hierarchical 
> directory
> structure)" (these go to data/gempak).  Can you tell me what the differences 
> are between
> these, or if/why I need the gempak and mcidas files?  One reason I'm prompted 
> to ask
> this question is that it appears to me that the pqact entries are identical 
> for both
> (just that the gempak entries are a little more specific and therefore broken 
> up into
> various directories while the mcidas entry just grabs everything and throws 
> it into
> the mcidas dir).

The pqact.conf actions that specify the use of the McIDAS routing table have 
the '-r'
flag.  The routing table (ROUTE.SYS) not only controls the name space of the 
image
to be written, it also controls whether an action is run after successful 
receipt
of an image.  The McIDAS routing table is an old facility in McIDAS that could 
be
replaced by standard LDM pqact.conf entries.  Since it still in use at long 
standing
McIDAS sites, it is hard to get rid of.  To really get a better idea of how the
routing table is used, I would advise you to read through the online McIDAS 
training
workshop materials.

> Thanks again for all your help and mentoring!  I feel a LOT better about our
> mcidas/ldm setup now.  I hope my many questions aren't frustrating/exhausting.

Absolutely no worries on your questions!  To really understand the "care and 
feeding"
of McIDAS, one really should attend a training workshop.

More later after I figure out why your lightning data is not being decoded (the 
reason
for this would be written to the ~ldm/logs/ldmd.log file IF syslogd logging was 
working).

Back to the meeting...

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