Hi again Marty, OK, the rebuild finished, and I reinstalled the newly built code: <as 'mcidas'> cd ~mcidas/mcidas2008/src make clobber make all make install.all I then stopped and restarted the LDM: <as 'ldm'> ldmadmin restart Finally, I reran the test you sent along that was previously failing: mcenv -f address@hidden -g 20 -i 48 imgdisp.k RTNEXRAD/N0R ID=MTX LINELE=230 230 PLACE=C MAG=1 1 EU=BREF SU=X ALL=1 12 SF=YES BAND= X REFRESH='MAP FILE=OUTLUSAM MCOL=4 WID=1 GRA=(GRA);BAR (GRA) SU=X X COL=7 ORIENT=VER' exit This time there were no error messages from BAR (a good thing :-) There are, however, some issues that I feel like I need to document: - when running constructs like the 'imgdisp.k' invocation that includes a REFRESH= keyword sequence in a script, you must be aware that the commands run from the REFRESH= clause are run asynchronously -- the MAP and BAR invocations will be run while the next imgdisp.k is running This is important since the script must keep running for as long as it takes for the MAP/BAR invocations to finish. This may, in fact, require that the user include some sort of sleep in the McIDAS processing sequence (McIDAS command WAIT) so that the mcenv invocation doesn't exit before all of the other processing is done. - there were three make-generated routines that failed during the re-build on your machine: kbprep.for nvprep.for mci_nvpp.for They all failed for the same reason, and that reason is still not 100% clear to me yet. If you don't mind, I will use your machine as a testbed for investigating the problem (since it no longer occurs on our Solaris 10 x86 machine). re: > Also, I have noticed that the WWDISP/FRNTDISP commands are a lot > slower than our other system. The WWDISP command takes about 30 > seconds each time it is run. I was wondering if these commands were > pulling their information from the web somewhere or getting it local > from our LDM. After the rebuild/reinstall I started poking around in the /usr/local/ldm/data/mcidas directory to see what I could see. Here is what I found: - the version of the wind profiler decoder that is being used is not deleting temporary files after decoding the broadcast data. This left a LOT of .tmp_netcdf* files in /usr/local/ldm/data/mcidas. I deleted these files as 'ldm', and will look to upgrade the ldm-mcidas 'proftomd' decoder to a newer version. - again, while looking through /usr/local/ldm/data/mcidas, I noticed that rapid access index files that should be updated by the XCD TEXT decoding were _not_ in the directory. The net result of this is that access to data via the ADDE TEXT server (e.g., dataset RTWXTEXT) would be very slow since each request for data (like fronts and weather watch boxes) would result in a linear search through the daily repository files for TEXT data, and those files are quite large: -bash-3.00$ dmap.k \*.XCD PERM SIZE LAST CHANGED FILENAME DIRECTORY ---- --------- ------------ ------------ --------- -rw- 1261742320 Apr 23 17:59 DD091130.XCD /usr/local/ldm/data/mcidas -rw- 1069854880 Apr 24 14:04 DD091140.XCD /usr/local/ldm/data/mcidas 2331597200 bytes in 2 files Apparently, the XCD setup BATCH file was never run as part of the XCD setup. I did this for you as follows: <as 'mcidas'> cd $MCDATA batch.k XCD.BAT <as 'ldm'> ldmadmin restart Now the TEXT data that comes in will be indexed, and the index files will make access to the newly processed data much, much faster than without the index files. Since the indexing does not go back in time, you will not see the benefit until after a few hours have passed. Please let me know if/when you have questions. 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: ANL-325610 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.