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 message; saves metadata into the MySQL database; and then files the raw GRIB 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
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.