>From: Sridharareddy Duggireddy <address@hidden> >Organization: USF >Keywords: 200210162107.g9GL7S107707 McIDAS web cgi-bin IMGDISP FRMSAVE Sridhara, > Thank you very much for your cooperation. I have understood your >scripts. But i have some doubts. They are > >what will MCTABLE_WRITE and MCTABLE_READ do in mcidas? MCTABLE_READ defines a list of McIDAS client routing table files to use to determine which ADDE server will be used to fulfill a data request. When you do a DATALOC LIST in McIDAS, the files in MCTABLE_READ are searched to give you the dataset/machine name pairs you have defined in your session. I setup MCTABLE_READ to first use .../htdocs/sridhara/mcidas/data/MCTABLE.TXT and then /home/mcidas/data/ADDESITE.TXT. This setup follows the McIDAS installation instructions detailed in: Unidata McIDAS-X HomePage http://my.unidata.ucar.edu/content/software/mcidas/index.html | |_Installation and Configuration Version 2002 http://my.unidata.ucar.edu/content/software/mcidas/2002/mcidas-x.html | |_Configuring Accounts http://www.unidata.ucar.edu/packages/mcidas/2002/mcx/config_mcx.html | |_Configure User Accounts http://www.unidata.ucar.edu/packages/mcidas/2002/mcx/config_users.html >In gen_mcidas_sat.csh > >what WILL "EU=IMAGE" AND "EU=H20" do to the mcidas image? The logic in gen_mcidas_sat.csh (adopted virtually in tact from the examples that Jim Koermer provided) look at the ADDE dataset name to see if the image is likely to be a Water Vapor (WV) image or not. If the image is a Water Vapor image, then the H2O.ET enhancement is used in the image display. Otherwise, the IMAGE.ET enhancement is used. The reason that there is a difference is that the information in water vapor images is contained in a much smaller brightness range than for IR or VIS images. The H2O.ET enhancement "colorizes" the water vapor images to bring out the features in that smaller range of brightnesses. >what will "SU=IRTEMP" and "SU=H20TEMP" do to the mcidas image? The selection of a stretch table (SU=) was done for the labeling of the images with the BAR command. If you play around with the display created from the web page, you will see that the data BAR on the right hand side shows different units for the different kinds of images, VIS, IR, and WV. >In the last lines you wrote the following code > > if(-e num_maps) then > set num=`cat num_maps` > @num+=1 > else > set num=1 > echo $ num > num_maps > >what did the above code do? This is code that Jim included in his example. It appears to be a counter for how many times the page was accessed (the count is incremented each time a GIF (tm) file is created). I left this in the script for you to use or ignore as you see fit. >you have created the user nobody. I did not create the user 'nobody'. 'nobody' was already a user. It is the user that is running the web server. >where have you created this user i mean under which directory? You should talk with Shelly about 'nobody'. It is not a login account, and its HOME directory is the same as for 'root', '/'. >Is it necessary to place mk_mcsat under ..sridhara/mcidas/bin? No. This file can be put anywhere you like AS LONG AS it is in a directory that has at least read and execute privilege for the user 'nobody'. >in mk_mcsat what will be the value in $HOME? HOME will be inherited from its setting in gen_mcidas_sat.csh. I set HOME to tell McIDAS to create its temporary directory in /usr/local/apps/php-apache/htdocs/sridhara/mcidas. If you CD to that directory and do a long list ('ls -alt'), you will see a directory called .mctmp. Each time McIDAS is run (and it is run each time a user asks for the creation of a display of an image and its subsequent save into a GIF file), it (McIDAS) creates a subdirectory under .mctmp. In this subdirectory, it creates a few files that are used for the duration of that invocation of McIDAS. When McIDAS exits (after the 'mcenv' invocation is over), the temporary directory under .mctmp and all of the files in that directory are removed. The way you had things setup, the .mctmp directory was located in '/' and it was owned by 'root'. What was needed was to consolidate all of the things that were happening into a single directory/directory hierarchy that is owned by 'nobody'. The way things were setup did not follow this, and this was on of the problems being encountered that prevented things from working. >Thank You, No worries. Tom
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.