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: Chris Herbster <address@hidden> >Organization: Embry-Riddle Aeronautical Univ. >Keywords: 200102131816.f1DIGsL18220 McIDAS MCPATH MCGUI Chris, >Perhaps a subject change relating to $MCPATH is appropriate? Yup. re: .cshrc contents versus contents of .mcenv >Opps - I guess I confused the stuff that should go in the .cshrc with >.mcenv. "Mcidas", the user, does invoke tcsh as the shell .... In this case, you would add the earlier configuration stuff to the .cshrc file and the Bourne/Korn shell stuff to the .mcenv file making sure that they both define things in the same way (i.e., MCPATH values (not syntax) in .cshrc matches MCPATH in .mcenv, etc.). re: check http://www.unidata.ucar.edu/packages/mcidas/770/mcx/mcxacct.html >Thanks - I must have been asleep at the wheel when I did this >installation. (-: No problem. >I have another problem, this is not new as I discovered it shortly after >sending this past message out. OK, ready... >When "Joe User" (actually in this case a generic lab user named "opwx") >tries to run mcidas, this is what they get: > >[opwx@thermal ~]$ mcidas >[opwx@thermal ~]$ ERROR: MCPATH contains no writeable directory >ERROR: current directory is not writable > >[opwx@thermal ~]$ >[opwx@thermal ~]$ echo $MCPATH >/wxhome/mcidas/workdata:/wxhome/mcidas/data:/wxhome/mcidas/help > >This seems to be consistent with the instructions. Actually, it is not. The user 'mcidas' account is setup differently from all other users accounts. This was done to reinforce the difference between 'mcidas' -- which should be thought of as 'root' for McIDAS stuff -- and all other users. The MCPATH for the user 'mcidas' would look like: /home/mcidas/workdata:/home/mcidas/data:/home/mcidas/help The HOME for your 'mcidas' user is /wxhome/mcidas, so the MCPATH for your 'mcidas' user would be: /wxhome/mcidas/workdata:/wxhome/mcidas/data:/wxhome/mcidas/help The MCPATH for all other users should look like: /home/user/mcidas/data:/home/mcidas/data:/home/mcidas/help Assuming that the HOME directory for your 'opwx' user is /wxhome/opwx, the MCPATH for 'opwx' would be: /wxhome/opwx/mcidas/data:/wxhome/mcidas/data:/wxhome/mcidas/help Note that you must make sure to create the mcidas/data subdirectory for the user 'opwx' and also make sure that this directory is readable and writable by the user 'opwx'. Once this change is made, you will not see the error that you list above. >This same behavior is seen in other user's accounts too. The same comment applies to other users. The MCPATH is generically: MCPATH=~user/mcidas/data:~mcidas/data:~mcidas/help (the ~user and ~mcidas should be replaced with the actual HOME directories for the users 'user' and 'mcidas', respectively). >I didn't notice this problem as my user id (herbster) that I had been >testing with is an auxiliary member of the group "data" that mcidas is >part of (along with ldm and gempak). The reason you did not see the problem is that by virtue of you being in the same group as 'mcidas' and 'ldm', you will have read/write permission to the ~mcidas/workdata (and ~mcidas/data and ~mcidas/help) directory. You should change your account setup to match the example above and that detailed in: Configuring Unidata McIDAS-X Accounts http://www.unidata.ucar.edu/packages/mcidas/770/mcx/config_mcx.html Configuring User Accounts http://www.unidata.ucar.edu/packages/mcidas/770/mcx/config_users.html The thing that may not have jumped out at you from the last page is the distinction between the MCHOME and HOME environment variables. >With group write permissions being the default for these accounts I >certainly don't want the average user to be in this group. >I've tried to find the answer to this online, but no luck so far. You are correct, you do not want the average user to have write capabilities in the directories owned by the user 'mcidas'. This is why I made the following comment in: Preparing the mcidas and mcadde Accounts http://www.unidata.ucar.edu/packages/mcidas/770/mcx/mcxacct.html ... 2. If the mcidas and mcadde accounts are not in the same group as the user running the Unidata LDM, have the system administrator put them in the same group. This group should be different than the one that general users are in. ... The operative comment is the last sentence: mcidas, mcadde, and ldm should be in the same group AND this group should be different that the one that general users are in. re: example BATCH file ><... snip ... stuff on how to view the images - Thanks!!> Did it all work as advertised? I wrote this from home where I was not running McIDAS, so I couldn't test it. re: do you want to run the ADDE remote server >Actually this is where I'd like to be headed. Thermal is our LDM >ingestor/data server. We have a couple of other machines that will >eventually be running the mcidas package and my understanding is that >ADDE give better performance than NSF mounts. Yes, exactly. Also, when one gets used to accessing stuff from remote servers (like using Netscape, for example), the data possibilities explode! >Actually, while getting setup, it might be nice to configure things for >another ADDE server(s). That way we could have good data access while I >nibble away on the in-house configuration. > >Any suggestions on which server to point to? Yes. My records show that you recently (May 23) grabbed a McIDAS distribution that has all of the recent mods included. Given this, you now have a GUI widget that you can use to setup dataset access to a list of ADDE servers at cooperating sites. Access to this widget is provided in two places: Fkey Menu: F8 Menu Administration ==> F5 ADDE Dataset Locations MCGUI: The stange looking icon just to the right of the capital Z (zoom); this icon has two PCs that are interconnected with arrows. When you pop open the GUI widget, you will see what machines are currently available for the various datasets listed (left click on the down arrow in the entry/button combination widget). For instance, the servers that are available for the dataset GINICOMP are currently: STRATUS.AL.NOAA.GOV PAPAGAYO.UNL.EDU CACIMBO.GGY.UGA.EDU SNOW.PLYMOUTH.EDU ADDE.UCAR.EDU LOCAL-DATA The same set of machines are available for most of the other datasets, but you will find varying numbers of radars at different sites. This is a result of what those sites are getting by IDD. Please note that the Fkey Menu is basically ADDEized (except for grid cross sections). MCGUI, on the other hand, only provides ADDE access to certain functions under Display ==> Observations: Meteorograms Thermodynamic Diagrams/Hodographs ------ Profiler Time-Height ------ Fronts Weather Watch Boxes As I mentioned in my previous email, the 7.8 MCGUI will be completely ADDEized. At this point, the Fkey menu should fall in disuse and so will be no longer be updated. ><snip stuff on sample script - Thanks again!> You are welcome. re; Please let me know if you run into any snags. >Here I am again! (-: McIDAS is a tough one to get to love, but I can tell you that being able to sit at your desktop and access data from servers from all over the world will make the pain worthwhile. In the future, you will see the list of cooperating ADDE server sites grow and grow. You will also see the number and variety of data served by those sites increase as people "publish" their local holdings. My job is to do a good enough job on the MCGUI to make this access as painless as possible. >Thanks Tom! You are welcome. Talk to you later... Tom