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
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.