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

20050211: GeoTIFF output from McIDAS ADDE server (cont.)

>From: address@hidden
>Organization: GMU
>Keywords: 200501201830.j0KIUJv2013893 McIDAS AREA GeoTIFF ADDE

Hi Ying,

Sorry I couldn't get to your inquiry before now...

>I can manually generate tif file by typing:
>sh mcrun.sh

First, please rename your script to something other than 'mcrun.sh'.
You will appreciate this in the future if your work gets lost during an
upgrade of your McIDAS installation.

Second, are you logging the messages from the McIDAS commands to a
file?

>but when I insert the converting script into pqact.conf, no tif file is
>generated although GOES data is continuously downloaded under
>gempak/image/sat/...

Two things here:

- if you are logging the output from the McIDAS commands, you should
  be able to see where things are failing

- second, McIDAS' access to the data files is indirect -- it is through
  ADDE and an ADDE dataset that has been defined to identify sets
  of files as being part of a dataset

One thing you did not say is who you were running the script as.
If you are running as the user running your LDM, I would expect that
the script would work when executed from a pqact.conf action in the
same way as it does when run from the command line.  This assumes
that the set of environment variables being used in both instances
are the same.

>In pqact.conf, I wrote as below:
>
># Vis (0.65um) image
>MCIDAS  ^pnga2area Q1 (U[^ACXY1]) (.*) (.*)_IMG (0.65)um (.*) (........) (....
> )
>        PIPE    -close
>        pnga2area -vl /usr/local/ldm/data/gempak/logs/ldm-mcidas.log
>        /usr/local/ldm/data/gempak/images/sat/\3/\5/VIS/VIS_\6_\7
>
># Convert UNWISC GOES-East VIsible images to GeoTIFF
>MCIDAS  ^pnga2area Q.(UV) (.*) (.*)_IMG (0.65)um (.*) (........) (....)
>        EXEC    "/bin/bash /usr/local/ldm/mcrun.sh"

The second action will be run as the user running the LDM (presumably 'ldm').

mcrun.sh is setup to use information defined in for the user that is
running it.  Given this, ADDE dataset definitions would need to be
setup in the 'ldm' account _if_ data access for the various sets like
RTIMAGES is through LOCAL-DATA, or, there would need to be a "pointing"
(DATALOC) to an ADDE server that has the data.  This can be the local
machine but the remote ADDE server access would have to have been setup
first.

By the way, the difference between locally defined datasets and access
to datasets through the remote ADDE server is _the_ concept that new
McIDAS users seem to have the most problem with.

Here is how to check your setup:

<as 'ldm'>

cd mcidas/data
dataloc.k LIST RTIMAGES

If the DATALOC listing comes back looking like:


Group Name                    Server IP Address
--------------------         ----------------------------------------
RTIMAGES                     <LOCAL-DATA>

<LOCAL-DATA> indicates that data will be accessed from the local data directory.
DATALOC -- done


it means that you would have had to define the datasets in the 'ldm'
account for the data files to be found.  The fact that you defined
them in the 'mcidas' account will not make any difference here.

If the listing comes back looking like:

Group Name                    Server IP Address
--------------------         ----------------------------------------
RTIMAGES                     ATM.GEO.NSF.GOV

<LOCAL-DATA> indicates that data will be accessed from the local data directory.
DATALOC -- done


** substitute your machine name for ATM.GEO.NSF.GOV in your interpretation **

it means that you are trying to get the data through the remote ADDE
interface on your machine.

So, the question at hand is exactly how you are trying to access the
RTIMAGES dataset?

>I doubt something wrong with the EXEC line. But I can not find it even
>after I specified the absolute path~~

I don't think that there is nothing wrong with the pqact.conf EXEC line.
I believe that the problem is that you are trying to access a
dataset that has not been defined for the user you are running as, 'ldm'.

Here is my recommendation:

1) make sure that the remote ADDE server is configured on your machine
   (instructions in the McIDAS web pages):

<as 'root'>
cd ~mcidas
sh ./mcinet2004.sh install mcadde   <- assumes that 'mcadde' user has been
                                       setup:

                                       - in the same group as 'mcidas'
                                       - has the same HOME directory as
                                         'mcidas'
                                       - is not a login account

<as 'mcidas'>
cd ~mcidas
cp admin/mcadde_env.ksh .mcenv
<edit .mcenv and make any changes that are needed to match your setup>

<as 'root'>

make sure that your firewall allows access to ports 112, 500, and 503

<as 'ldm'>

<define environment variables needed by 'mcidas' on the command line
(I recommend to not put these in your SHELL definition file (e.g., .cshrc
for C shell; .bash_profile for bash; etc.)

make the needed environment variables active in your shell

cd ~ldm/mcidas/data
dataloc.k ADD RTIMAGES fully_qualified_name_of your_ADDE_remote_server
batch.k MYDATA.BAT     <- define the MYDATA dataset in the 'ldm' account

** verify that 'ldm' can see the datasets:

dsinfo.k I RTIMAGES
imglist.k RTIMAGES/GE-VIS
 etc.

>Thanks a lot!

No worries.  The problems you are running into are characteristic of
one that has not had the opportunity of setting in on a McIDAS training
workshop.  Given this, a number of the concepts that tie things together
will be unknown to you or will seem very strange.  A little practice,
however, should result in a sudden realizatoin of how things work.
After that, getting things accomplished will become easy.

If you still can't get things to work I am more than happy to logon
to your system and setup things.  For this, I would need logins
as 'mcidas', 'ldm', and possibly 'root' (to setup the remote ADDE
server).  The part needed to be done by 'root' could be detailed
for someone there to do after looking around.

Cheers,

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.