[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[McIDAS #JUT-731693]: Cannot generate composite RTIMAGES/GEW-IRTOPO and POINTS
- Subject: [McIDAS #JUT-731693]: Cannot generate composite RTIMAGES/GEW-IRTOPO and POINTS
- Date: Tue, 21 Apr 2009 12:38:14 -0600
Hi Marty,
re: follow-up to tweaks on cldbz1.usurf.usu.edu
> Question: Did you copy ~mcidas/data/SCHEMA over to ~ldm/data/mcidas?
Yes, exactly. The decoders in McIDAS can find the file via the
McIDAS MCPATH or REDIRECT constructs, but the ldm-mcidas decoders
(proftomd, nldn2md) can not as they expect SCHEMA to exist in the
directory in which they write their output MD files.
re:
> It was more of a political decision for us to move to SunOS for this project.
> We use Sun Servers for all our major projects and so to be consistent they
> wanted
> us to move back to Sun. Thanks for finding this.
This was my programming naivety that got embodied in the version of
the ldm-mcidas decoders you are using (i.e., my bad). My other
mistake was in including a '-f' flag in the first line of Bourne
shell scripts (e.g., '#!/bin/sh -f'). I corrected both of these
mistakes in the scripts that had them on your machine.
re: I added REDIRECTs for MDXX00[789]* in the $MCDATA/LWPATH.NAM file
in the 'mcidas' account
> I will read up more about the REDIRECTs in LWPATH.NAM. I look forward to
> coming
> to the training as well.
REDIRECTions are a bit difficult for new users to get their heads around.
Here is the 10 cent description:
MCPATH is a colon-separated list of directories that McIDAS routines use
to find data and ancillary data files (ancillary data files are things
like enhancement tables, map outline files, etc.). MCPATH is used in
much the same way as PATH is used to find executables. The problem with
MCPATH, however, is that it has a built-in gotcha that is easily illustrated
by the following simple expample:
- suppose your MCPATH is defined as:
/home/mcidas/workdata:/home/mcidas/data:/home/mcidas/help
- this is the standard for the user 'mcidas' in Unidata McIDAS
- the directories are used from left to right
McIDAS will read a file in the first MCPATH directory in which
it has read permission and it will try to write a new file in
the first directory in which it has write permission. It will
attempt to write to an existing file in whatever directory
it first finds it.
- next suppose that you have copied the file AREA0001 to both the
/home/mcidas/workdata and /home/mcidas/data directories
- if you run the McIDAS DMAP command for AREA0001, it will list
the copy in the /home/mcidas/workdata directory. So far so
good.
- if you delete the file (e.g., LWU DEL AREA0001 in McIDAS), you
might expect that the file would be dead and gone.
That this is not true is illustrated by rerunning the DMAP
command. This time DMAP will indicate that the file exists
in the /home/mcidas/data directory (which it is).
The problem with this kind of situation (there are many more
more complicated examples) is that you can not be guaranteed
that you are reading or writing a particular file in the location
you expect/want. REDIRECTions solve that problem by allowing
the user to specify exactly where a file/files whose name matches
a regular expression resides ** even if the file does not exist**.
This allows a user to specify that s/he wants to write to a particular
file in a specific location.
The thing that you have to remember when using the combination of
MCPATH and REDIRECT is that REDIRECTions take precedence over
MCPATH.
re: your ~ldm/etc/pqact.conf actions for processing FNEXRAD images
will not result in the McIDAS routing table being updated
> Hmmm, I have looked over our pqact.conf file. I guess I do not understand
> this.
> I have the following in my pqact.conf file and it looks like it should work.
>
> FNEXRAD ^pnga2area Q5 (RL) (.*) (.*) (.*) (.*) (........) (....)
> PIPE -close
> pnga2area -vl logs/ldm-mcidas.log
> -a etc/SATANNOT
> -b etc/SATBAND
> data/gempak/nexrad/NEXRCOMP/6KN0R-NAT/\4_\6_\7
>
> # NEXRCOMP 10 km National RCM mosaic
> FNEXRAD ^pnga2area Q5 (RN) (.*) (.*) (.*) (.*) (........) (....)
> PIPE -close
> pnga2area -vl logs/ldm-mcidas.log
> -a etc/SATANNOT
> -b etc/SATBAND
> data/gempak/nexrad/NEXRCOMP/10KRCM-NAT/\4_\6_\7
These actions will work fine. Its just that they do not specify the
use of the McIDAS routing table for managing the output name space.
Instead, both actions specifically tell the ldm-mcidas decoder, pnga2area,
how to name the output files.
> Do I need to put the output into a different directory?
No, not at all. In fact, I would strongly recommend that you not
switch these actions to ones using the McIDAS routing table. The
reasons for my recommendation are a bit long and involved, but
suffice it to say that the routing table concept is not what folks
use in most cases today. It is still used for the images that
ones wants to composite because it gives the user additional
freedom to easily turn compositing on or off by simply changing
an entry in the routing table.
> I will try to dig a bit here as well.
I would not concern myself about this right now unless you are simply
interested.
re: wind profiler data was not being decoded; I added a ~ldm/etc/ldmd.conf
request to get the data from your upstream feeder machines
> These seem to be working now.
> Route.k
> U2 FSL2 hourly wind profiler default MDXX0081 09111 1613 none
> 3
> U6 FSL2 6-minute Wind profil default MDXX0091 09111 1619 none
> 3
Yup.
re: enabling the McIDAS ADDE remote server and opening up access through
your firewall for ADDE and LDM queries
> Yes, we have added firewall rules for your IP on port 112 and 388.
Thanks! I just verified that I can access your machine using the LDM
'notifyme' utility and McIDAS ADDE datasets from my workstation,
yakov.unidata.ucar.edu:
LDM 'notifyme' access:
/local/ldm% notifyme -vl- -f ANY -h cldbz1.usurf.usu.edu
Apr 21 18:32:35 notifyme[12276] NOTE: Starting Up: cldbz1.usurf.usu.edu:
20090421183235.451 TS_ENDT {{ANY, ".*"}}
Apr 21 18:32:35 notifyme[12276] NOTE: LDM-5 desired product-class:
20090421183235.451 TS_ENDT {{ANY, ".*"}}
Apr 21 18:32:35 notifyme[12276] INFO: Resolving cldbz1.usurf.usu.edu to
129.123.195.32 took 0.002576 seconds
Apr 21 18:32:35 notifyme[12276] NOTE: NOTIFYME(cldbz1.usurf.usu.edu): OK
Apr 21 18:32:38 notifyme[12276] INFO: 96 20090421183236.604 IDS|DDPLUS
134758662 SPCN41 CWAO 211829
Apr 21 18:32:38 notifyme[12276] INFO: 99 20090421183236.606 IDS|DDPLUS
134758663 SPCN41 CWAO 211828
...
McIDAS ADDE access:
DATALOC ADD RTIMAGES cldbz1.usurf.usu.edu
Group Name Server IP Address
-------------------- ----------------------------------------
RTIMAGES CLDBZ1.USURF.USU.EDU
<LOCAL-DATA> indicates that data will be accessed from the local data directory.
DATALOC -- done
IMGLIST RTIMAGES/GE-IR.-4
Image file directory listing for:RTIMAGES/GE-IR
Pos Satellite/ Date Time Center Band(s)
sensor Lat Lon
--- ------------- ------------ -------- ---- ---- ------------
66 G-12 IMG 21 APR 09111 18:15:00 0 72 4
65 G-12 IMG 21 APR 09111 17:45:00 0 72 4
64 G-12 IMG 21 APR 09111 17:15:00 0 72 4
63 G-12 IMG 21 APR 09111 16:45:00 0 72 4
62 G-12 IMG 21 APR 09111 16:15:00 0 72 4
IMGLIST: done
Things are looking good...
> Thanks again for taking a look at our setup.
No worries.
Cheers,
Tom
--
****************************************************************************
Unidata User Support UCAR Unidata Program
(303) 497-8642 P.O. Box 3000
address@hidden Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage http://www.unidata.ucar.edu
****************************************************************************
Ticket Details
===================
Ticket ID: JUT-731693
Department: Support McIDAS
Priority: Normal
Status: Closed