20010820: nvxlalo.dlm and MAKEAREA questions

>From: Darren Gallant <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200108152018.f7FKIg116523

Darren,

re: What function?

>nvxlalo.dlm

This is simply a navigation module instantiated in a subroutine.  It is
used by things like IMGDISP, MAP, etc. to know how to translate to
earth coordinates.

Your question:

>>Is this fuction designed to work within the LDM, on the Mcidas command
>>line, or on the unix command line? 

threw me off since it seemed like you were referring to a program, not
a subroutine for a program.  To answer you original question, nvxlalo.dlm
is _not_ a program, so it does not work from an LDM action or from
the McIDAS or Unix command lines.  It is a subroutine that gets linked
into any McIDAS command that has anything to do with navigation.

>How would one use makearea.k? Before our upgrade to McIDAS 7.8, I could
>copy makearea.k to a directory and run it there. The area I specified on
>the command line would be created in the same directory I ran
>./makearea.k. After the upgrade, no matter where I move makearea.k, it
>creates an area in /home/mcidas/workdata. I don't no where makearea.k is
>looking for the flat image file.

The way McIDAS programs determine where to write output files is governed
by two McIDAS concepts: file REDIRECTions and the set of directories
defined in a user's MCPATH.

A file REDIRECTion is a specification of a file name mask (regular expression)
and the directory that will always be used when reading/writing that file.

A few examples of REDIRECT invocations could look like:

REDIRECT ADD AREA1234 "/var/data/mcidas
REDIRECT ADD AREA2* "/home/mcidas/workdata
REDIRECT ADD AREA9996 "/home/gallant
etc.

The Unix environment variable MCPATH, on the other hand, contains a
colon separated list of directories that McIDAS will look through when
trying to find a file for reading or writing.  File REDIERCTion
specifications take precedence over MCPATH directories, so if you have
a REDIRECTion in place for a file name, it doesn't matter what set of
directories your MCPATH contains, the file to be read/written will
always be looked for/ created in the REDIRECT directory.

makearea.k has always used these two McIDAS facilities for locating
files.  Also, there is no need to copy makearea.k into your local
directory as this does nothing for you.

>-rw-rw-r--   1 gallant  staff    2203201 Aug 20 09:30 dycoms
> 
>./makearea.k dycoms 9996 1001 2201 0 1 0 255
>MAKEAREA - Begin
>MAKEAREA - Done 9996
>
>-rw-rw-r--   1 gallant  staff        256 Aug 20 09:06 AREA0001
-rw-rw-r--   1 gallant  staff        256 Aug 20 09:31 AREA9996
>-rw-rw-r--   1 gallant  staff        256 Aug 20 09:05 AREA9998
>Any ideas? 

The reason that your output file is not being written into your own directory
is two fold:

o your McIDAS session does not have a REDIRECTion that specifies exactly
  where to find AREA9996

o a file named AREA9996 exists in the /home/mcidas/workdata directory
  and that directory is in your MCPATH

Since you don't have a REDIRECTion for AREA9996, the MCPATH directories
will be searched for the existence of the file AREA9996.  If it is found,
then that copy will be used for reading and writing.  This would be OK
IF you were the user 'mcidas', since the /home/mcidas/workdata directory
is the default working directory for McIDAS sessions for the user 'mcidas'.
Now, if you are NOT the user 'mcidas', you have a problem: your MCPATH
is setup incorrectly.

I think you ran into a problem by unfortunately choosing an output AREA file
name that is already used by the 'mcidas' account.  If you chose a different
name, say AREA1234, you would get different results.  I am betting that
previously you were using a different AREA file name, and that is why
you did not run into any problems.

Here is what I recommend.  If you are doing the work as yourself (i.e., you
are not logged in as the user 'mcidas'), then do the following;

<login to your Unix session>
cd mcidas/data              <- you should have this directory if your account
                               is setup correctly to use McIDAS

<verify your MCPATH setting:  it should look something like:

/home/gallant/mcidas/data:/home/mcidas/data:/home/mcidas/help

(this assumes that your HOME is /home/gallant and that 'mcidas' HOME is
/home/mcidas)

If you want to always create output AREAs using MAKEAREA in the 2000 range
(AREA2000, AREA2001, ..., AREA2999), then create a REDIRECTion that will
tell your McIDAS sessions to always read/write those files in your
McIDAS working directory:

<start a McIDAS session>

REDIRECT ADD AREA2* "/home/gallant/mcidas/data

Now, when you run makearea.k (makearea.k from the Unix command line; MAKEAREA
from the McIDAS command and text window) as follows:

MAKEAREA dycoms 2000 1001 2201 0 1 0 255

The file AREA2000 will be created in the directory you specified in the
REDIRECT step above.

Tom

>From address@hidden Mon Aug 20 11:11:15 2001

Tom,

Thanks very much. After tinkering a bit with where I placed the flatimage
file, I figured out what was going on. Your email verified my conclusion. 

Thanks again.

FYI 

I have placed some more HDF files which contain lat/lon for every
line/sample in our anonymous ftp area. If your friends are still
interested, they can log into ftp.joss.ucar.edu as anonymous and cd to
/pub/download/bnl and retrieve the following HDF
files: g10.20010710.1530.dycoms.latlon.hdf and
g10.2001189.1430.dycoms.latlon.hdf. The position info is stored as floats.
g10.2001189.1430.dycoms.latlon.hdf contains high res vis, and the other
files contains low res visible and the other channels.

Thanks

Darren R. Gallant               UCAR/JOSS
Programmer/Technician           Joint OfFice Of Science Support
303-497-2634                    P.O. Box 3000
address@hidden                Boulder,CO 80307-30000

>From address@hidden Thu Aug 16 11:07:20 2001
>CC: address@hidden, address@hidden,
>   address@hidden
>Subject: Re: 20010802: Example HDF imagery files

Unidata Support wrote:

> Dave and Russ,
>
> A couple of weeks ago, you offered to take a look at imagery stored in
> an HDF file that is produced by TeraScan (tm):
>
>  Darren Gallant of UCAR/JOSS has put a few TeraScan HDF files out on an
> anonymous FTP server at JOSS for us to take a look at:
>
>
> Please let me know if you can make any sense out of any of the HDF
> files that Darren is making available.  His comments about the Seaspace
> documentation do not leave me with a warm and fuzzy feeling about being
> able to do anything easily, but perhaps we can figure something out.

I looked at one of the files and I didn't see much in the HDF file that
resembles what we need to navigate the GOES data:

http://www.ssec.wisc.edu/mug/prog_man/Current/progman-126.HTML#32013

I see 2 options at this time:

1) buy an SDI and plug it into the Terascan system..... $15,000
2) Get the navigation files from us. The NAVLIST command has a hidden
   keyword, FORM=COD, that will list out the nav parameters as a list of
   integers....it should be easy to just plug those into a McIDAS area.

You should probably check with Dee (or the Datacenter) for access.

dave