[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20030808: McIDAS v7.8 program FILTER and '-c' support in mcidas (cont.)

>From: "Fingerhut, William A" <address@hidden>
>Organization: Lyndon State
>Keywords: 200308041935.h74JZXLd009839 McIDAS FILTER sunset

Hi Bill,

Sorry I couldn't get to this before today, but I was out mountain biking
and hiking for 6 days.

>> >While checking out my old scripts on Mcidas 2002, I noticed that the 
>> >FILTER command is gone. It could filter 2-D grids.
>> The sunset for FILTER was announced in the Program Sunset 
>> Information page under Hot Topics for Unidata McIDAS v2002:
>> http://www.unidata.ucar.edu/packages/mcidas/2002/mcx/sunset.html

re: sunset of FILTER

>I followed the links to Installation and Configuration --> Release
>Notes --> Core Software Changes. I did not find FILTER in the list of
>deleted commands. Now I see it under Hot Topics.

Right you are.  Having the information in two places was bad in that
it made me have to remember to update listings in two places.  I think
I will modify the v2003 Release Notes page to contain a link ot the
Sunset page.  This way I will only have to update the information in
a single location.

>> If you still want to use FILTER, its source is still included 
>> in the distribution as are the actions that can be used to 
>> build its executable. Here are a couple of snippits from the 
>> v2003 makefile:

>I have been using a script to 'add' my programs to Mcidas. If it still
>works, I could use it ???

Sure.  I only suggested creating a Makefile structure to make things
easier for you in the long run.  The hierarchy that I setup for UVa

                              /\    \
                             /  \    \
                            /    \    data bin workdata savedata
                           /      \
                        mcidas   mcidas200x
                         /          \
                        /            \
                 src data bin      src data

The user Makefile is put in ~mcidas/mcidas/src along with program sources.
The executables built from the user sources is put in ~mcidas/mcidas/bin.
User ancillary data files are put in ~mcidas/mcidas/data.

With this structure, the 'mcidas' user has to modify his/her MCPATH:





Also, the PATH for the user needs to be changed so that the $MCHOME/mcidas/bin
directory comes before $MCHOME/bin (aka $MCGUI).

>--- script ---
># Script file to test a Mcidas program
>if( $1 == "" ) then
>  echo You must supply a program name.
>  echo
>  echo Usage is: "testmcipgm PROGRAM"
>  echo
>  echo Exiting....
>  exit
>vi $1.pgm
>rm $1.o
>rm t$1.k
>mccomp -c -I. -I/usr/local/mcidas/inc $1.pgm
>mccomp /usr/local/mcidas/lib/main.o $1.o -L/usr/local/mcidas/lib/
>-lmcidas -o t$1.k
>ls -l t$1.k
>--- end script ---
>I may have to update a path, and move the .k file, but otherwise, 
>is this approach still valid ?

Yes, this approach is still valid.  The idea behind the Makefile
structure is that your code will always be found in the ~mcidas/mcidas/src
directory.  It will not be affected by installation of a new version
of McIDAS.

re: the main reason you/Mark asked
about 'mcidas' vs >'mcidasx' was because you wanted to run a series of
McIDAS commands upon startup.  If 
>this is the only thing you were looking

>Yes, we wanted to run -c 'BATCH "STARTUP.BAT'
>(I think that's the correct syntax). This would be wonderful !

I added this into the first McIDAS addendum.  Since very few sites had
downloaded v2003 before this addition, I did not announce the addendum.
You can upgrade your v2003 installation easily as follows:

<logon as 'mcidas'>

cd mcidas2003
mkdir update
cd update

ftp ftp.unidata.ucar.edu
  <user> umcidas
  <pass> XXXXXX
  cd unix/2003/bugfix
  get mcunpack
  get mcupdate.tar.Z

chmod +x mcupdate
cd ../src
make all              <- however you made v2003 to begin with
make install.all      <- ditto

Please let me know if you run into any snags.


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.