This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>From: Gilbert Sebenste <address@hidden> >Organization: NIU >Keywords: 200311191905.hAJJ5lOb020725 McIDAS-X Fedora Linux Gilbert, >Now, let's throw in another bugaboo into the mix. > >Wanna have some fun? > >OK, let's go! Weather2.admin.niu.edu is now fully functional on Fedora 1, >running LDM 6.0.14 (compiled) and the old McIDAS...which is bombing left >and right because it can't find TCL/TK. Since the Tcl/Tk that McIDAS uses is part of the distribution, and since the location of the Tcl/Tk stuff gets "burned in" to the Tcl/Tk executables, I would guess that something in the location of the HOME directory for the user 'mcidas' changed. If this is the case, the easiest thing to do would be to rebuild the McIDAS distribution, a step that won't take long: <login as 'mcidas'> -- verify that the environment variables specified in your shell-specific configuration file (e.g., .cshrc for C shell/Tcsh; .profile for the Bourne shell, .bash_profile for bash, etc.) are correct for how McIDAS is now setup. cd mcidas2003/src make clobber make all VENDOR=-g77 make installall VENDOR=-g77 >The McIDAS decoders aren't liking Fedora one bit, either. Probably for much the same reason as the Tcl/Tk failure. >I'll do some more peeking this afternoon and see >if I can't fix the problem with single images not displaying on weather3. If I could export an X display back to my machine here at the UPC, I would. I tried this a few days ago, but it did not work. I think our system administrator turned off our ability to run remote X sessions with displays back here. >Specifically, look at /home/mcidas/workdata/CFDGONLY.BAT. It also chokes >on that. We talked about this the other day. You are referencing the ADDE dataset RTGRIDS in CFDGONLY.BAT, and you have no DATALOC for that dataset. When there is no DATALOC for a dataset, McIDAS assumes that it is locally defined. You are are neither ingesting NOAAPORT GINI images, nor do you have datasets setup to serve them. So, the BATCH file _should_ fail. OK, I made a copy of CFDGONLY.BAT as CFDGONLY_1.BAT and edited it to set the datsets as per my recommendation a few days ago. I then ran the BATCH file: <as 'mcidas'> cd ~mcidas/workdata batch.k CFDGONLY_1. and the display of images, saving to GIFs ran fine. What didn't work was the step of copying CFDG.GIF to /home/httpd/html/cfdg.gif. I think the reason for this failure is that permission is being asked to overwrite files in /home/httpd/html. Yup. The images in /home/httpd/html are owned by ldm, and their read/write permissions are rw-r--r--: ls -alt /home/httpd/html/cfdg* -rw-rw-r-- 1 mcidas unidata 66061 Nov 19 13:40 /home/httpd/html/cfdg.gif -rw-r--r-- 1 ldm unidata 118337 Oct 28 14:19 /home/httpd/html/cfdg5.gif -rw-r--r-- 1 ldm unidata 122205 Oct 28 14:19 /home/httpd/html/cfdg6.gif -rw-r--r-- 1 ldm unidata 93017 Oct 28 14:19 /home/httpd/html/cfdg7.gif -rw-r--r-- 1 ldm unidata 103398 Oct 28 14:19 /home/httpd/html/cfdg8.gif -rw-r--r-- 1 ldm unidata 79113 Oct 28 14:19 /home/httpd/html/cfdg2.gif -rw-r--r-- 1 ldm unidata 95773 Oct 28 14:19 /home/httpd/html/cfdg3.gif -rw-r--r-- 1 ldm unidata 99824 Oct 28 14:19 /home/httpd/html/cfdg4.gif -rw-rw-r-- 1 ldm unidata 3554 Oct 28 14:19 /home/httpd/html/cfdg.txt Presumably you run the CFDGONLY.BAT BATCH file out of a cron job by the user 'ldm' (hence the ownership of the GIFs (tm) by 'ldm'). This doesn't, however, seem to jibe with the cron job I see for the user 'mcidas': 00,12,27,42,57 * * * * /home/mcidas/kickoff CFDGONLY.BAT The solution for the BATCH files you run is simply: - change references to RTGINI to either GINIEAST, GINIWEST, or GINICOMP as appropriate Now, you could simply add a DATALOC for RTGINI: DATALOC ADD RTGINI adde.ucar.edu ** BUT ** I want to get rid of that dataset definition, so things will probably break in the future. Might as well take care of the problem the "right" way now. >And, if all goes well, would you be up for a McIDAS (eeek) re-install on >weather3 IF Fedora works well later this week or next? Are you thinking of wiping the disk, or of upgrading from the current version of RedHat Linux to Fedora? If you are updating, all that will be needed is a rebuild as I outlined above: <as 'mcidas'> cd mcidas2003/src make clobber make all VENDOR=-g77 make install.all VENDOR=-g77 >I've been told I >should think of it as RedHat 10. Outside of a few new security quirks, it >has been running fine for me so far... OK. Tom