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

20040616: help on running McIDAS executables from the command line

>From: "Luis A. Lopez" <address@hidden>
>Organization: UPRM
>Keywords: 200406162151.i5GLpQtK019904 McIDAS scripting

Hi Luis,

>  Sorry I bother you so much but I need more help:

No worries.

>When I give this command into Mcidas GUI it works fine
>
>IMGDISP RTNEXRAD/N0R ID=JUA LINELE= 230 230 PLACE=C MAG= 1 1 EU=BREF SU=X
>ALL=1 SF=YES

OK, good.  Another way of doing the same thing is:

IMGDISP RTNEXRAD/N0R ID=JUA STA=JUA EU=BREF ALL=1 SF=YES

or

IMGDISP RTNEXRAD/N0R 1 ID=JUA STA=JUA EU=BREF SF=YES

The SF=YES is only needed if you want to switch to the frame after
the image is loaded.

>command line
>
>imgdisp.k RTNEXRAD/N0R ID=JUA LINELE= 230 230 PLACE=C MAG= 1 1 EU=BREF
>SU=X ALL=1 SF=YES;imgdisp.k 1 ../images/doppler/test.gif

Since your object is to create a GIF (tm) rendition of the image
that is loaded, the second command should be 'frmsave.k', not
'imgdisp.k'.

>but if I run the command from the commandline (using programs in
>mcidas/bin) and add the imgsave command, the image alwways comes empty, do
>I need to add any other parameter when running from command line??

OK, the problem you are having comes from not understanding something
about what is going behind the scenes.

Here goes:

McIDAS applications use two shared memory segments to communicate with
one another.  Part of one of the memory segments is where the display
of data is actually done.  When you run a McIDAS session and see image
displays, etc., you are actually running several McIDAS programs at the
same time.  When you display an image in a McIDAS session, IMGDISP
actually displays the image in one of the shared memory segments.  The
only reason you can see the image is that a McIDAS application called
'mcimage' is running, and it gets an event that says that the content
of the shared memory segment has changed, so it should visualize the
shared memory for the user.

The two shared memory segments used are created either by the application
'mcenv' (which is run for you when you start a McIDAS session) or by
each routine individually.  By putting together two McIDAS commands on
a single Unix command line separated with semicolons, you have not
gotten away from the fact that each McIDAS application (imgdisp.k in
your example) is creating the shared memory segments upon startup
AND destroying those segments on completion.  So, the frame represented
by the shared memory segment from the first imgdisp.k command exists
while that command is running, and then disappears when the command
exits.  The second imgdisp.k command (which should be frmsave.k) then
creates its own new shared memory segments, and there is no image
displayed in those.

Here is what you want to do:

mcenv
imgdisp.k RTNEXRAD/N0R ID=JUA STA=JUA EU=BREF
frmsave.k 1 ../images/doppler/test.gif
exit

Here, 'mcenv' creates the memory segment; imgdisp.k displays the most
recent NEXRAD Level III base reflectivity product in the only frame
that exists ('mcenv' creates a session with 1 frame by default); and
then 'frmsave.k' saves the displayed image to the file test.gif.

You can get more information on the flags supported by 'mcenv' using
the McIDAS HELP command:

help.k mcenv

Notice that 'mcenv' is in lower case.  Commands whose executables end
in ".k" would need to be capitalized:

help.k IMGDISP

'mcenv' creates a session with frame size of 480x640, number of image
colors equal to 48, and number of graphic color levels of 8.  You can
verify this from the online help, and from running a mini McIDAS
session:

mcenv
f.k
gu.k TABLE
exit

So, what I am recommending is modifying your command sequence slightly:

mcenv -c 128 -g 32 -f 1@600x800
imgdisp.k RTNEXRAD/N0R ID=JUA STA=JUA EU=BREF
map.k H
frmsave.k 1 ../images/doppler/test.gif
exit

This 'mcenv' invocation creates a single 600x800 frame that supports
128 image colors and 32 graphic colors.  I also added the MAP
invocation to draw a map on top of the image displayed.

Given the above, the construct in mcrun.sh and mcbatch.sh should start
making more sense.  For instance, here is the 'meat' of mcrun.sh:

cd $MCDATA
mcenv << EOF

# put McIDAS-X commands you want to run here, one command per line.

# Example (note that these lines are commented out!!):
#
# dataloc.k ADD RTGINI adde.unidata.ucar.edu
# imgdisp.k RTGINI/GE1KVIS STA=KMIA EU=IMAGE SF=YES REFRESH='EG;MAP H'
# frmsave.k 1 miamivis.gif

# done
exit

'mcenv' is run to create a session in which multiple applications
can be run one after the other.

Last comment: notice that you must always exit the 'mcenv' session.

Running 'mcenv' is like running a new invocation of a shell from the
Unix command line.  If your default shell is the C Shell, then your
~/.cshrc file will be sourced upon setup.  This is the reason that the
installation instructions for the user 'mcidas' have you create the
following construct in .cshrc:

   # C-shell environment variable definitions for the user 'mcidas'
   
   # umask
   umask 002
   
   # MCHOME and McINST_ROOT
   setenv MCHOME $HOME
   setenv McINST_ROOT $MCHOME
   
   # NOTE: conditional definition is only needed for C-shell users
   if ( ! ${?MCPATH} ) then
     setenv MCDATA $MCHOME/workdata
     setenv MCPATH ${MCDATA}:$MCHOME/data:$MCHOME/help
     setenv MCGUI  $MCHOME/bin
     setenv MCTABLE_READ "${MCDATA}/MCTABLE.TXT;$MCHOME/data/ADDESITE.TXT"
     setenv MCTABLE_WRITE "$MCHOME/data/ADDESITE.TXT"
     setenv XCD_disp_file $MCDATA/DECOSTAT.DAT
     if ( ! ${?path} ) then
       set path=${MCGUI}
     else
       set path=(${MCGUI} $path)
     endif
   endif
   
   # Limit ADDE transfers to compressed ones
   setenv MCCOMPRESS TRUE
   
   # CD to the McIDAS working directory
   cd $MCDATA

The 'if' construct prevents MCDATA, MCPATH, etc. from being redefined
once MCPATH has been defined.  The reason for this is that your MCPATH
environment setting actually gets modified when you run 'mcenv'.  The
modification is that a new directory is appended to the end of MCPATH,
the directory is a subdirectory of the ~/.mctmp directory.  To get a
feeling for what is going on, try the following:

echo $MCPATH

mcenv
echo $MCPATH
exit

If the 'if' construct was not guarding against redefining MCPATH, the
~/.mctmp/... subdirectory appended to the end of MCPATH would disappear
and there would be bad, hard to understand consequences.

>Thank you for your support.

No worries.  You are at a disadvantage since you have not attended a
workshop where the concepts that we have been talking about in the past
couple/few emails are explained.  The good news is that once you get a
feeling for what is going on behind the scenes you will be able to
create quite complex and appealing displays easily.

Cheers,

Tom
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically 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.