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: Mark Tucker <address@hidden> >Organization: Lyndon State College >Keywords: 200003302234.PAA19269 Vis5D McIDAS-X REDIRECT Mark, >Hi, I've just been working on getting vis5d to compile/install on one of >our Linux workstations. After fixing some errors in the shell script I >found a "Linux" commented out in one of the case structures and >which caused the script to return that Linux was unsupported. There was >no mention of this anywhere in the documentation on the web site so I >assumed that if McIdas was supported on a given platform that vis5d would >be as well. This what I would have assumed if I were you, but it is not necessarily the case. I decided to check to see if Vis5D should work by checking out the Vis5D home page at SSEC: http://www.ssec.wisc.edu/~billh/vis5d.html and see the list of platforms supported in 5.1: Vis5D 5.1, the most recent version, works with the following systems: Silicon Graphics workstations with IRIX 5.x or later. Multiple CPUs are used when present. IBM RS/6000 workstations with AIX 3 or later. OpenGL-based 3-D hardware is supported. Sun workstations with SunOS 5.x or later. HP workstations with HP-UX A.09.01 or later. PEX-based 3-D hardware is supported. DEC Alpha workstations with OSF/1 V1.3 or later. IBM PC compatibles with Linux v1.2 or later. 90MHz Pentium or faster CPU recommended. Windows NT running on Intel. OS/2 running on Intel. Notes: At least 32 MB of RAM is recommended in all cases. At least 8-bit color is needed, 24-bit color is recommended. On systems without 3-D hardware rendering is done in software with the Mesa library. 3-D graphics hardware is highly recommended. The size of your memory determines the size of data set you can visualize. You should have two bytes of memory for each point in your data set in order to have maximum interactivity. However, you can visualize larger data sets with reduced interactivity. >Is the older version (4.3) of vis5d supported on Linux Not directly by us. Since the Vis5D web page says it should work, I am assuming that someone at SSEC has tested it; I have not. >and if so, would this work with McIdas 7.6? It should, but, again, I have not tried to. >Is it possible to get version 5.0 working on Linux? I am pretty sure given the slowness of the hardware listed in the Linux line from the Vis5D web page, that Vis5D has been supported on Linux for a reasonably long period of time. Please pay attention to the need to use the Mesa library if your machine doesn't support 3-D hardware rendering. >I also had a question about redirections in McIdas. Is there a way to >setup redirections so that McIdas will first look in the user's >mcidas/data director for *.ET and *.ST before looking in ~mcidas/data but >have these files available from either location? REDIRECTions are pointers to specific places, so the direct answer to your question is no. The McIDAS MCPATH construct, which works in conjunction with REDIRECTions, does what you want up to a point. >We'd like to have all of >the default files available but allow users to create their own tables >without writing to the mcidas installation directories. It has always been my recommendation that users creating new enhancements or stretch tables name them something different than the ones that are distributed with Unidata McIDAS-X. For instance, if a user wanted to alter the IMAGE.ET enhancement, then s/he should call her/his MYIMAGE.ET or something similar. If the setup for your users follows the EXAMPLE.NAM examples that we send out in Unidata McIDAS-X, then there are no REDIRECTions for either enhancments or stretch tables. Since there are none, then the list of directories defined in the user's MCPATH is searched when trying to find the enhancement/stretch. This is the functionality that you are looking for, so all you have to make sure of is: o each user has no REDIRECTions for enhancements or stretch tables o each user names their enhancements and stretches differently than the ones included in the distribution For instance, suppose I am a user named tom whose home directory is /home/tom. In order to use McIDAS-X, I should have had the following directory created for me: /home/tom/mcidas/data This directory is what is used in my .cshrc file (or .profile or .kshrc if using the Bourne or Korn shells, respectively) to define MCDATA: setenv MCDATA /home/tom/mcidas/data My .cshrc MCPATH definition is based on the definition of MCDATA: setenv MCPATH ${MCDATA}:/home/mcidas/data:/home/mcidas/help Assuming that I have not added a REDIRECTion for any enhancement, then when I load an image using something like: IMGDISP RTIMAGES/GE-IR STA=KBOS EU=IMAGE SF=YES REFRESH='EG;MAP H' McIDAS will search the following directories _in order_ for IMAGE.ET: /home/tom/mcidas/data /home/mcidas/data /home/mcidas/help If IMAGE.ET is not found, an error message will be issued by IMGDISP. Since IMAGE.ET is one of the enhancements distributed with Unidata McIDAS, it will be found in /home/mcidas/data. If I want to create my own image enhancement, I should call it something other than IMAGE.ET. When manipualting it, it will be written in the first writable directory in my MCPATH _UNLESS_ some other directory in my MCPATH has an file of the same name. If another directory has a file of the same name, my McIDAS session will try to modify it if I am attemping to create/change the enhancement. If your 'mcidas' account is setup according to our recommendations, the /home/mcidas/data and /home/mcidas/help directories will NOT be writable by 'tom' or any other user (except 'ldm' and 'mcadde'). In this case, the write will fail and the enhancement will not be changed. If I am writing to an enhancement that does not yet exist, it will be created in my /home/tom/mcidas/data directory. This is exactly what you are looking for. Please don't get fooled into thinking that you can copy an enhancement from the /home/mcidas/data directory to the user's ~/mcidas/data directory and expect things to work correctly. This would work _until_ the user deletes the enhancement. In this case his/her enhancement will be deleted since it will be found in a MCPATH directory before the ones for McIDAS-X; so far so good. After that, any attempted modifications would fail because McIDAS would once again be looking to update the file in /home/mcidas/data. This would be extremely confusing for the user and cause you support problems since they will be asking you what is going on :o. >Thanks. One last comment regarding REDIRECTions and MCPATH. REDIRECTions take precedence over the user of MCPATH. If you have a REDIRECTion to a file, then McIDAS will always attempt to read/write/use it each time the file is referenced. In this way, one _could_ have enhancements and stretch tables of the same name as the ones in the distribution. I don't recommend this _unless_ the user really knows what s/he is doing in McIDAS. >Mark Tucker >Information Technology >Lyndon State College >address@hidden Tom